Mach 10
A development methodology for agentic coding -- and a Claude Code plugin that implements it.
What is Mach 10?
In agentic coding, the AI is not an autocomplete engine -- it is an active collaborator that writes code, reviews it, manages GitHub issues and PRs, runs tests, and documents its work. The human's role shifts from writing code to directing, aligning, and reviewing. You describe requirements, approve architectural decisions, and steer direction. The AI handles the searching, writing, testing, and bookkeeping.
This changes the failure mode. The bottleneck is no longer typing speed or syntax recall -- it is context management. LLM context windows are finite. A deep code review can consume most of the available context, leaving little room for implementation. Multi-session feature development requires persistent memory across sessions. And without a structured workflow, agentic coding produces inconsistent results: missed edge cases, orphaned TODOs, reviews that never converge.
Mach 10 is a methodology that addresses these constraints directly: fresh sessions for each step, GitHub as persistent memory, staged implementation, and iterative review-fix cycles. This repository contains a Claude Code plugin that codifies the methodology into 14 slash commands, but the methodology stands on its own -- you can follow it manually with any agentic coding tool.
Because the methodology builds entirely on standard developer practices -- issues, PRs, comments, feature branches, frequent commits -- there is no vendor lock-in. Every artifact Mach 10 produces is a normal GitHub artifact. If you stop using the plugin, you're left with well-documented issues, structured PRs, and a clean commit history. Nothing is stored in a proprietary format or locked behind a tool-specific layer.
The methodology
Your role as the human
You are directing, not spectating. The AI handles the mechanical work -- searching, writing, testing, documenting -- but you own the decisions:
- Push back on designs. When the AI presents a plan, you don't have to accept it. Ask why it chose a particular approach. Ask it to present alternatives. If the architecture doesn't feel right, say so -- before implementation is the cheapest place to catch mistakes.
- Don't guess when the AI asks questions. When it presents clarifying questions with options, ask it to explain the tradeoffs of each option rather than picking one blindly. You have a collaborator that can reason about the implications -- use it.
- Review plans, not just code. Plans can be reviewed by AI agents just like code can. Catching a design flaw before implementation saves far more effort than catching it in code review.
- GitHub is the shared medium. Plans, assessments, and reviews are posted as GitHub comments. Any future session -- yours or a teammate's -- can read and build on prior work. The persistence layer is GitHub, not your local machine.
GitHub as shared memory
Each CLI session starts with a fresh context window. Multi-session feature development requires persistent memory. Rather than maintaining bespoke planning documents on disk, the methodology uses GitHub's existing infrastructure -- issues, PRs, and comments -- as the inter-session communication layer:
- Issues capture requirements, analysis, and staged implementation plans.
- PR descriptions summarize what was built.
- PR comments carry reviews, fix documentation, and design discussions.
Everything persists across sessions and is accessible via gh. When a new session starts, it reads the relevant issue or PR and has full context without any filesystem state or memory.
Fresh sessions for every step
LLM context windows are finite. A deep code review can consume most of the available context, leaving little room for implementation. If you try to review and fix in the same session, the fixes suffer from a starved context budget.
The methodology is designed around this constraint:
- Planning explores the codebase and persists its plan as a GitHub comment before the context fills up.
- Review posts its findings as a PR comment and does not fix anything.
- Fixing starts fresh with the full context budget available for implementation.
- Implementation runs one stage per session so each stage gets full context depth.
Staged implementation
Large features are broken into numbered stages during the planning step. Each stage is implemented in its own session. This significantly improves one-shot success rates compared to attempting an entire feature in a single session -- each stage gets full context depth for codebase exploration, architecture design, implementation, and quality review.
Iterative review-fix cycles
Code review is not a single pass. The methodology uses an iterative cycle:
