qc-checklist

GitHub

将流程描述转化为可操作的质检清单。通过识别过往故障模式,构建二元通过/失败检查项,区分关键与常规层级,明确验收标准及升级机制,确保任何人可执行且结果可记录,防止质量波动。

skills/qc-checklist/SKILL.md sgharlow/claude-code-recipes

触发场景

build a QC checklist standardize how we review X acceptance criteria for this process quality varying by who does the work

安装

npx skills add sgharlow/claude-code-recipes --skill qc-checklist -g -y
更多选项

不安装直接使用

npx skills use sgharlow/claude-code-recipes@qc-checklist

指定 Agent (Claude Code)

npx skills add sgharlow/claude-code-recipes --skill qc-checklist -a claude-code -g -y

安装 repo 全部 skill

npx skills add sgharlow/claude-code-recipes --all -g -y

预览 repo 内 skill

npx skills add sgharlow/claude-code-recipes --list

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

  1. 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.
  2. 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.
  3. 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".
  4. 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.
  5. 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.

版本历史

  • 9157c9a 当前 2026-07-19 10:48

同 Skill 集合

skills/data-cleanup/SKILL.md
skills/meeting-notes-to-actions/SKILL.md
skills/research-synthesis/SKILL.md
skills/summarize-document/SKILL.md
skills/weekly-status-report/SKILL.md

元信息

文件数
0
版本
9157c9a
Hash
39a497d8
收录时间
2026-07-19 10:48

首页 - Wiki
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-07-29 22:19
浙ICP备14020137号-1 $访客地图$