brainstorming

# Execute

→ New feature, product behavior, UI/component design, architecture/contract change, or ambiguous medium/high-complexity work? → **Design first. No implementation until the needed design/spec is approved.**
  1. Explore project context → read authority docs, check for existing patterns
  2. Ask clarifying questions one at a time (prefer multiple choice)
  3. Propose 2-3 approaches with trade-offs and your recommendation
  4. Present design sections → get user approval after each
  5. Write spec → self-review → user review → transition to writing-plans
→ HARD GATE: For tasks that match this skill, do NOT write code, scaffold projects, or invoke implementation skills until design/spec approval is satisfied.

# Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context and authority boundary, then ask questions one at a time to refine the idea. Once you understand what you're building, present the smallest design artifact that stabilizes the work and get the required approval.

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, or take implementation action for work that matches this skill until you have presented the required design/spec and the user has approved it where this workflow requires approval.
</HARD-GATE>

## Route Away When It Is Small

Do not force this workflow onto low-complexity work. A tiny wording edit,
single-owner bug fix, simple config/status question, or local utility change
can proceed through concise intent, baseline check, TDD/debugging, and
verification. If uncertainty or impact grows, escalate back here and write the
smallest stabilizing spec.

## Checklist

You MUST create a task for each of these items and complete them in order:

1. **Explore project context** — check files, docs, recent commits, authority docs, CONTEXT.md
2. **Choose the path and scope** — real design? diagnosis? route accordingly or decompose first
3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
4. **Draft working artifacts** — `TaskIntentDraft`, `BaselineReadSetHint`, `BaselineUsageDraft`, `ImpactStatementDraft`
5. **Run existence check when adding new surfaces** — only if an approach adds a new owner, skill, artifact, adapter, fallback, workflow step, or benchmark metric
6. **Propose 2-3 approaches** — with trade-offs and your recommendation
7. **Present design** — in sections scaled to complexity, get user approval where required
8. **Write spec artifact** — save a Spec Brief or Design Spec under `docs/aegis/specs/` when persistent requirements are needed
9. **Spec self-review** — check for placeholders, contradictions, ambiguity, scope, boundary
10. **User reviews written spec** — ask user to review before proceeding
11. **Transition to implementation** — invoke writing-plans skill (terminal state)

**The terminal state is invoking writing-plans.** Do NOT invoke any other implementation skill.

## The Process

**Understanding the idea:**
- Check current project state first (files, docs, recent commits)
- Read relevant authority docs before asking deep questions
- If the request is diagnosis/root-cause/follow-up to an approved plan → route to correct workflow
- If the request spans multiple independent subsystems → flag and decompose first
- Ask clarifying questions one at a time, prefer multiple choice
- Separate facts, assumptions, unknowns while exploring

**Working artifacts:** Keep four drafts: `TaskIntentDraft` (outcome, goal,
success evidence, stop condition, non-goals, scope, risks),
`BaselineReadSetHint` (candidate docs, authority gaps),
`BaselineUsageDraft` (required refs, optionally delivered context refs,
acknowledged-before-plan refs, cited refs, missing refs, advisory decision),
and `ImpactStatementDraft` (affected layers, owners, invariants, compat,
non-goals). Refresh when scope changes.

**Compact output contract:** `TaskIntentDraft`, `BaselineReadSetHint`,
`BaselineUsageDraft`, `Requirement Ready Check`, `ImpactStatementDraft`,
`Existence Check`, `Product Risk Lens`, `Architecture Integrity Lens`,
`Baseline Role Alignment`, `Plan-Time Complexity Check`, `Options`, and
`Decision Needed`. Use this compact shape before expanding into a full design
structure.

Use a compact `BaselineUsageDraft` whenever the design direction depends on
specific baseline docs or current-authority refs:

```text
BaselineUsageDraft:
- Required baseline refs:
- Delivered context refs:
- Acknowledged before plan refs:
- Cited in design refs:
- Missing refs:
- Decision: continue | needs-baseline-readback | needs-verification | pause-for-user | blocked
```

`Delivered context refs` is optional host-projected bookkeeping only. It is not
authoritative proof that a host injected or the model internally consumed a
context payload. The artifact exists to make baseline/context attention drift
visible before the design is recommended or approved.

Use a compact `Requirement Ready Check` before recommending a design when the
requirement is not already confirmed and complete:

```text
Requirement Ready Check:
- Requirement source refs:
- Goals and scope refs:
- User / scenario refs:
- Requirement item refs:
- Acceptance / verification criteria refs:
- Open blocker questions:
- Decision: ready | needs-source | needs-goal-alignment | needs-scenario | needs-acceptance-criteria | needs-clarification | needs-user-decision | blocked
```

Treat task intent, conversation, source documents, and agent inference as
candidate requirement sources until project authority confirms them. If the
decision is not `ready`, keep the design at proposal/spec clarification level;
do not turn the gap into implementation tasks.

**Existence Check:** Before recommending an approach that adds a new owner,
skill, artifact, host adapter, fallback, compatibility path, workflow step, or
benchmark metric, check whether it nee