菜单
Checkpoint a change against its spec's acceptance criteria — run the machine-checks, adjudicate the prose ones, and gate ship until every criterion passes. Opt-in; not wired into the default pipeline. Use late in Verify, alongside /test and /verify.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | eval |
| description | Checkpoint a change against its spec's acceptance criteria — run the machine-checks, adjudicate the prose ones, and gate ship until every criterion passes. Opt-in; not wired into the default pipeline. Use late in Verify, alongside /test and /verify. |
Goal: prove the work satisfies the spec it was built against, criterion by criterion. Green tests show the code runs; this shows it meets what was promised.
Opt-in. This skill is not invoked by any default-pipeline skill or hook. Running it is always explicit; it changes no baseline behavior. (Fulfills v0.4 AC-6 / v0.3 AC-E5.)
docs/specs/*.md; let the user name one if
the change targets an older spec. Confirm it's the spec this change was built against.node scripts/eval/checkpoint.js [spec.md]
```eval fenced shell command — that's its
machine-check. Add one to an AC when a deterministic check exists (port it from the
spec's own test commands)..claude/traces/ for what fired)
and judge PASS or FAIL yourself. The script never auto-passes prose — closing these is
your job. If a MANUAL criterion is genuinely verifiable, prefer adding an ```eval
fence so it's deterministic next time.```eval fences are shell-executed (via _lib.sh → execSync) with your privileges.
They are author-authored, committed markdown — trust them exactly like the repo's own test
scripts or build hooks. Review specs from untrusted branches/PRs before running /eval.checkpoint.js --list is the safe inspect-before-run path: it parses and shows which ACs
carry a check, but executes nothing.harness-claude:test (suite + coverage) and harness-claude:verify
(observe real behavior); this one ties the change back to its acceptance criteria.Every acceptance criterion in the spec is PASS (machine-checked or evidence-adjudicated).
Then harness-claude:ship.
Bug-fix fast lane — the entry point for fixing something already broken (a red test, a prod error, a reported defect), not building a new feature. Does the bug-specific part — reproduce as a failing test, find the root cause, write a minimal fix-plan — then hands off to the existing pipeline (/implement → /review → /security-review → /verify → /ship) so the fix rides the proven gates. The non-negotiable discipline: reproduce as a failing test FIRST, fix minimally. Opt-in; invoked explicitly. Use when something is broken and you want it fixed under the harness's gates without over-ceremonying it through /spec.
Execute a plan via test-driven development — write tests first, then minimal code, phase by phase. Use after /plan (and /architect if needed) to write the actual feature. Delegates to the harness-claude:tdd-guide agent.
Review changed code for quality, correctness, and maintainability before merge. Use immediately after implementing or modifying code. Delegates to the harness-claude:code-reviewer agent. First gate of the Verify phase.
Confirm the change actually works by running the app/feature and observing real behavior — not just that tests pass. Use late in the Verify phase, before ship. Closes the loop between "tests green" and "it works."
Orchestrate the entire IMPLEMENT phase — test-driven implementation of the approved plan, resolving build/type errors as they arise. Use after /harness-plan. Sequences /implement and /build-fix, delegates to subagents, and halts if reality diverges from the plan.
Orchestrate the entire PLAN phase in one command — spec, research, plan, plan-check, and (if warranted) architecture. Use at the start of any non-trivial feature/change. Sequences the atomic skills, delegates to subagents, and pauses for your input at each decision gate.