Kimi Mp Implement

Matt Pocock Implementation Pipeline (Kimi Code edition — AgentSwarm-engined)

Port of mp-implement (v2, Workflow-engined) to the Kimi Code harness. Same methodology, same phases, same HITL checkpoints — the Phase 3 execution engine is rebuilt on Kimi's Agent / AgentSwarm subagents instead of the Claude Code Workflow tool. Running on Claude Code or Codex? Use mp-implement instead — this edition exists because Kimi has no Workflow tool and no schema-enforced structured output.

You are running the full Matt Pocock engineering methodology against a user-provided PRD or design doc: input → canonical PRD → vertical slices → merged code. Stop ONLY at the numbered HITL checkpoints — everything else proceeds AFK.

Relationship to upstream mattpocock/skills

This pipeline is the AFK compression of Matt's human-driven chain (grill-with-docs → to-spec → to-tickets → implement → code-review). Upstream deliberately stays small, composable, and human-driven; this edition keeps the same disciplines but inlines them into prompts and controller steps, and hands user-invoked skills back to the human at HITL checkpoints rather than invoking them mid-run. Synced against upstream v1.1.0 (2026-07).

Input

One argument: a file path (path/to/feature.md), an issue tracker reference (#42, a GitHub/GitLab URL), or .scratch//PRD.md. If no argument, ask which PRD/design to operate on, then read it fully.

Persistence (goal-like harness)

You do NOT stop at the end of each phase. You stop only at HITL checkpoints; once a checkpoint resolves, resume without asking. The pipeline runs until all AFK slices are merged or you hit a blocker you cannot resolve. Loops are expected (diagnose → fix → re-verify). Drive forward.

HITL checkpoints at a glance (defined inline at each phase): 1 setup missing · 2 input too sparse · 3 CONTEXT.md sparse · 4 slice approval + merge policy · 5 ambiguity / ADR conflict / test red after 2 honest attempts · 6 load-bearing interface change · 7 stalled agent that won't resume, or cleanup resistance · 8 architecture candidates. Between these: drive forward without asking.

Asking: use AskUserQuestion when the harness allows it. In auto permission mode (AskUserQuestion suppressed), post the checkpoint as plain text and end the turn — the user's reply resolves it. Never silently self-approve a checkpoint; an auto-approved plan mode prompt is NOT the user's answer to a HITL checkpoint.

Pipeline

[Phase 0]   Setup verification          ──→ HITL 1 if repo not configured
[Phase 0.5] Canonicalize input → PRD    ──→ HITL 2 only if input too sparse
[Phase 1]   Domain alignment             ──→ HITL 3 if CONTEXT.md sparse
[Phase 2]   Decomposition + merge policy ──→ HITL 4 on slice approval
[Phase 3]   Wave-based implementation    ──→ AFK loop until all slices merged
   │  engine = AgentSwarm stage-swarms, one swarm per stage per wave
   │  (see ./phase3-swarm.md for call shapes, report formats, prompts)
   ├─ 3.0 pre-flight: baseline check, run manifest, worktrees, waves
   ├─ 3.1 dispatch stage-swarms → implement (TDD) → spec review loop
   │                             → multi-lens quality review loop → verify gate
   ├─ 3.2 harvest reports → push / PR / merge per policy; handle BLOCKED
   ├─ 3.3 per-wave cleanup → next wave
   └─ 3.F final sweep (manifest closed out, 0 orphaned worktrees)
[Phase 4]   Closing hygiene              ──→ HITL 8 on arch candidates

After Phase 0.5, every later phase operates on the canonical PRD on the issue tracker — the original input file becomes a reference, not the source of truth.

---

Phase 0 — Setup verification (one-time per repo)

Check whether setup-matt-pocock-skills has been run — look for the ## Agent skills block in CLAUDE.md / AGENTS.md:

grep -l "## Agent skills" CLAUDE.md AGENTS.md 2>/dev/null

If missing → HITL CHECKPOINT 1: "Setup hasn't been run in this repo. Running setup-matt-pocock-skills first — needs your input on issue tracker / triage labels / domain doc layout. Proceed?" Wait, then invoke it.

If present → resolve locations through the block's pointers, never by hardcoding paths (the tracker doc may live somewhere other than docs/agents/): read the tracker doc named by the ### Issue tracker pointer, the domain doc behind ### Domain docs, and — if the ### Triage labels pointer exists — the labels doc behind it. Confirm tracker, label vocabulary, domain layout. triage-labels.md may legitimately be absent (setup skips it when triage isn't installed) — fall back to the five canonical roles (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix). The tracker may be GitLab — then the doc drives glab, not gh. Proceed.

Phase 0.5 — Canonicalize input into a PRD

Read the input fully. Classify:

1. Already canonical (Problem Statement, Solution, numbered User Stories, Implementation Decisions, Testing Decisions, Out of Scope — AND lives on the tracker) → skip to Phase 1.
2. Canonical but local-only → publish to tracker as-is with ready-for-agent label. Phase 1.
3. Substantive but non-canonical (design doc, feature brief, meeting notes with clear intent) → synthesize with to-spec discipline: explore the relevant code, then write the canonical PRD. Do NOT interview the user. Sketch the test seams FIRST: prefer existing seams over new ones, test at the highest seam possible, add new seams only at the highest point you can — the fewer seams, the better, and the ideal number is one. The acceptance criteria you write define those seams; Phase 3 implementers will test only at them.
4. Too sparse or foggy → HITL CHECKPOINT 2. Two branches:

• Foggy AND too big for one session (the way to the destination isn't visible yet) → offer /wayfinder first: it charts the work as a shared map of decision tickets on the tracker, resolved with the human one at a time (HITL planning layer). When the fog clears and the destination is a spec, it hands back here to case 3. If scoping it up surfaces no fog — the way is already clear — wayfinder exits early; skip it and continue.
• Merely sparse (vague intent, no concrete stories) → offer grill-with-docs (~10-20 min interview, also updates CONTEXT.md/ADRs) or let the user expand the doc themselves. After grilling, fall through to case 3.

Grilling rule for either branch: the agent looks up facts itself (explore the repo; never ask what's findable) — only DECISIONS go to the human, one at a time — and nothing is acted on until the human confirms shared understanding.

Publish (cases 2-4): per the tracker doc resolved in Phase 0, ready-for-agent label, title in CONTEXT.md vocabulary. If the original was a tracker issue, link it as "Supersedes" — never modify or close the original. If the original was a local file, leave it as-is but add a one-line pointer at its top to where the canonical PRD now lives. Then show the user the link + 3-line summary (title, # stories, # out-of-scope), name the test seams, and ask to proceed — a light confirmation to catch mis-synthesis (and mis-seamed tests) before code gets written, not a full grilling.

Phase 1 — Domain alignment

Read CONTEXT.md (or CONTEXT-MAP.md + per-context files). If sparse for this PRD's area → HITL CHECKPOINT 3: offer grill-with-docs to build the shared language (same grilling rule: the agent finds the facts, the human makes the decisions, one at a time). If adequate → silent pass; note the terms you'll use everywhere. Read docs/adr/ for decisions constraining the approach. If the PRD contradicts an ADR, surface it explicitly before Phase 2 — don't silently comply, don't silently deviate; mark it as "Contradicts ADR-0007 — but worth reopening because…" and let the human rule on it.

Phase 2 — Decomposition + merge policy

Apply to-tickets discipline: break the PRD into vertical-slice tracer-bullet issues in dependency order. Prefactor first — look for the change that makes the change easy ("make the change easy, then make the easy change"); any prefactoring lands as its own leading ticket. Per slice: Title (CONTEXT.md vocabulary), Type (HITL or AFK — prefer AFK), Blocked by, User stories covered, Acceptance criteria. Keep specific file paths and code snippets OUT of the tickets — they go stale fast (exception: a prototype-produced snippet that encodes a decision more precisely than prose can — state machine, schema, type shape — inlined and noted as from a prototype).

HITL/AFK Type test (wayfinder's): a slice is HITL only if it resolves through a live exchange with the human — the agent never stands in for the human's side (a grilling agent answering its own questions has broken HITL). Everything else is AFK, and AFK is preferred.

Wide refactors are the exception to vertical slicing. One mechanical change (rename a column, retype a shared symbol) whose blast radius fans across the repo breaks thousands of call sites at once, so no slice can land green. Don't force it into a tracer bullet — sequence it expand–contract: expand (add the new form beside the old) blocks the migrate batches (call sites moved in blast-radius-sized batches, each its own slice), which block contract (delete the old form). When even the batches can't stay green alone, run them on a shared integration branch behind a final integrate-and-verify slice — green is promised only there. That variant pairs with merge policy (b); under (a), every batch must land green on its own.

HITL CHECKPOINT 4 (mandatory): present the numbered breakdown and ask:

• Granularity right? Does each slice only depend on slices that genuinely gate it? — related ≠ blocking; inflated blocking edges are what silently narrows Phase 3 wave width. HITL/AFK markings right (apply the Type test above)? Merge or split any?
• Merge policy (one-time decision for Phase 3): (a) auto-merge — controller merges each PR once both reviews + verification pass; fully AFK across waves (default for solo repos), or (b) await human review — PRs stack up, issues move to "awaiting human review", dependent waves branch off predecessor branches instead of main. Say explicitly when offering (a): it means no human sees any PR before it lands — the user must waive that knowingly, not by rubber-stamping the slice list.

Iterate until approved. Publish slices as tracker issues in dependency order (so "Blocked by" references real IDs); apply ready-for-agent to AFK slices. Where the tracker has native relationships, use them: sub-issues for slice → PRD parenting and native blocking edges for "Blocked by" (GitHub: issue dependencies via gh api; GitLab: /blocked_by) — ## Parent / ## Blocked by body sections are the fallback. Local-markdown trackers keep one file per slice as before.

Phase 3 — Wave-based implementation (AFK loop)

You are the controller; you never implement in your own context. Implementation, reviews, and verification run as Kimi subagents with isolated context. Kimi has no structured-output enforcement, so every agent contract is a report block (fixed YAML in a fenced block at the end of the agent's final message, plus a full report file on disk). Call shapes, report formats, prompt templates, and fix-loop mechanics live in ./phase3-swarm.md — use them; do not improvise the orchestration from memory.

3.0 Pre-flight (controller, once)

1. Baseline gate — run the project's test/lint/typecheck on the base branch now. Never start a wave from a broken baseline; fix or HITL first.
2. Run manifest — create .kimi/mp-run-.md, the authoritative registry of everything this run creates (full report files go in .kimi/mp-run--reports/; add .kimi/ and .worktrees/ to .git/info/exclude):

# MP Run Manifest (kimi)
Repo:  · Base:  · PRD:  · Created: 
Merge policy: auto-merge | await-review

| Slice | Wave | Branch | Worktree | Status | PR | Agents (impl/fix/spec/qual/verify) | Cleaned |
|-------|------|--------|----------|--------|----|------------------------------------|---------|
| #42   | 1    | feat/x | .worktrees/feat-x | ready | #51 | agent-3, agent-7, … | ✓ |

Status flow: registered → dispatched → READY|BLOCKED|SPEC_STUCK|QUALITY_STUCK|VERIFY_FAILED → merged|deferred → cleaned. (READY = verify gate passed; any carried concerns are then resolved at harvest, 3.2, before merge.)

1. Slice briefs — for each AFK slice, assemble a self-contained brief: full issue body + comments verbatim, relevant CONTEXT.md terms, constraining ADRs, test commands, scene-setting (where it fits). Subagents cannot reach back into this session or be asked questions mid-run — anything missing becomes a BLOCKED result, so front-load everything.
2. Waves (maximize width — this is the whole point of the engine) — topologically sort slices by "Blocked by"; every slice whose dependencies are satisfied goes into the next wave and runs in parallel. Default to the WIDEST wave: dependency-independent slices belong in the same wave even when they touch overlapping files. The bar for serializing two same-wave slices is a real edit collision at region granularity, NOT mere file overlap:

• Collision (serialize): both slices would edit the same region of a file — same function, same block, adjacent lines.
• No collision (keep parallel): different regions of a shared hub file — different event types in one watcher, different exports in a barrel, append-only additions to an allowlist/test file. These resolve as a union at harvest (3.2).

File-level disjointness is the old, too-strict heuristic; in mature codebases almost every slice grazes a few hub files, so file-level checking collapses every wave to one slice and wastes the parallel engine entirely. When genuinely uncertain, prefer the wider wave and let the integration review (3.F) catch cross-slice drift. Only a true same-region collision, or a real "Blocked by" dependency, justifies a separate wave.

1. Worktrees (register before dispatch) — for each slice in the wave: git worktree add .worktrees/ -b (if the repo already has a worktree convention via using-git-worktrees, follow it). Then run project setup inside the worktree and confirm the test suite runs green there: never hand an agent an unbuildable workspace, or its first failure surfaces as a misleading BLOCKED. Record path + branch in the manifest BEFORE the wave launches. No manifest entry, no dispatch.

3.1 Dispatch the wave (stage-swarms)

Run one AgentSwarm call per stage — IMPLEMENT → SPEC → QUALITY → VERIFY — with the templates from ./phase3-swarm.md. Slices within a stage run fully parallel; stages barrier per wave (the chain-parallel execution of the Workflow edition has no AgentSwarm equivalent — see phase3-swarm.md for why the barrier is accepted, not worked around).

• AgentSwarm discipline: the swarm call must be the only tool call in its response — do manifest bookkeeping in the turn before or after. Needs ≥2 items with distinct prompts; a single-slice (re)dispatch uses a plain Agent call. Run swarms in the foreground: the stage's results come back together, and your next step depends on them.
• Record agent IDs in the manifest as each swarm/Agent call returns — they are your resume handles. Subagents have a fixed 30-minute timeout: a timed-out agent is resumed (same ID, "continue"), never restarted fresh.
• Report blocks are the contract. A slice result without its closing ``yaml report block is not a result: resume the agent once to produce it; still missing → AGENT_LOST`. Evidence fields must be verbatim command output — a claim is invalid even if well-formed.
• Fix loops resume the implementer (same agent ID — it keeps context of the code it wrote), never a fresh agent that must re-discover the slice. Ever

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: skywalkercyt
• Source: skywalkercyt/mp-implement
• License: MIT

Install and usage instructions live in the source repository linked above.