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

/setup-project sets up the first of these, along with a glossary, decision-record conventions, and a way to verify the project between runs, 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.

The codebase gets easier to change, run by run

An agent copies the nearest example and takes the easiest path that passes its checks. So the workflow works on the path itself, inside the same four commands, with nothing extra to run: