@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. **Ask user for approval** before moving to next phase:
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
- 5. **Update STATE.md** after phase completion:
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 Conflict Resolution
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.5 Update Plan
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
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@allthingsclaude/blueprints",
3
- "version": "0.3.0-beta.24",
3
+ "version": "0.3.0-beta.25",
4
4
  "description": "Claude Code commands and agents for enhanced AI-assisted development workflows",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",