manifest-dev

See it explained → One request, run with a plain agent and then with manifest-dev.

Skills for agentic coding CLIs. They keep three things in your project instead of in your head: what it's becoming, what's worth doing next, and what done means here. The agent reads them, works against them, and checks the result before reporting it finished.

Agents can write almost anything. What they can't do is tell you whether it was worth writing. So a project drifts: every session re-derives the direction from scratch, and speed produces more work than anyone can evaluate. Writing those three things down where the agent reads them is the whole idea.

Start with one command, in any repository:

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

It reads your code first, then comes back with the question that decides the work. Nothing gets built until you both know what "right" means here.

The three things, and where they live

Each one makes the next decidable. You can't judge what's worth doing without knowing what the project is for, and you can't judge a diff without knowing what done means:

What it answers	Where it lives	Lifetime
What is this project becoming?	A North Star, in the repo	Stands until you change it
What's worth doing next?	A Ticket, in your tracker or in files	As long as that piece of work
What does done mean here?	A Manifest, written per run	Resets every run

/init-context sets up the first of these, along with a glossary and decision-record conventions, seeding them from the project's own history where there is any. /ticket-up writes the second. /define writes the third, and /do executes against it.

Install

Claude Code is the primary target:

/plugin marketplace add doodledood/manifest-dev
/plugin install manifest-dev@manifest-dev

Every skill also works on its own. If you only want the one from the top of this page:

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

The workflow

Three skills, run in order, though each is useful alone:

/figure-out <topic>          # understand the problem before touching anything
/define <what you want>      # write down what you'd accept
/do <manifest-path>          # build it, then verify every criterion

/figure-out carries the investigation forward until it needs your knowledge, judgment, or authority, or can give a supported conclusion. Short progress messages do not require acknowledgment to continue.

/define turns understanding into a Manifest: the deliverables, the criteria each one has to meet, and the rules that hold across all of them. It calls /figure-out first if the conversation hasn't reached understanding yet.

The default is durable work that makes subsequent changes easier to do correctly. Quality reviews require proportionate improvements to the work being done, respect explicit scope limits, and accept sound existing structure. Defect repairs must prevent the demonstrated mechanism when a concrete, proportionate boundary is available, or justify a weaker remedy.

/do implements against that Manifest and can't report completion until every criterion has evidence behind it, so "it's done" is a finding rather than a claim.

flowchart TD
    A["/define"] --> B["Manifest — what you'd accept"]
    B --> C["/do"]
    C --> D["Implement"]
    D --> E["Verify every criterion"]
    E -->|any fail| F["Fix, re-verify"]
    F --> E
    E -->|all pass| G["Done, with evidence"]
    E -->|blocked and no independent work| H["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 E gate;
    class G done;
    class H stop;

/auto chains all three without stopping for approval between them.

/do assumes you are away: it makes decisions without asking follow-up questions, including after a steering message. It may revise the planned size of the change before doing broader work when that produces a better long-term solution to your requested outcome. Explicit exclusions and binding requirements stay fixed. It reports material choices afterward, surfaces blockers promptly, and continues useful independent work before escalating.

For an unattended run, /do sets a host-native goal-setting or continuation contract before implementation, with the Manifest’s absolute path included. Where a host offers neither capability, the executor prints the same contract for you to apply manually. /auto leaves this to the executor: understanding and definition have no continuation goal, so an interruption there needs a restart.

An executor’s goal names the resolved file directly, for example:

Work under the Manifest at /workspace/manifests/search.md until every Acceptance Criterion and Global Invariant in it holds, each with evidence from the artifacts that gate names, and completion has been reported. Read this file before resuming execution.

What it costs

More tokens and more work up front than prompting directly. What you get back is a first pass that lands closer to done and a result you can check rather than take on trust. Writing acceptance criteria also keeps you engaged with your own code, which matters more the more of it the agent writes.

Resist jumping in mid-/do. It won't get everything first try — that's what the verify loop is for.

What's in it

Two plugins ship from this repository:

Plugin	What it covers
manifest-dev	The workflow itself, project setup, ticket authoring and execution, first-principles design with composable artifact and creative-direction guides (/design), artifact review, and the review skills the criteria call on
[`manife