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 you have a written implementation plan to execute in a separate session with review checkpoints
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
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always