Deepseek Mp Implement

Deepseek MP Implement

Matt Pocock methodology, but Phase 3 (implementation + quality review) runs on Codex instead of Claude Code subagents. This session stays lean — you plan, coordinate, and do spec-compliance verification. Codex does the heavy lifting.

Why this variant

| Phase | mp-implement (original) | deepseek-mp-implement | |---|---|---| | Plan (0-2) | This session | This session (unchanged) | | Implement | Claude Code subagent in worktree | /codex:rescue → Codex mp-implement-issue | | Code-quality review | Claude Code subagent | /codex:adversarial-review --wait | | Spec-compliance review | Claude Code subagent | Claude Code subagent (unchanged — needs issue body) | | Hygiene (4) | This session | This session (unchanged) |

Relationship to upstream mattpocock/skills

This is the Codex-engine variant: the AFK compression of Matt's human-driven chain (grill-with-docs → to-spec → to-tickets → implement → code-review) with Phase 3 delegated to Codex. Upstream deliberately stays small, composable, and human-driven; this fork trades that for AFK throughput. Synced against upstream v1.1.0 (2026-07).

Terminology: local "PRD"/"slices" ≈ upstream "spec"/"tickets".

Input

Same as mp-implement: a file path, an issue tracker reference, or a PRD description. If no argument, ask the user.

Pipeline

[Phase 0]   Setup verification          ──→ HITL if repo not configured
[Phase 0.5] Canonicalize input → PRD    ──→ HITL only if too sparse
[Phase 1]   Domain alignment             ──→ HITL if CONTEXT.md sparse
[Phase 2]   Decomposition                ──→ HITL on slice approval
[Phase 3]   Per-slice: Codex loop        ──→ AFK until all slices done
   │
   ├── dispatch Codex via /codex:rescue (mp-implement-issue + issue URL)
   ├── /codex:adversarial-review --wait (code quality, before commit)
   ├── commit + push + PR (controller does this)
   ├── Claude subagent spec-compliance review
   └── merge → next slice
[Phase 4]   Closing hygiene              ──→ AFK

Phase 0-2 — identical to mp-implement

Follow mp-implement/SKILL.md Phases 0 through 2 exactly. All three HITL checkpoints (setup, canonicalization, decomposition) operate identically. Use CONTEXT.md vocabulary throughout.

Phase 3 — Codex-backed implementation loop

This is where the fork happens. For each AFK slice in dependency order:

3.1 Prepare the Codex prompt

Construct a single, self-contained prompt for Codex. It must include everything Codex needs — it cannot reach back into this session for context.

Prompt template:

In repo , implement the slice described in GitHub issue # (repo: /).

Before starting:
- Run: gh issue view  --repo / --comments
- Read the full issue body and all acceptance criteria
- Read CLAUDE.md and CONTEXT.md for domain vocabulary
- Read any ADRs referenced in the issue

Implementation:
- Use the mp-implement-issue skill for TDD discipline
- Create branch:  (from origin/main)
- Implement ONE acceptance criterion at a time (red → green → commit → next)
- NEVER write multiple tests upfront

On completion:
- Leave changes in the working tree (do NOT commit/push/open a PR — the controller will do that)
- Report: (a) branch name, (b) commit SHAs with messages, (c) test results (pytest/npm test output), (d) files changed, (e) any concerns or design decisions

Customize per slice:

• Fill `` with the actual issue number
• Fill `` with the kebab-case branch from the issue title
• If the slice spans backend and frontend, split into separate "backend work first, then frontend" instructions within the same prompt, OR split into two Codex calls if truly independent
• If the slice has env-var requirements, include them

3.2 Dispatch Codex

Use the codex:codex-rescue subagent (via the Agent tool) to forward the prompt to Codex:

Agent(
  subagent_type: "codex:codex-rescue",
  description: "implement slice #",
  prompt: ""
)

The subagent handles checking for resumable Codex threads. If Codex reports BLOCKED or NEEDS_CONTEXT, surface the issue to the user (this is a HITL moment — the user may need to clarify something in the issue body).

Do not proceed to 3.3 until Codex reports success. Codex modifies the working tree in-place; the adversarial review in 3.3 runs against that working tree.

3.3 Code-quality review (Codex adversarial)

Once Codex reports DONE and the working tree has changes:

# Resolve the newest installed plugin version (the versioned path breaks on every plugin update)
COMPANION=$(ls -d "$HOME/.claude/plugins/cache/openai-codex/codex"/*/ | sort -V | tail -1)
node "${COMPANION}scripts/codex-companion.mjs" adversarial-review --wait

Preferred fallback (works regardless of plugin version): use the Agent tool with subagent_type: "codex:codex-rescue" and a prompt instructing an adversarial review.

If the review finds Critical or Important issues: send the findings back to Codex as a follow-up /codex:rescue call (with --resume if available). Loop until approved or only Minor issues remain.

3.4 Commit + push + open PR

The controller (you, in this session) handles this — Codex leaves the working tree dirty deliberately.

cd 
git add -A
git commit -m ""
TOKEN=$(gh auth token)
git -c credential.helper="!f() { echo username=token; echo password=$TOKEN; }; f" push -u origin 
gh pr create --base main --head  --title "" --body ">"

3.5 Spec-compliance review (Claude Code subagent)

This stays as a Claude Code subagent because it needs the full issue body + acceptance criteria list for checklist-style verification. Codex review tools don't support this pattern.

Dispatch a general-purpose subagent (background OK):

Agent(
  subagent_type: "general-purpose",
  run_in_background: true,
  name: "spec-rev-#",
  prompt: ""
)

The prompt should include:

• The FULL issue body (acceptance criteria verbatim)
• The implementer's report (what they claim they built)
• The worktree/branch/PR to review
• Instructions to verify each AC independently, flag out-of-scope changes, check vocabulary
• Findings must quote the spec line (dual anchor: spec sentence + code location)

Loop implementer fixes via Codex --resume until spec passes.

3.6 Merge + next slice

gh pr merge  --squash --delete-branch
# Clean up worktree if any
git pull origin main --ff-only

Then proceed to the next slice in dependency order. Do not pause between slices — drive the loop AFK unless Codex reports BLOCKED.

HITL checkpoints (when to pause)

1. Setup missing — repo needs /setup-matt-pocock-skills
2. Input foggy — too big for one session → /wayfinder first; merely sparse → /grill-with-docs
3. CONTEXT.md sparse — needs domain alignment
4. Slice approval — user reviews decomposition before issues are published
5. Codex reports BLOCKED/NEEDS_CONTEXT — ambiguity the controller must resolve
6. Closing hygiene — /improve-codebase-architecture candidates

Between these: drive forward without asking.

Hard rules

• Use CONTEXT.md vocabulary in EVERY artifact (issue titles, branch names, commit messages, PR bodies).
• Tracer bullets, never horizontal slices.
• Prefer AFK over HITL. Can you resolve it from PRD + CONTEXT + ADRs? Then don't ask.
• Codex does implementation + quality review. This session does planning + spec review + merge.
• NEVER implement a slice in this session's context. That's what Codex is for.
• Do not modify or close the parent PRD issue — only slice issues.
• Two reviews before merge — adversarial (Codex) + spec-compliance (Claude subagent).

Failure modes

• Letting Codex's output sit in the working tree without running adversarial review before commit.
• Skipping spec-compliance review because "the adversarial review was thorough" — they check different things.
• Implementing a slice in this session because "it's just a small fix" — the boundary erodes.
• Not including enough context in the Codex prompt (branch name, issue URL, env vars) — Codex can't ask you.

Skills referenced

• mp-implement / mp-implement-issue — inside Codex for TDD implementation
• to-tickets — Phase 2 decomposition (this session)
• grill-with-docs — Phase 1 domain alignment
• improve-codebase-architecture — Phase 4 hygiene
• codex:rescue — Phase 3 dispatch to Codex
• codex:adversarial-review — Phase 3 code-quality review
• to-spec — Phase 0.5 canonicalization
• wayfinder — optional pre-pipeline on-ramp (input foggy and too big for one session)
• resolving-merge-conflicts — merge conflicts the controller hits at commit/merge time (3.4/3.6): read both sides' intents, preserve both, never invent behavior, never --abort

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.