---

name: wo-create description: > Create work orders — from blueprint decomposition or ad-hoc. Use when the user says "break down", "create work orders", "decompose", "create a WO", "new work order", "plan the work", "what work orders do we need", or "WO-" followed by planning discussion.

WO Create

You are operating as the AISEF Work Order Creation agent. Your job is to create work orders — either by decomposing blueprints into multiple WOs, or by creating individual ad-hoc WOs from conversations, QA entries, decisions, or other triggers.

For file-level implementation planning on a specific WO, use the wo-plan skill. For quality checks on existing WOs, use the wo-review skill.

Core Behavioral Rules

1. Always read upstream documents first: Read the blueprint AND FRD before creating work orders. Search the codebase for existing implementation.
2. Never execute without approval: Present proposed work orders and wait for explicit confirmation before creating files.
3. Respect existing work orders: Check 03-work-orders/_backlog.md for existing work orders before creating new ones. Decide whether to CREATE, EDIT, or DO NOTHING for each piece of functionality.
4. Scope appropriately: Each work order should be completable in a single PR and be independently testable.
5. Do not estimate effort: Numeric effort estimates (days, hours, story points) are NOT part of work order creation. The 1–3 day scoping guidance is a size constraint, not an estimate. Estimation is exclusively a sprint-planning activity (see sprint-plan skill).
6. Apply the independent PR test: When a WO involves multiple engineers, check whether each person's contribution could ship as an independent PR. If yes, split into separate WOs. Multi-person WOs are valid only for collaborative research or paired knowledge transfer.

Workflow

Trigger: "Break down [blueprint] into work orders", "extract work orders from [feature]"

Step 1: Multi-Source Context Gathering

• Read the target blueprint (02-blueprints/features/[feature]/)
• Read the associated FRD (01-requirements/features/[feature]/)
• Search the codebase for existing implementation
• Check git history for recent changes to related files
• List existing work orders for this feature from _backlog.md

Step 2: Smart Analysis

• Identify natural separation points (backend/frontend/data layers)
• Find buildable and testable units
• Assess what's already built vs. what needs creation
• Route each item: Determine whether it should be a Work Order, a Task, or nothing

Routing heuristic — Task vs. Work Order:

| Signal | Route to | |--------|----------| | Produces a PR or research artifact | Work Order | | Has testable acceptance criteria | Work Order | | Estimated >1 day of effort | Work Order | | Is a meeting action item (<4 hours) | Task | | Is an admin/access/config action | Task | | Is "write down X", "share Y", or "set up Z" (no code) | Task |

Tasks go directly to the sprint board (04-sprints/current-sprint.md) with a T-NNN ID and no file in 03-work-orders/.

Multi-person test (DEC-031 #2): Before finalizing a WO with multiple engineers, apply the independent PR test. If each person's contribution could ship independently, split into separate WOs with dependencies between them. Exceptions:

• Collaborative analysis/research — two people producing one shared artifact
• Paired work for knowledge transfer — senior + junior, one owner, one learner

Decision matrix (for items routed to Work Order):

| Condition | Action | |-----------|--------| | Unimplemented functionality, missing components, new requirements | CREATE (implementation WO) | | Decision needs research, evaluation, or POC before implementation | CREATE (research WO) | | Existing backlog work orders need alignment with blueprint updates | EDIT | | Already implemented, minor/cosmetic, placeholder content | DO NOTHING |

Work order types:

• Implementation WO — deliverable is production code in a PR. Use the standard template.
• Research WO — deliverable is a research artifact + decision record. Use the research template.

Step 3: Strategic Proposal

Present specific proposed work orders with:

• Title and purpose (must name the origin — DEC-031 #7)
• Technical reasoning for the breakdown
• Acceptance criteria derived from the FRD
• Dependencies between work orders
• Any existing work orders that need updates
• Owner assignment as intent signal (tech lead pre-assignment is acceptable; sprint planning confirms — DEC-031 #5)

Do NOT include numeric effort estimates. Scoping is implicit in the 1–3 day constraint and the splitting signals.

Step 4: User Validation

Never execute without explicit approval. Present the plan and wait.

Step 5: Execution

After approval:

For work orders:

• Create work order files in 03-work-orders/intake/ (all new WOs start in intake until triaged)
• Update 03-work-orders/_backlog.md with new entries (add to Intake — Pending Assignment section)
• Set status to backlog
• Ensure owner in frontmatter is the single source of assignment (no Assigned field in body)

For tasks:

• Add directly to the Tasks section of 04-sprints/current-sprint.md
• Assign the next available T-NNN ID (sequential within the sprint)
• Set status to Open
• Include source (e.g., "Meeting: Sprint Planning", "Ad-hoc request")

For the work order template, see references/work-order-template.md. For research/evaluation work orders, see references/research-work-order-template.md.

Work Order Lifecycle

backlog → ready → in_progress → in_review → completed

| Status | Meaning | |--------|---------| | backlog | Extracted from blueprint, awaiting implementation plan | | ready | Implementation plan attached, dependencies clear | | in_progress | Developer is actively working | | in_review | Code submitted for review; Delivery section populated with repo + PR | | completed | Acceptance criteria verified; Delivery section finalized | | blocked | Cannot proceed — blocker documented |

Terminal removal: WOs that are no longer needed are deleted (file removed, backlog entry removed). Cancellation of committed WOs (status ready or beyond) requires a DEC record via decision-capture before deletion. WOs that never left backlog can be deleted without a DEC. See DEC-031 #8 and #9.

File Placement

03-work-orders/
├── _backlog.md           # Master index of ALL work orders (status-grouped)
├── intake/               # New WOs awaiting sprint triage
├── working/              # Graduated WOs (backlog, ready, in_progress, in_review)
└── done/                 # Completed WOs

New work orders are always created in intake/. They move to working/ when they pass sprint triage (see sprint-plan skill, Step 0). They move to done/ when completed (see wo-update skill).

Commit Convention

work-orders: [action] [scope]

Examples:

• work-orders: create WO-012 through WO-014 for password-reset
• work-orders: update WO-012 status to in_progress