@su-record/vibe 2.4.34 → 2.4.35
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 +345 -351
- package/LICENSE +21 -21
- package/README.md +210 -210
- package/agents/compounder.md +261 -261
- package/agents/diagrammer.md +178 -178
- package/agents/e2e-tester.md +266 -266
- package/agents/explorer.md +48 -48
- package/agents/implementer.md +53 -53
- package/agents/research/best-practices-agent.md +139 -139
- package/agents/research/codebase-patterns-agent.md +147 -147
- package/agents/research/framework-docs-agent.md +178 -178
- package/agents/research/security-advisory-agent.md +164 -164
- package/agents/review/architecture-reviewer.md +107 -107
- package/agents/review/complexity-reviewer.md +116 -116
- package/agents/review/data-integrity-reviewer.md +88 -88
- package/agents/review/git-history-reviewer.md +103 -103
- package/agents/review/performance-reviewer.md +86 -86
- package/agents/review/python-reviewer.md +150 -150
- package/agents/review/rails-reviewer.md +139 -139
- package/agents/review/react-reviewer.md +144 -144
- package/agents/review/security-reviewer.md +80 -80
- package/agents/review/simplicity-reviewer.md +140 -140
- package/agents/review/test-coverage-reviewer.md +116 -116
- package/agents/review/typescript-reviewer.md +127 -127
- package/agents/searcher.md +54 -54
- package/agents/simplifier.md +119 -119
- package/agents/tester.md +49 -49
- package/agents/ui-previewer.md +129 -129
- package/commands/vibe.analyze.md +260 -260
- package/commands/vibe.reason.md +223 -223
- package/commands/vibe.review.md +213 -213
- package/commands/vibe.run.md +931 -931
- package/commands/vibe.spec.md +442 -442
- package/commands/vibe.utils.md +101 -101
- package/commands/vibe.verify.md +282 -282
- package/dist/cli/collaborator.js +52 -52
- package/dist/cli/detect.js +32 -32
- package/dist/cli/index.js +137 -137
- package/dist/cli/index.js.map +1 -1
- package/dist/cli/llm.js +147 -147
- package/dist/cli/llm.js.map +1 -1
- package/dist/cli/setup.d.ts +1 -1
- package/dist/cli/setup.d.ts.map +1 -1
- package/dist/cli/setup.js +48 -54
- package/dist/cli/setup.js.map +1 -1
- package/dist/lib/MemoryManager.d.ts +4 -0
- package/dist/lib/MemoryManager.d.ts.map +1 -1
- package/dist/lib/MemoryManager.js +21 -2
- package/dist/lib/MemoryManager.js.map +1 -1
- package/dist/lib/PythonParser.js +108 -108
- package/dist/lib/gemini-api.d.ts +13 -3
- package/dist/lib/gemini-api.d.ts.map +1 -1
- package/dist/lib/gemini-api.js +198 -7
- package/dist/lib/gemini-api.js.map +1 -1
- package/dist/lib/gpt-api.d.ts +5 -4
- package/dist/lib/gpt-api.d.ts.map +1 -1
- package/dist/lib/gpt-api.js +168 -12
- package/dist/lib/gpt-api.js.map +1 -1
- package/dist/tools/memory/saveMemory.js +1 -1
- package/dist/tools/memory/saveMemory.js.map +1 -1
- package/dist/tools/reasoning/applyReasoningFramework.js +56 -56
- package/hooks/hooks.json +195 -195
- package/languages/dart-flutter.md +509 -0
- package/languages/go.md +396 -0
- package/languages/java-spring.md +586 -0
- package/languages/kotlin-android.md +491 -0
- package/languages/python-django.md +371 -0
- package/languages/python-fastapi.md +386 -0
- package/languages/rust.md +425 -0
- package/languages/swift-ios.md +516 -0
- package/languages/typescript-nextjs.md +441 -0
- package/languages/typescript-node.md +375 -0
- package/languages/typescript-nuxt.md +521 -0
- package/languages/typescript-react-native.md +446 -0
- package/languages/typescript-react.md +525 -0
- package/languages/typescript-vue.md +353 -0
- package/package.json +88 -87
- package/skills/context7-usage.md +82 -82
- package/skills/git-worktree.md +181 -181
- package/skills/multi-llm-orchestration.md +92 -92
- package/skills/parallel-research.md +77 -77
- package/skills/priority-todos.md +239 -239
- package/skills/tool-fallback.md +126 -126
- package/skills/vibe-capabilities.md +129 -129
- package/{.claude/vibe → vibe}/config.json +3 -3
- package/{.claude/vibe → vibe}/constitution.md +184 -184
- package/{.claude/vibe → vibe}/rules/core/communication-guide.md +104 -104
- package/{.claude/vibe → vibe}/rules/core/development-philosophy.md +52 -52
- package/{.claude/vibe → vibe}/rules/core/quick-start.md +120 -120
- package/{.claude/vibe → vibe}/rules/quality/bdd-contract-testing.md +388 -388
- package/{.claude/vibe → vibe}/rules/quality/checklist.md +276 -276
- package/{.claude/vibe → vibe}/rules/quality/testing-strategy.md +437 -437
- package/{.claude/vibe → vibe}/rules/standards/anti-patterns.md +369 -369
- package/{.claude/vibe → vibe}/rules/standards/code-structure.md +291 -291
- package/{.claude/vibe → vibe}/rules/standards/complexity-metrics.md +312 -312
- package/{.claude/vibe → vibe}/rules/standards/naming-conventions.md +198 -198
- package/{.claude/vibe → vibe}/setup.sh +31 -31
- package/{.claude/vibe → vibe}/templates/constitution-template.md +184 -184
- package/{.claude/vibe → vibe}/templates/contract-backend-template.md +517 -517
- package/{.claude/vibe → vibe}/templates/contract-frontend-template.md +594 -594
- package/{.claude/vibe → vibe}/templates/feature-template.md +96 -96
- package/{.claude/vibe → vibe}/templates/spec-template.md +199 -199
package/commands/vibe.spec.md
CHANGED
|
@@ -1,442 +1,442 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Create SPEC document with Specification Agent
|
|
3
|
-
argument-hint: "feature name"
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# /vibe.spec
|
|
7
|
-
|
|
8
|
-
Create a SPEC document (Specification Agent).
|
|
9
|
-
|
|
10
|
-
## Usage
|
|
11
|
-
|
|
12
|
-
```
|
|
13
|
-
/vibe.spec "feature-name"
|
|
14
|
-
```
|
|
15
|
-
|
|
16
|
-
## Rules Reference
|
|
17
|
-
|
|
18
|
-
**Must follow `.claude/vibe/rules/`:**
|
|
19
|
-
- `core/development-philosophy.md` - Surgical precision, simplicity
|
|
20
|
-
- `core/quick-start.md` - Korean first, DRY, SRP
|
|
21
|
-
- `core/communication-guide.md` - Communication principles
|
|
22
|
-
|
|
23
|
-
## Description
|
|
24
|
-
|
|
25
|
-
Collect requirements through conversation with the user and create an **AI-executable PTCF structured SPEC document**.
|
|
26
|
-
|
|
27
|
-
> **PTCF**: Persona, Task, Context, Format - Google Gemini prompt optimization framework
|
|
28
|
-
|
|
29
|
-
## External LLM Integration (Optional)
|
|
30
|
-
|
|
31
|
-
When external LLMs are enabled, automatically utilize during SPEC creation:
|
|
32
|
-
|
|
33
|
-
```
|
|
34
|
-
/vibe.spec "complex feature"
|
|
35
|
-
↓
|
|
36
|
-
[Claude Opus] Create SPEC draft
|
|
37
|
-
↓
|
|
38
|
-
[GPT enabled?] → gpt- Review this architecture: [design]
|
|
39
|
-
↓
|
|
40
|
-
[Gemini enabled?] → gemini- Suggest UX improvements for: [component]
|
|
41
|
-
↓
|
|
42
|
-
[Claude] Finalize SPEC
|
|
43
|
-
```
|
|
44
|
-
|
|
45
|
-
| External LLM | Prefix | Role | When Used |
|
|
46
|
-
|--------------|--------|------|-----------|
|
|
47
|
-
| GPT | `gpt-`, `gpt.`, `지피티-` | Architecture/design review (Web Search enabled) | After SPEC draft completion |
|
|
48
|
-
| Gemini | `gemini-`, `gemini.`, `제미나이-` | UI/UX consultation (Google Search enabled) | During design reference discussion |
|
|
49
|
-
|
|
50
|
-
**Activation:**
|
|
51
|
-
```bash
|
|
52
|
-
vibe gpt login # Enable GPT (OAuth)
|
|
53
|
-
vibe gemini login # Enable Gemini (OAuth)
|
|
54
|
-
vibe status # Check current settings
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
## Process
|
|
58
|
-
|
|
59
|
-
### 0. Git Branch Setup (Automatic)
|
|
60
|
-
|
|
61
|
-
**CRITICAL: Always create feature branch before starting SPEC**
|
|
62
|
-
|
|
63
|
-
```bash
|
|
64
|
-
# Check current branch
|
|
65
|
-
current=$(git branch --show-current 2>/dev/null || echo "main")
|
|
66
|
-
|
|
67
|
-
# Sanitize feature name (spaces → hyphens, lowercase)
|
|
68
|
-
branch_name="feature/$(echo "{feature-name}" | tr '[:upper:]' '[:lower:]' | tr ' ' '-')"
|
|
69
|
-
|
|
70
|
-
# Create feature branch if on main/master
|
|
71
|
-
if [[ "$current" == "main" || "$current" == "master" ]]; then
|
|
72
|
-
git checkout -b "$branch_name"
|
|
73
|
-
echo "✅ Created and switched to: $branch_name"
|
|
74
|
-
else
|
|
75
|
-
echo "ℹ️ Already on feature branch: $current"
|
|
76
|
-
echo " Continue on this branch? (Y/n)"
|
|
77
|
-
# If user says no, create new branch
|
|
78
|
-
fi
|
|
79
|
-
```
|
|
80
|
-
|
|
81
|
-
**Rules:**
|
|
82
|
-
- If on `main`/`master` → **Always** create `feature/{feature-name}` branch
|
|
83
|
-
- If already on feature branch → Ask user to confirm or create new branch
|
|
84
|
-
- Branch naming: `feature/passkey-auth`, `feature/dark-mode`, etc.
|
|
85
|
-
- Git check BEFORE starting requirements gathering
|
|
86
|
-
|
|
87
|
-
### 1. Project Analysis
|
|
88
|
-
|
|
89
|
-
**Existing project** (`vibe init`):
|
|
90
|
-
- Source code analysis: `package.json`, `pyproject.toml`, `pubspec.yaml`, `go.mod`, etc.
|
|
91
|
-
- Reference `CLAUDE.md` file (tech stack)
|
|
92
|
-
- Infer framework from file structure
|
|
93
|
-
- **Use `findSymbol` tool** to locate relevant existing implementations
|
|
94
|
-
|
|
95
|
-
**New project** (`vibe init <project-name>`):
|
|
96
|
-
- Suggest tech stack (2-3 options)
|
|
97
|
-
|
|
98
|
-
### 2. Collect Requirements via Conversation
|
|
99
|
-
|
|
100
|
-
**Principles:**
|
|
101
|
-
- Ask **one question at a time**
|
|
102
|
-
- Present options **with numbers** + "Feel free to describe in your own words"
|
|
103
|
-
- **Natural conversation** without fixed order
|
|
104
|
-
|
|
105
|
-
**Required confirmations:**
|
|
106
|
-
- Purpose (Why): Why is it needed?
|
|
107
|
-
- User (Who): Who will use it?
|
|
108
|
-
- Feature scope (What): What features are needed?
|
|
109
|
-
- Tech stack: Confirm existing stack or suggest new
|
|
110
|
-
- Design reference: UI/UX to reference
|
|
111
|
-
|
|
112
|
-
### 3. Parallel Research (v2.4.0) - MANDATORY AFTER requirements confirmed
|
|
113
|
-
|
|
114
|
-
**🚨 CRITICAL: Research is MANDATORY after requirements are confirmed**
|
|
115
|
-
|
|
116
|
-
**When to trigger:**
|
|
117
|
-
1. ✅ Feature type decided (e.g., "passkey authentication")
|
|
118
|
-
2. ✅ Tech stack confirmed (e.g., "React + Supabase")
|
|
119
|
-
3. ✅ Core requirements collected
|
|
120
|
-
|
|
121
|
-
**→ IMMEDIATELY run orchestrator research. NO EXCEPTIONS.**
|
|
122
|
-
|
|
123
|
-
**Execution via Orchestrator (4 agents in parallel):**
|
|
124
|
-
```bash
|
|
125
|
-
node -e "import('@su-record/vibe/orchestrator').then(o => o.research('[FEATURE]', ['[STACK1]', '[STACK2]']).then(r => console.log(r.content[0].text)))"
|
|
126
|
-
```
|
|
127
|
-
|
|
128
|
-
**Example:**
|
|
129
|
-
```bash
|
|
130
|
-
# After confirming: passkey auth + React + Supabase
|
|
131
|
-
node -e "import('@su-record/vibe/orchestrator').then(o => o.research('passkey authentication', ['React', 'Supabase']).then(r => console.log(r.content[0].text)))"
|
|
132
|
-
```
|
|
133
|
-
|
|
134
|
-
**What runs in parallel (180s timeout each):**
|
|
135
|
-
| Agent | Role | Tools |
|
|
136
|
-
|-------|------|-------|
|
|
137
|
-
| `best-practices-agent` | Best practices for [feature] + [stack] | WebSearch |
|
|
138
|
-
| `framework-docs-agent` | Latest docs via context7 | context7 MCP |
|
|
139
|
-
| `codebase-patterns-agent` | Similar patterns in existing codebase | Glob, Grep |
|
|
140
|
-
| `security-advisory-agent` | Security advisories for [feature] | WebSearch |
|
|
141
|
-
|
|
142
|
-
**IMPORTANT:**
|
|
143
|
-
- ❌ DO NOT skip research step
|
|
144
|
-
- ❌ DO NOT ask user "should I run research?"
|
|
145
|
-
- ✅ ALWAYS run after requirements confirmed
|
|
146
|
-
- ✅ Show "Running parallel research..." message
|
|
147
|
-
- ✅ Include all 4 agent results in SPEC Context
|
|
148
|
-
|
|
149
|
-
**Research results are reflected in SPEC's Context section.**
|
|
150
|
-
|
|
151
|
-
### 4. Write SPEC Document (PTCF Structure)
|
|
152
|
-
|
|
153
|
-
Create `.claude/vibe/specs/{feature-name}.md`:
|
|
154
|
-
|
|
155
|
-
```markdown
|
|
156
|
-
# SPEC: {feature-name}
|
|
157
|
-
|
|
158
|
-
## Persona
|
|
159
|
-
<role>
|
|
160
|
-
Define AI role and expertise for implementation
|
|
161
|
-
- Senior developer on the project
|
|
162
|
-
- Follow existing code patterns
|
|
163
|
-
- Write testable code
|
|
164
|
-
</role>
|
|
165
|
-
|
|
166
|
-
## Context
|
|
167
|
-
<context>
|
|
168
|
-
### Background
|
|
169
|
-
- Why this feature is needed
|
|
170
|
-
- Who will use it
|
|
171
|
-
|
|
172
|
-
### Tech Stack
|
|
173
|
-
- Backend: {technology}
|
|
174
|
-
- Frontend: {technology}
|
|
175
|
-
- Database: {technology}
|
|
176
|
-
|
|
177
|
-
### Related Code
|
|
178
|
-
- `src/xxx/`: Existing implementation to reference
|
|
179
|
-
- `src/yyy/`: Files to modify
|
|
180
|
-
|
|
181
|
-
### Design Reference
|
|
182
|
-
- {Reference app/service}
|
|
183
|
-
</context>
|
|
184
|
-
|
|
185
|
-
## Task
|
|
186
|
-
<task>
|
|
187
|
-
### Phase 1: {phase-name}
|
|
188
|
-
1. [ ] {specific task}
|
|
189
|
-
- File: `path/to/file`
|
|
190
|
-
- Verify: `command`
|
|
191
|
-
2. [ ] {specific task}
|
|
192
|
-
|
|
193
|
-
### Phase 2: {phase-name}
|
|
194
|
-
1. [ ] {specific task}
|
|
195
|
-
2. [ ] {specific task}
|
|
196
|
-
|
|
197
|
-
### Phase 3: Testing and Verification
|
|
198
|
-
1. [ ] Unit Tests
|
|
199
|
-
2. [ ] Integration Tests
|
|
200
|
-
</task>
|
|
201
|
-
|
|
202
|
-
## Constraints
|
|
203
|
-
<constraints>
|
|
204
|
-
- Follow existing code patterns
|
|
205
|
-
- Localize error messages
|
|
206
|
-
- Separate configuration via environment variables
|
|
207
|
-
- {other constraints}
|
|
208
|
-
</constraints>
|
|
209
|
-
|
|
210
|
-
## Output Format
|
|
211
|
-
<output_format>
|
|
212
|
-
### Files to Create
|
|
213
|
-
- `path/to/new/file.ts`
|
|
214
|
-
- `path/to/new/file.test.ts`
|
|
215
|
-
|
|
216
|
-
### Files to Modify
|
|
217
|
-
- `path/to/existing/file.ts`
|
|
218
|
-
|
|
219
|
-
### Verification Commands
|
|
220
|
-
- `npm test`
|
|
221
|
-
- `npm run build`
|
|
222
|
-
</output_format>
|
|
223
|
-
|
|
224
|
-
## Acceptance Criteria
|
|
225
|
-
<acceptance>
|
|
226
|
-
- [ ] {verifiable criterion 1}
|
|
227
|
-
- [ ] {verifiable criterion 2}
|
|
228
|
-
- [ ] All tests pass
|
|
229
|
-
- [ ] Build succeeds
|
|
230
|
-
</acceptance>
|
|
231
|
-
```
|
|
232
|
-
|
|
233
|
-
### 5. Create Feature File (BDD) - Required
|
|
234
|
-
|
|
235
|
-
**Must** create `.claude/vibe/features/{feature-name}.feature` file.
|
|
236
|
-
|
|
237
|
-
**Creation rules:**
|
|
238
|
-
1. Convert each SPEC Acceptance Criteria → one Scenario
|
|
239
|
-
2. Include Happy Path (normal case) + Edge Case (exception case)
|
|
240
|
-
3. Follow Given-When-Then format
|
|
241
|
-
|
|
242
|
-
**Feature structure:**
|
|
243
|
-
```markdown
|
|
244
|
-
# Feature: {feature-name}
|
|
245
|
-
|
|
246
|
-
**SPEC**: `.claude/vibe/specs/{feature-name}.md`
|
|
247
|
-
|
|
248
|
-
## User Story
|
|
249
|
-
**As a** {user}
|
|
250
|
-
**I want** {feature}
|
|
251
|
-
**So that** {value}
|
|
252
|
-
|
|
253
|
-
## Scenarios
|
|
254
|
-
|
|
255
|
-
### Scenario 1: {Happy Path}
|
|
256
|
-
\`\`\`gherkin
|
|
257
|
-
Scenario: {title}
|
|
258
|
-
Given {precondition}
|
|
259
|
-
When {action}
|
|
260
|
-
Then {result}
|
|
261
|
-
\`\`\`
|
|
262
|
-
**Verification**: SPEC AC #1
|
|
263
|
-
|
|
264
|
-
### Scenario 2: {Edge Case}
|
|
265
|
-
...
|
|
266
|
-
|
|
267
|
-
## Coverage
|
|
268
|
-
| Scenario | SPEC AC | Status |
|
|
269
|
-
|----------|---------|--------|
|
|
270
|
-
| 1 | AC-1 | ⬜ |
|
|
271
|
-
```
|
|
272
|
-
|
|
273
|
-
### 6. Ambiguity Scan - Required
|
|
274
|
-
|
|
275
|
-
After creating SPEC draft, **must perform systematic ambiguity check**.
|
|
276
|
-
|
|
277
|
-
**Check categories:**
|
|
278
|
-
|
|
279
|
-
| Category | Check Items |
|
|
280
|
-
|----------|-------------|
|
|
281
|
-
| **Functional Scope** | Missing features, unclear behavior definitions |
|
|
282
|
-
| **Data Model** | Undefined entities, unclear relationships |
|
|
283
|
-
| **Non-Functional** | Missing performance requirements, security considerations |
|
|
284
|
-
| **Edge Cases** | Boundary conditions, error handling scenarios |
|
|
285
|
-
| **Integration Points** | External system integration, API contracts |
|
|
286
|
-
|
|
287
|
-
**Check process:**
|
|
288
|
-
|
|
289
|
-
```
|
|
290
|
-
1. Create SPEC draft
|
|
291
|
-
↓
|
|
292
|
-
2. Scan by category for ambiguity
|
|
293
|
-
↓
|
|
294
|
-
3. Present list of found ambiguities
|
|
295
|
-
↓
|
|
296
|
-
4. Request user clarification
|
|
297
|
-
↓
|
|
298
|
-
5. Refine SPEC
|
|
299
|
-
↓
|
|
300
|
-
6. Re-check (until 0 ambiguities)
|
|
301
|
-
```
|
|
302
|
-
|
|
303
|
-
**Ambiguity output format:**
|
|
304
|
-
|
|
305
|
-
```markdown
|
|
306
|
-
## 🔍 Ambiguity Scan Results
|
|
307
|
-
|
|
308
|
-
### Functional Scope
|
|
309
|
-
- ⚠️ "Login failure behavior" not defined
|
|
310
|
-
- ⚠️ "Session expiration handling" unclear
|
|
311
|
-
|
|
312
|
-
### Edge Cases
|
|
313
|
-
- ⚠️ Concurrent login permission undefined
|
|
314
|
-
- ⚠️ No password retry limit specified
|
|
315
|
-
|
|
316
|
-
Please clarify the above items.
|
|
317
|
-
```
|
|
318
|
-
|
|
319
|
-
### 7. Quality Validation
|
|
320
|
-
|
|
321
|
-
Self-evaluate against `.claude/vibe/rules/quality/checklist.md` (0-100 score)
|
|
322
|
-
|
|
323
|
-
## Output
|
|
324
|
-
|
|
325
|
-
- `.claude/vibe/specs/{feature-name}.md` - PTCF structured SPEC
|
|
326
|
-
- `.claude/vibe/features/{feature-name}.feature` - BDD Feature file
|
|
327
|
-
- Ambiguity scan results (0 ambiguities confirmed)
|
|
328
|
-
- Quality score and improvement suggestions
|
|
329
|
-
|
|
330
|
-
## Example
|
|
331
|
-
|
|
332
|
-
```
|
|
333
|
-
User: /vibe.spec "brick-game"
|
|
334
|
-
|
|
335
|
-
Claude:
|
|
336
|
-
You're making a brick game! What style are you thinking of?
|
|
337
|
-
|
|
338
|
-
1. Classic Breakout style
|
|
339
|
-
2. Arkanoid (with power-up items)
|
|
340
|
-
3. Custom style with special gameplay
|
|
341
|
-
|
|
342
|
-
Feel free to describe in your own words.
|
|
343
|
-
|
|
344
|
-
User: 1
|
|
345
|
-
|
|
346
|
-
Claude: What platform will it run on?
|
|
347
|
-
|
|
348
|
-
1. Web (browser)
|
|
349
|
-
2. Mobile (iOS/Android)
|
|
350
|
-
3. Desktop
|
|
351
|
-
|
|
352
|
-
User: 1
|
|
353
|
-
|
|
354
|
-
Claude:
|
|
355
|
-
Here are tech stack suggestions for web game development:
|
|
356
|
-
|
|
357
|
-
1. **Phaser.js** (Recommended) - Game framework with built-in physics engine
|
|
358
|
-
2. **Canvas + JavaScript** - Lightweight with fine control
|
|
359
|
-
3. **PixiJS + Matter.js** - High-performance rendering
|
|
360
|
-
|
|
361
|
-
User: 1
|
|
362
|
-
|
|
363
|
-
Claude: What design style?
|
|
364
|
-
|
|
365
|
-
1. Retro pixel (Atari Breakout)
|
|
366
|
-
2. Neon graphics (Arkanoid)
|
|
367
|
-
3. Modern 3D effects
|
|
368
|
-
|
|
369
|
-
User: 2
|
|
370
|
-
|
|
371
|
-
[Conversation continues...]
|
|
372
|
-
|
|
373
|
-
Claude: SPEC draft created. Running ambiguity scan.
|
|
374
|
-
|
|
375
|
-
## 🔍 Ambiguity Scan Results
|
|
376
|
-
|
|
377
|
-
### Functional Scope
|
|
378
|
-
- ⚠️ Game over condition not defined (ball drop vs lives system)
|
|
379
|
-
- ⚠️ Stage clear condition unclear
|
|
380
|
-
|
|
381
|
-
### Edge Cases
|
|
382
|
-
- ⚠️ Ball reflection angle when hitting paddle edge
|
|
383
|
-
- ⚠️ Multiple brick collision handling
|
|
384
|
-
|
|
385
|
-
Please clarify the above items.
|
|
386
|
-
|
|
387
|
-
User: 3 lives, clear when all bricks destroyed, edge reflects at 45 degrees
|
|
388
|
-
|
|
389
|
-
Claude: Thank you. SPEC has been refined.
|
|
390
|
-
|
|
391
|
-
🔍 Re-check result: 0 ambiguities
|
|
392
|
-
|
|
393
|
-
✅ SPEC document complete!
|
|
394
|
-
📄 .claude/vibe/specs/brick-game.md (PTCF structure)
|
|
395
|
-
📄 .claude/vibe/features/brick-game.feature
|
|
396
|
-
📊 Quality score: 92/100 (A)
|
|
397
|
-
```
|
|
398
|
-
|
|
399
|
-
## Vibe Tools (Semantic Analysis & Memory)
|
|
400
|
-
|
|
401
|
-
### Tool Invocation
|
|
402
|
-
All tools are called via:
|
|
403
|
-
```bash
|
|
404
|
-
node -e "import('@su-record/vibe/tools').then(t => t.TOOL_NAME({...args}).then(r => console.log(r.content[0].text)))"
|
|
405
|
-
```
|
|
406
|
-
|
|
407
|
-
### Recommended Tools for SPEC Creation
|
|
408
|
-
|
|
409
|
-
| Tool | Purpose | When to Use |
|
|
410
|
-
|------|---------|-------------|
|
|
411
|
-
| `findSymbol` | Find symbol definitions | Locate existing implementations to reference |
|
|
412
|
-
| `findReferences` | Find all references | Understand how existing code is used |
|
|
413
|
-
| `analyzeComplexity` | Code complexity analysis | Evaluate complexity of code to modify |
|
|
414
|
-
| `saveMemory` | Save important decisions | Store confirmed requirements, design decisions |
|
|
415
|
-
| `recallMemory` | Recall saved memory | Retrieve previous project decisions |
|
|
416
|
-
|
|
417
|
-
### Example Tool Usage in SPEC Creation
|
|
418
|
-
|
|
419
|
-
**1. Find existing auth implementation:**
|
|
420
|
-
```bash
|
|
421
|
-
node -e "import('@su-record/vibe/tools').then(t => t.findSymbol({symbolName: 'login', searchPath: 'src/'}).then(r => console.log(r.content[0].text)))"
|
|
422
|
-
```
|
|
423
|
-
|
|
424
|
-
**2. Save confirmed requirements:**
|
|
425
|
-
```bash
|
|
426
|
-
node -e "import('@su-record/vibe/tools').then(t => t.saveMemory({key: 'brick-game-requirements', value: 'Platform: Web, Stack: Phaser.js, Style: Neon', category: 'spec', projectPath: process.cwd()}).then(r => console.log(r.content[0].text)))"
|
|
427
|
-
```
|
|
428
|
-
|
|
429
|
-
**3. Recall previous decisions:**
|
|
430
|
-
```bash
|
|
431
|
-
node -e "import('@su-record/vibe/tools').then(t => t.recallMemory({key: 'brick-game-requirements', projectPath: process.cwd()}).then(r => console.log(r.content[0].text)))"
|
|
432
|
-
```
|
|
433
|
-
|
|
434
|
-
## Next Step
|
|
435
|
-
|
|
436
|
-
```
|
|
437
|
-
/vibe.run "brick-game"
|
|
438
|
-
```
|
|
439
|
-
|
|
440
|
-
---
|
|
441
|
-
|
|
442
|
-
ARGUMENTS: $ARGUMENTS
|
|
1
|
+
---
|
|
2
|
+
description: Create SPEC document with Specification Agent
|
|
3
|
+
argument-hint: "feature name"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /vibe.spec
|
|
7
|
+
|
|
8
|
+
Create a SPEC document (Specification Agent).
|
|
9
|
+
|
|
10
|
+
## Usage
|
|
11
|
+
|
|
12
|
+
```
|
|
13
|
+
/vibe.spec "feature-name"
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## Rules Reference
|
|
17
|
+
|
|
18
|
+
**Must follow `.claude/vibe/rules/`:**
|
|
19
|
+
- `core/development-philosophy.md` - Surgical precision, simplicity
|
|
20
|
+
- `core/quick-start.md` - Korean first, DRY, SRP
|
|
21
|
+
- `core/communication-guide.md` - Communication principles
|
|
22
|
+
|
|
23
|
+
## Description
|
|
24
|
+
|
|
25
|
+
Collect requirements through conversation with the user and create an **AI-executable PTCF structured SPEC document**.
|
|
26
|
+
|
|
27
|
+
> **PTCF**: Persona, Task, Context, Format - Google Gemini prompt optimization framework
|
|
28
|
+
|
|
29
|
+
## External LLM Integration (Optional)
|
|
30
|
+
|
|
31
|
+
When external LLMs are enabled, automatically utilize during SPEC creation:
|
|
32
|
+
|
|
33
|
+
```
|
|
34
|
+
/vibe.spec "complex feature"
|
|
35
|
+
↓
|
|
36
|
+
[Claude Opus] Create SPEC draft
|
|
37
|
+
↓
|
|
38
|
+
[GPT enabled?] → gpt- Review this architecture: [design]
|
|
39
|
+
↓
|
|
40
|
+
[Gemini enabled?] → gemini- Suggest UX improvements for: [component]
|
|
41
|
+
↓
|
|
42
|
+
[Claude] Finalize SPEC
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
| External LLM | Prefix | Role | When Used |
|
|
46
|
+
|--------------|--------|------|-----------|
|
|
47
|
+
| GPT | `gpt-`, `gpt.`, `지피티-` | Architecture/design review (Web Search enabled) | After SPEC draft completion |
|
|
48
|
+
| Gemini | `gemini-`, `gemini.`, `제미나이-` | UI/UX consultation (Google Search enabled) | During design reference discussion |
|
|
49
|
+
|
|
50
|
+
**Activation:**
|
|
51
|
+
```bash
|
|
52
|
+
vibe gpt login # Enable GPT (OAuth)
|
|
53
|
+
vibe gemini login # Enable Gemini (OAuth)
|
|
54
|
+
vibe status # Check current settings
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
## Process
|
|
58
|
+
|
|
59
|
+
### 0. Git Branch Setup (Automatic)
|
|
60
|
+
|
|
61
|
+
**CRITICAL: Always create feature branch before starting SPEC**
|
|
62
|
+
|
|
63
|
+
```bash
|
|
64
|
+
# Check current branch
|
|
65
|
+
current=$(git branch --show-current 2>/dev/null || echo "main")
|
|
66
|
+
|
|
67
|
+
# Sanitize feature name (spaces → hyphens, lowercase)
|
|
68
|
+
branch_name="feature/$(echo "{feature-name}" | tr '[:upper:]' '[:lower:]' | tr ' ' '-')"
|
|
69
|
+
|
|
70
|
+
# Create feature branch if on main/master
|
|
71
|
+
if [[ "$current" == "main" || "$current" == "master" ]]; then
|
|
72
|
+
git checkout -b "$branch_name"
|
|
73
|
+
echo "✅ Created and switched to: $branch_name"
|
|
74
|
+
else
|
|
75
|
+
echo "ℹ️ Already on feature branch: $current"
|
|
76
|
+
echo " Continue on this branch? (Y/n)"
|
|
77
|
+
# If user says no, create new branch
|
|
78
|
+
fi
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
**Rules:**
|
|
82
|
+
- If on `main`/`master` → **Always** create `feature/{feature-name}` branch
|
|
83
|
+
- If already on feature branch → Ask user to confirm or create new branch
|
|
84
|
+
- Branch naming: `feature/passkey-auth`, `feature/dark-mode`, etc.
|
|
85
|
+
- Git check BEFORE starting requirements gathering
|
|
86
|
+
|
|
87
|
+
### 1. Project Analysis
|
|
88
|
+
|
|
89
|
+
**Existing project** (`vibe init`):
|
|
90
|
+
- Source code analysis: `package.json`, `pyproject.toml`, `pubspec.yaml`, `go.mod`, etc.
|
|
91
|
+
- Reference `CLAUDE.md` file (tech stack)
|
|
92
|
+
- Infer framework from file structure
|
|
93
|
+
- **Use `findSymbol` tool** to locate relevant existing implementations
|
|
94
|
+
|
|
95
|
+
**New project** (`vibe init <project-name>`):
|
|
96
|
+
- Suggest tech stack (2-3 options)
|
|
97
|
+
|
|
98
|
+
### 2. Collect Requirements via Conversation
|
|
99
|
+
|
|
100
|
+
**Principles:**
|
|
101
|
+
- Ask **one question at a time**
|
|
102
|
+
- Present options **with numbers** + "Feel free to describe in your own words"
|
|
103
|
+
- **Natural conversation** without fixed order
|
|
104
|
+
|
|
105
|
+
**Required confirmations:**
|
|
106
|
+
- Purpose (Why): Why is it needed?
|
|
107
|
+
- User (Who): Who will use it?
|
|
108
|
+
- Feature scope (What): What features are needed?
|
|
109
|
+
- Tech stack: Confirm existing stack or suggest new
|
|
110
|
+
- Design reference: UI/UX to reference
|
|
111
|
+
|
|
112
|
+
### 3. Parallel Research (v2.4.0) - MANDATORY AFTER requirements confirmed
|
|
113
|
+
|
|
114
|
+
**🚨 CRITICAL: Research is MANDATORY after requirements are confirmed**
|
|
115
|
+
|
|
116
|
+
**When to trigger:**
|
|
117
|
+
1. ✅ Feature type decided (e.g., "passkey authentication")
|
|
118
|
+
2. ✅ Tech stack confirmed (e.g., "React + Supabase")
|
|
119
|
+
3. ✅ Core requirements collected
|
|
120
|
+
|
|
121
|
+
**→ IMMEDIATELY run orchestrator research. NO EXCEPTIONS.**
|
|
122
|
+
|
|
123
|
+
**Execution via Orchestrator (4 agents in parallel):**
|
|
124
|
+
```bash
|
|
125
|
+
node -e "import('@su-record/vibe/orchestrator').then(o => o.research('[FEATURE]', ['[STACK1]', '[STACK2]']).then(r => console.log(r.content[0].text)))"
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
**Example:**
|
|
129
|
+
```bash
|
|
130
|
+
# After confirming: passkey auth + React + Supabase
|
|
131
|
+
node -e "import('@su-record/vibe/orchestrator').then(o => o.research('passkey authentication', ['React', 'Supabase']).then(r => console.log(r.content[0].text)))"
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
**What runs in parallel (180s timeout each):**
|
|
135
|
+
| Agent | Role | Tools |
|
|
136
|
+
|-------|------|-------|
|
|
137
|
+
| `best-practices-agent` | Best practices for [feature] + [stack] | WebSearch |
|
|
138
|
+
| `framework-docs-agent` | Latest docs via context7 | context7 MCP |
|
|
139
|
+
| `codebase-patterns-agent` | Similar patterns in existing codebase | Glob, Grep |
|
|
140
|
+
| `security-advisory-agent` | Security advisories for [feature] | WebSearch |
|
|
141
|
+
|
|
142
|
+
**IMPORTANT:**
|
|
143
|
+
- ❌ DO NOT skip research step
|
|
144
|
+
- ❌ DO NOT ask user "should I run research?"
|
|
145
|
+
- ✅ ALWAYS run after requirements confirmed
|
|
146
|
+
- ✅ Show "Running parallel research..." message
|
|
147
|
+
- ✅ Include all 4 agent results in SPEC Context
|
|
148
|
+
|
|
149
|
+
**Research results are reflected in SPEC's Context section.**
|
|
150
|
+
|
|
151
|
+
### 4. Write SPEC Document (PTCF Structure)
|
|
152
|
+
|
|
153
|
+
Create `.claude/vibe/specs/{feature-name}.md`:
|
|
154
|
+
|
|
155
|
+
```markdown
|
|
156
|
+
# SPEC: {feature-name}
|
|
157
|
+
|
|
158
|
+
## Persona
|
|
159
|
+
<role>
|
|
160
|
+
Define AI role and expertise for implementation
|
|
161
|
+
- Senior developer on the project
|
|
162
|
+
- Follow existing code patterns
|
|
163
|
+
- Write testable code
|
|
164
|
+
</role>
|
|
165
|
+
|
|
166
|
+
## Context
|
|
167
|
+
<context>
|
|
168
|
+
### Background
|
|
169
|
+
- Why this feature is needed
|
|
170
|
+
- Who will use it
|
|
171
|
+
|
|
172
|
+
### Tech Stack
|
|
173
|
+
- Backend: {technology}
|
|
174
|
+
- Frontend: {technology}
|
|
175
|
+
- Database: {technology}
|
|
176
|
+
|
|
177
|
+
### Related Code
|
|
178
|
+
- `src/xxx/`: Existing implementation to reference
|
|
179
|
+
- `src/yyy/`: Files to modify
|
|
180
|
+
|
|
181
|
+
### Design Reference
|
|
182
|
+
- {Reference app/service}
|
|
183
|
+
</context>
|
|
184
|
+
|
|
185
|
+
## Task
|
|
186
|
+
<task>
|
|
187
|
+
### Phase 1: {phase-name}
|
|
188
|
+
1. [ ] {specific task}
|
|
189
|
+
- File: `path/to/file`
|
|
190
|
+
- Verify: `command`
|
|
191
|
+
2. [ ] {specific task}
|
|
192
|
+
|
|
193
|
+
### Phase 2: {phase-name}
|
|
194
|
+
1. [ ] {specific task}
|
|
195
|
+
2. [ ] {specific task}
|
|
196
|
+
|
|
197
|
+
### Phase 3: Testing and Verification
|
|
198
|
+
1. [ ] Unit Tests
|
|
199
|
+
2. [ ] Integration Tests
|
|
200
|
+
</task>
|
|
201
|
+
|
|
202
|
+
## Constraints
|
|
203
|
+
<constraints>
|
|
204
|
+
- Follow existing code patterns
|
|
205
|
+
- Localize error messages
|
|
206
|
+
- Separate configuration via environment variables
|
|
207
|
+
- {other constraints}
|
|
208
|
+
</constraints>
|
|
209
|
+
|
|
210
|
+
## Output Format
|
|
211
|
+
<output_format>
|
|
212
|
+
### Files to Create
|
|
213
|
+
- `path/to/new/file.ts`
|
|
214
|
+
- `path/to/new/file.test.ts`
|
|
215
|
+
|
|
216
|
+
### Files to Modify
|
|
217
|
+
- `path/to/existing/file.ts`
|
|
218
|
+
|
|
219
|
+
### Verification Commands
|
|
220
|
+
- `npm test`
|
|
221
|
+
- `npm run build`
|
|
222
|
+
</output_format>
|
|
223
|
+
|
|
224
|
+
## Acceptance Criteria
|
|
225
|
+
<acceptance>
|
|
226
|
+
- [ ] {verifiable criterion 1}
|
|
227
|
+
- [ ] {verifiable criterion 2}
|
|
228
|
+
- [ ] All tests pass
|
|
229
|
+
- [ ] Build succeeds
|
|
230
|
+
</acceptance>
|
|
231
|
+
```
|
|
232
|
+
|
|
233
|
+
### 5. Create Feature File (BDD) - Required
|
|
234
|
+
|
|
235
|
+
**Must** create `.claude/vibe/features/{feature-name}.feature` file.
|
|
236
|
+
|
|
237
|
+
**Creation rules:**
|
|
238
|
+
1. Convert each SPEC Acceptance Criteria → one Scenario
|
|
239
|
+
2. Include Happy Path (normal case) + Edge Case (exception case)
|
|
240
|
+
3. Follow Given-When-Then format
|
|
241
|
+
|
|
242
|
+
**Feature structure:**
|
|
243
|
+
```markdown
|
|
244
|
+
# Feature: {feature-name}
|
|
245
|
+
|
|
246
|
+
**SPEC**: `.claude/vibe/specs/{feature-name}.md`
|
|
247
|
+
|
|
248
|
+
## User Story
|
|
249
|
+
**As a** {user}
|
|
250
|
+
**I want** {feature}
|
|
251
|
+
**So that** {value}
|
|
252
|
+
|
|
253
|
+
## Scenarios
|
|
254
|
+
|
|
255
|
+
### Scenario 1: {Happy Path}
|
|
256
|
+
\`\`\`gherkin
|
|
257
|
+
Scenario: {title}
|
|
258
|
+
Given {precondition}
|
|
259
|
+
When {action}
|
|
260
|
+
Then {result}
|
|
261
|
+
\`\`\`
|
|
262
|
+
**Verification**: SPEC AC #1
|
|
263
|
+
|
|
264
|
+
### Scenario 2: {Edge Case}
|
|
265
|
+
...
|
|
266
|
+
|
|
267
|
+
## Coverage
|
|
268
|
+
| Scenario | SPEC AC | Status |
|
|
269
|
+
|----------|---------|--------|
|
|
270
|
+
| 1 | AC-1 | ⬜ |
|
|
271
|
+
```
|
|
272
|
+
|
|
273
|
+
### 6. Ambiguity Scan - Required
|
|
274
|
+
|
|
275
|
+
After creating SPEC draft, **must perform systematic ambiguity check**.
|
|
276
|
+
|
|
277
|
+
**Check categories:**
|
|
278
|
+
|
|
279
|
+
| Category | Check Items |
|
|
280
|
+
|----------|-------------|
|
|
281
|
+
| **Functional Scope** | Missing features, unclear behavior definitions |
|
|
282
|
+
| **Data Model** | Undefined entities, unclear relationships |
|
|
283
|
+
| **Non-Functional** | Missing performance requirements, security considerations |
|
|
284
|
+
| **Edge Cases** | Boundary conditions, error handling scenarios |
|
|
285
|
+
| **Integration Points** | External system integration, API contracts |
|
|
286
|
+
|
|
287
|
+
**Check process:**
|
|
288
|
+
|
|
289
|
+
```
|
|
290
|
+
1. Create SPEC draft
|
|
291
|
+
↓
|
|
292
|
+
2. Scan by category for ambiguity
|
|
293
|
+
↓
|
|
294
|
+
3. Present list of found ambiguities
|
|
295
|
+
↓
|
|
296
|
+
4. Request user clarification
|
|
297
|
+
↓
|
|
298
|
+
5. Refine SPEC
|
|
299
|
+
↓
|
|
300
|
+
6. Re-check (until 0 ambiguities)
|
|
301
|
+
```
|
|
302
|
+
|
|
303
|
+
**Ambiguity output format:**
|
|
304
|
+
|
|
305
|
+
```markdown
|
|
306
|
+
## 🔍 Ambiguity Scan Results
|
|
307
|
+
|
|
308
|
+
### Functional Scope
|
|
309
|
+
- ⚠️ "Login failure behavior" not defined
|
|
310
|
+
- ⚠️ "Session expiration handling" unclear
|
|
311
|
+
|
|
312
|
+
### Edge Cases
|
|
313
|
+
- ⚠️ Concurrent login permission undefined
|
|
314
|
+
- ⚠️ No password retry limit specified
|
|
315
|
+
|
|
316
|
+
Please clarify the above items.
|
|
317
|
+
```
|
|
318
|
+
|
|
319
|
+
### 7. Quality Validation
|
|
320
|
+
|
|
321
|
+
Self-evaluate against `.claude/vibe/rules/quality/checklist.md` (0-100 score)
|
|
322
|
+
|
|
323
|
+
## Output
|
|
324
|
+
|
|
325
|
+
- `.claude/vibe/specs/{feature-name}.md` - PTCF structured SPEC
|
|
326
|
+
- `.claude/vibe/features/{feature-name}.feature` - BDD Feature file
|
|
327
|
+
- Ambiguity scan results (0 ambiguities confirmed)
|
|
328
|
+
- Quality score and improvement suggestions
|
|
329
|
+
|
|
330
|
+
## Example
|
|
331
|
+
|
|
332
|
+
```
|
|
333
|
+
User: /vibe.spec "brick-game"
|
|
334
|
+
|
|
335
|
+
Claude:
|
|
336
|
+
You're making a brick game! What style are you thinking of?
|
|
337
|
+
|
|
338
|
+
1. Classic Breakout style
|
|
339
|
+
2. Arkanoid (with power-up items)
|
|
340
|
+
3. Custom style with special gameplay
|
|
341
|
+
|
|
342
|
+
Feel free to describe in your own words.
|
|
343
|
+
|
|
344
|
+
User: 1
|
|
345
|
+
|
|
346
|
+
Claude: What platform will it run on?
|
|
347
|
+
|
|
348
|
+
1. Web (browser)
|
|
349
|
+
2. Mobile (iOS/Android)
|
|
350
|
+
3. Desktop
|
|
351
|
+
|
|
352
|
+
User: 1
|
|
353
|
+
|
|
354
|
+
Claude:
|
|
355
|
+
Here are tech stack suggestions for web game development:
|
|
356
|
+
|
|
357
|
+
1. **Phaser.js** (Recommended) - Game framework with built-in physics engine
|
|
358
|
+
2. **Canvas + JavaScript** - Lightweight with fine control
|
|
359
|
+
3. **PixiJS + Matter.js** - High-performance rendering
|
|
360
|
+
|
|
361
|
+
User: 1
|
|
362
|
+
|
|
363
|
+
Claude: What design style?
|
|
364
|
+
|
|
365
|
+
1. Retro pixel (Atari Breakout)
|
|
366
|
+
2. Neon graphics (Arkanoid)
|
|
367
|
+
3. Modern 3D effects
|
|
368
|
+
|
|
369
|
+
User: 2
|
|
370
|
+
|
|
371
|
+
[Conversation continues...]
|
|
372
|
+
|
|
373
|
+
Claude: SPEC draft created. Running ambiguity scan.
|
|
374
|
+
|
|
375
|
+
## 🔍 Ambiguity Scan Results
|
|
376
|
+
|
|
377
|
+
### Functional Scope
|
|
378
|
+
- ⚠️ Game over condition not defined (ball drop vs lives system)
|
|
379
|
+
- ⚠️ Stage clear condition unclear
|
|
380
|
+
|
|
381
|
+
### Edge Cases
|
|
382
|
+
- ⚠️ Ball reflection angle when hitting paddle edge
|
|
383
|
+
- ⚠️ Multiple brick collision handling
|
|
384
|
+
|
|
385
|
+
Please clarify the above items.
|
|
386
|
+
|
|
387
|
+
User: 3 lives, clear when all bricks destroyed, edge reflects at 45 degrees
|
|
388
|
+
|
|
389
|
+
Claude: Thank you. SPEC has been refined.
|
|
390
|
+
|
|
391
|
+
🔍 Re-check result: 0 ambiguities
|
|
392
|
+
|
|
393
|
+
✅ SPEC document complete!
|
|
394
|
+
📄 .claude/vibe/specs/brick-game.md (PTCF structure)
|
|
395
|
+
📄 .claude/vibe/features/brick-game.feature
|
|
396
|
+
📊 Quality score: 92/100 (A)
|
|
397
|
+
```
|
|
398
|
+
|
|
399
|
+
## Vibe Tools (Semantic Analysis & Memory)
|
|
400
|
+
|
|
401
|
+
### Tool Invocation
|
|
402
|
+
All tools are called via:
|
|
403
|
+
```bash
|
|
404
|
+
node -e "import('@su-record/vibe/tools').then(t => t.TOOL_NAME({...args}).then(r => console.log(r.content[0].text)))"
|
|
405
|
+
```
|
|
406
|
+
|
|
407
|
+
### Recommended Tools for SPEC Creation
|
|
408
|
+
|
|
409
|
+
| Tool | Purpose | When to Use |
|
|
410
|
+
|------|---------|-------------|
|
|
411
|
+
| `findSymbol` | Find symbol definitions | Locate existing implementations to reference |
|
|
412
|
+
| `findReferences` | Find all references | Understand how existing code is used |
|
|
413
|
+
| `analyzeComplexity` | Code complexity analysis | Evaluate complexity of code to modify |
|
|
414
|
+
| `saveMemory` | Save important decisions | Store confirmed requirements, design decisions |
|
|
415
|
+
| `recallMemory` | Recall saved memory | Retrieve previous project decisions |
|
|
416
|
+
|
|
417
|
+
### Example Tool Usage in SPEC Creation
|
|
418
|
+
|
|
419
|
+
**1. Find existing auth implementation:**
|
|
420
|
+
```bash
|
|
421
|
+
node -e "import('@su-record/vibe/tools').then(t => t.findSymbol({symbolName: 'login', searchPath: 'src/'}).then(r => console.log(r.content[0].text)))"
|
|
422
|
+
```
|
|
423
|
+
|
|
424
|
+
**2. Save confirmed requirements:**
|
|
425
|
+
```bash
|
|
426
|
+
node -e "import('@su-record/vibe/tools').then(t => t.saveMemory({key: 'brick-game-requirements', value: 'Platform: Web, Stack: Phaser.js, Style: Neon', category: 'spec', projectPath: process.cwd()}).then(r => console.log(r.content[0].text)))"
|
|
427
|
+
```
|
|
428
|
+
|
|
429
|
+
**3. Recall previous decisions:**
|
|
430
|
+
```bash
|
|
431
|
+
node -e "import('@su-record/vibe/tools').then(t => t.recallMemory({key: 'brick-game-requirements', projectPath: process.cwd()}).then(r => console.log(r.content[0].text)))"
|
|
432
|
+
```
|
|
433
|
+
|
|
434
|
+
## Next Step
|
|
435
|
+
|
|
436
|
+
```
|
|
437
|
+
/vibe.run "brick-game"
|
|
438
|
+
```
|
|
439
|
+
|
|
440
|
+
---
|
|
441
|
+
|
|
442
|
+
ARGUMENTS: $ARGUMENTS
|