菜单
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.
用 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.
Run the FULL SDLC pipeline end-to-end — Plan → Implement → Verify → Maintain — with a checkpoint between every phase. Use for a complete feature from a one-line idea to merge-ready. Chains the four phase orchestrators; you approve each phase boundary.
| name | harness-plan |
| description | 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. |
A thin orchestrator. It does not re-implement the sub-skills; it sequences them,
enforces the gates, and stops for you at real decision points. Keep using the atomic
skills (/harness-claude:spec, /harness-claude:plan, ...) directly when you only want one step.
/harness-claude:spec — clarify the request into a spec with testable acceptance criteria.
→ HALT and ask the user any load-bearing clarifying questions. Do not proceed on
guesses. Resume once the spec's open questions are resolved.
/harness-claude:research — reuse-first search (in-repo → context7 → registries/GitHub → web).
Produce the build-vs-reuse decision; fold it into the spec.
/harness-claude:plan — delegate to the harness-claude:planner agent (pass it the spec + reuse decision +
the objective, not just a query). Return a phased plan (tasks with write-sets +
depends_on + the AC-n each addresses) with per-task exit checks.
/harness-claude:plan-check — gate the plan against the spec (criteria coverage, scope,
parallel-task disjointness) before any code. Delegate to the harness-claude:planner agent in a
read-only check pass. Loop ≤3 revisions with /harness-claude:plan on findings.
→ HALT and show the user the checked plan for approval before any code. A standing
Critical finding blocks the phase.
Design gate — two independent, conditional siblings. A change can need one, both, or neither; run only what's relevant and say which you skipped.
/harness-claude:architect — only if the plan flagged a load-bearing system
decision (new subsystem, public interface/data model, cross-cutting change, multi-shape
refactor). Delegate to the harness-claude:architect agent and present the ADR./harness-claude:design — only if the change has a user-facing surface (page,
screen, component, form, mobile, CLI/TUI presentation). Produce the design brief.
→ HALT for approval on whichever ran. If the work is routine and internal (no UI, no
load-bearing design — like this CLI harness itself), skip both and say so./harness-claude:save-session for multi-session work.A short phase summary: spec ✓, reuse decision, approved plan (phases), and the design gate —
architecture decision (or "skipped — routine") and design brief (or "skipped — no UI surface").
Then hand off to /harness-claude:harness-implement.