Success Criteria Generator

Plans say what to build. Success criteria say how to know it's built correctly. This skill reads any plan, spec, or task list and produces a structured YAML checklist where every item is either automatically testable (run a command, check the output) or code-auditable (read specific files, verify specific logic).

The output format is designed to feed directly into the QA checklist loop (self-loop, or a continuation-enforcing loop plugin when one is enabled), which iterates until all checks pass.

AI / LLM / agent features: this skill produces the deterministic definition of done. If the feature has a probabilistic surface (an LLM call, an agent, generation, or recommendation), hand off to /ai-done after this checklist exists. /ai-done reuses this checklist as its deterministic layer (L1) and adds the eval bands, failure-triage playbook, tripwires + rehearsed rollback, and post-ship loop that deterministic checks cannot cover.

Why This Matters

Bad success criteria are the root cause of QA loops that never close. If criteria are vague ("app works well"), subjective ("UI looks good"), or incomplete (missing edge cases), the QA agent has no clear target. Every iteration becomes a judgment call, and judgment calls are where drift happens.

Good success criteria are:

• Specific: "GET /health returns HTTP 200" not "API works"
• Measurable: A command you can run, a file you can read, a condition you can check
• Complete: Covers every requirement in the plan, not just the obvious ones
• Independent: Each check can pass or fail on its own

Reactive Triggers (run WITHOUT being asked)