菜单
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".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
