devflow-kit 0.1.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 +64 -0
- package/LICENSE +21 -0
- package/README.md +144 -0
- package/dist/cli.d.ts +3 -0
- package/dist/cli.d.ts.map +1 -0
- package/dist/cli.js +32 -0
- package/dist/cli.js.map +1 -0
- package/dist/commands/init.d.ts +3 -0
- package/dist/commands/init.d.ts.map +1 -0
- package/dist/commands/init.js +338 -0
- package/dist/commands/init.js.map +1 -0
- package/dist/commands/uninstall.d.ts +3 -0
- package/dist/commands/uninstall.d.ts.map +1 -0
- package/dist/commands/uninstall.js +74 -0
- package/dist/commands/uninstall.js.map +1 -0
- package/package.json +54 -0
- package/src/claude/agents/devflow/audit-architecture.md +84 -0
- package/src/claude/agents/devflow/audit-complexity.md +102 -0
- package/src/claude/agents/devflow/audit-database.md +104 -0
- package/src/claude/agents/devflow/audit-dependencies.md +109 -0
- package/src/claude/agents/devflow/audit-performance.md +85 -0
- package/src/claude/agents/devflow/audit-security.md +75 -0
- package/src/claude/agents/devflow/audit-tests.md +107 -0
- package/src/claude/agents/devflow/catch-up.md +352 -0
- package/src/claude/agents/devflow/commit.md +347 -0
- package/src/claude/commands/devflow/catch-up.md +29 -0
- package/src/claude/commands/devflow/commit.md +28 -0
- package/src/claude/commands/devflow/debug.md +228 -0
- package/src/claude/commands/devflow/devlog.md +370 -0
- package/src/claude/commands/devflow/plan-next-steps.md +212 -0
- package/src/claude/commands/devflow/pre-commit.md +138 -0
- package/src/claude/commands/devflow/pre-pr.md +286 -0
- package/src/claude/scripts/statusline.sh +115 -0
- package/src/claude/settings.json +6 -0
|
@@ -0,0 +1,370 @@
|
|
|
1
|
+
---
|
|
2
|
+
allowed-tools: Bash, Read, Grep, Glob, Write, TodoWrite, Task
|
|
3
|
+
description: Create a development log entry capturing current project state and context
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Your task
|
|
7
|
+
|
|
8
|
+
Create a comprehensive development log entry that captures the current state of the project, recent work, decisions made, and what's left to do. This serves as a time capsule for any developer (including yourself) returning to this project later.
|
|
9
|
+
|
|
10
|
+
### Step 1: Capture Agent's Internal Todo List
|
|
11
|
+
|
|
12
|
+
**CRITICAL FIRST STEP**: Before doing anything else, capture the agent's current internal todo list state.
|
|
13
|
+
|
|
14
|
+
Use TodoWrite to dump the current todo list, then immediately document it:
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
# This will be the current todo list that needs to be preserved
|
|
18
|
+
# The agent should use TodoWrite to get their current state
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
**MANDATORY**: Document ALL current todos with their exact status:
|
|
22
|
+
- content (exact task description)
|
|
23
|
+
- status (pending/in_progress/completed)
|
|
24
|
+
- activeForm (present tense description)
|
|
25
|
+
|
|
26
|
+
This state MUST be preserved so future sessions can recreate the todo list exactly.
|
|
27
|
+
|
|
28
|
+
### Step 2: Gather Context
|
|
29
|
+
|
|
30
|
+
Determine the current date/time and project information:
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
# Get current date in DD-MM-YYYY format
|
|
34
|
+
DATE=$(date +"%d-%m-%Y")
|
|
35
|
+
TIME=$(date +"%H%M")
|
|
36
|
+
TIMESTAMP="${DATE}_${TIME}"
|
|
37
|
+
|
|
38
|
+
# Get project name from current directory
|
|
39
|
+
PROJECT_NAME=$(basename $(pwd))
|
|
40
|
+
|
|
41
|
+
# Create docs directory if it doesn't exist
|
|
42
|
+
mkdir -p .docs/status
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
### Step 3: Analyze Current Conversation
|
|
46
|
+
|
|
47
|
+
Review the current conversation context to understand:
|
|
48
|
+
- What was being worked on
|
|
49
|
+
- What problems were solved
|
|
50
|
+
- What decisions were made
|
|
51
|
+
- What's still pending
|
|
52
|
+
|
|
53
|
+
### Step 4: Gather Project State
|
|
54
|
+
|
|
55
|
+
Analyze the current project state:
|
|
56
|
+
|
|
57
|
+
```bash
|
|
58
|
+
# Recent git activity
|
|
59
|
+
git log --oneline -10 2>/dev/null || echo "No git history"
|
|
60
|
+
|
|
61
|
+
# Current branch and status
|
|
62
|
+
git branch --show-current 2>/dev/null
|
|
63
|
+
git status --short 2>/dev/null
|
|
64
|
+
|
|
65
|
+
# Recent file changes
|
|
66
|
+
find . -type f -mtime -1 -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/venv/*" -not -path "*/target/*" -not -path "*/build/*" 2>/dev/null | head -20
|
|
67
|
+
|
|
68
|
+
# Check for TODO/FIXME comments across common source file extensions
|
|
69
|
+
grep -r "TODO\|FIXME\|HACK\|XXX" \
|
|
70
|
+
--include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx" \
|
|
71
|
+
--include="*.py" --include="*.go" --include="*.rs" --include="*.java" \
|
|
72
|
+
--include="*.c" --include="*.cpp" --include="*.h" --include="*.hpp" \
|
|
73
|
+
--include="*.rb" --include="*.php" --include="*.swift" --include="*.kt" \
|
|
74
|
+
-l 2>/dev/null | head -10
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
### Step 5: Check Documentation
|
|
78
|
+
|
|
79
|
+
Look for existing project documentation to understand:
|
|
80
|
+
- Architecture decisions (ARCHITECTURE.md, ADR/)
|
|
81
|
+
- README status
|
|
82
|
+
- API documentation
|
|
83
|
+
- Any existing notes
|
|
84
|
+
|
|
85
|
+
### Step 6: Generate Comprehensive Status Document
|
|
86
|
+
|
|
87
|
+
Create `.docs/status/{timestamp}.md` with the following structure:
|
|
88
|
+
|
|
89
|
+
```markdown
|
|
90
|
+
# Project Status - {PROJECT_NAME}
|
|
91
|
+
**Date**: {DATE}
|
|
92
|
+
**Time**: {TIME}
|
|
93
|
+
**Author**: Claude (AI Assistant)
|
|
94
|
+
**Session Context**: {Brief description of what was being worked on}
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
## 🎯 Current Focus
|
|
99
|
+
|
|
100
|
+
### What We Were Working On
|
|
101
|
+
{Detailed description of the current task/feature being developed}
|
|
102
|
+
|
|
103
|
+
### Problems Solved Today
|
|
104
|
+
1. {Problem 1 and solution}
|
|
105
|
+
2. {Problem 2 and solution}
|
|
106
|
+
3. {Problem 3 and solution}
|
|
107
|
+
|
|
108
|
+
### Decisions Made
|
|
109
|
+
- **Decision**: {What was decided}
|
|
110
|
+
**Rationale**: {Why this approach}
|
|
111
|
+
**Alternatives Considered**: {Other options that were rejected}
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## 📊 Project State
|
|
116
|
+
|
|
117
|
+
### Recent Changes
|
|
118
|
+
```
|
|
119
|
+
{Git log showing recent commits}
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
### Files Modified Recently
|
|
123
|
+
- `path/to/file1` - {What was changed and why}
|
|
124
|
+
- `path/to/file2` - {What was changed and why}
|
|
125
|
+
|
|
126
|
+
### Current Branch
|
|
127
|
+
- Branch: `{branch_name}`
|
|
128
|
+
- Status: {Clean/Dirty with uncommitted changes}
|
|
129
|
+
|
|
130
|
+
---
|
|
131
|
+
|
|
132
|
+
## 🏗️ Architecture & Design
|
|
133
|
+
|
|
134
|
+
### Key Architectural Decisions
|
|
135
|
+
1. {Pattern/Decision 1}
|
|
136
|
+
- Why: {Rationale}
|
|
137
|
+
- Impact: {How it affects the codebase}
|
|
138
|
+
|
|
139
|
+
2. {Pattern/Decision 2}
|
|
140
|
+
- Why: {Rationale}
|
|
141
|
+
- Impact: {How it affects the codebase}
|
|
142
|
+
|
|
143
|
+
### Technology Stack
|
|
144
|
+
- **Language**: {Primary programming language}
|
|
145
|
+
- **Framework**: {Main framework or runtime}
|
|
146
|
+
- **Data Storage**: {Database or storage system}
|
|
147
|
+
- **Key Dependencies**: {Critical libraries or packages}
|
|
148
|
+
|
|
149
|
+
### Design Patterns in Use
|
|
150
|
+
- {Pattern 1}: {Where and why}
|
|
151
|
+
- {Pattern 2}: {Where and why}
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
## ⚠️ Known Issues & Technical Debt
|
|
156
|
+
|
|
157
|
+
### Critical Issues
|
|
158
|
+
1. {Issue description}
|
|
159
|
+
- Location: `file/path`
|
|
160
|
+
- Impact: {High/Medium/Low}
|
|
161
|
+
- Suggested Fix: {Approach}
|
|
162
|
+
|
|
163
|
+
### Technical Debt
|
|
164
|
+
1. {Debt item}
|
|
165
|
+
- Why it exists: {Historical reason}
|
|
166
|
+
- Cost of fixing: {Estimate}
|
|
167
|
+
- Priority: {High/Medium/Low}
|
|
168
|
+
|
|
169
|
+
### TODOs in Codebase
|
|
170
|
+
```
|
|
171
|
+
{List of files with TODO/FIXME comments}
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
---
|
|
175
|
+
|
|
176
|
+
## 📋 Agent Todo List State
|
|
177
|
+
|
|
178
|
+
**CRITICAL**: This section preserves the agent's internal todo list state for session continuity.
|
|
179
|
+
|
|
180
|
+
### Current Todo List (for recreation)
|
|
181
|
+
```json
|
|
182
|
+
{Exact TodoWrite JSON with all current todos}
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
### Todo Summary
|
|
186
|
+
- **Total tasks**: {count}
|
|
187
|
+
- **Pending**: {count of pending tasks}
|
|
188
|
+
- **In Progress**: {count of in_progress tasks}
|
|
189
|
+
- **Completed**: {count of completed tasks}
|
|
190
|
+
|
|
191
|
+
### Key Active Tasks
|
|
192
|
+
- 🔄 **In Progress**: {current active task}
|
|
193
|
+
- ⏳ **Next Priority**: {next pending task}
|
|
194
|
+
|
|
195
|
+
---
|
|
196
|
+
|
|
197
|
+
## 🚀 Next Steps
|
|
198
|
+
|
|
199
|
+
### Immediate (Next Session)
|
|
200
|
+
- [ ] **FIRST**: Recreate agent todo list using TodoWrite with preserved state above
|
|
201
|
+
- [ ] {Task 1 from conversation}
|
|
202
|
+
- [ ] {Task 2 from conversation}
|
|
203
|
+
- [ ] {Task 3 from conversation}
|
|
204
|
+
|
|
205
|
+
### Short Term (This Week)
|
|
206
|
+
- [ ] {Goal 1}
|
|
207
|
+
- [ ] {Goal 2}
|
|
208
|
+
|
|
209
|
+
### Long Term (This Month)
|
|
210
|
+
- [ ] {Major milestone 1}
|
|
211
|
+
- [ ] {Major milestone 2}
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## 💡 Context for Future Developer
|
|
216
|
+
|
|
217
|
+
### Things to Know
|
|
218
|
+
1. **Gotcha #1**: {Something non-obvious}
|
|
219
|
+
2. **Gotcha #2**: {Another tricky thing}
|
|
220
|
+
3. **Convention**: {Project-specific convention}
|
|
221
|
+
|
|
222
|
+
### Where to Start
|
|
223
|
+
If you're picking this up later, here's where to begin:
|
|
224
|
+
1. Check {specific file/area}
|
|
225
|
+
2. Review {documentation}
|
|
226
|
+
3. Run {command} to verify setup
|
|
227
|
+
|
|
228
|
+
### Key Files to Understand
|
|
229
|
+
- `path/to/important/file1` - {Why it's important}
|
|
230
|
+
- `path/to/important/file2` - {Why it's important}
|
|
231
|
+
|
|
232
|
+
### Testing Strategy
|
|
233
|
+
- How to run tests: `{command}`
|
|
234
|
+
- Test coverage: {status}
|
|
235
|
+
- Critical test files: {list}
|
|
236
|
+
|
|
237
|
+
---
|
|
238
|
+
|
|
239
|
+
## 🔗 Related Documents
|
|
240
|
+
|
|
241
|
+
### Project Documentation
|
|
242
|
+
- README.md - {Status: Updated/Outdated/Missing}
|
|
243
|
+
- CONTRIBUTING.md - {Status}
|
|
244
|
+
- ARCHITECTURE.md - {Status}
|
|
245
|
+
|
|
246
|
+
### Previous Status Notes
|
|
247
|
+
{Link to previous status documents if they exist}
|
|
248
|
+
|
|
249
|
+
---
|
|
250
|
+
|
|
251
|
+
## 📝 Raw Session Notes
|
|
252
|
+
|
|
253
|
+
### What the User Asked For
|
|
254
|
+
{Original user request}
|
|
255
|
+
|
|
256
|
+
### Approach Taken
|
|
257
|
+
{Step-by-step what was done}
|
|
258
|
+
|
|
259
|
+
### Challenges Encountered
|
|
260
|
+
{Any difficulties and how they were resolved}
|
|
261
|
+
|
|
262
|
+
### Time Spent
|
|
263
|
+
- Estimated session duration: {from timestamp data if available}
|
|
264
|
+
- Complexity level: {Simple/Medium/Complex}
|
|
265
|
+
|
|
266
|
+
---
|
|
267
|
+
|
|
268
|
+
## 🤖 AI Assistant Metadata
|
|
269
|
+
|
|
270
|
+
### Model Used
|
|
271
|
+
- Model: {Claude model version}
|
|
272
|
+
- Capabilities: {What tools were available}
|
|
273
|
+
- Limitations encountered: {Any AI limitations that affected work}
|
|
274
|
+
|
|
275
|
+
### Commands/Tools Used
|
|
276
|
+
- {Tool 1}: {How it was used}
|
|
277
|
+
- {Tool 2}: {How it was used}
|
|
278
|
+
|
|
279
|
+
---
|
|
280
|
+
|
|
281
|
+
## 📌 Final Thoughts
|
|
282
|
+
|
|
283
|
+
{A brief paragraph of final thoughts, advice, or warnings for whoever picks this up next. Written in first person as if leaving a note to your future self or a colleague.}
|
|
284
|
+
|
|
285
|
+
**Remember**: This is a snapshot in time. The project will have evolved since this was written. Use this as a starting point for understanding, not as gospel truth.
|
|
286
|
+
|
|
287
|
+
---
|
|
288
|
+
*This document was auto-generated by the `/devlog` command*
|
|
289
|
+
*To generate a new status report, run `/devlog` in Claude Code*
|
|
290
|
+
```
|
|
291
|
+
|
|
292
|
+
### Step 7: Create Compact Version
|
|
293
|
+
|
|
294
|
+
Create a compact summary at `.docs/status/compact/{timestamp}.md`:
|
|
295
|
+
|
|
296
|
+
```markdown
|
|
297
|
+
# Compact Status - {DATE}
|
|
298
|
+
|
|
299
|
+
**Focus**: {One-line summary of what was worked on}
|
|
300
|
+
|
|
301
|
+
**Key Accomplishments**:
|
|
302
|
+
- {Accomplishment 1}
|
|
303
|
+
- {Accomplishment 2}
|
|
304
|
+
- {Accomplishment 3}
|
|
305
|
+
|
|
306
|
+
**Critical Decisions**:
|
|
307
|
+
- {Decision 1}: {Brief rationale}
|
|
308
|
+
- {Decision 2}: {Brief rationale}
|
|
309
|
+
|
|
310
|
+
**Next Priority Actions**:
|
|
311
|
+
- [ ] {Top priority task}
|
|
312
|
+
- [ ] {Second priority task}
|
|
313
|
+
- [ ] {Third priority task}
|
|
314
|
+
|
|
315
|
+
**Critical Issues**:
|
|
316
|
+
- {Blocker 1}: {One-line description}
|
|
317
|
+
- {Blocker 2}: {One-line description}
|
|
318
|
+
|
|
319
|
+
**Key Files Modified**:
|
|
320
|
+
- `{file1}` - {Brief change description}
|
|
321
|
+
- `{file2}` - {Brief change description}
|
|
322
|
+
- `{file3}` - {Brief change description}
|
|
323
|
+
|
|
324
|
+
**Context Notes**:
|
|
325
|
+
{2-3 sentences of essential context for future sessions}
|
|
326
|
+
|
|
327
|
+
---
|
|
328
|
+
*Quick summary of [full status](./../{timestamp}.md)*
|
|
329
|
+
```
|
|
330
|
+
|
|
331
|
+
### Step 8: Create Summary Index
|
|
332
|
+
|
|
333
|
+
Also update or create `.docs/status/INDEX.md` to list all status documents:
|
|
334
|
+
|
|
335
|
+
```markdown
|
|
336
|
+
# Status Document Index
|
|
337
|
+
|
|
338
|
+
## Quick Reference
|
|
339
|
+
- [Latest Catch-Up Summary](../CATCH_UP.md) - For getting back up to speed
|
|
340
|
+
|
|
341
|
+
## Recent Status Reports
|
|
342
|
+
|
|
343
|
+
| Date | Time | Focus | Full | Compact |
|
|
344
|
+
|------|------|-------|------|---------|
|
|
345
|
+
| {DATE} | {TIME} | {Brief description} | [Full](./{timestamp}.md) | [Quick](./compact/{timestamp}.md) |
|
|
346
|
+
{Previous entries...}
|
|
347
|
+
|
|
348
|
+
## Usage
|
|
349
|
+
- **Starting a session?** → Use `/catch-up` command or check latest compact status
|
|
350
|
+
- **Ending a session?** → Use `/devlog` to document progress
|
|
351
|
+
- **Need full context?** → Read the full status documents
|
|
352
|
+
- **Quick reference?** → Use compact versions
|
|
353
|
+
```
|
|
354
|
+
|
|
355
|
+
### Step 9: Confirm Creation
|
|
356
|
+
|
|
357
|
+
After creating the document, provide confirmation:
|
|
358
|
+
- Full path to the created document
|
|
359
|
+
- Brief summary of what was captured
|
|
360
|
+
- Suggestion to review and edit if needed
|
|
361
|
+
|
|
362
|
+
### Important Considerations
|
|
363
|
+
|
|
364
|
+
1. **Be Honest**: Include both successes and failures
|
|
365
|
+
2. **Be Specific**: Use actual file paths and function names
|
|
366
|
+
3. **Be Helpful**: Write as if explaining to someone unfamiliar with recent work
|
|
367
|
+
4. **Be Concise**: Balance detail with readability
|
|
368
|
+
5. **Include Context**: Explain the "why" behind decisions
|
|
369
|
+
|
|
370
|
+
The goal is to create a time capsule that will be genuinely useful when someone (maybe you!) returns to this project after weeks or months away.
|
|
@@ -0,0 +1,212 @@
|
|
|
1
|
+
---
|
|
2
|
+
allowed-tools: TodoWrite, Read, Write, Edit, MultiEdit, Bash, Grep, Glob, Task
|
|
3
|
+
description: Extract actionable next steps from current discussion and save to todo list
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Your task
|
|
7
|
+
|
|
8
|
+
Analyze the current discussion and convert it into specific, actionable next steps that can be saved to the agent's internal todo list using TodoWrite. This command bridges the gap between talking about what to do and actually tracking concrete steps.
|
|
9
|
+
|
|
10
|
+
**🎯 FOCUS**: Turn discussion into trackable action items for the agent's internal todo list.
|
|
11
|
+
|
|
12
|
+
### Step 1: Extract Next Steps from Discussion
|
|
13
|
+
|
|
14
|
+
**FOCUS**: Look at the current discussion and identify concrete next steps that emerged from the conversation.
|
|
15
|
+
|
|
16
|
+
**What to Extract**:
|
|
17
|
+
- **Immediate tasks** mentioned or implied in the discussion
|
|
18
|
+
- **Code changes** that were discussed or agreed upon
|
|
19
|
+
- **Files** that need to be created, modified, or reviewed
|
|
20
|
+
- **Dependencies** that need to be installed or configured
|
|
21
|
+
- **Tests** that need to be written or updated
|
|
22
|
+
- **Documentation** that needs updating
|
|
23
|
+
- **Investigations** or research tasks mentioned
|
|
24
|
+
- **Decisions** that need to be made before proceeding
|
|
25
|
+
|
|
26
|
+
**Look for phrases like**:
|
|
27
|
+
- "We should..."
|
|
28
|
+
- "Next, I'll..."
|
|
29
|
+
- "Let me..."
|
|
30
|
+
- "I need to..."
|
|
31
|
+
- "We could..."
|
|
32
|
+
- "First, we'll..."
|
|
33
|
+
|
|
34
|
+
### Step 2: Convert to Actionable Todo Items
|
|
35
|
+
|
|
36
|
+
Transform the extracted items into specific todo tasks that can be tracked:
|
|
37
|
+
|
|
38
|
+
**Good todo items**:
|
|
39
|
+
- ✅ "Add authentication middleware to routes in `/src/middleware/auth`"
|
|
40
|
+
- ✅ "Write unit tests for user registration in `/tests/auth_test`"
|
|
41
|
+
- ✅ "Install password hashing library dependency"
|
|
42
|
+
- ✅ "Research API schema design for user endpoints"
|
|
43
|
+
- ✅ "Update README.md with new authentication setup instructions"
|
|
44
|
+
|
|
45
|
+
**Bad todo items**:
|
|
46
|
+
- ❌ "Improve authentication" (too vague)
|
|
47
|
+
- ❌ "Add better error handling" (not specific)
|
|
48
|
+
- ❌ "Make it more secure" (not actionable)
|
|
49
|
+
|
|
50
|
+
### Step 3: Save to Todo List with TodoWrite
|
|
51
|
+
|
|
52
|
+
**IMMEDIATELY** use TodoWrite to save the action items to the agent's internal todo list. Each task should:
|
|
53
|
+
- Be specific and testable
|
|
54
|
+
- Include file paths when relevant
|
|
55
|
+
- Be completable in 15-30 minutes
|
|
56
|
+
- Have clear success criteria
|
|
57
|
+
- Start as "pending" status
|
|
58
|
+
|
|
59
|
+
Example todo structure:
|
|
60
|
+
```json
|
|
61
|
+
[
|
|
62
|
+
{
|
|
63
|
+
"content": "Install password hashing library dependency",
|
|
64
|
+
"status": "pending",
|
|
65
|
+
"activeForm": "Installing password hashing library"
|
|
66
|
+
},
|
|
67
|
+
{
|
|
68
|
+
"content": "Create authentication middleware in src/middleware/auth",
|
|
69
|
+
"status": "pending",
|
|
70
|
+
"activeForm": "Creating authentication middleware"
|
|
71
|
+
},
|
|
72
|
+
{
|
|
73
|
+
"content": "Add password hashing to user registration in src/routes/users",
|
|
74
|
+
"status": "pending",
|
|
75
|
+
"activeForm": "Adding password hashing to user registration"
|
|
76
|
+
},
|
|
77
|
+
{
|
|
78
|
+
"content": "Write unit tests for auth middleware in tests/auth_test",
|
|
79
|
+
"status": "pending",
|
|
80
|
+
"activeForm": "Writing unit tests for auth middleware"
|
|
81
|
+
},
|
|
82
|
+
{
|
|
83
|
+
"content": "Update API documentation for new auth endpoints",
|
|
84
|
+
"status": "pending",
|
|
85
|
+
"activeForm": "Updating API documentation"
|
|
86
|
+
}
|
|
87
|
+
]
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
### Step 4: Prioritize the Todo Items
|
|
91
|
+
|
|
92
|
+
Arrange the todo items in logical order:
|
|
93
|
+
1. **Dependencies first** (installations, setup)
|
|
94
|
+
2. **Core implementation** (main functionality)
|
|
95
|
+
3. **Tests and validation** (verification)
|
|
96
|
+
4. **Documentation** (updates, guides)
|
|
97
|
+
5. **Follow-up tasks** (optimizations, research)
|
|
98
|
+
|
|
99
|
+
### Step 5: Present the Todo List
|
|
100
|
+
|
|
101
|
+
Show the developer what was extracted and saved:
|
|
102
|
+
|
|
103
|
+
```markdown
|
|
104
|
+
## 📋 Next Steps Added to Todo List
|
|
105
|
+
|
|
106
|
+
Based on our discussion, I've identified and saved these action items:
|
|
107
|
+
|
|
108
|
+
### Immediate Tasks (Dependencies)
|
|
109
|
+
- [ ] {Task 1}
|
|
110
|
+
- [ ] {Task 2}
|
|
111
|
+
|
|
112
|
+
### Core Implementation
|
|
113
|
+
- [ ] {Task 3}
|
|
114
|
+
- [ ] {Task 4}
|
|
115
|
+
- [ ] {Task 5}
|
|
116
|
+
|
|
117
|
+
### Testing & Validation
|
|
118
|
+
- [ ] {Task 6}
|
|
119
|
+
- [ ] {Task 7}
|
|
120
|
+
|
|
121
|
+
### Documentation
|
|
122
|
+
- [ ] {Task 8}
|
|
123
|
+
|
|
124
|
+
**Total: {X} tasks added to internal todo list**
|
|
125
|
+
**Ready to begin? The agent can now start working through these systematically.**
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
---
|
|
129
|
+
|
|
130
|
+
## Usage Examples
|
|
131
|
+
|
|
132
|
+
### Example 1: After Feature Discussion
|
|
133
|
+
```
|
|
134
|
+
Human: "Add user authentication to our web application"
|
|
135
|
+
AI: "I can help with that. What type of auth do you prefer?"
|
|
136
|
+
Human: "Token-based auth, and we need password reset functionality"
|
|
137
|
+
AI: "Got it. Should I use a password hashing library?"
|
|
138
|
+
Human: "Yes, and integrate with our existing database"
|
|
139
|
+
Developer: "/standup"
|
|
140
|
+
|
|
141
|
+
Result: AI extracts action items from discussion:
|
|
142
|
+
- Install password hashing and token libraries
|
|
143
|
+
- Create user authentication middleware
|
|
144
|
+
- Set up password reset email functionality
|
|
145
|
+
- Create database migration for user auth tables
|
|
146
|
+
- Write unit tests for auth endpoints
|
|
147
|
+
- Update API documentation
|
|
148
|
+
|
|
149
|
+
📋 6 tasks added to internal todo list
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
### Example 2: After Bug Investigation
|
|
153
|
+
```
|
|
154
|
+
Human: "Users are reporting slow page loads on the dashboard"
|
|
155
|
+
AI: "Let me investigate the dashboard queries. I found the issue - it's doing N+1 queries on user data."
|
|
156
|
+
Human: "Can you fix that?"
|
|
157
|
+
AI: "Yes, I'll add proper joins and implement pagination."
|
|
158
|
+
Developer: "/plan-next-steps"
|
|
159
|
+
|
|
160
|
+
Result: AI creates specific action items:
|
|
161
|
+
- Add eager loading to user dashboard query
|
|
162
|
+
- Implement pagination for dashboard data
|
|
163
|
+
- Add database indexes for performance
|
|
164
|
+
- Write performance test for dashboard endpoint
|
|
165
|
+
- Update frontend to handle paginated data
|
|
166
|
+
|
|
167
|
+
📋 5 tasks added to internal todo list
|
|
168
|
+
```
|
|
169
|
+
|
|
170
|
+
### Example 3: After Planning Discussion
|
|
171
|
+
```
|
|
172
|
+
Human: "I want to migrate our REST API to a query-based API"
|
|
173
|
+
AI: "That's a big change. Should we do it gradually?"
|
|
174
|
+
Human: "Yes, start with user endpoints but keep REST for compatibility"
|
|
175
|
+
AI: "I'll create a hybrid approach with both API styles."
|
|
176
|
+
Developer: "/standup"
|
|
177
|
+
|
|
178
|
+
Result: AI saves implementation steps:
|
|
179
|
+
- Install query API framework dependencies
|
|
180
|
+
- Create API schema for user types
|
|
181
|
+
- Implement user query resolvers
|
|
182
|
+
- Set up query endpoint alongside REST
|
|
183
|
+
- Write integration tests for new API
|
|
184
|
+
- Update documentation for new endpoints
|
|
185
|
+
|
|
186
|
+
📋 6 tasks added to internal todo list
|
|
187
|
+
```
|
|
188
|
+
|
|
189
|
+
---
|
|
190
|
+
|
|
191
|
+
## Command Behavior Rules
|
|
192
|
+
|
|
193
|
+
### ALWAYS Do These:
|
|
194
|
+
- ✅ Extract concrete action items from the discussion
|
|
195
|
+
- ✅ Use TodoWrite to save tasks to internal todo list
|
|
196
|
+
- ✅ Break tasks into 15-30 minute chunks
|
|
197
|
+
- ✅ Include file paths and specific details
|
|
198
|
+
- ✅ Prioritize tasks in logical order
|
|
199
|
+
|
|
200
|
+
### NEVER Do These:
|
|
201
|
+
- ❌ Create vague or untestable tasks
|
|
202
|
+
- ❌ Skip obvious implementation steps
|
|
203
|
+
- ❌ Forget to use TodoWrite to save the list
|
|
204
|
+
- ❌ Make tasks too large or complex
|
|
205
|
+
- ❌ Ignore dependencies or prerequisites
|
|
206
|
+
|
|
207
|
+
### Focus Areas:
|
|
208
|
+
- 🎯 **Extract**: Pull concrete next steps from discussion
|
|
209
|
+
- 🎯 **Clarify**: Make each task specific and actionable
|
|
210
|
+
- 🎯 **Save**: Use TodoWrite to store in agent's todo list
|
|
211
|
+
- 🎯 **Present**: Show what was captured for verification
|
|
212
|
+
|
|
@@ -0,0 +1,138 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Review uncommitted changes before committing using specialized sub-agents
|
|
3
|
+
allowed-tools: Task, Bash, Read, Write, Grep, Glob
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Your Task
|
|
7
|
+
|
|
8
|
+
Perform a comprehensive review of uncommitted changes by orchestrating multiple specialized sub-agents in parallel. This provides quick feedback before committing changes.
|
|
9
|
+
|
|
10
|
+
### Step 1: Analyze Current Changes
|
|
11
|
+
|
|
12
|
+
First, check what changes are available for review:
|
|
13
|
+
|
|
14
|
+
```bash
|
|
15
|
+
# Check for uncommitted changes
|
|
16
|
+
git status --porcelain
|
|
17
|
+
|
|
18
|
+
# Get the diff of uncommitted changes
|
|
19
|
+
if git diff --quiet HEAD; then
|
|
20
|
+
echo "No uncommitted changes to review"
|
|
21
|
+
exit 0
|
|
22
|
+
fi
|
|
23
|
+
|
|
24
|
+
# Show summary of changes
|
|
25
|
+
echo "=== CHANGES TO REVIEW ==="
|
|
26
|
+
git diff --stat HEAD
|
|
27
|
+
echo ""
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
### Step 2: Launch Specialized Sub-Agents in Parallel
|
|
31
|
+
|
|
32
|
+
Launch these sub-agents in parallel:
|
|
33
|
+
|
|
34
|
+
1. audit-security sub-agent
|
|
35
|
+
2. audit-performance sub-agent
|
|
36
|
+
3. audit-architecture sub-agent
|
|
37
|
+
4. audit-tests sub-agent
|
|
38
|
+
5. audit-complexity sub-agent
|
|
39
|
+
|
|
40
|
+
### Step 3: Synthesize Review Findings
|
|
41
|
+
|
|
42
|
+
After all sub-agents complete their analysis:
|
|
43
|
+
|
|
44
|
+
1. **Collect Results**: Gather findings from all sub-agents
|
|
45
|
+
2. **Prioritize Issues**: Categorize as Critical/High/Medium/Low
|
|
46
|
+
3. **Create Unified Review**: Synthesize into coherent review document
|
|
47
|
+
4. **Generate Action Items**: Provide specific next steps
|
|
48
|
+
|
|
49
|
+
### Step 4: Save Review Document
|
|
50
|
+
|
|
51
|
+
Create a comprehensive review document at `.docs/reviews/diff-{YYYY-MM-DD_HHMM}.md`:
|
|
52
|
+
|
|
53
|
+
```markdown
|
|
54
|
+
# Code Review - Uncommitted Changes
|
|
55
|
+
**Date**: {current_date}
|
|
56
|
+
**Time**: {current_time}
|
|
57
|
+
**Type**: Differential Review (uncommitted changes)
|
|
58
|
+
**Reviewer**: AI Sub-Agent Orchestra
|
|
59
|
+
|
|
60
|
+
---
|
|
61
|
+
|
|
62
|
+
## 📊 Review Summary
|
|
63
|
+
|
|
64
|
+
**Files Changed**: {number}
|
|
65
|
+
**Lines Added**: {number}
|
|
66
|
+
**Lines Removed**: {number}
|
|
67
|
+
|
|
68
|
+
### Issues Found
|
|
69
|
+
- 🔴 **Critical**: {count} issues requiring immediate attention
|
|
70
|
+
- 🟠 **High**: {count} issues should be addressed before commit
|
|
71
|
+
- 🟡 **Medium**: {count} improvements recommended
|
|
72
|
+
- 🔵 **Low**: {count} minor suggestions
|
|
73
|
+
|
|
74
|
+
---
|
|
75
|
+
|
|
76
|
+
## 🔍 Detailed Analysis
|
|
77
|
+
|
|
78
|
+
### Security Review (audit-security)
|
|
79
|
+
{security findings with file:line references}
|
|
80
|
+
|
|
81
|
+
### Performance Review (audit-performance)
|
|
82
|
+
{performance findings with specific optimizations}
|
|
83
|
+
|
|
84
|
+
### Architecture Review (audit-architecture)
|
|
85
|
+
{design pattern and structure analysis}
|
|
86
|
+
|
|
87
|
+
### Test Coverage Review (audit-tests)
|
|
88
|
+
{test gaps and quality assessment}
|
|
89
|
+
|
|
90
|
+
### Complexity Review (audit-complexity)
|
|
91
|
+
{maintainability and refactoring suggestions}
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
## 🎯 Action Items
|
|
96
|
+
|
|
97
|
+
### Before Committing (Critical/High)
|
|
98
|
+
- [ ] {action 1} in {file:line}
|
|
99
|
+
- [ ] {action 2} in {file:line}
|
|
100
|
+
|
|
101
|
+
### Future Improvements (Medium/Low)
|
|
102
|
+
- [ ] {improvement 1}
|
|
103
|
+
- [ ] {improvement 2}
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## 📈 Code Quality Metrics
|
|
108
|
+
|
|
109
|
+
**Overall Assessment**: {Excellent/Good/Needs Work/Poor}
|
|
110
|
+
**Commit Recommendation**: {✅ Safe to commit / ⚠️ Address issues first / 🚫 Do not commit}
|
|
111
|
+
|
|
112
|
+
---
|
|
113
|
+
|
|
114
|
+
*Review generated by DevFlow sub-agent orchestration*
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
### Step 5: Provide Interactive Summary
|
|
118
|
+
|
|
119
|
+
Give the developer a clear summary and next steps:
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
🔍 UNCOMMITTED CHANGES REVIEW COMPLETE
|
|
123
|
+
|
|
124
|
+
Changes analyzed: {X} files, {Y} lines modified
|
|
125
|
+
Issues found: {Critical} critical, {High} high, {Medium} medium, {Low} low
|
|
126
|
+
|
|
127
|
+
📋 COMMIT READINESS ASSESSMENT:
|
|
128
|
+
{✅ SAFE TO COMMIT | ⚠️ ISSUES TO ADDRESS | 🚫 DO NOT COMMIT}
|
|
129
|
+
|
|
130
|
+
🎯 TOP PRIORITY ACTIONS:
|
|
131
|
+
1. {Most critical issue and fix}
|
|
132
|
+
2. {Second most critical issue and fix}
|
|
133
|
+
3. {Third most critical issue and fix}
|
|
134
|
+
|
|
135
|
+
📄 Full review saved to: .docs/reviews/diff-{timestamp}.md
|
|
136
|
+
|
|
137
|
+
💡 TIP: Run `/review-branch` before creating PR for comprehensive feature review
|
|
138
|
+
```
|