Give Autohand Code logs, a stack trace, or user report and ask it to find the likely failing path before patching.
Start from the symptom and trace the runtime path
Incident response Delivery and operations Operate Analysis
autohand -p "Trace this production bug from the report to the code path and propose a fix"
A root-cause summary, patch, and focused verification path.
Investigate a production bug with Autohand Code is an incident workflow that starts from a production symptom, traces route, data, deploy, and state paths, then proposes a minimal fix and verification plan. ### At a glance | Question | Answer | | --- | --- | | Best for | route failures, bad data paths, regressions, logs, stack traces, and behavior that only appears in production | | Primary inputs | Exact error, URL, account shape, timestamp, or stack trace; Recent deploys, feature flags, and environment differences; Hotfix scope, rollback options, and production-check constraints | | Autohand Code returns | A root-cause summary, patch, and focused verification path. | | Avoid when | there is no symptom, timestamp, affected account, log, or reproducible signal | ### How Autohand Code handles this workflow 1. Connects the report to route handlers, state, data stores, and recent changes. 2. Separates confirmed evidence from hypotheses. 3. Proposes the smallest fix that explains the observed symptom. 4. Names focused verification plus production checks after deploy. ### Best inputs - Exact error, URL, account shape, timestamp, or stack trace - Recent deploys, feature flags, and environment differences - Hotfix scope, rollback options, and production-check constraints ### Strong prompt autohand -p "Trace this production bug from the report to the code path and propose a fix" ### Autohand Code CLI options - Run `autohand -p "Trace this production bug from report to code and propose a fix"` with logs, URL, timestamp, and deploy context. - When `slash_goal` is enabled, use `/goal <incident objective>` when the investigation needs trace, patch, verification, and post-deploy checks in one thread. - Use `--add-dir` when the incident crosses web, API, worker, or infra repositories. ### Review before accepting A strong incident answer includes root cause, evidence, patch scope, verification command, and what to watch after release. ### Source and validation signals Autohand AI maintains this workflow as first-party product guidance for Autohand Code. Use the [Autohand CLI Playbook](https://github.com/autohandai/code-cli/blob/main/docs/AUTOHAND_PLAYBOOK.md), [CLI reference](/docs/working-with-autohand-code/cli-reference.html), and [configuration reference](https://github.com/autohandai/code-cli/blob/main/docs/config-reference.md) when choosing between interactive mode, command mode, auto-mode, feature-enabled /goal, /settings, skills, MCP, and permission settings. The related resources below link to product docs and tutorials for the workflow, and the final answer should name repository-specific files, commands, outputs, or docs that a reviewer can verify. ### Frequently asked questions ### What is Investigate a production bug with Autohand Code? Investigate a production bug with Autohand Code is an incident workflow that starts from a production symptom, traces route, data, deploy, and state paths, then proposes a minimal fix and verification plan. ### When should a team use Investigate a production bug? Use it when fixing the wrong layer would create more risk than tracing first. ### What evidence should reviewers check for Investigate a production bug? A strong incident answer includes root cause, evidence, patch scope, verification command, and what to watch after release.
Guide Incident Response Trace production symptoms back to code, data, and deploy context. /docs/guides/sre/incident-response.html Guide Observability Integration Bring telemetry, logs, and runtime signals into an investigation. /docs/guides/sre/observability.html Guide Runbook Automation Capture repeatable incident steps as agent-assisted runbooks. /docs/guides/sre/runbook-automation.html