# Kimi Mp Implement

> Use when the user provides any kind of feature spec (rough notes / system design / partial spec / canonical PRD) and wants it implemented end-to-end autonomously on the Kimi Code CLI (AgentSwarm-engined), or invokes /kimi-mp-implement.

- **Type:** Skill
- **Install:** `agentstack add skill-skywalkercyt-mp-implement-kimi-mp-implement`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [skywalkercyt](https://agentstack.voostack.com/s/skywalkercyt)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [skywalkercyt](https://github.com/skywalkercyt)
- **Source:** https://github.com/skywalkercyt/mp-implement/tree/main/skills/kimi-mp-implement

## Install

```sh
agentstack add skill-skywalkercyt-mp-implement-kimi-mp-implement
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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`:

```bash
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`):

```markdown
# 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.)

3. **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.
4. **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.
5. **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](https://github.com/skywalkercyt)
- **Source:** [skywalkercyt/mp-implement](https://github.com/skywalkercyt/mp-implement)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-skywalkercyt-mp-implement-kimi-mp-implement
- Seller: https://agentstack.voostack.com/s/skywalkercyt
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.