القائمة
Final pre-merge step — sync docs, then prepare a clean commit/PR summary. Use after verify passes. Does NOT commit or push unless you explicitly ask; it prepares everything and stops.
التثبيت باستخدام 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 | ship |
| description | Final pre-merge step — sync docs, then prepare a clean commit/PR summary. Use after verify passes. Does NOT commit or push unless you explicitly ask; it prepares everything and stops. |
Goal: leave the change merge-ready, with docs in sync and a clear summary — without performing git actions you didn't ask for.
Docs sync — update every doc the change touches, not just the spec. Remove stale references; keep docs lean and accurate. Before a release, sweep for anything the change made stale and reconcile it before committing, not after:
(Project-specific files to touch live in the project's own context — for this repo, see CLAUDE.md → "Release docs sweep".)
Change summary — assemble from the full diff (git diff <base>...HEAD), not just
the last edit:
## Summary — what & why
## Changes (grouped by area)
## Test plan — how it was verified (link the /verify evidence)
## Risks / follow-ups
CI readiness — confirm build, types, lint, tests are green locally; no secrets,
no debug logs, no --no-verify.
Do not run git commit, git push, or open a PR unless the user explicitly asks — and
create no new branches here (the feature branch already exists, made at first write per
rules/git.md). Prepare, then stop:
type(scope): imperative subject ≤72 chars, BREAKING CHANGE: footer when applicable (see rules/git.md).-u, open the PR (draft until verify passed),
squash-merge by default — merge-commit only if the project's own history shows
non-squash merges.Docs synced, summary drafted, checks green. Awaiting the user's go for any git action.