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