メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | harness |
| description | 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. |
The top-level orchestrator. It walks all four phases by invoking the phase orchestrators in order, pausing at every phase boundary for your go-ahead. It is a convenience wrapper — it adds checkpoints and a running summary, nothing the phase skills don't already do.
/harness-claude:harness-plan ──▶ [checkpoint] ──▶ /harness-claude:harness-implement ──▶ [checkpoint]
──▶ /harness-claude:harness-verify ──▶ [checkpoint] ──▶ /harness-claude:harness-maintain (optional)
Plan — run /harness-claude:harness-plan. At its HALTs, get the user's answers/approvals.
→ CHECKPOINT: show the approved spec + plan (+ ADR). Wait for "go" before coding.
Implement — run /harness-claude:harness-implement against the approved plan.
→ CHECKPOINT: report what was built and test status. Wait for "go" before verify.
Verify — run /harness-claude:harness-verify. Halt on Critical/High; stop at the git boundary.
→ CHECKPOINT: show review/security verdicts, coverage, observed-working evidence.
Maintain — offer /harness-claude:harness-maintain. Run it only if the user wants cleanup now.
/harness-claude:save-session at each checkpoint so a long feature
survives compaction or a new session.rules/git.md). /harness-claude:harness-verify
ends at "ready to commit/PR."/harness-claude:harness
is for full features.A phase-by-phase rollup ending in "merge-ready (awaiting your git go-ahead)."
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.