git:20261005.042befb to git:20261005.e6a4c05

16 added, 12 removed. Audit A to A.

---

name: brainstorming

description: Structured brainstorming for Symfony projects - explore requirements, identify components, and plan architecture collaboratively

capabilities: [read, search]

tags: [workflow]

# projected by `bun run build` — do not edit by hand

allowed-tools:

- Read

- Glob

- Grep

---

# Brainstorming (Symfony)

## Use when

- - Refining architecture/workflows/context handling in Symfony projects.

- - Planning and executing medium/complex changes safely.

+ - A feature request is still vague and the requirements are not settled.

+ - Several designs are possible and the tradeoffs must be compared before choosing.

+ - You need to know which Symfony components a feature touches (entities, handlers, API resources, security, async) before planning.

+ - The decision must be made before a plan is written; once it is, hand off to `writing-plans`.

## Default workflow

- 1. Establish current boundaries, constraints, and coupling points.

- 2. Propose smallest coherent architectural adjustment.

- 3. Execute in checkpoints with validation at each stage.

- 4. Summarize tradeoffs and follow-up backlog.

+ 1. Restate the goal in one sentence and list what is known, unknown and out of scope.

+ 2. Ask the open questions (users, data, permissions, failure cases) and note the answers.

+ 3. Map the feature onto Symfony components: entities, services and handlers, API resources, voters, messages.

+ 4. Propose two or three designs with their tradeoffs and recommend one.

+ 5. Record the chosen design, the rejected options and the open risks, then hand off to `writing-plans`.

## Guardrails

- - Use existing project patterns by default.

- - Avoid broad refactors without explicit need.

- - Keep decision log clear and auditable.

+ - Do not write code or a step-by-step plan here: brainstorming ends at a chosen design.

+ - Prefer the patterns already present in the project over new ones.

+ - Ask one question at a time instead of guessing a missing requirement.

+ - Keep rejected options in the notes so the decision stays auditable.

## Progressive disclosure

- Use this file for execution posture and risk controls.

- Open references when deep implementation details are needed.

## Output contract

- - Architecture/workflow changes.

- - Checkpoint validation outcomes.

- - Residual risks and next steps.

+ - The goal, scope and answered questions.

+ - The components involved and the recommended design with its tradeoffs.

+ - Open risks, ready to feed `writing-plans`.

## References