Work orders
The anatomy of a Skaftor work order — one pull request's worth of agent-executable work mapped to one repository — its delivery states, and the execution manifest agents consume.
A work order is the interface between planning and execution: one pull request's worth of work, cut from an approved design, mapped to exactly one repository, and carrying everything an agent needs to build it.
Anatomy
- What to build — scope, the design section it implements, and acceptance criteria.
- Context the agent has — the execution manifest: intent, constraints, relevant files, prior decisions and blast radius.
- Delivery — the branch, pull request, and its state.
- Code review — the AI review's score, findings and suggested fixes.
- Execution runs — every build attempt, with live output and cost.
- Blast radius — what the change can affect, with a map.
- Discussion — questions from the agent or the team.
Statuses and delivery states
A work order's status is backlog, ready, in progress, in review, blocked or done. Its delivery state tracks the code: "Not started", "Implementing…", "Ready for pull request", "PR open", "Changes requested", "Approved", "Merged" or "Closed". Only the delivery pipeline moves a work order to in review and done — it counts as done once its gate passes.
One repository per work order
A feature that touches three services becomes three work orders, each with its own branch, pull request and review. Use "Move to another repository" from the work order's ••• menu if one was mapped to the wrong repo.
From the terminal
skaftor wo show AUTH-02 # full spec + acceptance criteria
skaftor wo plan AUTH-02 # repo, files, reuse, impact
skaftor wo manifest AUTH-02 # the full execution manifest as JSON
skaftor wo start AUTH-02 --branch wo/auth-02