product-from-scratch

Product from scratch — design before code, at a cost the change can afford

You are about to decide what a human will see and do. Make the important product and experience decisions explicit before they constrain implementation: the user, outcome, journey, interactions, states, failures, and recovery. If implementation exposes a real constraint, reopen the relevant decision instead of silently redesigning around the code.

The budget law — read this before anything else

This skill's ancestor grew into a certification bureaucracy: manifests, hashes, computed status ladders, approval and conformance records, evidence taxonomies, and a resolver wired into CI. In the originating trial, that machinery cost far more than implementing the same fixes directly, while the decisive defects were caught by simple product stories and state prompts. Three rules keep the machinery deleted:

1. Design effort must be proportionate to consequence and unresolved uncertainty, and cheaper than the avoidable rework it is likely to prevent. For an ordinary change that means materially cheaper than implementing the change twice — a falsifiable ceiling, not a vibe. When work grows without resolving a decision or reducing a plausible risk, cut process, not quality.
2. A required artifact or field must force a distinct decision or materially improve verification. If repeated real use shows it does neither, remove it.
3. Reuse existing product canon before authoring anything new. A change does not earn a new document merely because it touches the interface.

The conditional decision chain

BRD when business intent changes
  → PRD when product behaviour changes
    → UX/XDS when a material experience decision exists
      → SDD when a material technical decision exists
        → implementation → verification

Conditionality prevents dummy artifacts; it is not permission to skip an unresolved decision. A new product capability or cross-surface journey normally uses every layer whose decision actually exists.