← ClaudeAtlas

brainstorm-and-planlisted

Use before ANY creative work — creating features, building components, adding functionality, modifying behavior, or starting a new project. Also use when someone says 'build', 'create', 'add', 'implement', 'let's make', or describes something they want built. Do NOT write code until a design is approved and a plan is written.
burhankhatri/e2e-testing · ★ 15 · AI & Automation · score 65
Install: claude install-skill burhankhatri/e2e-testing
# Brainstorming and Planning ## Part 1: Brainstorming — Design Before Code <HARD-GATE> Do NOT write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE> ### Anti-Pattern: "This Is Too Simple To Need A Design" Every project goes through this process. A todo list, a single utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short, but you MUST present it and get approval. ### Process: 1. **Explore project context** — check files, docs, recent commits 2. **Ask clarifying questions** — one at a time, prefer multiple choice when possible 3. **Propose 2-3 approaches** — with trade-offs and your recommendation. Lead with recommended option and explain why. 4. **Present design** — in sections scaled to complexity, get user approval after each section. Cover: architecture, components, data flow, error handling, testing. 5. **Write design doc** — save to `docs/specs/YYYY-MM-DD-<topic>-design.md` and commit 6. **Spec self-review:** - Placeholder scan: Any "TBD", "TODO", incomplete sections? Fix them. - Internal consistency: Do sections contradict each other? - Scope check: Focused enough for a single plan, or needs decomposition? - Ambiguity check: Could any requirement be interpreted two ways? Pick one. 7. **User reviews written sp