CLAUDE CODE PLUGIN

The Development Machine

An agentic workflow plugin for Claude Code. An AI millwright writes every line of code, and you, the inspector, review each stage's output. The result is an auditable trail of requirements, specs, plans, diagrams, and reviews for every feature you ship.

Install the plugin

HOW IT FITS TOGETHER

Understanding the roles and the artifact trail

The plugin splits every feature into work the AI does and checkpoints the human owns, and it writes down everything in between.

THE AI

The Millwright

Claude, running the workflow. It digests your notes, writes the requirements, plans the work, implements every commit, and renders the diagrams. It never advances past a gate on its own.

THE HUMAN

The Inspector

You. You drop in the source notes, pick what gets built, and approve each stage's output. In the happy path you type just three slash commands across the whole cycle.

THE RECORD

The Artifact Trail

Every stage writes UUID-stamped Markdown files: todo lists, summaries, requirements, plans, diagrams, and reviews. The whole feature history lives on disk, fully auditable.

GET STARTED

How to install and initialize the plugin

Two steps stand between a fresh Claude Code session and a ready workspace.

Add the marketplace, install the plugin

RUN IN CLAUDE CODE

/plugin marketplace add Eminakkoc/Millwright-Inspector-Development-Machine
/plugin install millwright-inspector-development-machine@millwright-inspector
/reload-plugins

Commands are namespaced. Type /mi- in the prompt and pick the match from the slash-command menu.

Run the first-run wizard

RUN ONCE PER WORKSPACE

/mi-init

WHAT YOU GET

One y/n installs every missing dependency, including yq, pyyaml, and plantuml-mcp-server.
Prints the /plugin commands for the superpowers skills (those can't be auto-run from Bash).
Scaffolds the millwright-inspector/ workspace: journal/, quest/, and workflow-stream/.

A WORKED EXAMPLE

Follow one feature, end to end

The rest of this page walks a single feature through all nine stages. Watch the workspace fill up as each stage adds artifacts, spawns sub-agents, and hands the next stage a curated slice of context.

YOUR STARTING POINT

millwright-inspector/ journal/ your-notes/ kickoff-call.md product-spec.md id.md

you author this by hand

It begins with a folder of notes

Drop whatever defines the work, such as meeting transcripts, a spec, or design hand-offs, into journal/your-notes/ as .md or .txt files. The plugin mints an id.md so the folder stays linked even if you rename it. That folder is the only input you write yourself.

From here on, the millwright drives and you review at the gates.

THE WORKFLOW

The workflow from start to finish

Every stage below shows the command, the sub-agents it spawns, the artifacts it writes, and what it hands the next stage. In the happy path you only ever type /mi-run and /mi-continue, and the rest is auto-fired.

YOU

STAGE 0 · BEFORE IT STARTS

Journal populated

YOU EDITjournal/your-notes/*.md

You drop the raw inputs, such as notes, transcripts, or a spec, into a journal folder. Nothing runs yet; this is just you setting the table for the cycle.

SUB-AGENTS

None. You author the inputs by hand.

ARTIFACTS WRITTEN

id.md: a stable UUID for the folder, so every link survives a rename

INTO NEXT CONTEXT

Nothing yet. The files simply sit on disk until /mi-run reads them.

YOU

STAGE 1 · QUEST GENERATION

Quest generated

YOU TYPE/mi-run your-notes

The millwright digests every journal file and turns it into a structured cycle: a per-cycle folder under quest/ holding the work plan and runtime state.

SUB-AGENTS

journal-file-digester · journal-folder-digester

ARTIFACTS WRITTEN

todo-list.md: selectable work items, grouped by feature
summary.md: a per-feature digest of the journal inputs
progress.md: the feature queue and workflow state
queue-rationale.md: audit trail for the dependency-ordering decision
reference.md: UUID links back to the source journal folders
context-ledger.md: telemetry of context-heavy reads and delegations

INTO NEXT CONTEXT

Each digester reads its file in throwaway context and returns a ~1k-token summary. Main keeps the summaries, never the raw files.

YOU

1.5

STAGE 1.5 · SELECTION & ORDERING

Selection and ordering

YOU EDIT, THEN TYPE ×2

You tick the items to build with [x] (you), and the millwright promotes them to PENDING, analyses cross-feature dependencies, and proposes a queue order for you to accept.

SUB-AGENTS

dependency-mapper

ARTIFACTS WRITTEN

progress.md: selected items become a prioritized feature queue
queue-rationale.md: records why the queue was ordered that way

INTO NEXT CONTEXT

The dependency-mapper returns only the ordered queue and rationale. Its cross-feature analysis is discarded.

AUTO-FIRED

STAGE 2 · BLUEPRINT

Blueprint generated

AUTO-FIRED BY THE MILLWRIGHT/mi-apply-impact

For the first queued feature the millwright grounds itself in your codebase and writes the feature's blueprint, covering requirements, config, and structural diagrams, then hands it back for you to review.

SUB-AGENTS

codebase-grounder · blueprint-diagrammer

ARTIFACTS WRITTEN

requirements.md: goals, constraints and acceptance criteria
config.md: skills and rules relevant to this cycle
decisions.md: append-only log of verbal decisions and scope changes
grounding-report.md: audit of the existing seam each change lands in
blueprint diagrams: PlantUML structural diagrams of the planned change

INTO NEXT CONTEXT

The grounder walks the codebase in its own context; main receives only the grounding report, which seeds requirements.md.

AUTO + YOU PICK

STAGE 3 · IMPLEMENTATION

Implementation

AUTO-FIRED · YOU PICK A MODE/mi-plan-implementation

The millwright writes the code. Brainstorming mode runs an isolated planning-and-execution chain; direct mode keeps the work in your main session. Either way it commits against your chosen branch.

SUB-AGENTS

ARTIFACTS WRITTEN

primer.md: a compact context bundle the chain starts from
commits: the actual feature code, committed to your branch

INTO NEXT CONTEXT

primer.md is the chain's required first read: a snapshot so it never has to reload the canonical blueprint files.

YOU

STAGE 4 · IMPLEMENTATION RESUMED

Implementation resumed

YOU TYPE, THEN ANSWER/mi-continue

Back in the main session, the millwright analyses everything that changed, renders implementation diagrams, and asks you to confirm the result still matches intent.

SUB-AGENTS

implementation-analyst

ARTIFACTS WRITTEN

change-summary.md: cached base..HEAD diff, files grouped by area
implementation diagrams: existing-vs-new views of the change

INTO NEXT CONTEXT

The analyst reads the full diff in its own context and returns the change-summary. Main never loads the raw diff.

YOU

STAGE 5 · INSPECTOR REVIEW

Inspector review

YOU EDITimplementation/inspector-review.md

Your turn to inspect the work. Write findings as plain sentences (the millwright will canonicalise them later), or leave the file empty if it all looks good.

SUB-AGENTS

None. This stage is yours alone.

ARTIFACTS WRITTEN

inspector-review.md: your findings, in whatever wording is convenient

INTO NEXT CONTEXT

Nothing is spawned; the next /mi-continue reads the file and classifies each finding.

AUTO + YOU PICK

STAGE 6 · REVIEW SESSION

Review session

AUTO-FIRED · YOU PICK A MODE

The millwright canonicalises your findings into IR-NNN blocks and works the fix-and-approve loop, fixing, re-checking, and committing, until you type approve.

SUB-AGENTS

review-iteration-runner (one fresh runner per fix iteration)

ARTIFACTS WRITTEN

review-context.md: compact snapshot for the review session
inspector-review.md: findings canonicalised into IR-NNN blocks
review commits: the fixes applied during the loop

INTO NEXT CONTEXT

Each iteration runner gets review-context.md plus the open findings and returns only what it changed.

YOU

STAGE 7 · REVIEW COMPLETED

Review completed

YOU TYPE, THEN ANSWER y/n/mi-continue

The review-resume handler closes the loop and offers to re-render the implementation diagrams if review-loop commits have changed the picture.

SUB-AGENTS

None. Handler logic only, no delegation.

ARTIFACTS WRITTEN

implementation diagrams: re-rendered, if you answered y to the refresh

INTO NEXT CONTEXT

Workflow state in progress.md advances toward completion; nothing heavy is read.

AUTO-FIRED

STAGE 8 · COMPLETION

Completion

AUTO-FIRED BY THE MILLWRIGHT/mi-complete-workflow

The feature ships. Blueprints are archived with their full version history, lessons are recorded, and the queue advances to the next feature, or the cycle ends.

SUB-AGENTS

None. Archival is metadata-only.

ARTIFACTS WRITTEN

blueprints/history/: the full blueprint snapshot, versioned
lessons-learned.md: mistakes captured so future cycles avoid them
todo-list.md: the cycle’s items flipped to IMPLEMENTED

INTO NEXT CONTEXT

Context is flushed at the clear-point. The next queued feature starts fresh back at Stage 2.

WHY IT STAYS FAST

Heavy reads happen in throwaway context

The reason a nine-stage workflow doesn't drown in its own context: every sub-agent is spawned empty, pointed at a specific subset of artifacts, and discarded the moment it returns.

PERSISTS ACROSS THE STAGE

Main orchestrator

Carries the workflow forward. It never reads a codebase file, a raw diff, or a journal transcript directly.

Holds per-feature summaries, progress.md state, the active blueprint.
Grows by ~1k tokens per delegation, not tens of thousands.
Stays small enough that stage 8 runs as fast as stage 1.

DISCARDED ON RETURN

Fresh sub-agent

Spawned empty for a single job. It does the expensive reading, then vanishes. Its context is never merged back.

Reads the codebase, the base..HEAD diff, or journal files as needed.
Pointed at one specific artifact subset, nothing more.
Returns a single structured summary, then dies.

The clear-point gates flush context at every stage boundary; the sub-agents handle the cost between gates. Together they keep a nine-stage cycle as light as a one-stage one.

THE ARTIFACT TRAIL

Everything the workflow writes down

By the end of a cycle the workspace holds the whole story. Every file below is UUID-stamped and cross-linked. Here is where each one lives and what it is for.

THE millwright-inspector/ WORKSPACE

millwright-inspector/
    journal/
        your-notes/
            kickoff-call.md
            id.md
    quest/
        active.md
        2026-06-02-your-notes/
            todo-list.md   summary.md   progress.md
            queue-rationale.md   reference.md   context-ledger.md
    workflow-stream/
        <feature>/
            blueprints/
                current/
                    requirements.md   config.md   decisions.md
                history/
                    versioned blueprint snapshots
            grounding-report.md
            implementation/
                primer.md   change-summary.md   inspector-review.md
                review-context.md   lessons-learned.md
                diagrams/

Quest cycle

quest/<slug>/

todo-list.md

Selectable work items grouped by feature, each with a state, an assignee, and a stable id. The file you mark [x].

summary.md

A per-feature digest of the journal inputs, split so each downstream stage reads only its own section.

progress.md

The single source of truth for workflow state: the feature queue, the completed list, and the active feature.

queue-rationale.md

The audit trail for the stage-1.5 dependency-ordering decision, kept so it survives a session break.

reference.md

A UUID link table tying the cycle to its journal source folders and its workflow-stream feature folders.

context-ledger.md

Per-cycle telemetry of context-heavy reads and delegations, used to catch context regressions.

active.md

The top-level pointer recording which per-cycle quest folder is currently the live one.

Blueprint

workflow-stream/<feature>/blueprints/

requirements.md

Goals, constraints, acceptance criteria, and explicit non-goals for the feature.

config.md

The skills and rules relevant to this cycle, folded into every chain primer.

decisions.md

An append-only log of verbal decisions and scope changes captured during Q&A.

grounding-report.md

A stage-2 audit of the existing code seam each planned change will land in.

blueprint diagrams

PlantUML structural diagrams of the planned change, for you to review.

blueprints/history/

Versioned snapshots of every past blueprint, so any plan can be traced.

Implementation

workflow-stream/<feature>/implementation/

primer.md

A compact context bundle the stage-3 chain starts from, holding a snapshot of the blueprint.

change-summary.md

A cached base..HEAD diff analysis, with changed files grouped by area.

inspector-review.md

Where you write review findings; canonicalised into IR-NNN blocks by the millwright.

review-context.md

A compact snapshot assembled for the stage-6 review session.

lessons-learned.md

A cumulative record of mistakes from PR reviews, read by future cycles to avoid repeats.

implementation diagrams

Existing-vs-new diagrams of the change that actually shipped.

THE HAPPY PATH

Three commands carry the whole cycle

Nine stages, eleven sub-agents, and dozens of artifacts, yet in the happy path you type just these three.

/mi-init

ONCE PER WORKSPACE

The first-run wizard. One y/n installs every missing dependency and scaffolds the journal, quest, and workflow-stream folders.

/mi-run

ONCE PER CYCLE

Turns the named journal folders into a quest, generating the cycle's todo list, summary, progress file, and queue.

/mi-continue

AT EVERY GATE

The universal advance signal. It reads progress.md, dispatches to the right handler, and auto-fires the next launcher for you.

Everything else (/mi-apply-impact, /mi-plan-implementation, /mi-review, /mi-complete-workflow) is auto-fired by the millwright at the right gate. You never type it.

GET BUILDING

Put the millwright to work

Install the plugin, run /mi-init, and let an auditable workflow carry your next feature from a folder of notes to a reviewed branch.

Install the plugin