원클릭으로
brainstorming
// Use when creating or developing anything, before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
// Use when creating or developing anything, before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
Build AI-first applications with RAG pipelines, embeddings, vector databases, agentic workflows, and LLM integration. Master prompt engineering, function calling, streaming responses, and cost optimization for 2025+ AI development. Includes local LLM inference with Ollama for 93% CI cost reduction.
Use this skill when designing REST, GraphQL, or gRPC APIs. Provides comprehensive API design patterns, versioning strategies, error handling conventions, authentication approaches, and OpenAPI/AsyncAPI templates. Ensures consistent, well-documented, and developer-friendly APIs across all backend services.
Use this skill when documenting significant architectural decisions. Provides ADR templates following the Nygard format with sections for context, decision, consequences, and alternatives. Helps teams maintain architectural memory and rationale for backend systems, API designs, database choices, and infrastructure decisions.
Create beautiful ASCII art visualizations for plans, architectures, workflows, and data
Capture content from JavaScript-rendered pages, login-protected sites, and multi-page documentation using Playwright MCP tools or Claude Chrome extension. Use when WebFetch fails on SPAs, dynamic content, or auth-required pages.
Use this skill when designing database schemas for relational (SQL) or document (NoSQL) databases. Provides normalization guidelines, indexing strategies, migration patterns, and performance optimization techniques. Ensures scalable, maintainable, and performant data models.
| name | brainstorming |
| description | Use when creating or developing anything, before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation |
Transform rough ideas into fully-formed designs through structured questioning and alternative exploration.
Core principle: Ask questions to understand, explore alternatives, present design incrementally for validation.
Announce skill usage at start of session.
Activate this skill when:
Skip brainstorming when:
Examples of clear requirements (no brainstorming needed):
| Phase | Key Activities | Tool Usage | Output |
|---|---|---|---|
| 1. Understanding | Ask questions (one at a time) | AskUserQuestion for choices | Purpose, constraints, criteria |
| 2. Exploration | Propose 2-3 approaches | AskUserQuestion for approach selection | Architecture options with trade-offs |
| 3. Design Presentation | Present in 200-300 word sections | Open-ended questions | Complete design with validation |
Goal: Gather purpose, constraints, and success criteria.
Process:
Tool Usage: Use AskUserQuestion for clarifying questions with 2-4 clear options.
Example: "Where should the authentication data be stored?" with options for Session storage, Local storage, Cookies, each with trade-off descriptions.
See references/example-session-auth.md for complete Phase 1 example.
Goal: Propose 2-3 different architectural approaches with explicit trade-offs.
Process:
Trade-off Format:
| Approach | Pros | Cons | Complexity |
|---|---|---|---|
| Option 1 | Benefits | Drawbacks | Low/Med/High |
| Option 2 | Benefits | Drawbacks | Low/Med/High |
| Option 3 | Benefits | Drawbacks | Low/Med/High |
See references/example-session-dashboard.md for complete Phase 2 example with SSE vs WebSockets vs Polling comparison.
Goal: Present complete design incrementally, validating each section.
Process:
Typical Sections:
Validation Pattern: After each section, pause for feedback before proceeding to next section.
Benefits:
Flexibility is key. Go backward when needed - don't force linear progression.
Return to Phase 1 when:
Return to Phase 2 when:
Continue forward when:
| Principle | Application |
|---|---|
| One question at a time | Phase 1: Single question per message, use AskUserQuestion for choices |
| Structured choices | Use AskUserQuestion tool for 2-4 options with trade-offs |
| YAGNI ruthlessly | Remove unnecessary features from all designs |
| Explore alternatives | Always propose 2-3 approaches before settling |
| Incremental validation | Present design in sections, validate each |
| Flexible progression | Go backward when needed - flexibility > rigidity |
Consider these optional next steps:
Use templates in assets/design-doc-template.md and assets/decision-matrix-template.md for structured documentation.
Goal: Understand the "why" behind the feature.
Goal: Uncover limitations and requirements.
Goal: Make implicit preferences explicit.
Goal: Ensure we consider all viable approaches.
❌ BAD:
"Before we start, I need to know:
1. What's your tech stack?
2. How many users?
3. What's the budget?
4. What's the timeline?
5. Who's the target audience?
..."
✅ GOOD:
"What problem does this solve for your users?"
[Wait for answer, then ask next most important question]
Why: Information overload prevents conversation flow. Ask one at a time.
❌ BAD:
"Here's the solution: Use Redis for caching..."
✅ GOOD:
"I see three approaches:
1. Redis (fast, but adds infrastructure)
2. In-memory (simple, but doesn't scale)
3. Database query cache (integrated, but slower)
Which trade-offs matter most?"
Why: Single approach suggests you haven't explored alternatives.
❌ BAD:
"Let's use microservices, Kubernetes, Redis, Kafka,
message queues, and a service mesh..."
✅ GOOD:
"For 100 users/day, a monolith with PostgreSQL
is sufficient. We can split services later if needed."
Why: YAGNI (You Aren't Gonna Need It). Start simple, scale when necessary.
❌ BAD:
"Let's rebuild this with a completely different architecture..."
✅ GOOD:
[Read existing code first]
"I see you're using Express + PostgreSQL. Let's extend
that pattern with a new route handler..."
Why: Consistency > novelty. Use existing patterns unless there's a compelling reason to change.
After brainstorming completes, consider:
Example flow:
Phase 1 - Understanding:
Phase 2 - Exploration:
Phase 3 - Design:
Result: Simple, fast recommendation system launched in 2 weeks
Phase 1 - Understanding:
Phase 2 - Exploration:
Phase 3 - Design:
Result: Real-time dashboard without WebSocket complexity
Phase 1 - Understanding:
Phase 2 - Exploration:
Phase 3 - Design:
Result: Secure upload service with virus scanning and optimization
Complete brainstorming sessions:
references/example-session-auth.md - Authentication storage design (JWT vs Session vs Cookies)references/example-session-dashboard.md - Real-time dashboard design (SSE vs WebSockets vs Polling)Output templates:
assets/design-doc-template.md - Structured design document formatassets/decision-matrix-template.md - Weighted decision comparison formatVersion: 1.1.0 (December 2025) Status: Production-ready patterns from real-world brainstorming sessions