Work Order Writer

What this 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.

Requirements

This skill needs no account, API key or paid service. It works from the files, exports and answers you give it, in any agent that reads SKILL.md.

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

Inputs

• 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

Shared context this skill reads

Before doing anything else, read whichever of these exist at the project root and use them instead of asking the user to repeat themselves:

• BRAND.md

If none exist, do the work from what the user gives you, then offer to write the missing file so the next skill in the pack starts warmer.

Tool connection

This skill needs no live data tool. It works from the files, exports and answers you give it, so it runs the same in any agent with no setup.

Method

1. 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.
2. Write the steps in order, with each one producing something the next one consumes. A step that produces nothing is a hope.
3. Write the constraints as prohibitions, not preferences. What must not be changed, what must not be published, what must not be deleted.
4. 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.
5. 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.
6. Include the verification: how the executor proves it worked, and make it a check that could fail. A verification that cannot fail proves nothing.
7. Say what supersedes what, if this replaces an earlier brief, so nobody executes the old one.
8. Check the output with scripts/check-output.py before you return it.

Approval stop

This skill does not send email or write to a CRM. If the user asks it to, stop first: show what would be sent or written and wait for an explicit yes.

Output

A work order with goal, done state, ordered steps, constraints, halt conditions, output location, and a verification that could fail.

Check the output before you return it

Save the output to a file and run python3 scripts/check-output.py <file>. The contract it checks is scripts/output-contract.json.

• Exit 0, COMPLETE: return the output.
• Exit 2, INCOMPLETE: do not present the output as finished. Fill what you can, run the check again, and if parts stay missing, return the output under the heading Incomplete with every reason the check printed.

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

Related skills

• results-doc-verifier
• knowledge-write-discipline
• friction-log-to-rules

Ships in the agency-delivery, knowledge-ops-pack packs.