Menu
Intake a PRD and decompose it into dispatchable work orders under .factory/orders/. Use when Guillaume supplies a PRD, feature request, or asks to "run this through the factory".
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Design and install a focused Agent Skill from a plain-language request. Use when the user asks to create, add, customize, or install a reusable skill for their Harness agent.
Create or change a recurring market review, alert, or bounded position-management Routine and its optional Mandate. Use when the user asks the agent to remember work on a cadence, monitor a condition, send an alert, or manage a position until a condition is met.
Plan, execute, and verify a trade or position-management request without inventing transaction parameters. Use when the user asks to place, open, buy, sell, long, short, close, cancel, reverse, or otherwise change account state.
Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.
Plan a huge chunk of work — more than one agent session can hold — as a shared map of investigation tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
Dispatch one work order to its delegate model via pi, then run the review gate and commit on pass. Use after /factory-prd has written orders and Guillaume confirmed the dispatch plan.
| name | factory-prd |
| description | Intake a PRD and decompose it into dispatchable work orders under .factory/orders/. Use when Guillaume supplies a PRD, feature request, or asks to "run this through the factory". |
Turn a PRD (argument text, a file path, or the current conversation) into
work orders ready for /factory-dispatch. This skill produces PLANNING
ARTIFACTS ONLY — no code changes, no delegate invocations.
Read the PRD. If the argument is a file path, read it; if it's inline text, use it; if empty, ask Guillaume for the PRD. Restate the goal in one sentence and list acceptance criteria you can verify.
Interrogate repo state before decomposing. Grep/read the touched
areas (respect reading discipline: grep first, bounded reads). Identify
existing utilities to reuse — never order new code where a suitable
implementation exists. Check .factory/PITFALLS.md for constraints that
shape the design.
For UI/layout WPs: measure the component's real rendered size range before writing acceptance criteria — check its grid span, the page's media queries, and compute (or probe) the actual min/max container width. Never anchor acceptance to an assumed viewport. (Learned on monitor-row-overlap: the order fixed "no overlap at ~900px viewport" without knowing the panel shrinks to ~230px there — the delegate executed a perfect fix to an insufficient spec.)
Decompose into 1–N work packages. Each WP must be:
Write the orders. Slug the feature (<slug>), then write
.factory/orders/<slug>/wp1.md, wp2.md, … from
.factory/ORDER_TEMPLATE.md. Fill every section — exact absolute file
lists, verbatim load-bearing payloads, acceptance criteria, validation
commands. An order a delegate could misread is a defective order.
Print the dispatch plan as a table: WP → goal → delegate → risk notes → suggested order (note WPs that must run serially vs can parallel).
Confirm before dispatch. End by asking Guillaume to confirm (or
amend) the plan. Do not invoke /factory-dispatch without confirmation
while the factory is human-in-the-loop.
After the feature ships, fold anything that creaked (bad decomposition,
missing pitfall, unclear order section) back into CLAUDE.md,
.factory/PITFALLS.md, or these skills.
