skills

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

Acquire strict, task-specific project context for the `harness-kit` project — read `.agents/rules.md`, `.agents/local-docs-index.md`, `.agents/remote-docs-index.md`, and `~/wikis/index.md` with progressive disclosure, then produce a self-contained context document at `docs/harness-kit/context/YYYY-MM-DD-<topic>.md`. Use this skill whenever the user explicitly asks for "harness-kit context", asks you to acquire / read / update project context, starts a multi-step harness-kit task (planning, designing, implementing), or another harness-kit skill (e.g. `harness-kit:start`, `harness-kit:brainstorm`, `harness-kit:writing-plans`) says project context is required. Do NOT use it for isolated one-off questions that do not need project rules or docs.

Entry point for a harness-kit working session: proactively read AGENTS.md and then combines it with the user's prompt to begin work. Use this skill whenever the user explicitly invokes harness-kit to start — e.g. "start harness-kit", "harness-kit start", "kick off harness-kit", "use harness-kit to begin", or any phrasing where the user is clearly asking harness-kit to bootstrap a session. Do NOT trigger when the user is asking a general dev question.

Use when implementing any feature or bugfix, before writing implementation code

管理本地 wikis 文档库的新增、查找、修改操作。当你需要对本机 wikis 目录进行文档操作时使用，包括：总结内容输出到 wikis 目录、查找 wikis 中的文档、修改 wikis 中的文档内容、创建新的文档分类。请务必使用此 skill 来管理 wikis 文档，用户可以通过指定路径来指定 wikis 目录位置，格式如 `~/wikis` 或 `/path/to/wikis`。