# Goga Brainstorm Intake

> Input collection and normalization for the brainstorm pipeline

- Skill: `qarium/goga-brainstorm-intake` (Agent Skill)
- Install (CLI): `npx skillmds@latest add qarium/goga-brainstorm-intake`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qarium/goga-brainstorm-intake/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: qarium (https://skillmd.com/u/qarium)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/qarium/goga-brainstorm-intake

---

# 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** — a path to a task file (e.g., the path printed by `goga history path -f task.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.

```md
# [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