Synopsis
Treat every generated command, script, and configuration as an untrusted draft. An operations prompt identifies the system, current state, evidence, scope, safety limits, rollback path, and verification method.
Do not paste credentials, private keys, customer data, or unrestricted production logs into a hosted service. Redact sensitive fields while preserving the structure needed for diagnosis.
Record the system state
State the facts that determine command and configuration behavior:
- Operating system and release
- Architecture and package source
- Service and tool versions
- Shell and privilege level
- Relevant configuration and recent changes
- Exact error messages, logs, and timestamps
- Production, staging, test, or local scope
Do not ask for a command before establishing the target environment. A command valid on one operating system or release can be ineffective or destructive on another.
Separate diagnosis from change
Request read-only inspection first.
Diagnose why nginx fails to start on Debian 13.
Use only the attached service status, journal excerpt, and configuration.
List the evidence for each finding.
Return read-only inspection commands only.
Do not propose a change yet.
Confirm the diagnosis before requesting a modification. Do not let a proposed fix become evidence that the diagnosis was correct.
Bound the change
Name the files, services, hosts, and actions that are in scope. State prohibited actions explicitly.
Propose the smallest change to restore this service.
Modify only /etc/nginx/sites-enabled/app.conf.
Do not restart the service, change firewall rules, install packages, or delete files.
Return a unified diff and explain each changed directive.
Generated output does not authorize execution. Apply changes only through the normal review and change-control process.
Require rollback and verification
Every state-changing procedure needs a rollback condition and a result check.
Write a change plan with these sections:
Preconditions, Read-only checks, Change, Verification, Rollback, and Stop conditions.
Explain what each command reads or changes.
Mark destructive or irreversible operations with WARNING.
A backup is useful only when its contents and restoration procedure have been tested. A service start is not proof that the application works. Define an application-level check when possible.
Review generated commands
Before execution, check:
- Command names and options against the installed manual pages
- Quoting, glob expansion, redirection, and variable values
- Paths, hosts, namespaces, accounts, and regions
- Privilege requirements and ownership changes
- Effects on data, processes, network access, and dependent services
- Idempotency and behavior after partial failure
- Availability of a dry-run or read-only mode
Resolve variables and globs before reviewing a destructive command. Avoid copying a generated command that identifies its target through an unverified substitution.
Example troubleshooting prompt
OpenBSD 7.8 amd64 runs httpd from the base system.
The service stopped accepting connections after the attached configuration change.
The configuration, rcctl output, and relevant log lines follow.
Identify the first confirmed failure.
Quote the evidence from the supplied material.
Use OpenBSD 7.8 manual-page syntax.
Return read-only checks before any proposed edit.
For a proposed edit, provide a diff, verification steps, rollback steps, and stop conditions.
Do not run commands or assume access to the host.
Verification checklist
Before approving a procedure, confirm that:
- The target system and versions are explicit
- The diagnosis is supported by supplied evidence
- Read-only checks precede state changes
- Commands identify exact targets
- Destructive effects are visible
- Rollback is possible and described
- Stop conditions prevent continued execution after unexpected results
- Verification covers both service state and application behavior
- Current primary documentation supports the command syntax