/implement

name: implement
description: |
  TRIGGER when: user asks to implement, fix, build, or work on something — whether from a
  docs/feat/wip plan OR a standalone task (bug fix, GitHub issue, one-off change).
  Examples: "work on task 1", "fix this bug", "implement feature X from the issue".
  Provides structured execution with profile detection, dependency handling, review checkpoints.

Implementing Work

**Start with instruction reads.** After this entry point loads, your next tool calls read the three shared protocols below and the selected mode procedure. Do not batch them with repository searches or source/document reads. Reading only this SKILL.md does not open investigation. Complete the profile-loading checkpoint before investigation, tests or edits; only the declared bounded predicate routing below may inspect content earlier. A filename-only scope operation is not that checkpoint.

Conventions

• **Read capy knowledge base conventions** at [shared-capy-knowledge-protocol.md](shared-capy-knowledge-protocol.md).
• **Always read change context** at [shared-change-context.md](shared-change-context.md), including when no profile matches. It defines the factual record used before editing and refreshed for independent review.
• **Read profile detection** at [shared-profile-detection.md](shared-profile-detection.md). When the sub-task's target files activate a profile that contributes an `implement/` subdirectory (e.g., `${TOOLBOX_PLUGIN_ROOT}/profiles/k8s/implement/`), its `index.md` lists per-task gotchas the skill must consult BEFORE writing. See Step 2.

Modes

Two modes, determined automatically: **plan mode** when the user references a docs/feat/wip feature or task number; **standalone mode** otherwise (bug fix, GitHub issue, one-off change). When ambiguous, ask.

• **Plan mode:** Read [plan-mode.md](plan-mode.md) for entry, iteration, and completion procedures.
• **Standalone mode:** Read [standalone-mode.md](standalone-mode.md) for entry procedure.

Both modes share the same execution core (Step 2 onward) — instruction loading, investigation and change context, implementation, verification, review.

Required Outputs

After each execution + review cycle, verify all outputs:

• [ ] Implementation addresses intended outcomes, preserved contracts and hard task/delivery requirements
• [ ] Verification/tests pass for the claimed scope; unverified conditions are explicit
• [ ] Code review completed (via `/kk:review-code` — which owns indexing its own `kk:review-findings`)
• [ ] Refreshed context and evidence supplied to review; findings resolved or permitted follow-up recorded durably
• [ ] Code completion distinguished from release/migration/activation conditions
• [ ] New project conventions indexed as `kk:project-conventions` (skip if none established)
• [ ] (Plan mode only) `tasks.md` updated to `done`

**Indexing ownership:** Review skills (`/kk:review-code`, `/kk:review-spec`) index their own findings. This skill only indexes `kk:project-conventions` for non-obvious patterns discovered during implementation. Do NOT duplicate review indexing here.

Review Mode

By default, review checkpoints use **isolated mode** (`/kk:review-code:isolated`, `/kk:review-spec:isolated`). This is mandatory because the implementing session has authorship bias — the same model that wrote the code produces weaker reviews of it. Isolated mode spawns an independent sub-agent with no prior exposure to the implementation.

The user can override at any checkpoint ("use standard review for this one") to fall back to in-session `/kk:review-code`.

Workflow

**Mandatory order — instructions before action.** The flow below is strictly sequential. Load this skill, the selected mode procedure, shared protocols and every resolved profile instruction before source/requirement investigation, edits (including task-status edits), tests or implementation decisions. Entry procedures collect minimal task/file metadata solely to select scope and profile guidance; they do not analyze requirement prose. After basic instructions load, the sole early-content exception is routing for a declared detection or conditional-load predicate: inspect at most approximately 16 KiB per candidate file, log the predicate/path, and conservatively load an instruction when its conditional is undecidable within that bound. Routing permits no behavioral analysis, full-diff read, findings, edits or tests.

**Phases:** load basic instructions and scope metadata → detect profiles and load their content → investigate requirements/source and establish change context → implement and verify → refresh evidence and review → assess completion. Detailed investigation has one entry point in Step 2; mode entry procedures do not duplicate it.

The Process

Step 1: Load Instructions and Mode Context

Read the shared protocols in Conventions, determine mode (see §Modes), then read the appropriate mode file and follow its entry procedure:

• **Plan mode:** Read [plan-mode.md](plan-mode.md) — locates the feature documents and selects task/target metadata for routing.
• **Standalone mode:** Read [standalone-mode.md](standalone-mode.md) — selects request/target metadata without investigation.

After completing the mode's entry procedure, continue with Step 2.

Scope routing returns filenames/metadata only. For symbol lookup use a filename-only search (`Grep` with `output_mode: files_with_matches`, or `rg -l`), never matching source lines. In plan mode extract only the task headings/status/dependency/target-path fields specified by the mode procedure; do not use a full `Read`/`cat` of `tasks.md` as metadata, even when it is short. If a target is unclear, route a conservative file list rather than investigating it early.

Step 2: Execute

1. **Detect and load profiles.** Run `shared-profile-detection.md` against candidate target filenames and any diff-so-far, however small the task. Read every Known profiles detection rule in a batch