@allthingsclaude/blueprints 0.3.0-beta.24 → 0.3.0-beta.25
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.
|
@@ -128,6 +128,7 @@ For each task in the current phase:
|
|
|
128
128
|
- Check git diff to review changes
|
|
129
129
|
- Verify the change works as expected
|
|
130
130
|
- **Convention adherence**: Does this code follow the patterns discovered in Step 1.5? If the project uses a specific styling method, did you use it? If there's an established feedback/notification system, did you use it instead of a raw alternative? If there's a custom hook or data fetching pattern, did you follow it?
|
|
131
|
+
- **No inline styles**: Never add inline styles unless absolutely necessary (e.g., a dynamic value that can't be expressed as a class). If the project uses CSS modules, SCSS, Tailwind, or any other styling method — use that. Look at how existing components are styled and follow the same approach.
|
|
131
132
|
- **Accessibility basics** (for UI tasks — modals, forms, dialogs, interactive elements): Labels associated with inputs, ARIA roles on overlays/modals, keyboard handling (Escape to close, focus trap in modals), visible focus indicators
|
|
132
133
|
- **Data access patterns** (for tasks involving data fetching or transformation): No per-item queries inside loops or list iterations, batch operations where possible, efficient relationship loading
|
|
133
134
|
|
|
@@ -167,7 +168,8 @@ At the end of each phase:
|
|
|
167
168
|
- No unnecessary duplication (e.g., identical handler functions across components that could be shared)
|
|
168
169
|
- Consistent component structure and naming
|
|
169
170
|
- If any inconsistencies are found, fix them before moving on
|
|
170
|
-
5. **
|
|
171
|
+
5. **DRY check**: Run `/dry` (or mentally audit the phase's code) to identify any repeated patterns, duplicated logic, or code that should be extracted into shared utilities, components, or constants. Fix any DRY violations before presenting to the user.
|
|
172
|
+
6. **Ask user for approval** before moving to next phase:
|
|
171
173
|
|
|
172
174
|
```markdown
|
|
173
175
|
🎯 **Phase 1 Complete**
|
|
@@ -193,7 +195,7 @@ At the end of each phase:
|
|
|
193
195
|
Ready to commit this phase before moving to Phase 2? (yes/no/review)
|
|
194
196
|
```
|
|
195
197
|
|
|
196
|
-
|
|
198
|
+
7. **Update STATE.md** after phase completion:
|
|
197
199
|
- **Always READ existing STATE.md first** to preserve `## Overview` table and `## Plans` sections
|
|
198
200
|
- Update the `**Phase**` field in the header to the next phase number
|
|
199
201
|
- Update the `**Status**` field if needed (keep `🚧 In Progress` during work, set `✅ Complete` when all phases done)
|
|
@@ -190,6 +190,8 @@ You are implementing Stream [N] of a parallelized plan execution.
|
|
|
190
190
|
|
|
191
191
|
These are authoritative patterns from the existing codebase. Always follow them — never introduce a parallel approach for the same concern.
|
|
192
192
|
|
|
193
|
+
**Inline styles**: Never add inline styles unless absolutely necessary (e.g., a truly dynamic value that can't be expressed as a class). Look at how existing components are styled and use the same approach.
|
|
194
|
+
|
|
193
195
|
## Important Context
|
|
194
196
|
|
|
195
197
|
- Other streams are running in parallel
|
|
@@ -331,7 +333,17 @@ After type check and lint pass, review code from all streams for pattern alignme
|
|
|
331
333
|
|
|
332
334
|
If any drift is found between streams, fix it to match the project's established conventions before reporting results.
|
|
333
335
|
|
|
334
|
-
#### 5.4
|
|
336
|
+
#### 5.4 DRY Check
|
|
337
|
+
|
|
338
|
+
After cross-stream consistency review, audit the combined code for DRY violations. Different agents may have independently created similar utilities, components, or patterns. Look for:
|
|
339
|
+
- Duplicated helper functions or utilities across streams
|
|
340
|
+
- Similar component patterns that could share a base
|
|
341
|
+
- Repeated constants, types, or configurations
|
|
342
|
+
- Any code that should be extracted into shared modules
|
|
343
|
+
|
|
344
|
+
Fix violations before reporting results — consolidate duplicates into shared code.
|
|
345
|
+
|
|
346
|
+
#### 5.5 Conflict Resolution
|
|
335
347
|
|
|
336
348
|
If conflicts exist (shouldn't if partitioning was correct):
|
|
337
349
|
1. Identify conflicting changes
|
|
@@ -339,7 +351,7 @@ If conflicts exist (shouldn't if partitioning was correct):
|
|
|
339
351
|
3. Apply manual fix
|
|
340
352
|
4. Document what happened
|
|
341
353
|
|
|
342
|
-
#### 5.
|
|
354
|
+
#### 5.6 Update Plan
|
|
343
355
|
|
|
344
356
|
Mark completed tasks in the plan document:
|
|
345
357
|
|
|
@@ -41,6 +41,7 @@ Launching the **implement agent** which will work independently in a separate co
|
|
|
41
41
|
- ✅ Validate each phase before proceeding
|
|
42
42
|
- ✅ Handle blockers (will pause and report)
|
|
43
43
|
- ✅ Adapt plan if better approaches discovered
|
|
44
|
+
- ✅ Run DRY checks after each phase to extract shared patterns
|
|
44
45
|
- ✅ Return comprehensive summary when complete
|
|
45
46
|
|
|
46
47
|
### What You'll See
|
|
@@ -36,7 +36,7 @@ I'll work through this plan collaboratively with you:
|
|
|
36
36
|
|
|
37
37
|
1. **Load & Review**: I'll load the plan and show you a summary
|
|
38
38
|
2. **Environment Check**: Verify git status and project state
|
|
39
|
-
3. **Convention Discovery**: Scan the codebase for established patterns (error handling, styling, state management, data fetching, test infrastructure) and share findings so we're aligned on which patterns to follow
|
|
39
|
+
3. **Convention Discovery**: Scan the codebase for established patterns (error handling, styling, state management, data fetching, test infrastructure) and share findings so we're aligned on which patterns to follow. Look at how existing code is structured — never add inline styles unless absolutely necessary, always use the project's established styling method
|
|
40
40
|
4. **Task Tracking**: Set up TodoWrite for all plan tasks
|
|
41
41
|
5. **Step-by-Step**: Execute tasks one at a time with your input
|
|
42
42
|
6. **Validation**: Run type checks and lints after each task
|
|
@@ -74,3 +74,5 @@ Then ask: "Ready to start implementing? Which phase should we tackle first?"
|
|
|
74
74
|
Use TodoWrite to create todos for all tasks from the plan once user confirms.
|
|
75
75
|
|
|
76
76
|
Then begin executing tasks step-by-step, staying in the main context, validating as you go.
|
|
77
|
+
|
|
78
|
+
After completing each phase, run `/dry` to check if any repeated patterns or duplicated code should be extracted into shared utilities, components, or constants. Fix any DRY violations before moving to the next phase.
|
package/package.json
CHANGED