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. **Propose 2-3 approaches** — with trade-offs and your recommendation
6. **Present design** — in sections scaled to complexity, get user approval where required
7. **Write spec artifact** — save a Spec Brief or Design Spec under `docs/aegis/specs/` when persistent requirements are needed
8. **Spec self-review** — check for placeholders, contradictions, ambiguity, scope, boundary
9. **User reviews written spec** — ask user to review before proceeding
10. **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`, `ImpactStatementDraft`, `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.

**Product Risk Lens:** For ambiguous product, feature, UI, workflow, or
architecture choices, add a compact review lens, not persona roleplay:

```text
Product Risk Lens:
- Value:
- Non-goals:
- Trade-offs:
- Decision needed:
```

This is a review lens, not persona output. It does not override baseline evidence,
approved requirements, or current authority docs; it only makes the product risk
and decision point visible before implementation.

**Plan-Time Complexity Check:** Before choosing an implementation direction for
medium/high work, inspect the likely owner files and current shape. This is an
advisory design pressure check, not a gate and not completion authority. Do not
force it onto tiny low-risk edits.

Use `using-aegis/references/complexity-governance.md` for the shared artifact
classes, pressure-signal interpretation, and over-budget handling.

```text
Complexity Budget:
- Artifact class:
- Target files / artifacts:
- Current pressure:
- Projected post-change pressure:
- Budget result: within-budget | at-risk | over-budget
- Planned governance:

Plan-Time Complexity Check:
- Better file boundary:
- Recommendation: edit-in-place | extract helper