manifest-dev

Your agent builds the wrong thing, confidently.

Not broken code — wrong code. It compiles. The tests pass. And it solves a problem you don't have, because the agent started typing before it understood what you meant.

/figure-out is the pushback. An adversarial thinking partner. It digs through your codebase on its own and presses on the question that decides the work. It refuses to touch code until you both know what "right" is, holds its position under pushback, and changes its mind when the evidence changes.

npx skills add doodledood/manifest-dev --skill figure-out

/figure-out why do half my background jobs silently stall?

A minute in, it has read your code and come back with the question you hadn't thought to ask. That first question is the fastest way to find out whether this tool is for you.

Every skill here works standalone. Take what you want. No framework to adopt, nothing else to install. If you never run another command from this repo, /figure-out still earns its keep.

The loop was never the hard part

Everyone's writing loops now: the shift from prompting an agent by hand to designing the system that prompts it. But a loop pointed at a shallow understanding just ships the wrong thing faster. And the loop vouches for itself. It runs, declares victory on a confident summary. You find out in review.

The leverage lives upstream of the while: understand the problem before anything is built, define what "done" means, then verify it independently. That's the rest of manifest-dev: loop engineering, with a stop condition you can trust.

manifest-dev puts understanding first, adversarially, before /define writes anything down. Most spec-driven tools generate the spec straight from your description, so the spec runs only as deep as what you already said.

manifest-dev rides on top of whatever runs your loop, including your host's own /loop and /goal, and leaves scheduling jobs and managing worktrees to that runtime. It supplies the part those primitives leave to you: what to verify, and how to know you're actually done.

Quick Start

The one-skill door is above. The full system installs as a plugin:

# Claude Code (primary)
/plugin marketplace add doodledood/manifest-dev
/plugin install manifest-dev@manifest-dev

For OpenCode, Codex CLI, and Pi, see Multi-CLI Support below.

Then work through the three beats:

/figure-out <topic or problem>     # 1. Figure it out — understand before acting
/define <what you want to build>   # 2. Encode what you'd accept into a manifest
/do <manifest-path>                # 3. Execute and verify every criterion inline
/do <manifest-path> --verification consolidated  # opt in to one verifier per round
/do <manifest-path> --verification self          # opt in to executor verification
/do <manifest-path> --exhaustive-verification    # opt in to re-sampling every judgment gate each round

/auto <what you want to build>     # Or run all three, chained, no approval gates

/define takes the understanding you reached and encodes it into a manifest, auto-invoking /figure-out first if you skipped ahead. /do implements toward the manifest and can't call it done until every criterion has fresh evidence under the selected mode, keeping a default-on execution log of deviations and dead ends as it goes (--no-log skips it). The default per-gate mode runs one fresh independent verifier per gate, concurrently, so each gate gets a whole reader to itself; opt-in consolidated puts the outstanding gate set through a single verifier in sequence, which pays off where the gates are many and each is slight, and opt-in self trades independence for the lowest execution cost. --verifier-model <model> optionally selects the independent verifier model and is invalid with self. Re-verification follows each gate's declared kind: a gate whose verdict comes from a command re-runs in full, while a gate whose verdict is a model's judgment takes one full look and afterwards judges only its prior findings' repairs and what changed since — so runs converge on repaired findings instead of on a review round that happens to come up empty (--exhaustive-verification restores full re-sampling — more rounds, for a better chance of catching what a first read walked past; without it a defect sitting in ground already judged once stays missed). /auto chains all three with no waiting and forwards the same execution flags without putting them in the manifest.

For unattended runs of /do or /auto (the recommended way to run both), set your host's goal-setting or continuation capability to the completion contract those skills print; see the manifest-dev plugin README for the full contract text and why it's shaped that way.

Babysit an existing PR through review without any manifest-dev setup: /babysit-pr [pr-url]. Details in the manifest-dev-tools README.

Pass --canvas to /figure-out for a refreshable, browser-rendered map of the session alongside the chat, readable on any screen: the crux tree with the question you're standing on marked on it, what's still open around it, and how much ground is still unsurveyed. Annotate it in place and hand your notes back in one paste.

How It Works

flowchart TD
    A["/figure-out 'problem'"] --> B["Shared understanding"]
    B --> C["/define"]
    C --> D["Manifest = what you'd accept"]
    D --> E["/do manifest.md"]
    E --> F{"For each Deliverable"}
    F --> G["Implement toward ACs"]
    G --> H["Evaluate gates under selected mode"]
    H -->|any FAIL| I["Fix everything the round found"]
    I -->|re-verify per head| H
    H -->|all PASS| J["/done"]
    F -->|risk surfaces| K["Consult trade-offs, adjust approach"]
    K -->|reachable| F
    K -->|stuck| L["/escalate"]
    classDef gate fill:#15803D,stroke:#0F172A,color:#FFFFFF;
    classDef done fill:#0F172A,stroke:#15803D,color:#FFFFFF;
    classDef stop fill:#B45309,stroke:#0F172A,color:#FFFFFF;
    class H gate;
    class J done;
    class L stop;

FAIL routes back to a fix; a real blocker (amber) routes to /escalate.

What Changes

Your first pass lands closer to done, and the fix loop cleans up what's left on its own. Writing acceptance criteria also keeps you engaged with your own code. That matters more the more you lean on the agent, right when the codebase starts to feel like someone else wrote it.

[!TIP] Resist the urge to jump in mid-/do. It won't nail everything first try; that's expected. You invested in understanding the problem, so let the loop run.

Who This Is For

You've burned out on the weekly "game-changing AI coding tool" cycle and want something grounded that works. You're an experienced developer who cares more about output quality than raw speed, and you've learned the hard way that AI code needs guardrails more than cheerleading. If you count every cent per token, or want the fastest possible output regardless of what it costs you in review, this isn't your thing.

Multi-CLI Support

The Claude Code plugins are the source of truth. The same components run in OpenCode, Codex CLI, and Pi through native per-CLI distributions under dist/, all carrying the same topology-neutral gate schema and run-level verification modes.

Individual skills also install into 18+ agents (Cursor, Copilot, Cline, and more) via npx skills add doodledood/manifest-dev --skill <name>.

Each linked README covers that CLI's install, upgrade, and uninstall path. Architecture decisions behind the multi-CLI design are indexed in docs/adr/.

Available Plugins

Full plugin and skill catalogs live in claude-plugins/README.md and each plugin's own README.

Development

# Setup (first time)
./scripts/setup.sh
source .venv/bin/activate

# Lint, format, typecheck, test
ruff check --fix claude-plugins/ tests/ && black claude-plugins/ tests/ && mypy && python3 -m pytest tests/

After changing plugin components, run /sync-tools to regenerate the dist/ distributions.

Contributing

See CONTRIBUTING.md for plugin development guidelines.

License

MIT

Built by developers who understand LLM limitations, and design around them.

Follow along: @aviramkofman