`discover`

Take raw signal — interviews, journeys, a strategy question — to a requirement a human has ratified, so design starts from an agreed problem rather than an assumed one.

Use it when: Use when the user is deciding what to build, scoping a feature, or turning stakeholder conversations into requirements.
Comes with: The product-manager pack
Where you decide: Ratify (G0): you decide
Size: 4 stages · 1 gate · up to 3 revision rounds

npx skilldrop-cli install --loop discover

Installs the loop as an invokable skill, plus every skill its stages run.

Other ways to install

Every loop in its pack, with their skills:

npx skilldrop-cli install --loop --pack product-manager

The loop alone, without its stage skills (each stage falls back to an inline version):

npx skilldrop-cli install --loop discover --no-skills

In Claude Code, the product-manager plugin includes it:

/plugin install product-manager@skilldrop

The loop

%%{init: {'theme':'base','themeVariables':{'fontFamily':'Segoe UI, Helvetica, Arial','fontSize':'15px','lineColor':'#9AA5B1'},'flowchart':{'curve':'basis','rankSpacing':70,'nodeSpacing':50,'padding':16}}}%%
flowchart LR
    classDef gen    fill:#E8F0FE,stroke:#4C7DF0,stroke-width:1.5px,color:#1A3A8F;
    classDef review fill:#FDEAEA,stroke:#E05B5B,stroke-width:1.5px,color:#8A1F1F;
    classDef gate   fill:#FBE3A2,stroke:#D9971E,stroke-width:2px,color:#6B4500,font-weight:bold;
    classDef ship   fill:#E6F7EC,stroke:#34A853,stroke-width:2px,color:#0F6B33,font-weight:bold;

    gather["gather<br/><small>requirements-interview +3</small>"]:::gen
    structure["structure<br/><small>brief-intake</small>"]:::gen
    specify["specify<br/><small>prd-draft</small>"]:::gen
    ratify["ratify<br/><small>doc-critique</small>"]:::gate
    G0{"G0 · human"}:::gate
    DONE(["complete"]):::ship

    gather --> structure
    structure --> specify
    specify --> ratify
    ratify --> G0
    G0 == "PROCEED" ==> DONE

    G0 -- "REVISE (max 3)" --> structure

Stages

#	Stage	What it does	Skills	Gate
1	gather generate	Collect the raw signal from whichever direction it arrives: a stakeholder conversation, an existing user journey, or a strategic question.	`requirements-interview`, `user-journey-map`, `strategy-analysis`, `feedback-synthesis`	—
2	structure generate	Turn the mess into one brief with every field tagged explicit / implied / inferred / missing, so downstream can see what was assumed.	`brief-intake`	—
3	specify generate	Turn the ratified brief into numbered requirements a design can be held to.	`prd-draft`	—
4	ratify gate	A human agrees this is the problem worth solving. The critique informs that decision; it does not make it.	`doc-critique`	G0 — you decide PROCEED · PROCEED WITH CONDITIONS · REVISE · RECONSIDER · BLOCKED

The first loop of the lifecycle, and the cheapest one to run twice. Everything downstream inherits whatever this loop got wrong, which is why it ends at a human gate rather than a script: no check can tell you that you solved the wrong problem well.

How to run this loop

Gather from whichever direction the signal arrives. A stakeholder conversation → requirements-interview. An existing experience with known friction → user-journey-map. An open strategic question → strategy-analysis. A pile of tickets, survey verbatims or interview notes already collected → feedback-synthesis. Run one; running several on the same input produces several views of the same thing and no more information.
Structure once. brief-intake tags every field [explicit] / [implied] / [inferred] / [missing] with verbatim quotes. The tags are the deliverable — an untagged brief hides which parts are somebody's assumption.
Resolve the missing before specifying. brief-intake ends with what the downstream skill will refuse to start without. Answer those; do not let prd-draft invent them.
Specify. prd-draft turns the brief into numbered requirements a design can be held to.
Ratify at G0. Run doc-critique against the PRD, then put the decision to a human. The critique informs; the human decides. REVISE returns to structure, not to specify — a weak PRD almost always means a thin brief.

Verdicts

Defined in contracts/terminals.json. G0 emits PROCEED, PROCEED WITH CONDITIONS, REVISE, RECONSIDER, or BLOCKED. RECONSIDER leaves the loop: the problem itself is wrong, and no amount of re-briefing fixes that.

Non-interactive runs

With no human present, G0 cannot be satisfied. Emit BLOCKED: need ratification of <the brief's central claim> and stop. Do not self-ratify — a fabricated goal corrupts every artifact the other four loops produce.

When a stage's skill is not installed

Name the missing skill and skilldrop as its source, do the minimal inline version of that stage, and record that it ran degraded. Never skip G0.

Run log (opt-in)

Only when the environment variable SKILLDROP_LOOP_LOG is set to a file path: after each gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is sent anywhere. When the variable isn't set, or you can't read it, skip this section.

printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"discover","stage":"ratify","gate":"G0","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"

Fields: ts (UTC), loop, stage, gate (null for a stage without one), verdict (the gate's exact word), and round (1 for the first attempt, counting returns under the cap). skilldrop loop-stats summarises the file: which gates pass first time, which loop back, and which end in BLOCKED.

Quality bar

Every field carries a provenance tag. A brief that does not distinguish quoted from inferred cannot be ratified, only believed.
[missing] is resolved or stated, never filled. Inventing the goal, the customer, or the success measure is the one failure this loop exists to prevent.
The requirements are numbered and testable. "Fast" is not a requirement; a latency target is.
A human ratifies before design starts. G0 is the loop's only reason to exist — an unratified brief is a draft, whatever the critique said.

Anti-patterns to avoid

❌ Running every gather skill to be thorough. Three lenses on one input is not three inputs; pick the one that matches where the signal came from.
❌ Letting prd-draft fill a [missing] field. That converts an open question into a fact nobody agreed to.
❌ Treating doc-critique's SHIP IT as ratification. The critique judges the document; G0 judges the problem.
❌ Returning REVISE to specify. Re-writing the PRD from the same thin brief reproduces the same gaps in better prose.

Source

LOOP.md · loop.json on GitHub · Why loops