@champpaba/claude-agent-kit 3.0.2 → 3.0.3
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/CHANGELOG.md +527 -0
- package/.claude/CLAUDE.md +98 -586
- package/.claude/agents/_shared/pre-work-checklist.md +53 -0
- package/.claude/commands/csetup.md +65 -0
- package/.claude/commands/cview.md +364 -364
- package/.claude/contexts/design/accessibility.md +611 -611
- package/.claude/contexts/design/layout.md +400 -400
- package/.claude/contexts/design/responsive.md +551 -551
- package/.claude/contexts/design/shadows.md +522 -522
- package/.claude/contexts/design/typography.md +465 -465
- package/.claude/contexts/domain/README.md +164 -164
- package/.claude/contexts/patterns/agent-coordination.md +388 -388
- package/.claude/contexts/patterns/development-principles.md +513 -513
- package/.claude/contexts/patterns/error-handling.md +478 -478
- package/.claude/contexts/patterns/logging.md +424 -424
- package/.claude/contexts/patterns/tdd-classification.md +516 -516
- package/.claude/contexts/patterns/testing.md +413 -413
- package/.claude/lib/tdd-classifier.md +345 -345
- package/.claude/lib/validation-gates.md +484 -484
- package/.claude/settings.local.json +42 -42
- package/.claude/templates/PROJECT_STATUS.template.yml +16 -41
- package/.claude/templates/context-template.md +45 -45
- package/.claude/templates/flags-template.json +42 -42
- package/.claude/templates/phases-sections/accessibility-test.md +17 -17
- package/.claude/templates/phases-sections/api-design.md +37 -37
- package/.claude/templates/phases-sections/backend-tests.md +16 -16
- package/.claude/templates/phases-sections/backend.md +37 -37
- package/.claude/templates/phases-sections/business-logic-validation.md +16 -16
- package/.claude/templates/phases-sections/component-tests.md +17 -17
- package/.claude/templates/phases-sections/contract-backend.md +16 -16
- package/.claude/templates/phases-sections/contract-frontend.md +16 -16
- package/.claude/templates/phases-sections/database.md +35 -35
- package/.claude/templates/phases-sections/e2e-tests.md +16 -16
- package/.claude/templates/phases-sections/fix-implementation.md +17 -17
- package/.claude/templates/phases-sections/frontend-integration.md +18 -18
- package/.claude/templates/phases-sections/manual-flow-test.md +15 -15
- package/.claude/templates/phases-sections/manual-ux-test.md +16 -16
- package/.claude/templates/phases-sections/refactor-implementation.md +17 -17
- package/.claude/templates/phases-sections/refactor.md +16 -16
- package/.claude/templates/phases-sections/regression-tests.md +15 -15
- package/.claude/templates/phases-sections/responsive-test.md +16 -16
- package/.claude/templates/phases-sections/script-implementation.md +43 -43
- package/.claude/templates/phases-sections/test-coverage.md +16 -16
- package/.claude/templates/phases-sections/user-approval.md +14 -14
- package/LICENSE +21 -21
- package/package.json +1 -1
|
@@ -0,0 +1,527 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
> **Version History for Claude Agent Kit**
|
|
4
|
+
> For current features, see `CLAUDE.md`
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## v3.0.0: Template-Free Architecture (Task Analyzer v2.0)
|
|
9
|
+
|
|
10
|
+
**Problem Solved:** Phase templates (`phase-templates.json`) were limiting and caused task loss. When `tasks.md` had 5 detailed phases but template had only 2, tasks disappeared. Templates overrode the single source of truth.
|
|
11
|
+
|
|
12
|
+
**Solution:** Delete templates entirely. Use AI-driven Task Analyzer to transform `tasks.md` (WHAT) into `phases.md` (HOW).
|
|
13
|
+
|
|
14
|
+
### Key Changes
|
|
15
|
+
|
|
16
|
+
| Component | Before (v2.x) | After (v3.0) |
|
|
17
|
+
|-----------|---------------|--------------|
|
|
18
|
+
| phases.md source | phase-templates.json | tasks.md (single source of truth) |
|
|
19
|
+
| Agent assignment | Keyword matching | AI context understanding |
|
|
20
|
+
| Missing best practices | Warning prompts | Auto-add automatically |
|
|
21
|
+
| Complex tasks | Same as simple | Incremental milestones |
|
|
22
|
+
| Task filtering | Templates filter tasks | No filtering, ALL tasks kept |
|
|
23
|
+
|
|
24
|
+
### How It Works
|
|
25
|
+
|
|
26
|
+
```
|
|
27
|
+
tasks.md (WHAT to build)
|
|
28
|
+
↓
|
|
29
|
+
Step 1: Parse ALL tasks (no filtering)
|
|
30
|
+
Step 2: AI-driven analysis (complexity, risk, agent, dependencies)
|
|
31
|
+
Step 3: Auto-add best practices (no warnings)
|
|
32
|
+
Step 4: Generate incremental milestones
|
|
33
|
+
Step 5: Sort by priority (phase order → dependencies → risk)
|
|
34
|
+
↓
|
|
35
|
+
phases.md (HOW to build incrementally)
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
### AI-Driven Analysis (vs Keyword Matching)
|
|
39
|
+
|
|
40
|
+
**Old (keyword matching):**
|
|
41
|
+
```
|
|
42
|
+
"Create user service that connects to database"
|
|
43
|
+
Keywords: "service" (backend), "connects" (frontend), "database" (database)
|
|
44
|
+
→ Conflict! Which agent?
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
**New (AI decision):**
|
|
48
|
+
```
|
|
49
|
+
"Create user service that connects to database"
|
|
50
|
+
→ AI understands: This is a backend service layer
|
|
51
|
+
→ Agent: backend ✓
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
### Auto-Add Best Practices (No Warnings)
|
|
55
|
+
|
|
56
|
+
| Condition | Auto-Added Task |
|
|
57
|
+
|-----------|-----------------|
|
|
58
|
+
| HIGH risk task | Checkpoint: Verify before proceeding |
|
|
59
|
+
| External API | Error handling + retry + timeout |
|
|
60
|
+
| Implementation (complexity ≥ 5) | Verification task |
|
|
61
|
+
| Database changes | Backup + rollback test |
|
|
62
|
+
| Security-critical | Security review + log check |
|
|
63
|
+
|
|
64
|
+
### Incremental Milestones
|
|
65
|
+
|
|
66
|
+
Complex tasks (risk=HIGH OR complexity≥7) get automatic milestones:
|
|
67
|
+
|
|
68
|
+
| Pattern | Strategy | Milestones |
|
|
69
|
+
|---------|----------|------------|
|
|
70
|
+
| Repository/Service | method-by-method | 1 method → half → all |
|
|
71
|
+
| External API | mock-to-real | mock → 1 real → errors → scale |
|
|
72
|
+
| Batch Processing | scale-up | 1 → 5 → 20 → full |
|
|
73
|
+
| Complex Form | field-by-field | architecture → e2e → all fields |
|
|
74
|
+
|
|
75
|
+
### Files Changed
|
|
76
|
+
|
|
77
|
+
| File | Change |
|
|
78
|
+
|------|--------|
|
|
79
|
+
| `phase-templates.json` | **DELETED** |
|
|
80
|
+
| `task-analyzer.md` | Complete rewrite (v2.0) - 666 lines |
|
|
81
|
+
| `csetup.md` | Remove Steps 3-4 (keyword/template), new Step 3 (Task Analyzer) |
|
|
82
|
+
|
|
83
|
+
### Migration
|
|
84
|
+
|
|
85
|
+
No migration needed. Just run `/csetup` - it will generate phases.md from tasks.md directly.
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## v2.8.0: Critical Flow Injection
|
|
90
|
+
|
|
91
|
+
**Problem Solved:** Research layers are flexible and context-dependent, but security/compliance items are non-negotiable. Previously, critical requirements like password hashing, PCI-DSS compliance, or HIPAA regulations could be missed if research didn't surface them.
|
|
92
|
+
|
|
93
|
+
**Solution:** Auto-inject critical required items into research layers based on change analysis.
|
|
94
|
+
|
|
95
|
+
### How It Works
|
|
96
|
+
|
|
97
|
+
```
|
|
98
|
+
/csetup analyzes change:
|
|
99
|
+
├── hasAuth: true → Inject auth security items (7 items)
|
|
100
|
+
├── hasPayment: true → Inject payment security items (5 items)
|
|
101
|
+
├── industryContext: healthcare → Inject HIPAA compliance items (5 items)
|
|
102
|
+
└── industryContext: fintech → Inject PCI-DSS compliance items (6 items)
|
|
103
|
+
|
|
104
|
+
Research layers (flexible) + Critical items (non-negotiable)
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
### Critical Flow Categories
|
|
108
|
+
|
|
109
|
+
| Flow | Layer | Items | Examples |
|
|
110
|
+
|------|-------|-------|----------|
|
|
111
|
+
| Auth | Security | 7 | Password hashing (bcrypt/argon2), JWT secure storage, session timeout |
|
|
112
|
+
| Payment | Security | 5 | PCI key security, no card storage, webhook signature verification |
|
|
113
|
+
| Healthcare | Compliance | 5 | PHI encryption, role-based access, audit trail, BAA, breach plan |
|
|
114
|
+
| Fintech | Compliance | 6 | Data encryption, key rotation, audit logging, access controls |
|
|
115
|
+
| Sensitive Data | Security + Data Architecture | 6 | Encryption at rest/transit, access logging, backup, retention |
|
|
116
|
+
|
|
117
|
+
### Item Structure
|
|
118
|
+
|
|
119
|
+
Each critical item has:
|
|
120
|
+
```javascript
|
|
121
|
+
{
|
|
122
|
+
id: 'auth-password-hash', // Unique identifier
|
|
123
|
+
check: '☐ Password hashing...', // Checklist item
|
|
124
|
+
why: 'Plain text passwords...', // Explanation
|
|
125
|
+
severity: 'critical' // Always 'critical'
|
|
126
|
+
}
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
### Files Changed
|
|
130
|
+
|
|
131
|
+
| File | Change |
|
|
132
|
+
|------|--------|
|
|
133
|
+
| `tests/helpers.js` | `CRITICAL_FLOWS` constant + `injectCriticalRequiredItems()` function |
|
|
134
|
+
| `csetup.md` Step 2.6 | Calls `injectCriticalRequiredItems()` for each layer |
|
|
135
|
+
|
|
136
|
+
---
|
|
137
|
+
|
|
138
|
+
## v2.7.0: UX Testing Agent (Persona-Based)
|
|
139
|
+
|
|
140
|
+
**Problem Solved:** UI was approved by developers, not real users. No validation that the UI actually converts customers before spending time on backend development.
|
|
141
|
+
|
|
142
|
+
**Solution:** Auto-inject Phase 1.5 (ux-tester) after uxui-frontend with approval gate workflow.
|
|
143
|
+
|
|
144
|
+
### How It Works
|
|
145
|
+
|
|
146
|
+
```
|
|
147
|
+
Phase 1: uxui-frontend (build UI)
|
|
148
|
+
↓
|
|
149
|
+
Phase 1.5: ux-tester (approval gate)
|
|
150
|
+
→ Auto-generate personas from product context
|
|
151
|
+
→ Test each persona via Chrome DevTools
|
|
152
|
+
→ Calculate weighted conversion prediction
|
|
153
|
+
→ Generate UX test report
|
|
154
|
+
→ PAUSE for user approval
|
|
155
|
+
↓
|
|
156
|
+
[User approves] → Phase 2: backend + database
|
|
157
|
+
[User rejects] → Loop back to Phase 1 with feedback
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
### Key Features
|
|
161
|
+
|
|
162
|
+
| Feature | Description |
|
|
163
|
+
|---------|-------------|
|
|
164
|
+
| **Auto-Generated Personas** | 3-5 personas with % breakdown based on product context |
|
|
165
|
+
| **Weighted Conversion** | Calculate purchase likelihood weighted by customer % |
|
|
166
|
+
| **Chrome DevTools Testing** | Screenshots, snapshots, click tests, mobile responsive |
|
|
167
|
+
| **Approval Gate** | PAUSE and wait for user approve/reject |
|
|
168
|
+
| **Rejection Loop** | Feedback passed to uxui-frontend, re-run Phase 1 → 1.5 |
|
|
169
|
+
|
|
170
|
+
### Files Changed
|
|
171
|
+
|
|
172
|
+
| File | Change |
|
|
173
|
+
|------|--------|
|
|
174
|
+
| `.claude/agents/07-ux-tester.md` | New agent for persona-based UX testing |
|
|
175
|
+
| `.claude/templates/phases-sections/ux-testing.md` | Phase template with approval gate |
|
|
176
|
+
| `.claude/lib/task-analyzer.md` | **v2.0:** Complete rewrite - template-free, AI-driven |
|
|
177
|
+
| `.claude/lib/agent-executor.md` | Approval gate execution logic |
|
|
178
|
+
| `.claude/commands/cdev.md` | Step 4.6 approval gate handling |
|
|
179
|
+
|
|
180
|
+
### UX Test Report Example
|
|
181
|
+
|
|
182
|
+
```markdown
|
|
183
|
+
# UX Test Report
|
|
184
|
+
|
|
185
|
+
## Personas Tested
|
|
186
|
+
| Persona | % ลูกค้า | Would Buy | Weighted |
|
|
187
|
+
|---------|----------|-----------|----------|
|
|
188
|
+
| นักศึกษา 18-24 | 40% | Maybe (50%) | +20% |
|
|
189
|
+
| พนักงาน 25-35 | 35% | Yes (100%) | +35% |
|
|
190
|
+
| ผู้สูงวัย 50-65 | 15% | No (0%) | +0% |
|
|
191
|
+
| ผู้ปกครอง 35-50 | 10% | Maybe (50%) | +5% |
|
|
192
|
+
|
|
193
|
+
## Conversion Prediction: 60%
|
|
194
|
+
## Potential After Fixes: 92.5%
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
---
|
|
198
|
+
|
|
199
|
+
## v2.5.0: Smart Topic Query + Integration Risk Detection
|
|
200
|
+
|
|
201
|
+
**Problem Solved:** Context7 queries used static topic "best practices" which missed adapter/integration documentation. Example: Drizzle + Auth.js requires specific column naming (snake_case) but this wasn't detected, causing runtime errors.
|
|
202
|
+
|
|
203
|
+
**Solution:** Smart Topic Query includes other library names in topic + automatic integration risk detection.
|
|
204
|
+
|
|
205
|
+
### How Smart Topic Query Works
|
|
206
|
+
|
|
207
|
+
```
|
|
208
|
+
Old (v2.4.0):
|
|
209
|
+
topic: "best practices, patterns, anti-patterns, common mistakes"
|
|
210
|
+
→ Misses adapter-specific docs
|
|
211
|
+
|
|
212
|
+
New (v2.5.0):
|
|
213
|
+
topic: "best practices, patterns, adapter, integration, schema, {other-lib-names}"
|
|
214
|
+
→ Gets cross-library integration docs automatically
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
### Key Features
|
|
218
|
+
|
|
219
|
+
| Feature | Description |
|
|
220
|
+
|---------|-------------|
|
|
221
|
+
| **Smart Topic** | Includes other detected library names in Context7 topic |
|
|
222
|
+
| **Bidirectional Query** | Query BOTH libraries (Auth.js → Drizzle, Drizzle → Auth.js) |
|
|
223
|
+
| **Risk Pattern Detection** | Scans docs for adapter, schema, column, sync, webhook patterns |
|
|
224
|
+
| **INTEGRATION_RISKS.md** | Auto-generated summary of detected integration concerns |
|
|
225
|
+
| **Zero Maintenance** | No hardcoded library pairs - works with any combination |
|
|
226
|
+
|
|
227
|
+
### Integration Risk Patterns Detected
|
|
228
|
+
|
|
229
|
+
| Pattern | Keywords | Example |
|
|
230
|
+
|---------|----------|---------|
|
|
231
|
+
| Adapter | adapter, drizzleadapter, prismaadapter | ORM + Auth integrations |
|
|
232
|
+
| Schema | column, snake_case, camelcase, mapping | Column naming mismatches |
|
|
233
|
+
| Sync | sync, migrate, syncurl, embedded replica | Mobile/Edge data sync |
|
|
234
|
+
| Webhook | webhook, webhookendpoint | Payment/notification handlers |
|
|
235
|
+
| Lifecycle | beforeall, aftereach, setup, teardown | Test configuration |
|
|
236
|
+
|
|
237
|
+
### Output Files
|
|
238
|
+
|
|
239
|
+
| File | Content |
|
|
240
|
+
|------|---------|
|
|
241
|
+
| `best-practices/{lib}.md` | Library-specific best practices (enhanced with integration docs) |
|
|
242
|
+
| `best-practices/INTEGRATION_RISKS.md` | Cross-library risk summary + checklist |
|
|
243
|
+
|
|
244
|
+
### Example Flow
|
|
245
|
+
|
|
246
|
+
```
|
|
247
|
+
Detected: [drizzle, auth.js, stripe]
|
|
248
|
+
|
|
249
|
+
Query drizzle with topic: "best practices, adapter, integration, auth.js, stripe"
|
|
250
|
+
→ Gets: Drizzle adapter patterns, column naming
|
|
251
|
+
|
|
252
|
+
Query auth.js with topic: "best practices, adapter, integration, drizzle, stripe"
|
|
253
|
+
→ Gets: DrizzleAdapter config, usersTable/accountsTable schema
|
|
254
|
+
|
|
255
|
+
Query stripe with topic: "best practices, adapter, integration, drizzle, auth.js"
|
|
256
|
+
→ Gets: Webhook patterns, payment integration
|
|
257
|
+
|
|
258
|
+
Risk Detection:
|
|
259
|
+
→ auth.js mentions "drizzleadapter", "userstable" → SCHEMA pattern
|
|
260
|
+
→ stripe mentions "webhook", "webhooksecret" → WEBHOOK pattern
|
|
261
|
+
|
|
262
|
+
Output:
|
|
263
|
+
→ drizzle.md (with auth.js integration info)
|
|
264
|
+
→ auth-js.md (with Drizzle adapter config)
|
|
265
|
+
→ stripe.md (with webhook patterns)
|
|
266
|
+
→ INTEGRATION_RISKS.md (summary of all detected risks)
|
|
267
|
+
```
|
|
268
|
+
|
|
269
|
+
### Files Changed
|
|
270
|
+
|
|
271
|
+
| File | Change |
|
|
272
|
+
|------|--------|
|
|
273
|
+
| `csetup.md` Step 2.7 | Smart Topic Query implementation |
|
|
274
|
+
| `detectIntegrationRisks()` | New: Pattern detection from docs |
|
|
275
|
+
| `generateIntegrationRiskSummary()` | New: INTEGRATION_RISKS.md output |
|
|
276
|
+
|
|
277
|
+
---
|
|
278
|
+
|
|
279
|
+
## v2.4.0: Adaptive Depth Research
|
|
280
|
+
|
|
281
|
+
**Problem Solved:** Previous feature detection was hardcoded (only 4 types: auth, payment, fileUpload, apiDesign) and used fixed standards. Missing domain-level best practices like "how to design a good database" or "healthcare compliance requirements."
|
|
282
|
+
|
|
283
|
+
**Solution:** Dynamic research layers that adapt to each change's complexity (0 to 10+ layers).
|
|
284
|
+
|
|
285
|
+
### Key Principles
|
|
286
|
+
|
|
287
|
+
| Principle | Description |
|
|
288
|
+
|-----------|-------------|
|
|
289
|
+
| L1 = Best Practice (ALWAYS) | "คนอื่นทำกันยังไง?" (How do others do it?) for ALL non-trivial changes |
|
|
290
|
+
| Dynamic Depth | No fixed min/max - truly adaptive (0-10+ layers) |
|
|
291
|
+
| Separation of Concerns | Visual (/designsetup) is STATIC, Strategy (research) is DYNAMIC |
|
|
292
|
+
| Per-Change Output | Generates `research-checklist.md` for each change |
|
|
293
|
+
| Design Conflict Warnings | Warns if industry practice conflicts with user's design choices |
|
|
294
|
+
|
|
295
|
+
### Layer Examples by Change Type
|
|
296
|
+
|
|
297
|
+
| Change Type | Layers | Example Layers |
|
|
298
|
+
|-------------|--------|----------------|
|
|
299
|
+
| Typo fix, debug log | 0 | None needed |
|
|
300
|
+
| Simple API endpoint | 2 | Best Practice, API Design |
|
|
301
|
+
| Auth system | 4 | Best Practice, Security, API Design, Testing |
|
|
302
|
+
| E-commerce checkout | 7 | Best Practice, Security, UX, Payment, Integration, Performance, Testing |
|
|
303
|
+
| Healthcare portal | 10 | Best Practice, Security, Compliance (HIPAA), UX, Data Architecture, API, Performance, Testing, Integration, Audit |
|
|
304
|
+
|
|
305
|
+
### Knowledge Sources (Separated)
|
|
306
|
+
|
|
307
|
+
| Step | Knowledge Type | Source | Example |
|
|
308
|
+
|------|----------------|--------|---------|
|
|
309
|
+
| **2.6** | Domain (HOW to design) | Claude's Knowledge | Normalization, UX patterns, Security |
|
|
310
|
+
| **2.7** | Stack (HOW to use tool) | Context7 | Prisma, React, Next.js |
|
|
311
|
+
|
|
312
|
+
### How It Works
|
|
313
|
+
|
|
314
|
+
```
|
|
315
|
+
1. Analyze change from proposal.md, tasks.md, design.md
|
|
316
|
+
→ Detect: primaryType, complexity, riskLevel, domains, features
|
|
317
|
+
|
|
318
|
+
2. Determine research layers dynamically:
|
|
319
|
+
- Trivial (complexity ≤ 1, no UI/API/DB) → 0 layers
|
|
320
|
+
- Non-trivial → L1 Best Practice + context-specific layers
|
|
321
|
+
|
|
322
|
+
3. Execute research per layer using Claude's knowledge:
|
|
323
|
+
- Claude knows: UX (Nielsen Norman, Baymard), DB (Codd), Security (OWASP)
|
|
324
|
+
- No static files needed - Claude reasons from training
|
|
325
|
+
- No WebSearch needed - domain knowledge is stable
|
|
326
|
+
|
|
327
|
+
4. Generate research-checklist.md with:
|
|
328
|
+
- Key questions per layer
|
|
329
|
+
- Best practices (from Claude's knowledge)
|
|
330
|
+
- Anti-patterns to avoid
|
|
331
|
+
- Trade-offs explained
|
|
332
|
+
- Recommendations specific to THIS change
|
|
333
|
+
|
|
334
|
+
5. Agents read research-checklist.md before implementing
|
|
335
|
+
```
|
|
336
|
+
|
|
337
|
+
**WHY Claude's Knowledge?**
|
|
338
|
+
- Domain principles rarely change (Normalization = 50 years, REST = 20 years)
|
|
339
|
+
- No maintenance needed (no static files to update)
|
|
340
|
+
- Context-aware (Claude applies principles to YOUR specific change)
|
|
341
|
+
- Stack knowledge goes to Context7 (Step 2.7) which has live docs
|
|
342
|
+
|
|
343
|
+
### Available Research Layers
|
|
344
|
+
|
|
345
|
+
| Layer | Triggered By |
|
|
346
|
+
|-------|--------------|
|
|
347
|
+
| Best Practice / Industry Standard | Always (non-trivial changes) |
|
|
348
|
+
| Security Requirements | hasAuth, hasPayment, hasSensitiveData |
|
|
349
|
+
| {Industry} Compliance | healthcare, fintech, or other regulated industries |
|
|
350
|
+
| User Experience Patterns | isExternalFacing + hasUI |
|
|
351
|
+
| Conversion Psychology | marketing/sales pages |
|
|
352
|
+
| Content Strategy | marketing/content pages |
|
|
353
|
+
| Data Architecture | hasDatabase, data-intensive |
|
|
354
|
+
| API Design | hasAPI |
|
|
355
|
+
| Multi-tenancy Patterns | SaaS with tenant isolation |
|
|
356
|
+
| Real-time Architecture | WebSocket, collaboration features |
|
|
357
|
+
| Performance Optimization | external-facing OR complexity ≥ 6 |
|
|
358
|
+
| Integration Patterns | external APIs, webhooks |
|
|
359
|
+
| Testing Strategy | HIGH risk OR complexity ≥ 7 |
|
|
360
|
+
|
|
361
|
+
### Files Changed
|
|
362
|
+
|
|
363
|
+
| File | Change |
|
|
364
|
+
|------|--------|
|
|
365
|
+
| `csetup.md` Step 2.6 | Complete rewrite - Adaptive Depth Research |
|
|
366
|
+
| `analyzeChangeCharacteristics()` | New: semantic analysis of change context |
|
|
367
|
+
| `determineResearchLayers()` | New: dynamic layer selection |
|
|
368
|
+
| `executeLayerResearch()` | New: Context7 + semantic research |
|
|
369
|
+
| `generateResearchChecklist()` | New: markdown output per change |
|
|
370
|
+
| `checkDesignConflicts()` | New: warns on design vs industry fit |
|
|
371
|
+
|
|
372
|
+
---
|
|
373
|
+
|
|
374
|
+
## v2.3.0: Zero-Maintenance Tech Stack Detection
|
|
375
|
+
|
|
376
|
+
**Problem Solved:** Previously, `/csetup` required hardcoded regex patterns and Context7 ID mappings for each library. Adding support for new libraries (like SQLAlchemy, Pydantic, Rust crates) required code changes.
|
|
377
|
+
|
|
378
|
+
**Solution:** Dynamic detection that works with any library in any language without maintenance.
|
|
379
|
+
|
|
380
|
+
### How It Works
|
|
381
|
+
|
|
382
|
+
```
|
|
383
|
+
1. Extract potential library names from ALL text sources:
|
|
384
|
+
- Spec files (proposal.md, design.md, tasks.md)
|
|
385
|
+
- Package files (package.json, requirements.txt, Cargo.toml, go.mod, etc.)
|
|
386
|
+
- Import statements in code snippets
|
|
387
|
+
- Prose mentions ("using FastAPI", "with Prisma")
|
|
388
|
+
|
|
389
|
+
2. Send each candidate to Context7 resolve-library-id:
|
|
390
|
+
- If Context7 recognizes it → confirmed library ✅
|
|
391
|
+
- If not recognized → not a library, skip ❌
|
|
392
|
+
|
|
393
|
+
3. For confirmed libraries, fetch best practices:
|
|
394
|
+
- Context7 get-library-docs with "best practices" topic
|
|
395
|
+
- Generate .md file with patterns, anti-patterns, checklist
|
|
396
|
+
|
|
397
|
+
4. Result: Best practices for ANY library, automatically!
|
|
398
|
+
```
|
|
399
|
+
|
|
400
|
+
### Benefits
|
|
401
|
+
|
|
402
|
+
| Aspect | Before (v1.8.0) | After (v2.3.0) |
|
|
403
|
+
|--------|-----------------|----------------|
|
|
404
|
+
| New library support | Manual code change | Automatic |
|
|
405
|
+
| Python stack | Partial (FastAPI, Django only) | Full (SQLAlchemy, Pydantic, Click, etc.) |
|
|
406
|
+
| Rust support | None | Automatic |
|
|
407
|
+
| Go support | None | Automatic |
|
|
408
|
+
| Maintenance | Required for each library | Zero |
|
|
409
|
+
|
|
410
|
+
### Files Changed
|
|
411
|
+
|
|
412
|
+
| File | Change |
|
|
413
|
+
|------|--------|
|
|
414
|
+
| `csetup.md` Step 2.7 | Complete rewrite with dynamic detection |
|
|
415
|
+
| `extractPotentialLibraryNames()` | New helper for NLP extraction |
|
|
416
|
+
| `parseContext7Response()` | New helper for Context7 response parsing |
|
|
417
|
+
| `generateBestPracticesFile()` | Updated signature, includes Context7 ID |
|
|
418
|
+
| `detectAdditionalTech()` | Deprecated, delegates to new system |
|
|
419
|
+
|
|
420
|
+
---
|
|
421
|
+
|
|
422
|
+
## v2.2.0: claude-mem Integration
|
|
423
|
+
|
|
424
|
+
**What is claude-mem?** A Claude Code plugin that automatically captures tool usage observations and provides persistent memory across sessions.
|
|
425
|
+
|
|
426
|
+
### Division of Responsibilities
|
|
427
|
+
|
|
428
|
+
| Data Type | Source | How to Access |
|
|
429
|
+
|-----------|--------|---------------|
|
|
430
|
+
| Past decisions | claude-mem (auto) | Ask: "what decisions about X?" |
|
|
431
|
+
| Past learnings | claude-mem (auto) | Ask: "what did we learn about X?" |
|
|
432
|
+
| Past bugs/fixes | claude-mem (auto) | Ask: "what bugs with X?" |
|
|
433
|
+
| Future ideas | claude-mem (auto) | Ask: "what ideas for X?" |
|
|
434
|
+
| **Blockers** | PROJECT_STATUS.yml | Read file (requires human decision) |
|
|
435
|
+
| **Priorities** | PROJECT_STATUS.yml | Read file (requires human decision) |
|
|
436
|
+
| **Tech debt** | PROJECT_STATUS.yml | Read file (actionable items) |
|
|
437
|
+
| What to build | tasks.md → phases.md | /csetup generates |
|
|
438
|
+
| How to build | Agents | /cdev executes |
|
|
439
|
+
|
|
440
|
+
### PROJECT_STATUS.yml Changes
|
|
441
|
+
|
|
442
|
+
- **REMOVED:** `decisions`, `notes`, `future_ideas` → claude-mem handles automatically
|
|
443
|
+
- **KEPT:** `blockers`, `next_priorities`, `technical_debt` → requires human decision
|
|
444
|
+
- **Query past context:** Just ask naturally → mem-search skill auto-invoked
|
|
445
|
+
|
|
446
|
+
---
|
|
447
|
+
|
|
448
|
+
## v2.1.0: Design System v2 + Context Optimization
|
|
449
|
+
|
|
450
|
+
### Design System v2 (YAML-based)
|
|
451
|
+
|
|
452
|
+
- `/extract https://site.com` → Extracts design from reference site
|
|
453
|
+
- `/designsetup @prd.md` → Interactive 3-round loop with theme selection
|
|
454
|
+
- Generates: `data.yaml` (~800 lines) + `README.md` (~100 lines)
|
|
455
|
+
|
|
456
|
+
### Context Optimization
|
|
457
|
+
|
|
458
|
+
- **Problem:** Multiple files read by different commands/agents
|
|
459
|
+
- **Solution:** `data.yaml` = SINGLE SOURCE for all agents
|
|
460
|
+
|
|
461
|
+
### Cross-Session Context
|
|
462
|
+
|
|
463
|
+
- `PROJECT_STATUS.yml` provides quick context snapshot for new sessions
|
|
464
|
+
- Contains: infrastructure state, blockers, completed work, next priorities
|
|
465
|
+
|
|
466
|
+
---
|
|
467
|
+
|
|
468
|
+
## v2.0.0: Claude 4.5 Optimization
|
|
469
|
+
|
|
470
|
+
**Based on:** [Claude 4 Best Practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-4-best-practices)
|
|
471
|
+
|
|
472
|
+
### Changes Applied
|
|
473
|
+
|
|
474
|
+
| Before | After | WHY |
|
|
475
|
+
|--------|-------|-----|
|
|
476
|
+
| "MUST", "WILL BE REJECTED" | Professional tone | Claude 4.5 works better with respectful instructions |
|
|
477
|
+
| "Don't do X", "Never Y" | "Use X instead" | Positive instructions are clearer |
|
|
478
|
+
| Rules without context | Rules with WHY | Claude applies rules more intelligently |
|
|
479
|
+
| Duplicated content (6x) | Shared `_shared/` folder | 83% token reduction |
|
|
480
|
+
| ~1000 lines per agent | ~250-350 lines | 65% smaller |
|
|
481
|
+
|
|
482
|
+
### New Shared Components
|
|
483
|
+
|
|
484
|
+
```
|
|
485
|
+
.claude/agents/_shared/
|
|
486
|
+
├── pre-work-checklist.md # Common validation steps
|
|
487
|
+
├── package-manager.md # Package manager protocol
|
|
488
|
+
├── documentation-policy.md # What files to create
|
|
489
|
+
├── agent-boundaries.md # When to use which agent
|
|
490
|
+
└── README.md # Overview
|
|
491
|
+
```
|
|
492
|
+
|
|
493
|
+
### Token Savings
|
|
494
|
+
|
|
495
|
+
| Agent | Before | After | Reduction |
|
|
496
|
+
|-------|--------|-------|-----------|
|
|
497
|
+
| uxui-frontend | ~1037 | ~375 | 64% |
|
|
498
|
+
| integration | ~600 | ~210 | 65% |
|
|
499
|
+
| backend | ~700 | ~244 | 65% |
|
|
500
|
+
| database | ~680 | ~273 | 60% |
|
|
501
|
+
| frontend | ~650 | ~296 | 54% |
|
|
502
|
+
| test-debug | ~580 | ~252 | 57% |
|
|
503
|
+
| **Total** | **~4247** | **~1650** | **61%** |
|
|
504
|
+
|
|
505
|
+
Plus ~500 tokens in shared files = **~2150 total** (was ~4247)
|
|
506
|
+
|
|
507
|
+
### Files Refactored
|
|
508
|
+
|
|
509
|
+
**Implementation Logic (lib/):** agent-router.md, agent-executor.md, context-loading-protocol.md, flags-updater.md, document-loader.md, detailed-guides/agent-system.md
|
|
510
|
+
|
|
511
|
+
**Commands:** cdev.md, csetup.md, pageplan.md, designsetup.md
|
|
512
|
+
|
|
513
|
+
**Patterns (contexts/patterns/):** validation-framework.md, error-recovery.md, ui-component-consistency.md, task-breakdown.md, agent-discovery.md, code-standards.md, animation-patterns.md, frontend-component-strategy.md, performance-optimization.md, change-workflow.md, task-classification.md
|
|
514
|
+
|
|
515
|
+
**Design (contexts/design/):** index.md, box-thinking.md
|
|
516
|
+
|
|
517
|
+
**Templates:** phases-sections/frontend-mockup.md, design-context-template.md, STYLE_GUIDE.template.md
|
|
518
|
+
|
|
519
|
+
---
|
|
520
|
+
|
|
521
|
+
## Earlier Versions
|
|
522
|
+
|
|
523
|
+
- **v1.8.0** - File Creation Policy
|
|
524
|
+
- **v1.6.0** - Incremental Testing
|
|
525
|
+
- **v1.3.0** - TaskMaster-style Analysis
|
|
526
|
+
|
|
527
|
+
See git history for details.
|