Brainstorming Requirements And Backlog

Requirements Phase is the sole route from bounded requirements to delivery-depth backlog projection. It runs Requirements Grill, Create Spec, and Write Backlog in that order.

You can invoke it directly with ordinary bounded requirements. Finder is optional context: when a Fog, Finder child, Research child, Prototype child, or durable Finder handoff is supplied, Requirements Phase preserves that provenance without making it a prerequisite.

• Use this when: scope, terms, acceptance signals, testing decisions, or implementation constraints still need closure.
• It gives you: closed requirements, an agent-ready specification with neutral OUT-### outcome identities, and exact provider delivery identities when projection is requested.
• It does not require: a Fog, a prior Finder invocation, an existing Story, or a fixed count of Grilling children, specifications, Stories, or Tasks.
• Wrapped skills: $requirements-grill, $create-spec, then $write-backlog for delivery projection.

Runtime Graph

Close Requirements

requirements-grill owns the human interview. It keeps question identities, prerequisites, frontier membership, locked decisions, glossary terms, acceptance criteria, non-goals, and parked scope durable. It can use $show-me when a relationship is materially easier to understand visually.

Finder evidence is input, not authority to skip closure. Research and Prototype can support a requirements branch, but they never authorize backlog projection independently.

Compile Outcomes

create-spec consumes closed decisions without running a second interview or mutating the provider. It uses neutral OUT-### identities for accepted product outcomes. Those identifiers express specification traceability; they do not pretend that Story identities already exist.

Derive The Backlog

write-backlog derives the actual Epic, Story, and Task identities from the retained specification and fresh provider evidence. It does not require a pre-existing Story and does not copy OUT-### identifiers into provider objects as false Story identities.

Each derived Story must remain a shippable product outcome. Each derived Task must be atomic, independently ownable, understandable within its Story, and traceable to stable specification authority. These quality rules impose no cardinality.

The writer validates the complete reachable blocker graph before mutation. Missing targets, future-version blockers, self-edges, cycles, or inconsistent milestone membership produce zero writes. Existing exact objects are enriched; title-only or ambiguous candidates stop the operation. Material hierarchy or roadmap changes require an authority-derived preview and explicit approval.

Flow

1. Invoke $requirements-phase with bounded requirements and any optional Finder context.
2. Run $requirements-grill until the active frontier is closed or explicitly parked.
3. Run $create-spec to compile neutral OUT-### outcomes.
4. Follow the named upstream route when compilation returns spec-not-ready.
5. Retain and verify the agent-ready specification at an immutable source link.
6. Run $write-backlog to derive and read back the provider hierarchy, Stories, Tasks, milestone membership, and blockers.
7. Run $create-plan with those exact provider Task identities and dependencies rather than inventing a second private Task graph.

Terminal Outcome

Downstream delivery receives a verified agent-ready specification plus exact provider work identities when projection was requested. Validate the requirements frontier, OUT-### traceability, immutable spec link, derived hierarchy, Story and Task quality, complete blocker graph, and exact provider readback.