specweave 0.23.14 → 0.23.16
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CLAUDE.md +55 -0
- package/dist/src/core/spec-detector.d.ts +5 -0
- package/dist/src/core/spec-detector.d.ts.map +1 -1
- package/dist/src/core/spec-detector.js +91 -33
- package/dist/src/core/spec-detector.js.map +1 -1
- package/package.json +1 -1
- package/plugins/specweave-github/.claude-plugin/plugin.json +15 -1
- package/plugins/specweave-github/hooks/.specweave/logs/hooks-debug.log +16 -0
- package/plugins/specweave-github/hooks/post-task-completion.sh +53 -0
- package/plugins/specweave-release/hooks/.specweave/logs/dora-tracking.log +24 -0
- package/plugins/specweave-alternatives/.claude-plugin/plugin.json +0 -21
- package/plugins/specweave-alternatives/skills/bmad-method-expert/SKILL.md +0 -626
- package/plugins/specweave-alternatives/skills/bmad-method-expert/scripts/analyze-project.js +0 -318
- package/plugins/specweave-alternatives/skills/bmad-method-expert/scripts/check-setup.js +0 -208
- package/plugins/specweave-alternatives/skills/bmad-method-expert/scripts/generate-template.js +0 -1149
- package/plugins/specweave-alternatives/skills/bmad-method-expert/scripts/validate-documents.js +0 -340
- package/plugins/specweave-alternatives/skills/spec-kit-expert/SKILL.md +0 -1010
- package/plugins/specweave-cost-optimizer/.claude-plugin/plugin.json +0 -20
- package/plugins/specweave-cost-optimizer/skills/cost-optimizer/SKILL.md +0 -190
- package/plugins/specweave-docs/.claude-plugin/plugin.json +0 -19
- package/plugins/specweave-docs/skills/docusaurus/SKILL.md +0 -613
- package/plugins/specweave-docs/skills/spec-driven-brainstorming/README.md +0 -264
- package/plugins/specweave-docs/skills/spec-driven-brainstorming/SKILL.md +0 -439
- package/plugins/specweave-docs/skills/spec-driven-debugging/README.md +0 -479
- package/plugins/specweave-docs/skills/spec-driven-debugging/SKILL.md +0 -652
- package/plugins/specweave-figma/.claude-plugin/.mcp.json +0 -12
- package/plugins/specweave-figma/.claude-plugin/plugin.json +0 -20
- package/plugins/specweave-figma/ARCHITECTURE.md +0 -453
- package/plugins/specweave-figma/README.md +0 -728
- package/plugins/specweave-figma/skills/figma-to-code/SKILL.md +0 -632
- package/plugins/specweave-figma/skills/figma-to-code/test-1-token-generation.yaml +0 -29
- package/plugins/specweave-figma/skills/figma-to-code/test-2-component-generation.yaml +0 -27
- package/plugins/specweave-figma/skills/figma-to-code/test-3-typescript-generation.yaml +0 -28
- package/plugins/specweave-frontend/.claude-plugin/plugin.json +0 -21
- package/plugins/specweave-frontend/skills/design-system-architect/SKILL.md +0 -107
- package/plugins/specweave-frontend/skills/frontend/SKILL.md +0 -177
- package/plugins/specweave-frontend/skills/nextjs/SKILL.md +0 -176
- package/plugins/specweave-testing/.claude-plugin/plugin.json +0 -20
- package/plugins/specweave-testing/skills/e2e-playwright/README.md +0 -506
- package/plugins/specweave-testing/skills/e2e-playwright/SKILL.md +0 -457
- package/plugins/specweave-testing/skills/e2e-playwright/execute.js +0 -373
- package/plugins/specweave-testing/skills/e2e-playwright/lib/utils.js +0 -514
- package/plugins/specweave-testing/skills/e2e-playwright/package.json +0 -33
- package/plugins/specweave-tooling/.claude-plugin/plugin.json +0 -19
- package/plugins/specweave-tooling/skills/skill-creator/LICENSE.txt +0 -202
- package/plugins/specweave-tooling/skills/skill-creator/SKILL.md +0 -209
- package/plugins/specweave-tooling/skills/skill-creator/scripts/init_skill.py +0 -303
- package/plugins/specweave-tooling/skills/skill-creator/scripts/package_skill.py +0 -110
- package/plugins/specweave-tooling/skills/skill-creator/scripts/quick_validate.py +0 -65
- package/plugins/specweave-tooling/skills/skill-router/SKILL.md +0 -479
- package/plugins/specweave-ui/.claude-plugin/plugin.json +0 -26
- package/plugins/specweave-ui/.mcp.json +0 -10
- package/plugins/specweave-ui/README.md +0 -492
- package/plugins/specweave-ui/skills/browser-automation/SKILL.md +0 -676
|
@@ -1,439 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: spec-driven-brainstorming
|
|
3
|
-
description: Refines rough ideas into spec-ready designs through structured Socratic questioning, alternative exploration, and incremental validation. Use BEFORE creating increments - transforms vague concepts into clear requirements. Activates for: brainstorm, explore idea, refine concept, design thinking, what should I build, help me think through, ultrathink, ultrathink on, think through this, deep thinking, architecture exploration, analyze this idea, evaluate approach, explore options.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Spec-Driven Brainstorming
|
|
7
|
-
|
|
8
|
-
## Overview
|
|
9
|
-
|
|
10
|
-
Transform rough ideas into specification-ready designs through structured questioning and alternative exploration, preparing them for SpecWeave's increment workflow.
|
|
11
|
-
|
|
12
|
-
**Core principle:** Ask questions to understand, explore alternatives, validate design incrementally, then create specs.
|
|
13
|
-
|
|
14
|
-
**Announce at start:** "I'm using spec-driven brainstorming to refine your idea before creating the SpecWeave increment."
|
|
15
|
-
|
|
16
|
-
**🧠 Ultrathink Mode:** For complex designs requiring deep reasoning (31,999 thinking tokens), ask: "Can you **ultrathink** this design?" to enable extended analysis.
|
|
17
|
-
|
|
18
|
-
## Quick Reference
|
|
19
|
-
|
|
20
|
-
| Phase | Key Activities | Tool Usage | Output |
|
|
21
|
-
|-------|---------------|------------|--------|
|
|
22
|
-
| **1. Understanding** | Socratic questioning (one at a time) | AskUserQuestion for choices | Purpose, constraints, success criteria |
|
|
23
|
-
| **2. Tech Stack Detection** | Identify existing/desired technologies | Grep/Read existing code | Framework-specific guidance |
|
|
24
|
-
| **3. Exploration** | Propose 2-3 architectural approaches | AskUserQuestion with trade-offs | Architecture options evaluated |
|
|
25
|
-
| **4. Design Validation** | Present design in 250-word sections | Open-ended validation | Complete, validated design |
|
|
26
|
-
| **5. SpecWeave Handoff** | Create increment with validated design | increment-planner skill | spec.md, plan.md, tests.md |
|
|
27
|
-
|
|
28
|
-
## The Process
|
|
29
|
-
|
|
30
|
-
Track your progress with this checklist:
|
|
31
|
-
|
|
32
|
-
```
|
|
33
|
-
Brainstorming Progress:
|
|
34
|
-
- [ ] Phase 1: Understanding (purpose, constraints, criteria gathered)
|
|
35
|
-
- [ ] Phase 2: Tech Stack Detection (technologies identified)
|
|
36
|
-
- [ ] Phase 3: Exploration (2-3 approaches proposed and evaluated)
|
|
37
|
-
- [ ] Phase 4: Design Validation (design validated in sections)
|
|
38
|
-
- [ ] Phase 5: SpecWeave Handoff (increment created with specs)
|
|
39
|
-
```
|
|
40
|
-
|
|
41
|
-
### Phase 1: Understanding
|
|
42
|
-
|
|
43
|
-
**Goal:** Gather requirements through Socratic questioning
|
|
44
|
-
|
|
45
|
-
**Activities:**
|
|
46
|
-
- Check current project state (Glob for existing code structure)
|
|
47
|
-
- Ask **ONE question at a time** to refine the idea
|
|
48
|
-
- **Use AskUserQuestion tool** when presenting 2-4 structured choices
|
|
49
|
-
- Gather: Purpose, user needs, constraints, success criteria, non-functional requirements
|
|
50
|
-
|
|
51
|
-
**Example using AskUserQuestion:**
|
|
52
|
-
```
|
|
53
|
-
Question: "What's the primary goal of this feature?"
|
|
54
|
-
Options:
|
|
55
|
-
- "User-facing functionality" (UI/UX focus, needs frontend + backend)
|
|
56
|
-
- "Backend API/service" (Integration focus, no UI needed)
|
|
57
|
-
- "Infrastructure/DevOps" (Platform capability, deployment-focused)
|
|
58
|
-
- "Data processing/analytics" (Batch/stream processing, data-centric)
|
|
59
|
-
```
|
|
60
|
-
|
|
61
|
-
**Critical Guidelines:**
|
|
62
|
-
- ✅ Ask about user problems (WHY) before solutions (HOW)
|
|
63
|
-
- ✅ Identify constraints early (budget, timeline, team size)
|
|
64
|
-
- ✅ Discover non-functional requirements (performance, scale, security)
|
|
65
|
-
- ❌ Don't assume tech stack yet - that's Phase 2
|
|
66
|
-
|
|
67
|
-
### Phase 2: Tech Stack Detection
|
|
68
|
-
|
|
69
|
-
**Goal:** Understand existing/desired technology context
|
|
70
|
-
|
|
71
|
-
**Activities:**
|
|
72
|
-
- **Detect existing tech stack** (if brownfield):
|
|
73
|
-
- Search for `package.json` (Node.js/TypeScript/Next.js)
|
|
74
|
-
- Search for `requirements.txt` or `pyproject.toml` (Python)
|
|
75
|
-
- Search for `.csproj` (.NET)
|
|
76
|
-
- Check framework indicators (React, Vue, Angular, FastAPI, Django, etc.)
|
|
77
|
-
- **Ask about desired tech stack** (if greenfield):
|
|
78
|
-
- Use AskUserQuestion to present 2-3 appropriate stacks
|
|
79
|
-
- Consider project goals (web app, API, CLI, mobile, etc.)
|
|
80
|
-
- **Activate relevant SpecWeave skills**:
|
|
81
|
-
- `nextjs` for Next.js projects
|
|
82
|
-
- `nodejs-backend` for Node.js APIs
|
|
83
|
-
- `python-backend` for Python backends
|
|
84
|
-
- `dotnet-backend` for .NET/C#
|
|
85
|
-
- `frontend` for React/Vue/Angular
|
|
86
|
-
|
|
87
|
-
**Example using AskUserQuestion (greenfield):**
|
|
88
|
-
```
|
|
89
|
-
Question: "Which technology stack fits your team's expertise and project needs?"
|
|
90
|
-
Options:
|
|
91
|
-
- "Next.js 14 + TypeScript" (Full-stack React, best for web apps, great DX)
|
|
92
|
-
- "FastAPI + Python" (Fast async APIs, ML-ready, Python ecosystem)
|
|
93
|
-
- "ASP.NET Core + C#" (Enterprise-grade, strong typing, Microsoft stack)
|
|
94
|
-
```
|
|
95
|
-
|
|
96
|
-
### Phase 3: Exploration
|
|
97
|
-
|
|
98
|
-
**Goal:** Propose and evaluate 2-3 architectural approaches
|
|
99
|
-
|
|
100
|
-
**Activities:**
|
|
101
|
-
- Generate **2-3 distinct approaches** (not just variations)
|
|
102
|
-
- For each approach:
|
|
103
|
-
- Core architecture pattern (microservices, monolith, serverless, event-driven)
|
|
104
|
-
- Key components and their responsibilities
|
|
105
|
-
- Trade-offs (complexity vs scalability, cost vs performance)
|
|
106
|
-
- Estimated effort (relative complexity)
|
|
107
|
-
- Technology fit (how well it matches existing stack)
|
|
108
|
-
- **Use AskUserQuestion tool** to present approaches as structured choices
|
|
109
|
-
- Apply YAGNI (You Aren't Gonna Need It) ruthlessly - remove unnecessary complexity
|
|
110
|
-
|
|
111
|
-
**Example using AskUserQuestion:**
|
|
112
|
-
```
|
|
113
|
-
Question: "Which architectural approach should we use for real-time price tracking?"
|
|
114
|
-
Options:
|
|
115
|
-
- "Event-driven with WebSockets" (Real-time updates, complex setup, best UX, higher cost)
|
|
116
|
-
- "Polling with REST API" (Simple, predictable, easier to debug, slightly delayed)
|
|
117
|
-
- "Server-Sent Events (SSE)" (One-way real-time, simpler than WebSockets, HTTP-friendly)
|
|
118
|
-
```
|
|
119
|
-
|
|
120
|
-
**🧠 Ultrathink Tip:** For complex architecture decisions with many trade-offs, ask: "Can you **ultrathink** these approaches?" to get deeper analysis (31,999 thinking tokens).
|
|
121
|
-
|
|
122
|
-
**Critical Guidelines:**
|
|
123
|
-
- ✅ Present genuinely different approaches (not just implementation details)
|
|
124
|
-
- ✅ Explain trade-offs in business terms (cost, time-to-market, maintenance)
|
|
125
|
-
- ✅ Consider existing codebase patterns (consistency matters)
|
|
126
|
-
- ❌ Don't overwhelm with >3 options
|
|
127
|
-
- ❌ Don't propose over-engineered solutions for simple problems
|
|
128
|
-
|
|
129
|
-
### Phase 4: Design Validation
|
|
130
|
-
|
|
131
|
-
**Goal:** Present complete design incrementally and validate each section
|
|
132
|
-
|
|
133
|
-
**Activities:**
|
|
134
|
-
- Present design in **250-word sections** (SpecWeave's spec.md max is 250 lines)
|
|
135
|
-
- Cover essential sections:
|
|
136
|
-
- **Architecture Overview:** High-level design pattern chosen
|
|
137
|
-
- **Components:** Key modules/services and their responsibilities
|
|
138
|
-
- **Data Flow:** How information moves through the system
|
|
139
|
-
- **Error Handling:** Failure modes and recovery strategies
|
|
140
|
-
- **Testing Strategy:** How to validate it works (unit, integration, E2E)
|
|
141
|
-
- **Security Considerations:** Authentication, authorization, data protection
|
|
142
|
-
- **Performance & Scale:** Expected load, bottlenecks, optimization approach
|
|
143
|
-
- Ask after each section: **"Does this align with your vision?"** (open-ended)
|
|
144
|
-
- Use **open-ended questions** here to allow freeform feedback
|
|
145
|
-
|
|
146
|
-
**Example validation question:**
|
|
147
|
-
```
|
|
148
|
-
"I've outlined the data flow from price API → WebSocket server → client browser.
|
|
149
|
-
Does this approach handle your offline/reconnection scenarios adequately?"
|
|
150
|
-
```
|
|
151
|
-
|
|
152
|
-
**Critical Guidelines:**
|
|
153
|
-
- ✅ Present incrementally (don't dump entire design at once)
|
|
154
|
-
- ✅ Focus on WHAT and WHY (not implementation details yet)
|
|
155
|
-
- ✅ Keep it technology-agnostic where possible (e.g., "message queue" not "RabbitMQ")
|
|
156
|
-
- ✅ Reference SpecWeave's validation criteria (testable, measurable, clear)
|
|
157
|
-
- ❌ Don't dive into code-level details (that's plan.md's job)
|
|
158
|
-
|
|
159
|
-
### Phase 5: SpecWeave Handoff
|
|
160
|
-
|
|
161
|
-
**Goal:** Create SpecWeave increment with validated design
|
|
162
|
-
|
|
163
|
-
When design is validated, ask: **"Ready to create the SpecWeave increment with this design?"**
|
|
164
|
-
|
|
165
|
-
When user confirms (any affirmative response):
|
|
166
|
-
|
|
167
|
-
**Option A: Full Increment Creation (Recommended)**
|
|
168
|
-
|
|
169
|
-
Announce: "I'm using the increment-planner skill to create the full increment."
|
|
170
|
-
|
|
171
|
-
**Handoff to increment-planner:**
|
|
172
|
-
- Pass validated design from Phase 4
|
|
173
|
-
- increment-planner will:
|
|
174
|
-
1. Invoke **PM agent** to create `.specweave/docs/internal/strategy/` documentation
|
|
175
|
-
2. Invoke **Architect agent** to create `.specweave/docs/internal/architecture/` documentation
|
|
176
|
-
3. Create `.specweave/increments/0001-feature-name/` with:
|
|
177
|
-
- `spec.md` (WHAT & WHY - references strategy docs)
|
|
178
|
-
- `plan.md` (HOW - references architecture docs)
|
|
179
|
-
- `tasks.md` (implementation checklist)
|
|
180
|
-
- `tests.md` (test strategy and cases)
|
|
181
|
-
- `context-manifest.yaml` (selective loading for 70%+ token reduction)
|
|
182
|
-
|
|
183
|
-
**Option B: Quick Increment (Fast Start)**
|
|
184
|
-
|
|
185
|
-
Announce: "I'm creating a quick-start increment. We can expand documentation later."
|
|
186
|
-
|
|
187
|
-
**Direct creation** (for rapid prototyping):
|
|
188
|
-
- Create `.specweave/increments/0001-feature-name/` directory
|
|
189
|
-
- Write `spec.md` with validated design (WHAT & WHY)
|
|
190
|
-
- Write basic `plan.md` outline (HOW - to be expanded)
|
|
191
|
-
- Write `tasks.md` checklist
|
|
192
|
-
- Write `tests.md` with acceptance criteria
|
|
193
|
-
- Create `context-manifest.yaml` with minimal context
|
|
194
|
-
|
|
195
|
-
**🔄 Follow-up:** After quick increment, documentation can be expanded incrementally as implementation proceeds.
|
|
196
|
-
|
|
197
|
-
## Question Patterns
|
|
198
|
-
|
|
199
|
-
### When to Use AskUserQuestion Tool
|
|
200
|
-
|
|
201
|
-
**Use AskUserQuestion for:**
|
|
202
|
-
- Phase 1: Clarifying questions with 2-4 clear options (project type, goals)
|
|
203
|
-
- Phase 2: Tech stack selection (2-3 technology options)
|
|
204
|
-
- Phase 3: Architectural approach selection (2-3 distinct approaches)
|
|
205
|
-
- Any decision with mutually exclusive choices
|
|
206
|
-
- When options have clear trade-offs to explain
|
|
207
|
-
|
|
208
|
-
**Benefits:**
|
|
209
|
-
- Structured presentation with descriptions
|
|
210
|
-
- Clear trade-off visibility
|
|
211
|
-
- Forces explicit choice (prevents vague "maybe both" responses)
|
|
212
|
-
- Tracks decision history for specs
|
|
213
|
-
|
|
214
|
-
### When to Use Open-Ended Questions
|
|
215
|
-
|
|
216
|
-
**Use open-ended questions for:**
|
|
217
|
-
- Phase 1: When gathering nuanced requirements ("What problem are you solving?")
|
|
218
|
-
- Phase 4: Design validation ("Does this handle your use case?")
|
|
219
|
-
- When you need detailed feedback or explanation
|
|
220
|
-
- When user should describe their own context
|
|
221
|
-
- When structured options would limit creative input
|
|
222
|
-
|
|
223
|
-
**Example decision flow:**
|
|
224
|
-
- "What authentication method?" → Use AskUserQuestion (OAuth, JWT, sessions)
|
|
225
|
-
- "Does this design meet your security needs?" → Open-ended (validation)
|
|
226
|
-
|
|
227
|
-
## When to Revisit Earlier Phases
|
|
228
|
-
|
|
229
|
-
**You can and should go backward when:**
|
|
230
|
-
- User reveals new constraint during Phase 3 or 4 → Return to Phase 1
|
|
231
|
-
- Tech stack discovery reveals misalignment → Return to Phase 2
|
|
232
|
-
- Validation shows fundamental gap in requirements → Return to Phase 1
|
|
233
|
-
- User questions approach during Phase 4 → Return to Phase 3
|
|
234
|
-
- Something doesn't make sense → Go back and clarify
|
|
235
|
-
|
|
236
|
-
**Example flow diagram:**
|
|
237
|
-
```
|
|
238
|
-
New constraint revealed?
|
|
239
|
-
├─ Yes → Return to Phase 1 (re-understand requirements)
|
|
240
|
-
└─ No → Continue
|
|
241
|
-
│
|
|
242
|
-
Tech stack misalignment?
|
|
243
|
-
├─ Yes → Return to Phase 2 (re-detect or choose stack)
|
|
244
|
-
└─ No → Continue
|
|
245
|
-
│
|
|
246
|
-
Approach questioned?
|
|
247
|
-
├─ Yes → Return to Phase 3 (re-explore alternatives)
|
|
248
|
-
└─ No → Continue to Phase 4
|
|
249
|
-
```
|
|
250
|
-
|
|
251
|
-
**Don't force forward linearly** when going backward would give better results.
|
|
252
|
-
|
|
253
|
-
## Key Principles
|
|
254
|
-
|
|
255
|
-
| Principle | Application |
|
|
256
|
-
|-----------|-------------|
|
|
257
|
-
| **One question at a time** | Phase 1: Single question per message in Understanding phase |
|
|
258
|
-
| **Structured choices** | Use AskUserQuestion for 2-4 options with clear trade-offs |
|
|
259
|
-
| **Tech stack awareness** | Phase 2: Detect existing or choose appropriate technologies |
|
|
260
|
-
| **YAGNI ruthlessly** | Remove unnecessary complexity from ALL designs |
|
|
261
|
-
| **Explore alternatives** | Always propose 2-3 approaches before settling |
|
|
262
|
-
| **Incremental validation** | Present design in 250-word sections, validate each |
|
|
263
|
-
| **Flexible progression** | Go backward when needed - flexibility > rigidity |
|
|
264
|
-
| **SpecWeave integration** | End with increment creation, not just design document |
|
|
265
|
-
| **Ultrathink for complexity** | Use "ultrathink" keyword for deep reasoning (31,999 tokens) |
|
|
266
|
-
|
|
267
|
-
## Integration with SpecWeave
|
|
268
|
-
|
|
269
|
-
### Relationship to Other Skills
|
|
270
|
-
|
|
271
|
-
**spec-driven-brainstorming → increment-planner**
|
|
272
|
-
- Brainstorming refines rough idea → validated design
|
|
273
|
-
- increment-planner takes validated design → creates increment
|
|
274
|
-
- PM agent creates strategy docs (`.specweave/docs/internal/strategy/`)
|
|
275
|
-
- Architect agent creates architecture docs (`.specweave/docs/internal/architecture/`)
|
|
276
|
-
|
|
277
|
-
**When to use spec-driven-brainstorming:**
|
|
278
|
-
- ✅ User has vague/rough idea needing exploration
|
|
279
|
-
- ✅ Multiple approaches need evaluation
|
|
280
|
-
- ✅ Requirements need clarification through questioning
|
|
281
|
-
- ✅ Complex design needing deep thinking ("ultrathink")
|
|
282
|
-
|
|
283
|
-
**When to skip to increment-planner:**
|
|
284
|
-
- ✅ User has clear, well-defined requirements
|
|
285
|
-
- ✅ Tech stack is obvious from existing code
|
|
286
|
-
- ✅ Solution approach is straightforward
|
|
287
|
-
- ✅ No alternatives need exploration
|
|
288
|
-
|
|
289
|
-
### Relationship to SpecWeave Agents
|
|
290
|
-
|
|
291
|
-
**This skill orchestrates:**
|
|
292
|
-
- **No agents directly** (focuses on user dialogue)
|
|
293
|
-
- Hands off to `increment-planner` which invokes:
|
|
294
|
-
- `pm` agent (requirements, user stories)
|
|
295
|
-
- `architect` agent (technical design, ADRs)
|
|
296
|
-
- `qa-lead` agent (test strategy)
|
|
297
|
-
|
|
298
|
-
### Documentation Flow
|
|
299
|
-
|
|
300
|
-
```
|
|
301
|
-
spec-driven-brainstorming (this skill)
|
|
302
|
-
↓ (validated design)
|
|
303
|
-
increment-planner skill
|
|
304
|
-
↓ (orchestration)
|
|
305
|
-
├─ PM Agent → .specweave/docs/internal/strategy/
|
|
306
|
-
│ ├── overview.md (product vision)
|
|
307
|
-
│ ├── requirements.md (FR-001, NFR-001)
|
|
308
|
-
│ └── user-stories.md (US1, US2, US3)
|
|
309
|
-
│
|
|
310
|
-
├─ Architect Agent → .specweave/docs/internal/architecture/
|
|
311
|
-
│ ├── system-design.md (HLD)
|
|
312
|
-
│ ├── component-design.md (LLD)
|
|
313
|
-
│ └── adr/0001-decision.md (ADRs)
|
|
314
|
-
│
|
|
315
|
-
└─ Increment Files → .specweave/increments/0001-feature/
|
|
316
|
-
├── spec.md (summary, references strategy)
|
|
317
|
-
├── plan.md (summary, references architecture)
|
|
318
|
-
├── tasks.md (implementation checklist)
|
|
319
|
-
├── tests.md (test strategy)
|
|
320
|
-
└── context-manifest.yaml (selective loading)
|
|
321
|
-
```
|
|
322
|
-
|
|
323
|
-
## Ultrathink Deep Reasoning Mode
|
|
324
|
-
|
|
325
|
-
**What is Ultrathink?**
|
|
326
|
-
- Claude Code feature that allocates **31,999 thinking tokens** for complex reasoning
|
|
327
|
-
- Enables deeper analysis, exploration of edge cases, and nuanced trade-off evaluation
|
|
328
|
-
- Most useful for architecture decisions, security considerations, and complex system design
|
|
329
|
-
|
|
330
|
-
**When to use Ultrathink:**
|
|
331
|
-
- Complex architecture with many trade-offs
|
|
332
|
-
- Security-critical design decisions
|
|
333
|
-
- Performance/scale optimization challenges
|
|
334
|
-
- Novel problem domains requiring creative solutions
|
|
335
|
-
- Integrating multiple systems with constraints
|
|
336
|
-
|
|
337
|
-
**How to activate:**
|
|
338
|
-
Ask user: "Would you like me to **ultrathink** this design?" or suggest: "This seems complex - let me **ultrathink** the architecture options."
|
|
339
|
-
|
|
340
|
-
**Other thinking modes:**
|
|
341
|
-
- `think` - 4,000 tokens (simple problems)
|
|
342
|
-
- `megathink` - 10,000 tokens (moderate complexity)
|
|
343
|
-
- `ultrathink` - 31,999 tokens (high complexity)
|
|
344
|
-
|
|
345
|
-
**Example usage:**
|
|
346
|
-
```
|
|
347
|
-
User: "I need to design a distributed caching system that handles 100K requests/sec"
|
|
348
|
-
Assistant: "This is a complex distributed systems problem with many trade-offs.
|
|
349
|
-
Let me **ultrathink** the architecture approaches to evaluate:
|
|
350
|
-
- Consistency vs availability trade-offs (CAP theorem)
|
|
351
|
-
- Cache invalidation strategies
|
|
352
|
-
- Horizontal scaling patterns
|
|
353
|
-
- Network topology and latency considerations
|
|
354
|
-
- Cost optimization at scale"
|
|
355
|
-
```
|
|
356
|
-
|
|
357
|
-
## Examples
|
|
358
|
-
|
|
359
|
-
### Example 1: Vague Idea → Validated Design
|
|
360
|
-
|
|
361
|
-
**User:** "I want to build something with crypto prices"
|
|
362
|
-
|
|
363
|
-
**Assistant (Phase 1 - Understanding):**
|
|
364
|
-
"I'm using spec-driven brainstorming to refine your idea. Let me understand what you're trying to achieve."
|
|
365
|
-
|
|
366
|
-
[Asks ONE question at a time:]
|
|
367
|
-
- "What's your primary goal?" (AskUserQuestion: tracking, trading, analysis, alerts)
|
|
368
|
-
- "Who are the users?" (yourself, team, public)
|
|
369
|
-
- "What's your timeline?" (weekend project, production app)
|
|
370
|
-
- "Any budget/infrastructure constraints?" (free tier, cloud budget)
|
|
371
|
-
|
|
372
|
-
**Assistant (Phase 2 - Tech Stack):**
|
|
373
|
-
[Scans for package.json, finds Next.js project]
|
|
374
|
-
"I see you have Next.js 14 in your project. Great - we can build on that."
|
|
375
|
-
|
|
376
|
-
**Assistant (Phase 3 - Exploration):**
|
|
377
|
-
"Let me propose three approaches:" (AskUserQuestion with 3 options)
|
|
378
|
-
1. Event-driven with WebSockets (real-time, complex)
|
|
379
|
-
2. Polling with REST API (simple, delayed)
|
|
380
|
-
3. Server-Sent Events (middle ground)
|
|
381
|
-
|
|
382
|
-
[User selects SSE]
|
|
383
|
-
|
|
384
|
-
**Assistant (Phase 4 - Design Validation):**
|
|
385
|
-
[Presents architecture in 250-word sections]
|
|
386
|
-
- Component overview → "Does this make sense?"
|
|
387
|
-
- Data flow → "Does this handle reconnection?"
|
|
388
|
-
- Testing strategy → "Does this cover your needs?"
|
|
389
|
-
|
|
390
|
-
**Assistant (Phase 5 - SpecWeave Handoff):**
|
|
391
|
-
"Design validated! Ready to create the SpecWeave increment?"
|
|
392
|
-
[User confirms]
|
|
393
|
-
"I'm using the increment-planner skill to create the full increment with PM and Architect agents."
|
|
394
|
-
|
|
395
|
-
### Example 2: Complex Problem → Ultrathink
|
|
396
|
-
|
|
397
|
-
**User:** "I need a distributed task queue with exactly-once delivery guarantees"
|
|
398
|
-
|
|
399
|
-
**Assistant:**
|
|
400
|
-
"This is a complex distributed systems problem with many trade-offs. Let me **ultrathink** the architecture approaches to ensure we consider all the edge cases around consistency, failure modes, and exactly-once semantics."
|
|
401
|
-
|
|
402
|
-
[Engages ultrathink mode for deep analysis of distributed systems patterns]
|
|
403
|
-
|
|
404
|
-
## Anti-Patterns to Avoid
|
|
405
|
-
|
|
406
|
-
| Anti-Pattern | Why It's Bad | What to Do Instead |
|
|
407
|
-
|--------------|--------------|-------------------|
|
|
408
|
-
| Asking 5 questions at once | Overwhelming, unclear priorities | ONE question at a time in Phase 1 |
|
|
409
|
-
| Jumping to implementation | Skips validation, no alternatives explored | Follow Phase 1→2→3→4→5 progression |
|
|
410
|
-
| Presenting only 1 approach | No trade-off evaluation | Always propose 2-3 alternatives |
|
|
411
|
-
| Skipping tech stack detection | Mismatch with existing codebase | Phase 2: Scan existing or ask |
|
|
412
|
-
| Design dump (no validation) | User overwhelmed, no feedback | 250-word sections with validation |
|
|
413
|
-
| Creating files directly | Bypasses SpecWeave structure | Use increment-planner handoff |
|
|
414
|
-
| Over-engineering simple tasks | Unnecessary complexity | Apply YAGNI ruthlessly |
|
|
415
|
-
|
|
416
|
-
## Summary
|
|
417
|
-
|
|
418
|
-
**spec-driven-brainstorming** prepares rough ideas for SpecWeave's spec-driven workflow:
|
|
419
|
-
|
|
420
|
-
1. ✅ **Socratic questioning** refines vague concepts
|
|
421
|
-
2. ✅ **Tech stack awareness** ensures alignment
|
|
422
|
-
3. ✅ **Alternative exploration** evaluates trade-offs
|
|
423
|
-
4. ✅ **Incremental validation** confirms design
|
|
424
|
-
5. ✅ **Ultrathink mode** handles complex reasoning
|
|
425
|
-
6. ✅ **SpecWeave integration** creates increment with validated design
|
|
426
|
-
7. ✅ **Flexible progression** allows revisiting earlier phases
|
|
427
|
-
|
|
428
|
-
**When to use this skill:**
|
|
429
|
-
- Rough idea needing refinement
|
|
430
|
-
- Multiple approaches to evaluate
|
|
431
|
-
- Complex design requiring deep thinking
|
|
432
|
-
- Requirements unclear and need Socratic questioning
|
|
433
|
-
|
|
434
|
-
**When to skip to increment-planner:**
|
|
435
|
-
- Clear requirements already defined
|
|
436
|
-
- Obvious solution approach
|
|
437
|
-
- No alternatives need exploration
|
|
438
|
-
|
|
439
|
-
**End state:** Validated design ready for SpecWeave increment creation with PM/Architect agent orchestration.
|