mcpField
B
brainstorming

brainstorming

github.com/dev-toolingsAgent workflows22788 installsUpdated 4w ago
Repository

About brainstorming

A Symfony skill for clarifying feature requirements and comparing designs before implementation planning. It maps a feature to Symfony components, records tradeoffs and risks, then hands the chosen design to writing-plans.

Key features

  1. 01Clarify goals, scope, and open questions
  2. 02Map features to Symfony components
  3. 03Compare designs and tradeoffs
  4. 04Record decisions, rejected options, and risks
  5. 05Hand off the chosen design to writing-plans

Use cases

  1. 01Explore a feature with unsettled requirements
  2. 02Compare approaches before choosing a design
  3. 03Identify Symfony components affected by a feature

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/dev-toolings/superpowers-symfony --skill brainstorming

After installing, type/brainstormingin Claude Code to confirm it loaded.

Details

From the project README

Brainstorming (Symfony)

Use when

  • 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. 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

  • 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

  • The goal, scope and answered questions.
  • The components involved and the recommended design with its tradeoffs.
  • Open risks, ready to feed writing-plans.

References

Comments

Markdown supported