product-engineering

Say this	What happens
discovery-loop	Start or resume a supervised end-to-end discovery
frame-intent	Frame a product problem at any altitude
de-risk-intent	Surface the riskiest assumption and design a prototype approach
decompose-intent	Break the converged intent into delivery briefs and specs
ux-writing	Characterize the product voice and write per-state UI copy

---

Which level to enter at

Every intent — from a product bet to a single feature — is the same artifact with one field that differs: Level. The recognized set runs deepest-product-bet first:

product-vision › product-strategy › capability › feature

You enter at the altitude you’re operating at. Most work starts somewhere in the middle; the rungs above exist for when the real bet is higher up.

Level	The question being answered	Enter here when…
product-vision	Should this product exist at all, for whom, and through what wedge?	You’re at a greenfield concept and the existence bet is not yet settled
product-strategy	What is the central challenge, and what path do we take through it?	The product exists but the strategic direction — which problem, which segment, in what order — is the open question
capability	Can we build and operate this platform or capability coherently?	The strategy is set and you’re committing a bounded capability (a billing platform, an API gateway, a data pipeline)
feature	Do users want this specific thing, and does it land?	The scope is already clear — one buildable, shippable slice

The set is open: if your org operates at an altitude the recognized set doesn’t name (an initiative, an epic), name it — Level is a free string, not a fixed ladder.

De-risking shifts with the level. At product-vision and product-strategy, the riskiest assumption is market-existence — will anyone want this at all, can it be a business? That bet is tested once at the top, not relitigated per feature. At capability, the risk is architectural or adoption-shaped. At feature, it’s desirability — do users want this feature?

Decomposition runs one level at a time. A capability intent decomposes into feature intents; a feature intent decomposes into a spec/slice — the shippable unit your delivery loop builds. Each child re-enters the loop at its own level: frame-intent → de-risk-intent → decompose-intent.

---

1. Shape intent

Type frame-intent and describe the product problem — any altitude, any level of clarity. The agent will confirm the level with you before framing begins; if the scope implies a higher bet, it will offer to raise it.

At feature level — the scope is already clear, one shippable slice:

frame-intent

  Level    feature
  Problem  New users don't understand the product's value in the first session.
  User     First-time user arriving after sign-up with no prior context.
  Outcome  Activation rate rises; first-session drop-off decreases.

Ratify framing? ›

At capability level — committing a bounded platform or capability:

frame-intent

  Level    capability
  Problem  Every team builds its own billing integration — no shared primitives.
  User     Engineering teams shipping subscription-based features.
  Outcome  Time to add a new billing flow drops from weeks to days.

Ratify framing? ›

At product-vision level — the existence bet is the open question:

frame-intent

  Level    product-vision
  Problem  Small studios can't afford dedicated developer tooling, so they ship slowly and inconsistently.
  User     2–5-person studio without a dedicated platform engineer.
  Outcome  Studios reach production quality on their first release, not their third.

Ratify framing? ›

• You decide: approve the intent — ratify the framing before the loop diverges. A vague problem means the loop explores the wrong space.
• Output: an intent document with a specific problem, named user, and measurable outcome, stamped with the confirmed Level.
• State: draft

---

2. Diverge across candidates

Type discovery-loop and let the agent run explore-options to generate candidate product shapes with distinct tradeoff profiles.

explore-options

  Shape   Mechanic                      Riskiest assumption
  A       Guided setup wizard           Users complete wizard without abandoning
  B       API-first self-serve          Users tolerate high first-session cost
  C       Community-driven templates    Template quality drives first activation
  D       In-app explainer video        Passive exposure converts without action

• Output: a set of candidate product shapes with distinct tradeoff profiles — each with a named riskiest assumption.
• State: draft

---

3. Run the lens roster

The discovery-lead agent runs discovery-threat-reviewer and discovery-reliability-reviewer against each surviving candidate; each reads cold and returns findings.

discovery-threat-reviewer

  Concern  Shape A: wizard collects account data before trust is established
  Blocker  Shape B: token stored at rest without encryption boundary named

discovery-reliability-reviewer

  Concern  Shape C: community template freshness has no defined staleness bound

• Output: a filtered candidate set with review findings attached; candidates with Blockers are eliminated.
• State: read-only

---

4. Check mid-discovery

The agent surfaces the surviving candidates for your mid-course review.

discovery-loop

  Candidate   Status       Note
  Shape A     surviving    concern addressed — trust framing added
  Shape C     surviving    staleness concern open — carried to convergence
  Shape B     eliminated   token-at-rest blocker
  Shape D     eliminated   no commitment signal detected

Mid-discovery check — confirm candidates? ›

• You decide: choose a candidate — confirm the surviving candidates or direct a re-exploration. This is the last cheap moment to expand the option space.
• Output: a confirmed candidate field ready for convergence.
• State: draft

---

5. Converge on the candidate

The agent runs de-risk-intent to surface the riskiest assumption and design a test, then decompose-intent to break the winning shape into the next level down.

de-risk-intent

  Assumption   Users complete the wizard without abandoning at step 2.
  Kill cond.   < 4 of 6 target users reach step 3 in a moderated prototype session.
  Approach     validate-first — predeclare the line, then run sessions.
  Hook         Conduct 6 moderated prototype sessions with target user profile.

What decompose-intent produces depends on your level:

• At capability or above — child intents at the next level down (e.g. a capability intent produces feature intents). Each child re-enters the loop at its own level and is de-risked independently.
• At feature — one independently shippable feature becomes a delivery contract. Use a delivery brief only when the result coordinates multiple specs or repositories.

A child whose riskiest assumption is killed bubbles back up — the parent must re-decompose or reframe. That feedback edge keeps the tree honest.

• Output: a de-risked candidate with a predeclared kill condition and a named validation hook; then a decomposition one level down — child intents or, at the leaf, a delivery contract unless multi-spec or cross-repository coordination requires a delivery brief.
• State: draft

---

6. Reconcile and commit

The agent presents the full discovery sidecar — intent, assumption-test, validated candidate, and decomposition — for your final review.

discovery-loop

  Section          Status     Notes
  intent           ratified   feature level, onboarding-activation
  assumption-test  done       validate-first, 6 sessions, line predeclared
  candidates       1 of 4     Shape A survived
  decision-brief   ready      validation hook attached

Reconcile? ›

• You decide: approve the decision brief — is the brief complete? Then commit to build — am I ready to build this? These are two distinct decisions; read the brief in full before ratifying either.
• Output: a ratified decision record with a connected hypothesis and validation hooks. One independently shippable feature hands off as a delivery contract; a multi-spec or cross-repository result uses a coordinating delivery brief. A compatible Core invocation admits either through work-intake; otherwise the agent renders a portable bounded handoff. At capability or above it produces ratified child intents — each re-enters the loop independently at its own level.
• State: confirmed-write