القائمة
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.