Agent Skills
› sgharlow/claude-code-recipes
› qc-checklist
qc-checklist
GitHub将流程描述转化为可执行的二进制质量控制清单，包含关键与常规分级、验收标准及故障模式分析。适用于标准化审查、定义验收条件或解决因人员差异导致的质量波动问题。
Trigger Scenarios
构建质量检查清单
标准化X的审查方式
流程的验收标准
Install
npx skills add sgharlow/claude-code-recipes --skill qc-checklist -g -y
SKILL.md
Frontmatter
{
"name": "qc-checklist",
"description": "Turn a process description into an operational quality-control checklist — binary pass\/fail checks, acceptance criteria, critical-vs-routine tiers, and failure modes with catch-points. Use when the user says \"build a QC checklist\", \"standardize how we review X\", \"acceptance criteria for this process\", or describes quality varying by who does the work."
}
Quality Control Checklist
Convert "experienced people just know" into checks anyone can run. A good check is binary (pass/fail), observable (no judgment calls hidden inside), and placed at the point where the failure it catches actually happens.
Steps
- Get the process: what's produced, the steps, who performs it, and — most important — what has actually gone wrong before. Real past failures anchor the checklist; ask for 2–3 if none are offered.
- Draft the failure-mode inventory first: for each step, what can go wrong, how it would be detected, and the cost of missing it. Every checklist item must trace to a failure mode — a check that catches nothing is process theater.
- Build the checklist in two tiers:
- Critical (stop-the-line): failures that are costly or invisible downstream. These are never skippable and each states its acceptance criterion measurably.
- Routine: consistency checks that tolerate an occasional miss. Phrase every item as a verifiable pass/fail question with the evidence to look at — "Invoice total matches PO total (compare field X to field Y)", not "check invoice".
- Add the operating shell: when the checklist runs (per unit / per batch / per release), who signs off, where results are recorded, and the escalation when a critical check fails. A checklist without a recorded result is a suggestion.
- Verify by dry-run: walk one recent real work product through the draft. Every past failure the user named must be caught by some item; items that catch nothing on the dry-run get justified or cut. Then hand over with a 90-day review note — checklists drift as processes change.
Constraints
- No item without a named failure mode it exists to catch.
- Acceptance criteria are measurable ("≤ 2 business days", "all 4 fields populated") — no "appropriate", "sufficient", or "high quality".
- Keep it runnable: if the full list exceeds ~15 items per tier, split by role or stage rather than shipping a wall nobody completes under time pressure.
Full walkthrough, examples, and variations: recipes/Recipe-048-Quality-Control-Checklists-Standards.md.
For enforcing checks on AI-assisted code specifically, the same philosophy is implemented in
ai-control-framework.
Version History
- 9157c9a Current 2026-07-19 10:48
