菜单
Use when about to claim work is complete, shippable, or ready to release or tag a milestone — run a script that reads declared criteria and emits GO/NO-GO instead of asserting completion from memory; the author never self-certifies.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
| name | definition-of-done-tooling |
| description | Use when about to claim work is complete, shippable, or ready to release or tag a milestone — run a script that reads declared criteria and emits GO/NO-GO instead of asserting completion from memory; the author never self-certifies. |
A definition of done that lives as a checklist in someone's head, or a paragraph in a PR template, decays over a long session — steps get skipped under time pressure, and the person who wrote the code is the worst-positioned person to judge whether they finished it. Make completion a mechanical gate: a script reads a small declared list of criteria, runs every one marked required, and emits a single GO or NO-GO. The author's belief that they're done is a proposal; the script's exit code is the verdict.
Before claiming any non-trivial unit of work is complete, before cutting a release or tagging a milestone, and before a PR description says "ready for review" or "ready to merge."
Red-flag thoughts that mean STOP and apply this skill:
n/a, not silence.)required or n/a — never left implicit. Typical criteria: tests/CI green, no leftover placeholders in shipped artifacts, docs current, acceptance tests green, lint, coverage threshold, telemetry wired.required criterion with a real, runnable check. A criterion with no check behind it — a vague "where applicable" — is not a gate, it's a comment; either wire a check or mark the criterion n/a.n/a a visible, reviewable decision, not an absence. Deleting a line hides that anyone considered the criterion; marking it n/a in the config leaves a reviewer the chance to disagree with the call.required check through one script that emits a single GO or NO-GO — never a partial pass. Any required NO-GO fails the whole gate; there is no "mostly done."Self-certification fails for the same reason self-review fails: the person closest to the work has the least ability to see what they missed, and under time pressure the checklist in their head quietly shrinks to whatever they remember without prompting. A script has no such pressure and no stake in the outcome — it either observed the criterion pass or it didn't. Requiring a visible n/a rather than allowing silent omission is what keeps the config honest over time: a criterion nobody explicitly excused can't be waved away by whoever's in a hurry this week. And wrapping the existing CI entrypoint rather than duplicating its logic is what keeps the gate from becoming a second, drifting definition of "passing" that quietly diverges from the one CI actually enforces.
Adapted from cmanaha/extended-superpowers (MIT), rewritten here without any reference to a specific hook mechanism or plugin runtime — the gate is any script your project can run, wired into whatever pre-merge or pre-release checkpoint your team already has. A minimal reference implementation of this exact pattern lives in the kibana-mcp project: a dod.config file declares each criterion required or n/a, and scripts/checks/definition-of-done.sh reads that config, runs every required check, and prints a single GO/NO-GO verdict, wrapping the project's own CI entrypoint rather than re-implementing it. It is named here only as a concrete shape worth looking at, not vendored into this pack — the pattern itself is language- and tool-agnostic: the same three moves (declare, gate, wrap-don't-duplicate) work equally as a POSIX-sh script, a Makefile target, or a CI job step in any stack.
required with no real check wired behind it.n/a.This skill is the enforcement shape the others plug into, and it is machine-checkable by construction: criteria declared one per line as required or n/a, every required backed by a runnable command, one script emitting a single GO/NO-GO, wrapping the CI entrypoints it certifies rather than re-implementing them. Guard the gate itself: the config is reviewed like code — editing the exam is the named anti-pattern — and a meta-check asserts that no required criterion points at nothing.