Menú
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Reconcile existing spec/plan/design docs with the current codebase after implementation drift, so the written intent matches the shipped code. Trigger whenever the user signals that docs are stale relative to code—even implicitly. Typical cues include: finishing a spec/plan-driven task then vibe coding on top of it, "I manually tweaked the implementation", "the result wasn't satisfying so I changed it directly", "docs/specs are out of date", "docs 和代码不一致了", "把文档和代码同步一下", "回填 spec/plan", "round-trip the docs", "align docs with implementation". Do NOT trigger for writing fresh docs from scratch, for pure code-only changes, or when no prior spec/plan exists.
Archive a finished spec/plan pair into a single summary document under `docs/harness-kit/archive/` and delete the originals, so the intent + outcome of shipped work lives in one auditable place. You MUST use this skill whenever the user explicitly asks to archive, wrap up, or summarize the docs for a finished feature — phrasings include '归档这个 spec/plan', '把 X 的 spec 和 plan 归档了', 'archive the docs for <feature>', 'wrap up the spec/plan for <feature>', or asks to clean up `docs/harness-kit/specs/` and `docs/harness-kit/plans/` because the work is shipped. Do NOT trigger while the work is still in progress, when the user wants to reconcile docs against drifted code (use `harness-kit:docs-round-tripping` instead), or for unrelated doc housekeeping.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when implementing user-visible behavior (Web UI, Electron desktop app) — drives the outer Outside-In TDD loop with agent-browser as the only browser/desktop driver. Triggered by the spec's `## E2E Strategy` section listing one or more `AS-N` acceptance scenarios. Skip when the spec marks E2E Strategy as `EXEMPT`.
Use when implementation is complete and all tests pass — verifies tests + e2e, sanity-checks the e2e evidence is still gitignored, then reports completion with a suggested commit command. Does NOT merge, push, open PRs, delete branches, remove worktrees, or delete files; those are the user's call.
Use when you have a spec or requirements for a multi-step task, before touching code
| name | harness-kit:execute-plans |
| description | Use when you have a written implementation plan to execute in a separate session with review checkpoints |
Load plan, review critically, execute all tasks, report when complete.
Announce at start: "I'm using the harness-kit:execute-plans skill to implement this plan."
Note: Tell your human partner that harness-kit works much better with access to subagents. The quality of its work will be significantly higher if run on a platform with subagent support (such as Claude Code or Codex). If subagents are available, use harness-kit:subagent-driven-development instead of this skill.
For each task:
Report task completion (do NOT commit) — emit that report verbatim (file list + verification result + suggested commit command) and stop. Do not start the next task until the user replies (typically next, but they may want to commit, inspect the diff, or revise something first).Why the per-task pause: plans are written assuming the user wants control over commit boundaries — batching, message wording, skipping a commit entirely, etc. Auto-rolling into Task N+1 silently strips that control. Even if the user said "go" once at the start, treat each task as a fresh checkpoint. If the user explicitly says something like "just blast through all of them, don't ask" you can honor that for the remainder of the session.
Never run on the user's behalf inside this skill: git commit, git push, git merge, gh pr create. Those belong to the user — and the same is true of every other harness-kit skill, including harness-kit:finishing-a-development-branch, which only verifies and reports. If the plan accidentally contains a literal git commit step, treat it as a Report task completion step instead — surface the suggested command, do not run it, and flag the plan bug to the user.
After all tasks complete and verified:
STOP executing immediately when:
Ask for clarification rather than guessing.
Return to Review (Step 1) when:
Don't force through blockers - stop and ask.
Report task completion message and wait for the user before starting the next taskgit commit / git push / git merge / gh pr create on the user's behalfRequired workflow skills: