home / skills / makfly / superpowers-symfony / brainstorming

brainstorming skill

safe

This skill helps refine Symfony architectures and execution workflows with controlled scope, checkpoints, and auditable decision logs to support safe

npx playbooks add skill makfly/superpowers-symfony --skill brainstorming

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.1 KB

---

name: symfony:brainstorming
allowed-tools:
  - Read
  - Glob
  - Grep
description: Apply production-grade Symfony architecture and execution workflows with controlled scope and clear checkpoints. Use for brainstorming tasks.
---

# Brainstorming (Symfony)

## Use when
- Refining architecture/workflows/context handling in Symfony projects.
- Planning and executing medium/complex changes safely.

## Default workflow
1. Establish current boundaries, constraints, and coupling points.
2. Propose smallest coherent architectural adjustment.
2. Execute in checkpoints with validation at each stage.
2. Summarize tradeoffs and follow-up backlog.

## Guardrails
- Use existing project patterns by default.
- Avoid broad refactors without explicit need.
- Keep decision log clear and 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.

## References
- `docs/complexity-tiers.md`

Overview

This skill applies production-grade Symfony architecture and execution workflows with controlled scope and clear checkpoints. It helps teams brainstorm targeted, low-risk changes while keeping decisions auditable and reversible. Use it to align architecture decisions to current project patterns and operational constraints.

How this skill works

I inspect current boundaries, coupling points, and constraints in your Symfony code and deployment surface. I propose the smallest coherent architectural adjustment, break the change into checkpoints, and define validation steps for each checkpoint. After execution I summarize tradeoffs, residual risks, and a prioritized follow-up backlog.

When to use it

Refining architecture or context-handling patterns in an existing Symfony app.
Planning medium-complexity changes that must be safe and incremental.
Designing execution workflows with validation gates and rollback points.
Aligning a team on constrained scope and auditable decision logs.
Preparing a phased migration or feature-flag rollout strategy.

Best practices

Start from existing project patterns and only deviate when justified.
Define clear, small checkpoints with pass/fail validation for each step.
Document decisions, reasons, and rollback options in a decision log.
Avoid broad refactors; prefer minimal, testable adjustments.
Include automated and manual validation steps at each checkpoint.

Example use cases

Introduce a new context or service layer while preserving legacy controllers with migration checkpoints.
Add a feature-flagged subsystem and roll it out gradually with validation steps and metrics.
Refactor coupling between domain services and infrastructure in small, reversible increments.
Design a deployment workflow that adds health checks and canary releases for Symfony workers.

FAQ

How granular should checkpoints be?

Make checkpoints small enough to validate a single hypothesis or risk—code compile, unit tests, integration smoke, and a controlled deploy. If a checkpoint fails, you should be able to revert without touching later work.

Do you recommend full architecture rewrites?

No. Prefer incremental adjustments that reuse existing patterns. Full rewrites are high-risk; reserve them for cases where technical debt makes maintenance impossible and plan them with explicit migration checkpoints.