feat: improved the Claude Kit as a plugin

2026-07-16 04:35:18 +03:00 · 2026-04-19 14:09:14 +07:00
parent 3103a8da1b
commit d1a6d2a2bc
186 changed files with 771 additions and 1691 deletions
@@ -0,0 +1,256 @@
+---
+name: brainstorming
+argument-hint: "[topic]"
+description: >
+  Use when the user wants to design, explore, or ideate on ANY new feature, architecture decision, or unclear requirement. Activate for keywords like "brainstorm", "design", "explore", "what if", "how should we", "options for", "trade-offs", or any open-ended question about implementation approach. Also trigger when requirements are vague, ambiguous, or when multiple valid solutions exist -- err on the side of brainstorming before jumping into code.
+---
+
+# Brainstorming
+
+## When to Use
+
+- Designing new features with unclear requirements
+- Exploring architecture decisions
+- Refining user requirements
+- Breaking down complex problems
+- When multiple valid approaches exist
+
+## When NOT to Use
+
+- Executing already-approved plans -- use `executing-plans` instead
+- Simple bug fixes with obvious solutions -- jump straight to fixing
+- Mechanical refactoring where the approach is already clear
+
+---
+
+## Three-Phase Process
+
+### Phase 1: Understanding
+
+**Goal**: Clarify requirements through sequential questioning.
+
+**Rules**:
+- Ask only ONE question per message
+- If a topic needs more exploration, break it into multiple questions
+- Prefer multiple-choice questions over open-ended when possible
+- Wait for user response before next question
+
+**Example**:
+```
+BAD: "What authentication method do you want, and should we support SSO,
+      and what about password requirements?"
+
+GOOD: "Which authentication method should we use?
+       a) Username/password only
+       b) OAuth (Google, GitHub)
+       c) Both options"
+```
+
+### Phase 2: Exploration
+
+**Goal**: Present alternatives with clear trade-offs.
+
+**Process**:
+1. Present 2-3 different approaches
+2. Lead with the recommended option
+3. Explain trade-offs for each
+4. Let user choose direction
+
+**Format**:
+```markdown
+## Approach 1: [Name] (Recommended)
+[Description]
+- Pros: [Benefits]
+- Cons: [Drawbacks]
+
+## Approach 2: [Name]
+[Description]
+- Pros: [Benefits]
+- Cons: [Drawbacks]
+
+Which approach aligns better with your goals?
+```
+
+### Phase 3: Design Presentation
+
+**Goal**: Present validated design in digestible chunks.
+
+**Rules**:
+- Break design into 200-300 word sections
+- Validate incrementally after each section
+- Cover: architecture, components, data flow, error handling, testing
+- Be flexible - allow user to request clarification or changes
+
+**Sections to Cover**:
+1. Architecture overview
+2. Component breakdown
+3. Data flow
+4. Error handling
+5. Testing considerations
+
+---
+
+## Core Principles
+
+### YAGNI Ruthlessly
+
+Remove unnecessary features aggressively:
+- Question every "nice to have"
+- Start with minimal viable design
+- Add complexity only when justified
+- "We might need this later" = remove it
+
+### One Question at a Time
+
+Sequential questioning produces better results:
+- Gives user time to think deeply
+- Prevents overwhelming with choices
+- Creates natural conversation flow
+- Allows follow-up on unclear points
+
+### Multiple-Choice Preference
+
+When possible, provide structured options:
+- Reduces cognitive load
+- Surfaces your understanding
+- Makes decisions concrete
+- Still allow "Other" option
+
+---
+
+## Output Format
+
+After design validation, document to timestamped markdown:
+
+```markdown
+# Design: [Feature Name]
+Date: [YYYY-MM-DD]
+
+## Summary
+[2-3 sentences]
+
+## Architecture
+[Architecture decisions]
+
+## Components
+[Component breakdown]
+
+## Data Flow
+[How data moves through system]
+
+## Error Handling
+[Error scenarios and handling]
+
+## Testing Strategy
+[Testing approach]
+
+## Open Questions
+[Any remaining unknowns]
+```
+
+---
+
+## Post-Design Workflow
+
+After design is validated:
+1. Commit design document to version control
+2. Optionally proceed to implementation
+3. Use `writing-plans` skill for detailed task breakdown
+4. Use `executing-plans` skill for implementation
+
+---
+
+## MCP Integration
+
+This skill leverages MCP servers for enhanced brainstorming:
+
+### Sequential Thinking (Primary)
+```
+Use Sequential Thinking for structured exploration:
+- Track design options as thought sequences
+- Build confidence in recommendations incrementally
+- Allow for revisions as user provides feedback
+- Document reasoning chain for design decisions
+```
+
+### Memory
+```
+Persist design decisions across sessions:
+- Store design concepts as entities
+- Create relations between components
+- Recall user preferences from previous sessions
+- Build project design knowledge over time
+```
+
+### Context7
+```
+For informed technology choices:
+- Fetch current library documentation
+- Compare capabilities accurately
+- Ground recommendations in real data
+```
+
+---
+
+## Stack-Specific Brainstorming Examples
+
+These show what Phase 2 (Exploration) output looks like for different domains:
+
+### FastAPI endpoint design
+
+```markdown
+## Approach 1: REST + JWT Bearer Auth (Recommended)
+POST /api/orders with Pydantic v2 validation, async SQLAlchemy.
+- Pros: Simple, cacheable, great OpenAPI docs via FastAPI
+- Cons: Multiple round-trips for nested resources
+
+## Approach 2: GraphQL + API Key Auth
+Single /graphql endpoint with Strawberry, API key in header.
+- Pros: Flexible queries, single round-trip for nested data
+- Cons: Caching harder, team unfamiliar with Strawberry
+
+**Decision**: REST — team knows it, OpenAPI auto-docs save time,
+nested resources not needed for this feature.
+```
+
+### React data table component
+
+```markdown
+## Approach 1: TanStack Table + URL Params (Recommended)
+Server component fetches data, client component for interactions.
+Sort/filter state in URL search params (shareable links).
+- Pros: Bookmarkable state, SSR-friendly, no global store needed
+- Cons: URL parsing boilerplate
+
+## Approach 2: Zustand Store + SWR
+Client-only with SWR for fetching, Zustand for table state.
+- Pros: Simple state management, familiar pattern
+- Cons: Not SSR-friendly, state lost on refresh
+
+**Decision**: TanStack Table + URL params — users need to share
+filtered views, and it works with Next.js App Router.
+```
+
+### Database multi-tenancy
+
+```markdown
+## Approach 1: Shared Table + tenant_id + RLS (Recommended)
+Single `orders` table with `tenant_id` column, PostgreSQL RLS policies.
+- Pros: Simple migrations, single connection pool, no schema sprawl
+- Cons: Must never forget WHERE tenant_id = ? (RLS prevents this)
+
+## Approach 2: Schema-per-tenant
+Each tenant gets own PostgreSQL schema, selected via search_path.
+- Pros: Strong isolation, easy per-tenant backup/restore
+- Cons: Migration complexity grows linearly with tenants
+
+**Decision**: Shared table + RLS — we have <100 tenants, RLS gives
+isolation guarantees without migration pain.
+```
+
+---
+
+## Related Skills
+
+- `writing-plans` -- After brainstorming produces a validated design, use writing-plans to create a detailed implementation plan
+- `sequential-thinking` -- For complex problems that benefit from structured step-by-step reasoning during the brainstorming process
@@ -0,0 +1,88 @@
+# Brainstorming Question Patterns
+
+Quick-reference catalog of effective question types for brainstorming sessions. Use these to systematically explore a problem space before jumping to solutions.
+
+---
+
+## Clarifying Questions
+
+**Purpose:** Ensure you understand the actual problem before solving it. Most failed implementations stem from unclear requirements.
+
+**When to use:** At the start of every brainstorming session, and whenever the request contains ambiguous terms.
+
+| # | Question | Context |
+|---|----------|---------|
+| 1 | What exactly should happen when a user does X? | Use when the described behavior has multiple valid interpretations. Forces concrete scenario thinking. |
+| 2 | Who is the primary user of this feature, and what's their current workflow? | Use when the requester assumes you know the audience. Different users need different solutions. |
+| 3 | What does success look like? How will you know this is working? | Use to surface acceptance criteria early. Prevents building the wrong thing correctly. |
+| 4 | Can you walk me through a specific example from start to finish? | Use when the description is abstract. Concrete examples reveal hidden requirements. |
+
+---
+
+## Constraint Questions
+
+**Purpose:** Identify boundaries that shape the solution space. Constraints eliminate options early and prevent wasted effort.
+
+**When to use:** After clarifying the goal, before exploring solutions. Especially important when the requester says "just build X."
+
+| # | Question | Context |
+|---|----------|---------|
+| 1 | What's the timeline? Is there a hard deadline or a target? | Use always. A 2-day solution looks nothing like a 2-month solution. |
+| 2 | What can't change? Are there existing systems, APIs, or schemas we must preserve? | Use when modifying an existing system. Reveals integration constraints. |
+| 3 | What's the performance budget? Expected load, response time, data volume? | Use for any feature touching data pipelines, APIs, or user-facing flows. |
+| 4 | Are there compliance, security, or accessibility requirements? | Use for anything involving user data, payments, or public-facing UI. Easy to forget, expensive to retrofit. |
+
+---
+
+## Alternative Questions
+
+**Purpose:** Expand the solution space. The first idea is rarely the best idea.
+
+**When to use:** After constraints are clear but before committing to an approach. Especially when the requester has already proposed a specific solution.
+
+| # | Question | Context |
+|---|----------|---------|
+| 1 | What if we solved this without building anything new? Could an existing tool or configuration handle it? | Use to challenge the assumption that code is needed. Sometimes a config change or third-party tool is enough. |
+| 2 | What's the simplest version that still delivers value? | Use to find the MVP. Strips away nice-to-haves and focuses on the core need. |
+| 3 | Have you considered [opposite approach]? What would that look like? | Use to break anchoring bias. If they propose a push model, ask about pull. If sync, ask about async. |
+| 4 | What would we do if we had to ship this today? | Use to identify which parts are truly essential vs. which are aspirational. |
+
+---
+
+## Prioritization Questions
+
+**Purpose:** Sequence work effectively when there's more to do than time allows.
+
+**When to use:** When the feature has multiple components, when scope is growing, or when the team is debating what to build first.
+
+| # | Question | Context |
+|---|----------|---------|
+| 1 | Which of these capabilities is most important to the first user? | Use to rank features by user impact rather than technical convenience. |
+| 2 | What's the MVP — the smallest thing we can ship and learn from? | Use when scope is expanding. Forces a shippable first increment. |
+| 3 | What can wait for v2 without blocking the core experience? | Use to defer non-essential work explicitly rather than letting it creep in. |
+| 4 | If we could only ship one of these this week, which one? | Use when the team can't agree on priority. Forces a direct comparison. |
+
+---
+
+## Technical Questions
+
+**Purpose:** Ground the discussion in implementation reality. Surface architecture decisions that affect the solution.
+
+**When to use:** Once the goal and constraints are clear, before writing a plan. Essential for features that touch multiple systems.
+
+| # | Question | Context |
+|---|----------|---------|
+| 1 | What's the data model? What entities exist, and how do they relate? | Use for any feature involving persistent state. Data model drives everything. |
+| 2 | How does authentication and authorization work for this? Who can see/do what? | Use for any feature with access control. Auth is often assumed but rarely specified. |
+| 3 | What's the expected scale — users, requests/sec, data size? | Use to choose between simple and scalable approaches. Over-engineering is as wasteful as under-engineering. |
+| 4 | What existing code or patterns should this follow? Are there conventions to match? | Use to maintain consistency. New code that ignores existing patterns creates maintenance burden. |
+
+---
+
+## Using This Reference
+
+1. **Don't ask all questions** — pick the 3-5 most relevant for the situation
+2. **Start with clarifying** — always ensure you understand the problem
+3. **Adapt the phrasing** — these are templates, not scripts
+4. **Listen for gaps** — the questions the requester struggles to answer reveal the areas that need more thought
+5. **Document answers** — capture decisions as they're made so you don't re-ask later