arthai-marketplace

/qa-incident

Manually create a QA incident from a known issue.

Synopsis

/qa-incident [description]

When to use it

A bug reached production (or a user) without being caught, log it so future QA runs target that area
You know about an issue you aren’t fixing right now, but want the QA system to remember it
Not for: actually fixing the bug, that’s /fix, which writes its own incident record automatically; or reviewing the knowledge base, that’s /qa-learn

Quickstart

/qa-incident admin page crashes when user has no sessions

What you’ll see: a few clarifying questions (severity, affected files, root cause if known), then a confirmation: “Incident logged. Next /qa run will generate a regression test targeting this issue.”

Examples

/qa-incident admin page crashes when user has no sessions
/qa-incident credit balance goes negative under concurrent checkout
/qa-incident                # no description — you'll be prompted for one

What it does

Parses the description from your argument; if you provided none, it asks you to describe the issue first.
Asks clarifying questions, severity (high / medium / low), affected files if known, and root cause if known (user-confirmation checkpoint).
Creates the incident file at .claude/qa-knowledge/incidents/{date}-{slug}.md with status: uncovered, the root cause (or “To be investigated”), how QA missed it, and a regression-test recommendation. The knowledge-base directory is created automatically if it doesn’t exist yet.
Confirms, the next /qa run reads uncovered incidents and generates a regression test targeting the issue.

Auto-logging from escalation (not manual)

There is also a separate, fully automatic path, you never invoke this yourself. When another workflow resolves an error after the escalation guard tripped (3+ consecutive failures in a row), the resolution is auto-logged as a distinct incident at .claude/qa-knowledge/incidents/{date}-escalation-{slug}.md, with status: covered and type: escalation-resolution (vs. status: uncovered for manually-created incidents above). It records what was tried and failed, the actual root cause, the fix applied, and search keywords, so future sessions find the fix instead of repeating the same debugging journey. This is why you may see both uncovered and covered incidents in the directory: uncovered means “log it, /qa will write a test”; covered means “already resolved, kept as a searchable record.”

Output & artifacts

.claude/qa-knowledge/incidents/{date}-{slug}.md, the incident record (status: uncovered until a regression test covers it)
.claude/qa-knowledge/incidents/{date}-escalation-{slug}.md, auto-logged escalation-resolution records (status: covered), created only by the auto-logging path above, not by manual /qa-incident runs
.claude/qa-knowledge/bug-patterns.md, updated only by the auto-logging path, when an escalation resolution represents a new recurring pattern
Picked up by /qa on later runs, it reads uncovered incidents and generates a regression test targeting each one

Troubleshooting

Problem	Fix
Invoked with no description	You’ll be prompted: describe the issue in a sentence (e.g. “admin page crashes when user has no sessions”)
`.claude/qa-knowledge/` doesn’t exist	Created automatically: no setup needed
Incident logged but `/qa` didn’t test it	Make sure the next QA run touches the affected area: incidents inform scenario generation for relevant changes

/qa, consumes incidents to generate targeted regression scenarios
/qa-learn, review incident counts, coverage status, and prune stale entries
/fix, the formal fix pipeline, which logs its own incident records on completion
QA Guide, how the QA knowledge base feeds the self-improving loop