qa

QA — independent quality discipline

Seed a QA pass onto the guild board. QA is a discipline that produces work, not a step in the feature chain: the qa-strategist plans risk-based coverage, the qa-tester runs the actual product and authors end-to-end regression specs, and any defect is filed back as a developer fix task paired with a re-verify qa-tester task that empirically confirms the fix.

QA's two durable outputs are board rows. The strategist writes the risk map as coverage rows; the tester files defects as bug rows and stamps the areas it drove. That is what puts QA's work in v_brief, in the dashboard's Bugs and Coverage views, and in reach of a cadence. .guild/qa/ still holds the charter, the missions, the session logs and the regression manifest — the thinking, not the records.

Three skills carry the detail; load what you need:

• guild:warehouse — how to write SQL against the board at all. Load it first.
• guild:qa-mindset — the discipline (pillars, what-if catalog, hybrid oracle)
• guild:qa-artifacts — which output is a row, which is prose, and the exact SQL for each

Step 1 — is there a guild

export PATH="$HOME/.turso:$PATH"
DB=.guild/guild.db
[ -f .guild/config.yaml ] || echo "no guild here"
q() { printf '%s\n' "$1" | tursodb -q -m list "$DB"; }

-m list, always — the default pretty mode truncates long values with an ellipsis, and a clipped requirement body is a QA pass planned against the wrong oracle.

Not found:

No guild found. Run /guild:check-in to initialize first.

Stop here.

Step 2 — ensure the QA workspace

mkdir -p .guild/qa/missions .guild/qa/sessions

Step 3 — scope and mode

• scope — product (a full pass) or a named area/flow. If absent, ask: What should QA cover? ("product" for a full pass, or a flow like "checkout")
• mode — full (default) or cadence.

Step 4 — the standing QA umbrella requirement

QA tasks anchor to a requirement, and there is one evergreen umbrella reused across every pass. Look for it before creating it: