workflowworkflowtrueorfalse
work-order
Turns an ask into a scoped work order file with acceptance criteria, story points and verify commands.
looks for
- a task accepted with no written scope
- "add X" requests that touch several files or modules
- scope creep mid-task
- an estimate or sprint slot is needed
outputs
- → {{WORK_ORDERS_DIR}}/WO-YYYYMMDD-short-slug.md
- → story points with a one-line rationale
- → acceptance criteria and out-of-scope list
drawing flowchart…
SKILL.md
Work order
A work order (WO) is the contract for one piece of work. If it is not in the WO, it is not in scope.
File location
{{WORK_ORDERS_DIR}}/WO-YYYYMMDD-short-slug.md
Story points (Fibonacci only)
| SP | Effort | Use when |
|---|---|---|
| 1 | < 1 hr | Config tweak, copy fix, single field |
| 2 | ~2 hrs | One file, one function, one test |
| 3 | ~4 hrs | One feature slice (model + service, or page + hook) |
| 5 | ~1 day | Full feature (model + service + route + tests, or a full page) |
| 8 | ~2 days | Cross-module or multi-phase |
| 13 | ~3–4 days | Epic slice: break it up before starting |
| 21 | > 1 week | Too big: decompose; no estimate is valid |
Want to write 4, 6 or 7? Round up.
Template
# WO-YYYYMMDD-short-slug
**Status:** draft | ready | in_progress | blocked | in_review | done | cancelled
**Priority:** P0 | P1 | P2 | P3
**Story points:** 1 | 2 | 3 | 5 | 8 | 13 | 21
**Sprint:** YYYY-Wxx | backlog
**Style:** directive | collaborative | delegated | review-gate
**Primary owner:** <role>
**Reviewers:** <optional>
**Modules touched:** <list>
**Created:** YYYY-MM-DD
## Goal
One sentence.
## Background
Why now. Link docs instead of pasting them.
## Acceptance criteria
- [ ] ...
- [ ] All verify commands pass
## Out of scope
- Item — why excluded
## Phases
| Phase | Deliverable | SP | Gate |
|---|---|---|---|
| 1 — name | what ships | n | check command |
| N — Docs + handoff | docs updated | 1 | verify sign-off |
## Touch list
- `path/to/file` — reason
## Dependencies
- WO-… must land first / runs in parallel
## Verify commands
| Module | Command |
|---|---|
| {{MODULE}} | `{{VERIFY_COMMAND}}` |
## Handoff log
_(append entries — see the handoff skill)_
Management styles
| Style | Use when |
|---|---|
directive | Hotfix; zero ambiguity; exact steps listed |
collaborative | Cross-module; tech lead and implementer plan together |
delegated | Single module; outcome only; implementer owns the approach |
review-gate | UI redesign; cannot close until design review passes |
State rules
- Only the primary owner or the manager changes status.
blockednames the blocker and who must act.doneneeds a verify PASS in the handoff log.- Never put secrets, tokens or customer data in a WO.
Customize for your project
{{WORK_ORDERS_DIR}},{{MODULE}},{{VERIFY_COMMAND}}.- Your sprint length and capacity (e.g. 20 SP per person-week).
- Standing out-of-scope items your product never does.
pairs with
- workflowtrueorfalse
handoff
Records done / not done / decisions / files / risks / next 3 actions so work survives a role switch or a pause.
- end of a session with work unfinished
- a role switch inside a work order
- QA failed and goes back to the implementer
Claude · Codex · ChatGPT - ruletrueorfalse
agent-team
Routes each ask to one owning role, then enforces work order → specialist → verify → handoff.
- a new task with no clear owner
- work that touches more than one module or repo
- who should do this?
Claude · Codex · ChatGPT - personatrueorfalse
eng-manager
Turns asks into work orders, sizes them, assigns one owner, and closes them only after verify passes.
- a brand-new ask
- work spanning more than one module
- a sprint plan or backlog question
Claude · Codex · ChatGPT - personatrueorfalse
qa-verifier
Runs the real checks, records an honest PASS/FAIL/PENDING report in the work order, and never fakes green.
- implementation finished
- a request to close a work order or merge
- is it green?
Claude · Codex · ChatGPT