manifest-dev

manifest-dev

Hand your agent a task. Get back work you can trust.

manifest-dev is a set of free, open-source skills for coding agents. With it, your agent works out what you mean, writes down what done means, and requires evidence that the intended result and current checks hold. Use one skill, finish a defined task, or assign a project outcome while keeping the decisions you care about.

See it explained → — the available paths, one scene at a time.

Install

Claude Code is the primary target. Inside a Claude Code session, run:

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

Codex, Pi, OpenCode, and Cursor (and with it Grok Bot) install it too (other CLIs). Every skill also works on its own: npx skills add doodledood/manifest-dev --skill figure-out installs just one.

Start with one real question

In the repository you want to work on:

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

Ask about the bug you keep putting off. When a term or a step is unclear, ask /manifest-dev-help: it answers any question about manifest-dev in plain, simple English, with the reason behind each part.

One piece of work

First, it works out what you mean. /figure-out reads your code, finds the question that decides the work, and asks you only what the code can't answer, with its recommended answer first.

Then you agree what done means. /define writes a Manifest: the intended result (Outcome), pieces of work (Deliverables), their acceptance claims (Acceptance Criteria), and rules across the work (Global Invariants). It separates your hard requirements from the agent's working targets and methods.

It builds toward the agreed result. /do requires fresh evidence for the Outcome and every current check. It can correct its own working targets on evidence, reporting the change; your hard requirements need your authorization to change. /do assumes you are away: it decides without asking, reports the decisions it made for you, and raises a blocker as soon as it finds one.

/auto runs all three steps in one go.

What you review: a pull request that shows the change working. When the work ships as a pull request, its top reads in about a minute. It says what changed and why, and shows the change working with screenshots or command output. It lists the decisions it made for you and the debt it left: what it could not fix there, such as a problem that is a project of its own, an unrelated one the project's own rules keep out of the pull request, or a paid check it did not run. The description also lists the old problems the run fixed on the way.

A project that remembers

/setup-project, run once, gives your project a North Star: one file that says what the project is for and for whom, how it measures progress, and what it never does. The choices made along the way go in decision records. Every session reads it before it decides what's worth doing.

It also keeps the project's words, decisions, and checks: a glossary of its terms, a record of each decision and why it was made, and one command that checks the project still works. That command is recommended, not required: a project that already verifies its own way keeps doing so. Every run keeps these current where its work touches them. It also turns a mistake someone caught into a check that catches it next time. It fixes the old problems its work runs into in the same pull request; only one that is a project of its own is left, and offered to the next change through that code.

A shared queue

Work waits as Tickets anyone can pick up. A Ticket carries all a person or an agent needs to do one piece of work and know it's done. /ticket-up writes them, into GitHub Issues, files in the repository, or a tracker you describe; /next-ticket picks the one whose wait costs most.

Coordinate an outcome or run a queue

/orchestrate lending proposes a plan over the lending effort's ready Tickets and waits for approval by default. --autonomous runs within the assignment without those plan approvals. A finite queue assignment ends when its work is exhausted; the flag does not turn it into ongoing project operation.

For outcome coordination, give the outcome, relevant evidence, and limits. For example:

/orchestrate help readers get the next available book without volunteer chasing.
Use the lending report and support cases. You may investigate and propose work.
I retain product direction, final acceptance, sending, and spending. Work this round only.

The coordinator can commission inquiry or delivery, read results, and continue, wait, ask, or finish. Every independently managed job gets a Ticket before dispatch. Related source messages can form one case; routine reasoning needs no separate Tickets. Completed code is delivery evidence. Whether people use it and achieve the intended result is a separate question.

One status page shows progress, evidence waits, and what needs you. A wait names its recommendation, evidence, risk, and next step. Continuation uses an available host wake or a manual resume; manifest-dev adds no scheduler. Missing evidence or access gets a concrete acquisition step or ask.

Decide what to delegate

Review looks broadly for defects and material costs in using or maintaining the result. By default, findings and severity labels are evidence about those requirements; the executor can reject a finding with supported reasoning. A deliberately required review threshold or approval still binds. Real failures and missing necessary evidence prevent completion, and supported review decisions survive a restart unless new evidence changes them.

An assignment says what to do now: investigate, review, build, or coordinate. Delegation says which decisions it may make inside that work. Existing skill defaults remain; you only need to state adjustments. /setup-project reads existing instructions and shows the exact shared or personal text before saving new choices. When you accept coordination, it asks which decisions you keep. A run with no person present flags those offers and writes nothing. Shared rules live in the project's context file or a reachable companion; personal rules stay in your private instructions.

You can delegate visual direction and still retain acceptance of the rendered result. Accepting a version does not accept a materially changed version. Technical delegation also preserves a team's required review. A worker keeps the intent, evidence, and current authority through handoffs and stops dependent work at a retained decision.

Auto on a Ticket permits full completion under its grant and repository rules. A Ticket without Auto can still be investigated or prepared up to the retained decision: a Question returns an answer, while implementation can return a ready pull request. Feedback resumes the same job. The flag, a tool, a source message, or a new Ticket never supplies wider authority.

Isolated checks can expose instruction defects; reliable sustained project progress, and autonomous business operation in particular, remain to be established through actual use.

Choose an entry point

Choose what you need; there is no required sequence:

• Understand a question — /figure-out investigates and recommends. It does not start implementation. Product questions can explore what people are trying to accomplish, what they use today, and what would make them try or keep using a solution.
• Finish defined work — /define makes a finite Manifest; /do executes it. /auto combines understanding, definition, and execution when that is the assignment.
• Prepare a project — /setup-project connects its existing direction, words, decisions, and checks, and offers a principles skill for each area where the team has repeatedly said how it wants the work done; /create-principles-skill adds or refreshes one later. It resolves coordination settings only when you want them, and starts no work.
• Track or work one job — /ticket-up writes a Question Ticket for inquiry or a Shaped Ticket ready for delivery; /next-ticket selects one; /run-ticket works that exact Ticket. An inquiry can go directly from /figure-out to /ticket-up without a Manifest.
• Coordinate work — /orchestrate proposes a queue plan or pursues an explicitly assigned outcome. --autonomous acts within that assignment and its limits.

Each choice works on its own, including inside a team that does not use manifest-dev. The plugin README explains each skill.

What it costs

More effort up front, less checking after. manifest-dev is free and open source (MIT). It spends more tokens and time before building than prompting an agent directly, and unattended runs spend them on work you may still turn down. It's built for experienced developers who would rather put the effort in before building than review afterwards. If shipping fastest is all that matters, a plain agent fits better.

What's in it

Two plugins ship from this repository:

Each plugin's README lists what it ships.

Other CLIs

The Claude Code plugins are the source, and the same skill text serves every host: OpenCode, Pi and Cursor read it from the source tree, and Codex installs a generated copy under dist/.

Individual skills install into many other agents through npx skills add doodledood/manifest-dev --skill <name>.

Decisions behind the multi-CLI design are indexed in docs/adr/.

Development

Setup needs Python 3.10+ and Node 22.18+, and Java 11+ only for the ticket protocol model (scripts/verify drive ticket-protocol-model).

./scripts/setup.sh
source .venv/bin/activate

scripts/check.sh --fix                # lint and format, typecheck, test while iterating
scripts/verify drive property-suite   # the same checks through the harness, before a pull request

Run python3 scripts/sync_dist.py after changing plugin components; the test suite fails when a generated copy drifts.

Contributing

This is built for its author's own projects and shared as it's used. See CONTRIBUTING.md for how the plugins are put together.

License

MIT