Brainstorming Requirements And Backlog

Requirements to backlog is the first harness gate. $grilling owns generic question scheduling and closure; $requirements-grill adds requirements pressure tests and durable state before accepted work becomes backlog.

Backlog output uses an EPIC -> stories hierarchy. The EPIC is the parent capability boundary. Child stories or sub-issues are the independently observable product slices beneath that EPIC.

• Use this when: project context, decisions, scope, glossary, or backlog shape are still unclear.
• It gives you: project knowledge and context persisted into an EPIC with child stories or sub-issues.
• It ends with: accepted backlog structure that downstream spec and delivery work can trust.
• Wrapped phase/skills: $requirements-phase, $requirements-grill, $write-backlog.

Runtime Graph

The flow is a sieve: unclear intent stays in the grill, accepted scope crosses into backlog, delivery receives only the shape it can trust. Read the arrows as ownership transfers, not status updates.

Reading The Gate

• Setup first: the agent needs the requirements skills and wiki surface before it can preserve project context.
• Grill is the pressure chamber. $grilling owns scheduling and closure; $requirements-grill keeps stable ids, prerequisites, current-frontier membership, and answer state durable.
• $write-backlog receives accepted material only. Parked scope stays parked.
• The provider must preserve EPIC plus child stories. Delivery should not have to reconstruct intent from prose.

Entrypoints

• $requirements-phase: wrap the whole requirements gate as one lifecycle slice.
• $requirements-grill: run the active interview for branch closure, glossary decisions, non-goals, acceptance criteria, and parked scope.
• $write-backlog: consume the grill log/status after $requirements-grill completes, then turn accepted requirements into backlog items.

Maturity Rule

A requirement is ready for backlog after $requirements-grill completes and its accepted branch can survive implementation planning without invention. The evidence is a grill status and log that name stable question ids and prerequisites, current-frontier membership, answered and unanswered state, locked decisions, glossary terms, acceptance criteria, non-goals, and parked scope.

The backlog derives from accepted requirements only. Parked or unresolved scope stays visible as parked or unresolved; it should never be smoothed into work the team did not agree to.

Backlog Shape

$write-backlog formats accepted requirements as EPICS plus child stories or sub-issues.

• One EPIC maps to one coherent parent capability and one future SPEC.md.
• Every child story or sub-issue under that EPIC must remain visible, not flattened into parent prose.
• Story order, blockers, and parent/child relationships must use native tracker fields when the provider supports them.
• EPIC and story bodies stay product-facing. Execution details move later into SPEC.md, PLAN.md, IMPLEMENTATION-NOTES.md, review notes, validation logs, or debt artifacts.
• Deferred or parked work becomes backlog notes, future EPIC/story candidates, or non-goal context; it must not be silently absorbed into committed story scope.

Provider Mapping

Provider details should preserve the same hierarchy instead of flattening it.

For GitHub-backed backlog sync, use GitHub Projects V2 and Issues together:

• create the target Project V2 when it does not exist
• map module/milestone to a repository milestone plus Project grouping field
• map each EPIC to a parent issue in the Project
• map each story to a child issue or sub-issue under its EPIC
• store story order with native issue dependencies

An issues-only GitHub path is not enough for this model when Projects V2 is available.

Flow

Keep the execution strict:

1. The agent confirms dp scaffold init has prepared requirements skills and a wiki tree when the repository needs them.
2. Invoke $requirements-grill from the available source material.
3. Run $requirements-grill; it owns requirements pressure tests and persists each round and response.
4. Invoke $write-backlog after $requirements-grill completes.
5. Create an EPIC for each accepted parent capability.
6. Create every accepted requirement slice as a child story or sub-issue under its target EPIC.
7. Preserve child-story detail when a parent capability absorbs multiple requirements.
8. Move to Implementation or AFK Implementation once backlog scope is accepted.

Decision Points

• If the user says the scope is only a narrow closure, keep the backlog slice exact.
• If requirements change the implementation scope, update backlog before planning.
• If a branch is intentionally parked, name the parked branch and avoid forcing a premature decision.
• If child stories or sub-issues carry important acceptance detail, preserve them instead of flattening everything into an EPIC summary.

Handoff Contract

The handoff is a set of accepted backlog items with enough context for downstream spec work. The next agent should be able to see the target EPIC, every child story or sub-issue under it, what was decided, what was rejected, what remains open, and which stories block each other.

Terminal Outcome

The backlog mirrors accepted requirements, unresolved questions remain visible, parked scope stays parked, and downstream spec work has enough context to avoid invention.

Validation

Check that grill status, grill log, and backlog output agree on closed branches, open questions, non-goals, acceptance checks, EPIC boundaries, child stories or sub-issues, and story blockers.