| name | goga-brainstorm-intake |
| description | Input collection and normalization for the brainstorm pipeline |
goga-brainstorm-intake
Identity
You are responsible for accepting and normalizing the user's architecture request.
Workflow
Phase 1. Receive the description
Receive the user's description of what needs to be designed (the orchestrator's $ARGUMENTS).
Retain the original description verbatim for the entire session.
Phase 2. Classify the description
Classify the description into one of:
- Brief — one sentence or a feature name
- Detailed — a complete specification with requirements, constraints, examples
- Task file — path to
docs/tasks/<topic>.md
Phase 3. Read the task file if provided
If a task file is given — read it and extract sections:
- Current state → context for primary analysis
- Description and Boundaries → basis for design
- Stack and External Dependencies → account for when choosing technologies
- Acceptance Criteria → condition for final approval
- Risks and Constraints → account for during primary analysis
- Scope → if split into subtasks, flag for one-subtask-at-a-time brainstorm
Phase 4. Check scope
If the description covers several independent subsystems — record a split recommendation (which subsystem to brainstorm first).
Output Format
Fill every section. No empty sections.
# [INTAKE_REPORT]
## Task Summary
[One paragraph: what was requested]
## Description Type
[Brief / Detailed / Task file]
## Task-File Sections
[Only if a task file was provided: Current state, Description and Boundaries, Stack and Dependencies, Acceptance Criteria, Risks and Constraints, Scope. Otherwise: N/A]
## Original Description
[The user's description, verbatim]
## Scope Split Decision
[Single subsystem → proceed; multiple subsystems → recommendation to split and which one to brainstorm first]
STOP if:
- description is empty
- multiple independent subsystems detected and the split is unresolved