Work Order Writer
free skill · agency-operations
Write a work order an agent or a contractor can execute end to end without asking a question. Use when delegating a task, briefing an agent, writing a spec, or when work keeps coming back wrong.
Install it
bash
/plugin marketplace add mambalabsdev/mamba-labs-skillsWhat it does
Work comes back wrong when the brief specified the output but not the done state, the constraints, or what to do at a fork. This skill writes the four sections that remove the ambiguity, and the one that most briefs omit entirely: the halt conditions, which say when to stop and ask rather than guess.
When to use it
- write a work order
- brief this task
- delegate this properly
- the work keeps coming back wrong
- write a spec for an agent
What it needs from you
- goal: what must be true when this is finished
- context: where the work happens and what already exists
- limits: budget, time, and what must not be touched
How it works
- Write the done state as a condition that can be checked by someone who was not involved. Not improve the thing, but the thing measures above a number, verified this way.
- Write the steps in order, with each one producing something the next one consumes. A step that produces nothing is a hope.
- Write the constraints as prohibitions, not preferences. What must not be changed, what must not be published, what must not be deleted.
- Write the halt conditions: the situations where the executor should stop and ask rather than choose. This is the section that separates a brief that works from one that produces confident wrong work.
- Name where the output goes and in what form, because output that lands in the wrong place is close to output that does not exist.
- Include the verification: how the executor proves it worked, and make it a check that could fail. A verification that cannot fail proves nothing.
- Say what supersedes what, if this replaces an earlier brief, so nobody executes the old one.
What you get back
A work order with goal, done state, ordered steps, constraints, halt conditions, output location, and a verification that could fail.
The quality bar
- The done state is checkable by an uninvolved person
- Halt conditions are present and specific
- Constraints are written as prohibitions
- The verification is a check capable of failing
- Superseded briefs are named
Where it runs
- Claude Code
- Codex CLI
- Cursor
- MCP-compatible agents
Get the skill
We will email you the install command and a link to the skill. No account, no purchase.