菜单
Turn a vague request into a clear, written spec with acceptance criteria before any code. Use at the start of any non-trivial feature, change, or bugfix. First gate of the Plan phase.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| name | spec |
| description | Turn a vague request into a clear, written spec with acceptance criteria before any code. Use at the start of any non-trivial feature, change, or bugfix. First gate of the Plan phase. |
Goal: eliminate misunderstanding before a line of code. A vague ask becomes a short, testable spec.
AC-1, AC-2, …). The IDs are load-bearing: /harness-claude:verify
builds its coverage matrix against them, so they must not be renumbered later. These
become the tests in /harness-claude:implement.For non-trivial work, write the spec to .claude/planning/<slug>/SPEC.md — pick a
short kebab-case <slug> for the feature (schema: docs/state-and-artifacts.md) — so
later steps and any fresh-context subagent read a file, not the conversation. Also present
it in the conversation. For a trivial/one-file change (lazy reflex), skip the artifact and
say so in one line — a spec in the reply is enough. Format:
# Spec: <title>
## Problem
## In scope / Out of scope
## Acceptance criteria
- [ ] AC-1: ...
- [ ] AC-2: ...
## Constraints
## Open questions (with recommended defaults)
When you wrote a SPEC.md, patch .claude/STATE.md: set slug, phase: spec,
status: done, next_skill: /research (schema + convention in
docs/state-and-artifacts.md). Skip for trivial work.
Acceptance criteria are concrete, testable, and ID'd, and no blocking open question
remains. Then proceed to /harness-claude:research.