devflow-kit 0.3.3 → 0.5.0
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/CHANGELOG.md +131 -0
- package/README.md +84 -15
- package/dist/commands/init.d.ts.map +1 -1
- package/dist/commands/init.js +202 -190
- package/dist/commands/init.js.map +1 -1
- package/dist/commands/uninstall.d.ts.map +1 -1
- package/dist/commands/uninstall.js +77 -63
- package/dist/commands/uninstall.js.map +1 -1
- package/dist/utils/git.d.ts +11 -0
- package/dist/utils/git.d.ts.map +1 -0
- package/dist/utils/git.js +36 -0
- package/dist/utils/git.js.map +1 -0
- package/dist/utils/paths.d.ts +32 -0
- package/dist/utils/paths.d.ts.map +1 -0
- package/dist/utils/paths.js +86 -0
- package/dist/utils/paths.js.map +1 -0
- package/package.json +1 -1
- package/src/claude/agents/devflow/debug.md +475 -0
- package/src/claude/agents/devflow/project-state.md +419 -0
- package/src/claude/commands/devflow/debug.md +29 -201
- package/src/claude/commands/devflow/devlog.md +211 -172
- package/src/claude/commands/devflow/implement.md +507 -0
- package/src/claude/skills/devflow/code-smell/SKILL.md +428 -0
- package/src/claude/skills/devflow/debug/SKILL.md +119 -0
- package/src/claude/skills/devflow/error-handling/SKILL.md +597 -0
- package/src/claude/skills/devflow/input-validation/SKILL.md +514 -0
- package/src/claude/skills/devflow/pattern-check/SKILL.md +238 -0
- package/src/claude/skills/devflow/research/SKILL.md +135 -0
- package/src/claude/skills/devflow/test-design/SKILL.md +384 -0
|
@@ -0,0 +1,238 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pattern-check
|
|
3
|
+
description: Automatically validate architectural patterns and detect violations when code changes are made. Use when implementing new functionality, refactoring existing code, or when Result types, dependency injection, or immutability patterns might be violated.
|
|
4
|
+
allowed-tools: Read, Grep, Glob, AskUserQuestion
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Pattern Check Skill
|
|
8
|
+
|
|
9
|
+
## Purpose
|
|
10
|
+
|
|
11
|
+
Enforce core architectural patterns defined in project guidelines:
|
|
12
|
+
1. **Result types** instead of exceptions
|
|
13
|
+
2. **Dependency injection** instead of internal instantiation
|
|
14
|
+
3. **Immutability** instead of mutation
|
|
15
|
+
4. **Pure functions** instead of side-effect-heavy code
|
|
16
|
+
|
|
17
|
+
## When This Skill Activates
|
|
18
|
+
|
|
19
|
+
Automatically triggers when:
|
|
20
|
+
- New functions or methods are being added
|
|
21
|
+
- Error handling code is being written
|
|
22
|
+
- Class constructors are being modified
|
|
23
|
+
- Data structures are being updated
|
|
24
|
+
- Refactoring is in progress
|
|
25
|
+
|
|
26
|
+
## Pattern Validation Process
|
|
27
|
+
|
|
28
|
+
### 1. Result Type Pattern Check
|
|
29
|
+
|
|
30
|
+
**CRITICAL**: Business logic must NEVER throw exceptions directly.
|
|
31
|
+
|
|
32
|
+
Search for violations:
|
|
33
|
+
```typescript
|
|
34
|
+
// ❌ VIOLATION
|
|
35
|
+
function createUser(data: unknown): User {
|
|
36
|
+
if (!valid(data)) {
|
|
37
|
+
throw new ValidationError(); // VIOLATION: throwing exception
|
|
38
|
+
}
|
|
39
|
+
return user;
|
|
40
|
+
}
|
|
41
|
+
|
|
42
|
+
// ✅ CORRECT
|
|
43
|
+
function createUser(data: unknown): Result<User, ValidationError> {
|
|
44
|
+
if (!valid(data)) {
|
|
45
|
+
return { ok: false, error: new ValidationError() };
|
|
46
|
+
}
|
|
47
|
+
return { ok: true, value: user };
|
|
48
|
+
}
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
**Detection patterns:**
|
|
52
|
+
- `throw new Error` inside business logic functions
|
|
53
|
+
- `try/catch` blocks wrapping business operations (except at boundaries)
|
|
54
|
+
- Functions returning data types without Result wrapper
|
|
55
|
+
- Missing error handling in function signatures
|
|
56
|
+
|
|
57
|
+
### 2. Dependency Injection Pattern Check
|
|
58
|
+
|
|
59
|
+
**CRITICAL**: Dependencies must be injected, not instantiated internally.
|
|
60
|
+
|
|
61
|
+
Search for violations:
|
|
62
|
+
```typescript
|
|
63
|
+
// ❌ VIOLATION
|
|
64
|
+
class UserService {
|
|
65
|
+
private db = new Database(); // VIOLATION: creating dependency
|
|
66
|
+
|
|
67
|
+
async getUser(id: string) {
|
|
68
|
+
return this.db.query(id);
|
|
69
|
+
}
|
|
70
|
+
}
|
|
71
|
+
|
|
72
|
+
// ✅ CORRECT
|
|
73
|
+
class UserService {
|
|
74
|
+
constructor(private db: Database) {} // Injected dependency
|
|
75
|
+
|
|
76
|
+
async getUser(id: string) {
|
|
77
|
+
return this.db.query(id);
|
|
78
|
+
}
|
|
79
|
+
}
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
**Detection patterns:**
|
|
83
|
+
- `new SomeClass()` inside constructors or methods
|
|
84
|
+
- Direct file system imports for services
|
|
85
|
+
- Hardcoded configuration values
|
|
86
|
+
- Singleton patterns without DI container
|
|
87
|
+
|
|
88
|
+
### 3. Immutability Pattern Check
|
|
89
|
+
|
|
90
|
+
**CRITICAL**: Data structures must return new objects, not mutate existing ones.
|
|
91
|
+
|
|
92
|
+
Search for violations:
|
|
93
|
+
```typescript
|
|
94
|
+
// ❌ VIOLATION
|
|
95
|
+
function updateUser(user: User, name: string): User {
|
|
96
|
+
user.name = name; // VIOLATION: mutating input
|
|
97
|
+
return user;
|
|
98
|
+
}
|
|
99
|
+
|
|
100
|
+
// ✅ CORRECT
|
|
101
|
+
function updateUser(user: User, name: string): User {
|
|
102
|
+
return { ...user, name }; // New object
|
|
103
|
+
}
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
**Detection patterns:**
|
|
107
|
+
- Direct property assignment on parameters
|
|
108
|
+
- Array mutation methods: `push`, `pop`, `splice`, `sort` (without returning new array)
|
|
109
|
+
- Object property mutations on inputs
|
|
110
|
+
- Missing `const` declarations for data structures
|
|
111
|
+
|
|
112
|
+
### 4. Pure Function Pattern Check
|
|
113
|
+
|
|
114
|
+
**CRITICAL**: Business logic should be pure; side effects isolated.
|
|
115
|
+
|
|
116
|
+
Search for violations:
|
|
117
|
+
```typescript
|
|
118
|
+
// ❌ VIOLATION
|
|
119
|
+
function calculateTotal(items: Item[]): number {
|
|
120
|
+
console.log('Calculating...'); // VIOLATION: side effect
|
|
121
|
+
logToDatabase('calculation'); // VIOLATION: side effect
|
|
122
|
+
return items.reduce((sum, item) => sum + item.price, 0);
|
|
123
|
+
}
|
|
124
|
+
|
|
125
|
+
// ✅ CORRECT
|
|
126
|
+
function calculateTotal(items: Item[]): number {
|
|
127
|
+
return items.reduce((sum, item) => sum + item.price, 0); // Pure
|
|
128
|
+
}
|
|
129
|
+
|
|
130
|
+
// Wrapper handles side effects
|
|
131
|
+
async function processOrder(items: Item[]): Promise<Result<number, Error>> {
|
|
132
|
+
logToDatabase('calculation'); // Side effect in wrapper
|
|
133
|
+
const total = calculateTotal(items); // Pure function call
|
|
134
|
+
return { ok: true, value: total };
|
|
135
|
+
}
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
**Detection patterns:**
|
|
139
|
+
- I/O operations inside pure business logic
|
|
140
|
+
- Console logs in calculation functions
|
|
141
|
+
- Database calls mixed with business logic
|
|
142
|
+
- File system access in data transformations
|
|
143
|
+
|
|
144
|
+
## Violation Report Format
|
|
145
|
+
|
|
146
|
+
When violations are found, report using this format:
|
|
147
|
+
|
|
148
|
+
```markdown
|
|
149
|
+
⚠️ ARCHITECTURAL PATTERN VIOLATIONS DETECTED
|
|
150
|
+
|
|
151
|
+
## 🔴 CRITICAL - Result Type Violations
|
|
152
|
+
**File**: src/services/user.ts:45
|
|
153
|
+
**Issue**: Function throws exception instead of returning Result type
|
|
154
|
+
**Current**:
|
|
155
|
+
```typescript
|
|
156
|
+
throw new ValidationError('Invalid email');
|
|
157
|
+
```
|
|
158
|
+
**Fix Required**:
|
|
159
|
+
```typescript
|
|
160
|
+
return { ok: false, error: new ValidationError('Invalid email') };
|
|
161
|
+
```
|
|
162
|
+
**Impact**: Breaks error handling consistency, makes errors invisible to type system
|
|
163
|
+
|
|
164
|
+
## 🔴 CRITICAL - Dependency Injection Violations
|
|
165
|
+
**File**: src/services/order.ts:12
|
|
166
|
+
**Issue**: Service instantiates database directly
|
|
167
|
+
**Current**:
|
|
168
|
+
```typescript
|
|
169
|
+
private db = new Database();
|
|
170
|
+
```
|
|
171
|
+
**Fix Required**:
|
|
172
|
+
```typescript
|
|
173
|
+
constructor(private db: Database) {}
|
|
174
|
+
```
|
|
175
|
+
**Impact**: Makes testing impossible, creates tight coupling
|
|
176
|
+
|
|
177
|
+
## 🟡 HIGH - Immutability Violations
|
|
178
|
+
**File**: src/models/cart.ts:23
|
|
179
|
+
**Issue**: Mutating input parameter
|
|
180
|
+
**Current**:
|
|
181
|
+
```typescript
|
|
182
|
+
cart.items.push(newItem);
|
|
183
|
+
return cart;
|
|
184
|
+
```
|
|
185
|
+
**Fix Required**:
|
|
186
|
+
```typescript
|
|
187
|
+
return { ...cart, items: [...cart.items, newItem] };
|
|
188
|
+
```
|
|
189
|
+
**Impact**: Creates hidden side effects, breaks referential transparency
|
|
190
|
+
|
|
191
|
+
## 📊 Summary
|
|
192
|
+
- **Critical**: 5 violations
|
|
193
|
+
- **High**: 3 violations
|
|
194
|
+
- **Files affected**: 4
|
|
195
|
+
- **Estimated fix time**: 30 minutes
|
|
196
|
+
|
|
197
|
+
## 🛠️ Next Steps
|
|
198
|
+
1. Fix Result type violations first (breaks consistency)
|
|
199
|
+
2. Apply dependency injection (enables testing)
|
|
200
|
+
3. Remove mutations (prevents bugs)
|
|
201
|
+
4. Verify with pattern-check after fixes
|
|
202
|
+
```
|
|
203
|
+
|
|
204
|
+
## Integration with Workflow
|
|
205
|
+
|
|
206
|
+
After detecting violations:
|
|
207
|
+
|
|
208
|
+
1. **STOP implementation** - Do not proceed with current changes
|
|
209
|
+
2. **Report violations** - Use format above
|
|
210
|
+
3. **Propose fixes** - Show correct patterns
|
|
211
|
+
4. **Wait for approval** - Get explicit user confirmation
|
|
212
|
+
5. **Apply fixes** - Implement corrections systematically
|
|
213
|
+
6. **Re-validate** - Run pattern-check again
|
|
214
|
+
|
|
215
|
+
## Red Flags - Immediate Stop
|
|
216
|
+
|
|
217
|
+
Stop immediately and report if you detect:
|
|
218
|
+
- Multiple Result type violations in same file
|
|
219
|
+
- Systematic lack of dependency injection
|
|
220
|
+
- Widespread mutation patterns
|
|
221
|
+
- Business logic mixed with I/O throughout codebase
|
|
222
|
+
|
|
223
|
+
These indicate architectural issues requiring design discussion, not quick fixes.
|
|
224
|
+
|
|
225
|
+
## Success Criteria
|
|
226
|
+
|
|
227
|
+
Code passes pattern-check when:
|
|
228
|
+
- ✅ All business functions return Result types
|
|
229
|
+
- ✅ All dependencies are injected
|
|
230
|
+
- ✅ All data updates return new objects
|
|
231
|
+
- ✅ Pure functions contain no side effects
|
|
232
|
+
- ✅ Side effects isolated in wrapper functions
|
|
233
|
+
|
|
234
|
+
## Example Usage
|
|
235
|
+
|
|
236
|
+
User implements new feature → pattern-check automatically triggers → validates patterns → reports violations if any → blocks merge until fixed.
|
|
237
|
+
|
|
238
|
+
This creates automatic quality gates without requiring explicit invocation.
|
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: research
|
|
3
|
+
description: Auto-launch pre-implementation research when unfamiliar features, libraries, or patterns are requested. Use when implementing new functionality that requires understanding approaches, integration strategies, or best practices.
|
|
4
|
+
allowed-tools: Task
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Research Skill - Auto-Dispatcher
|
|
8
|
+
|
|
9
|
+
**Purpose**: Detect when pre-implementation research is needed and auto-launch the research agent.
|
|
10
|
+
|
|
11
|
+
## When to Activate
|
|
12
|
+
|
|
13
|
+
Auto-activates when:
|
|
14
|
+
- Unfamiliar features or technologies requested
|
|
15
|
+
- New libraries or frameworks need integration
|
|
16
|
+
- Multiple implementation approaches possible
|
|
17
|
+
- User asks "how should I implement..."
|
|
18
|
+
- Integration strategy unclear
|
|
19
|
+
- Best practices unknown for this codebase
|
|
20
|
+
|
|
21
|
+
## Lightweight Assessment
|
|
22
|
+
|
|
23
|
+
```markdown
|
|
24
|
+
Quick check (don't do heavy research):
|
|
25
|
+
1. Is this pattern already in codebase? → Show example
|
|
26
|
+
2. Is this unfamiliar/complex? → Launch research agent
|
|
27
|
+
3. Are there multiple approaches? → Launch research agent
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
## Decision Logic
|
|
31
|
+
|
|
32
|
+
**Show existing pattern** (known):
|
|
33
|
+
- Pattern exists in codebase
|
|
34
|
+
- Similar feature already implemented
|
|
35
|
+
- Just need to reference existing code
|
|
36
|
+
|
|
37
|
+
**Launch research agent** (unknown):
|
|
38
|
+
- Unfamiliar feature or technology
|
|
39
|
+
- New library integration
|
|
40
|
+
- Multiple possible approaches
|
|
41
|
+
- Need to study docs/examples
|
|
42
|
+
- Integration strategy unclear
|
|
43
|
+
|
|
44
|
+
## Auto-Launch Research Agent
|
|
45
|
+
|
|
46
|
+
When research is needed:
|
|
47
|
+
|
|
48
|
+
```
|
|
49
|
+
I've detected this requires pre-implementation research.
|
|
50
|
+
|
|
51
|
+
**Feature**: [what's being implemented]
|
|
52
|
+
**Unknowns**: [what we need to research]
|
|
53
|
+
|
|
54
|
+
Launching research agent to analyze approaches and create implementation plan...
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
Then launch the research agent using Task tool:
|
|
58
|
+
|
|
59
|
+
```
|
|
60
|
+
Task(
|
|
61
|
+
subagent_type="research",
|
|
62
|
+
description="Pre-implementation research",
|
|
63
|
+
prompt="Conduct comprehensive research for implementing: [feature description].
|
|
64
|
+
|
|
65
|
+
Research focus:
|
|
66
|
+
- Evaluate implementation approaches
|
|
67
|
+
- Study official documentation and examples
|
|
68
|
+
- Analyze existing codebase patterns
|
|
69
|
+
- Design integration strategy
|
|
70
|
+
- Create actionable implementation plan
|
|
71
|
+
|
|
72
|
+
Context: [relevant project context]"
|
|
73
|
+
)
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
## Post-Agent Summary
|
|
77
|
+
|
|
78
|
+
After agent completes, summarize key findings:
|
|
79
|
+
|
|
80
|
+
```markdown
|
|
81
|
+
🔬 **Research Complete**
|
|
82
|
+
|
|
83
|
+
**Recommended Approach**: [chosen solution]
|
|
84
|
+
**Integration Points**: [where it fits]
|
|
85
|
+
**Implementation Plan**: [step-by-step]
|
|
86
|
+
**Key Considerations**: [risks/trade-offs]
|
|
87
|
+
**Documentation**: `.docs/research/[session-id].md`
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
## Examples
|
|
91
|
+
|
|
92
|
+
**Example 1: Known Pattern - Show Inline**
|
|
93
|
+
```
|
|
94
|
+
User: "I need to add validation to this endpoint"
|
|
95
|
+
Skill: "We already use this pattern. See src/api/users.ts:45
|
|
96
|
+
[Shows existing validation pattern, no agent needed]
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
**Example 2: Unfamiliar - Launch Agent**
|
|
100
|
+
```
|
|
101
|
+
User: "Add OAuth authentication"
|
|
102
|
+
Skill: "OAuth integration requires research of approaches and patterns.
|
|
103
|
+
Launching research agent..."
|
|
104
|
+
[Launches research agent for comprehensive analysis]
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
**Example 3: Multiple Approaches - Launch Agent**
|
|
108
|
+
```
|
|
109
|
+
User: "Add real-time updates to dashboard"
|
|
110
|
+
Skill: "Multiple approaches possible (WebSockets, SSE, polling).
|
|
111
|
+
Launching research agent to evaluate options..."
|
|
112
|
+
[Launches research agent]
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
## Quick Pattern Recognition
|
|
116
|
+
|
|
117
|
+
Before launching agent, do **minimal** codebase check:
|
|
118
|
+
|
|
119
|
+
```bash
|
|
120
|
+
# Only if very quick (< 5 seconds)
|
|
121
|
+
grep -r "similar_pattern" --include="*.ts" src/ | head -3
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
If pattern found → Show it
|
|
125
|
+
If not found → Launch agent
|
|
126
|
+
|
|
127
|
+
## Key Points
|
|
128
|
+
|
|
129
|
+
- **Lightweight**: Skill does minimal checking (~20 lines)
|
|
130
|
+
- **Smart dispatch**: Shows existing patterns vs researches new
|
|
131
|
+
- **No heavy analysis**: Delegates comprehensive research to agent
|
|
132
|
+
- **Autonomous**: Auto-launches when research needed
|
|
133
|
+
- **Clean context**: Main session stays focused on implementation
|
|
134
|
+
|
|
135
|
+
This ensures thorough research happens in separate context while main session remains clean.
|