Step 4 · Definition

The PM cuts a third of my request, then three specialists build

The product-manager agent reads the research first and writes the PRD. Then a product designer, a prototyper, and a tech architect work from that PRD in parallel. This is the stage where my original ask got edited, on the record.

What this stage wrote to disk

4 agents · 4 documents + the prototype
prd.mdrequirements R1-R11, two validation experiments, three release gates193 lines
design-spec.mdedit mode, entry points, accessibility intent, built on the step-2 tokens203 lines
tech-spec.mdassumed architecture, data model, workstreams, effort ranges251 lines
demo.htmlworking prototype, embedded below48 KB
research/prototype-manifest.mdwhat the demo proves vs. what it fakes67 lines

The scope decision

I asked for three things. One got killed.
kept · V1

Reorder

Extends the app's existing "pin what you use to the top" idea (Starred) from content to navigation.

kept · V1

Hide, reversibly

Hidden items drop into a "More" group, one tap away. Never destructive, and "New chat" can never be hidden.

cut from V1

Default landing screen

No positive comparator precedent anywhere. Changes app-open behavior for a majority well served by chat home. Triggered a kill condition in the competitive research.

prd.md · product-manager

"The idea as proposed is three features: reorder + hide + set-default-landing-section. The research does not support shipping all three, and it does not support treating this as an obvious win."

"Two hard gates precede heavy investment… Gate 1 (skewed-usage cohort) — Validation Experiment 1 must show the target cohort exists at meaningful scale before build."

The architect prices it honestly

tech-spec.md · tech-architect

"Neither kill condition is cleanly triggered, but the money is in the wrong place if you build UI-first. Build the model and the telemetry first (they are the durable, reusable assets); do not fund per-platform edit-UI parity until Gate 1 confirms the cohort exists."

"Reusing Starred here means reusing a mental model for users, not a code path for engineers. Treat nav preferences as a new subsystem, and price it as one."

Its effort math, carried into the verdict: roughly 1 eng-week for the instrumentation, 7 to 12 eng-weeks for an Android-only beta, 12 to 21 for cross-platform parity. Those numbers are why "instrument first" is a real decision and not hedging.

The prototype, playable

built to the step-2 design language

Working drag-to-reorder, reversible hide into "More," the locked New-chat anchor, and a first-run discovery prompt. State lives in memory only. Open the hamburger menu, tap Edit, and drag.

The prototyper also filed a manifest separating what the demo proves from what it merely depicts, which is what let the risk sweep audit it honestly:

Real interaction

  • Drag-to-reorder, touch and mouse
  • Hide / unhide with a "More" group
  • Locked "New chat" anchor
  • Done / Cancel / Reset
  • First-run discovery coach mark

Static or faked

  • Status bar, greeting, composer
  • No real navigation or routing
  • No sync, no persistence
  • Almost none of its own accessibility intent

Open the prototype full screen →