菜单
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.