Skip to main content

/normalize

Turn a raw product exploration into the canonical PRD when it never went through the product-side normalizer. This is the R&D-side fallback for the Product โ†’ R&D handoff: work that predates the plugin โ€” or that reached R&D as an engineering spec + a mockup + ticket remarks instead of a PRD โ€” has no document /plan-feature can consume. /normalize backfills that PRD by invoking the prd-writer agent on the intake.

This is not the default path. The canonical normalizer is the product-side Cowork flow in docs/methodology/product-authoring.md. /normalize exists only for when that step was skipped, so R&D is not blocked waiting for a PRD that no one produced. It does product's job as a stopgap โ€” the resulting PRD is a draft the product owner (e.g. Gali) must review and own before it is treated as ready.

Argumentsโ€‹

$ARGUMENTS โ€” the intake: a ClickUp link (or CU-id) plus the exploration material (a spec doc/URL, a mockup HTML/Figma URL, and remarks). The minimum the normalizer needs is a ClickUp link + a mockup + a spec/remarks. If any is missing, ask for it โ€” do not proceed on a guess.

Stepsโ€‹

  1. State the boundary up front. Announce that the canonical path is the Cowork normalizer (product-authoring.md) and that /normalize is running it as a fallback because no PRD exists for this work item. Make clear the output is a draft the product owner must confirm โ€” most of all any decision the normalizer had to assume rather than resolve.

  2. Confirm there is no PRD already. Look for docs/prds/<slug>-<cu-id>.md for this CU-id. If one exists, stop โ€” this is not a normalization gap; route to /handoff (validate the PRD) or /plan-feature (PRD โ†’ Design Doc) instead.

  3. Gather the intake โ€” spec + mockup + remarks + ClickUp link from $ARGUMENTS. Detect whether the intake contains HOW (API contracts, schemas, architecture, library choices): that is R&D's territory leaking into product's. Carry it as source material, but the PRD you produce restates it as WHAT/WHY requirements, never as the mechanism.

  4. Invoke prd-writer on the intake. The agent owns the procedure โ€” reading the brand context in docs/company/, filling the PRD template, anchoring ยง7.2 UI to COMPONENTS.md (never inventing components, never raw hex), itemizing ยง7.2.a deltas, writing copy as text, and self-checking the Definition of Ready. The PRD lands at docs/prds/<slug>-<cu-id>.md. Do not duplicate that logic here โ€” this command is only the entry point.

  5. Stop and ask on ambiguity โ€” never design forward. Where the intake is silent or self-contradictory, prd-writer surfaces the question rather than inventing an answer. Any gap the normalizer had to fill with an assumption is recorded as an Open Question flagged for the product owner, not silently resolved.

  6. Link the ticket; do not flip status. Set the PRD's clickup_parent / clickup_url to the work item (a real CU-id โ€” never a TBD/CU-pending placeholder). Leave status: draft. Flipping to ready-for-rd is the product owner's call after gatekeeper Mode A validates the Definition of Ready (run via /handoff).

Boundariesโ€‹

  • Fallback, not default. If the product owner can still run the Cowork normalizer, prefer that โ€” it keeps authorship on the product side. Use /normalize only when that did not happen.
  • The PRD is a draft pending the product owner's sign-off. /normalize does product's job under a deadline; it does not assume product's authority. Flag every assumed answer for the owner โ€” especially P0-blocking Open Questions โ€” and hand the document back to them to own.
  • No HOW in the PRD. The intake may be an engineering spec; the PRD restates requirements as WHAT/WHY. Implementation belongs in the Design Doc (/plan-feature), not here.
  • Thin wrapper. The authoring procedure lives in prd-writer; this command must not restate it. If prd-writer changes, /normalize follows for free.