@allthingsclaude/blueprints 0.3.0-beta.23 → 0.3.0-beta.25

package/content/agents/implement.md

@@ -128,6 +128,7 @@ For each task in the current phase:
 - Check git diff to review changes
 - Verify the change works as expected
 - **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?
+- **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.
 - **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
 - **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
 
@@ -167,7 +168,8 @@ At the end of each phase:
    - No unnecessary duplication (e.g., identical handler functions across components that could be shared)
    - Consistent component structure and naming
    - If any inconsistencies are found, fix them before moving on
-5. **Ask user for approval** before moving to next phase:
+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.
+6. **Ask user for approval** before moving to next phase:
 
 ```markdown
 🎯 **Phase 1 Complete**
@@ -193,7 +195,7 @@ At the end of each phase:
 Ready to commit this phase before moving to Phase 2? (yes/no/review)
 ```
 
-5. **Update STATE.md** after phase completion:
+7. **Update STATE.md** after phase completion:
    - **Always READ existing STATE.md first** to preserve `## Overview` table and `## Plans` sections
    - Update the `**Phase**` field in the header to the next phase number
    - Update the `**Status**` field if needed (keep `🚧 In Progress` during work, set `✅ Complete` when all phases done)

package/content/agents/parallelize.md

@@ -190,6 +190,8 @@ You are implementing Stream [N] of a parallelized plan execution.
 
 These are authoritative patterns from the existing codebase. Always follow them — never introduce a parallel approach for the same concern.
 
+**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.
+
 ## Important Context
 
 - Other streams are running in parallel
@@ -331,7 +333,17 @@ After type check and lint pass, review code from all streams for pattern alignme
 
 If any drift is found between streams, fix it to match the project's established conventions before reporting results.
 
-#### 5.4 Conflict Resolution
+#### 5.4 DRY Check
+
+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:
+- Duplicated helper functions or utilities across streams
+- Similar component patterns that could share a base
+- Repeated constants, types, or configurations
+- Any code that should be extracted into shared modules
+
+Fix violations before reporting results — consolidate duplicates into shared code.
+
+#### 5.5 Conflict Resolution
 
 If conflicts exist (shouldn't if partitioning was correct):
 1. Identify conflicting changes
@@ -339,7 +351,7 @@ If conflicts exist (shouldn't if partitioning was correct):
 3. Apply manual fix
 4. Document what happened
 
-#### 5.5 Update Plan
+#### 5.6 Update Plan
 
 Mark completed tasks in the plan document:
 

package/content/commands/history.md

@@ -0,0 +1,72 @@
+---
+description: Tell the narrative story of a file or function through its git history
+argument-hint: <file path> [optional: :function or symbol name]
+author: "@markoradak"
+---
+
+# File History
+
+Investigating the history of: **$ARGUMENTS**
+
+> **When to use**: You want to understand how a file evolved over time — who created it, what major changes shaped it, and whether it's a hot spot or stable code.
+
+## Context
+
+**Working Directory**: !`pwd`
+
+**File Exists**: !`test -f "$ARGUMENTS" && echo "Yes" || echo "File not found — check the path"`
+
+**File Size**: !`wc -l < "$ARGUMENTS" 2>/dev/null || echo "N/A"`
+
+## Git History
+
+**Full Log (following renames)**:
+!`git log --follow --format="%h|%an|%ar|%s" -- "$ARGUMENTS" 2>/dev/null || echo "No git history available"`
+
+**File Creation**:
+!`git log --follow --diff-filter=A --format="%h %an (%ar): %s" -- "$ARGUMENTS" 2>/dev/null || echo "Unable to determine creation"`
+
+**Contributors**:
+!`git log --follow --format="%an" -- "$ARGUMENTS" 2>/dev/null | sort | uniq -c | sort -rn || echo "N/A"`
+
+**Recent Activity (last 30 days)**:
+!`git log --since="30 days ago" --follow --format="%h %s (%ar)" -- "$ARGUMENTS" 2>/dev/null || echo "No recent changes"`
+
+**Change Frequency**:
+!`echo "Total commits: $(git log --follow --oneline -- "$ARGUMENTS" 2>/dev/null | wc -l | tr -d ' ')"`
+
+---
+
+## Instructions
+
+Using the git history data above, tell the story of this file as a narrative. Don't just list commits — interpret the history.
+
+### 1. Origin
+
+When was the file created, by whom, and why? Use the creation commit message and context to explain what purpose it originally served.
+
+### 2. Evolution
+
+Group commits into phases or themes. For example:
+- "Initial implementation" (first few commits)
+- "Feature expansion" (when significant functionality was added)
+- "Refactoring" (structural changes without new features)
+- "Bug fixes" (corrections and patches)
+
+Summarize each phase in 1-2 sentences rather than listing individual commits.
+
+### 3. Key Contributors
+
+Who has shaped this file the most? Mention the top 2-3 contributors and what kind of work each contributed.
+
+### 4. Current State
+
+- **Activity level** — Is this file actively changing or has it stabilized?
+- **Hot spot or stable?** — High commit frequency = hot spot (may need attention). Low frequency = stable (likely reliable).
+- **Size context** — Is the file large enough to consider splitting?
+
+### 5. Function Focus (if specified)
+
+If `$ARGUMENTS` includes a `:function` or symbol name after the file path, narrow the story to just that symbol. Use `git log -p` mentally to focus on commits that touched that specific function.
+
+**This is read-only. Do not modify any files.**

package/content/commands/implement.md

@@ -41,6 +41,7 @@ Launching the **implement agent** which will work independently in a separate co
 - ✅ Validate each phase before proceeding
 - ✅ Handle blockers (will pause and report)
 - ✅ Adapt plan if better approaches discovered
+- ✅ Run DRY checks after each phase to extract shared patterns
 - ✅ Return comprehensive summary when complete
 
 ### What You'll See

package/content/commands/kickoff.md

@@ -36,7 +36,7 @@ I'll work through this plan collaboratively with you:
 
 1. **Load & Review**: I'll load the plan and show you a summary
 2. **Environment Check**: Verify git status and project state
-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
+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
 4. **Task Tracking**: Set up TodoWrite for all plan tasks
 5. **Step-by-Step**: Execute tasks one at a time with your input
 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?"
 Use TodoWrite to create todos for all tasks from the plan once user confirms.
 
 Then begin executing tasks step-by-step, staying in the main context, validating as you go.
+
+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/content/commands/standup.md

@@ -0,0 +1,71 @@
+---
+description: Generate a standup summary from recent git activity
+argument-hint: [optional: timeframe like "3 days" or "this week"]
+author: "@markoradak"
+---
+
+# Standup Summary
+
+Generating a standup summary from recent activity.
+
+> **When to use**: You need a quick done/doing/next summary for a standup meeting, status update, or just to remind yourself what you've been working on.
+
+## Recent Activity
+
+**Current Branch**: !`git branch --show-current 2>/dev/null || echo "Not a git repository"`
+
+**Author**: !`git config user.name 2>/dev/null || echo "Unknown"`
+
+**Commits (last 48 hours)**:
+!`git log --since="48 hours ago" --author="$(git config user.name)" --format="%h %s (%ar)" 2>/dev/null || echo "No recent commits"`
+
+**Uncommitted Changes**:
+!`git diff --stat 2>/dev/null || echo "None"`
+
+**Staged Changes**:
+!`git diff --cached --stat 2>/dev/null || echo "None"`
+
+**Stashed Work**:
+!`git stash list 2>/dev/null || echo "No stashes"`
+
+**Active Plan Files**:
+!`ls -1 {{TASKS_DIR}}/*.md 2>/dev/null || echo "No plan files found"`
+
+## Timeframe Override
+
+$ARGUMENTS
+
+---
+
+## Instructions
+
+Using the activity data above, generate a clean standup summary in this format:
+
+### Output Format
+
+```markdown
+## Standup — [date]
+
+### Done
+- [completed work items from commits, grouped by theme]
+
+### In Progress
+- [current branch context and uncommitted changes]
+
+### Up Next
+- [items from plan files, or next logical steps]
+```
+
+### Rules
+
+1. **Done** — Synthesize commits into meaningful work items. Don't list every commit — group related commits into a single bullet (e.g., three auth-related commits become "Implemented user authentication flow"). Use the commit messages to understand what was accomplished.
+
+2. **In Progress** — Describe what the current branch and uncommitted changes suggest you're working on. If there are stashes, mention them as paused work.
+
+3. **Up Next** — Pull from plan files if they exist. If not, infer reasonable next steps from the in-progress work or leave as "TBD — no active plan."
+
+4. **Timeframe** — If `$ARGUMENTS` specifies a different timeframe (e.g., "3 days", "this week"), adjust the "Done" section scope accordingly. The shell commands captured the last 48 hours; if the user wants a wider window, note that some older work may not appear.
+
+5. **Tone** — Keep it concise and factual. No filler. Ready to paste into Slack or Teams.
+
+**This is read-only. Do not modify any files.**

package/content/commands/todo.md

@@ -0,0 +1,64 @@
+---
+description: Scan codebase for TODO/FIXME/HACK markers and present an organized summary
+argument-hint: [optional: directory, file, or keyword to filter]
+author: "@markoradak"
+---
+
+# TODO Scanner
+
+Scanning the codebase for code markers and annotations.
+
+> **When to use**: You want a quick overview of outstanding TODOs, FIXMEs, and other code markers scattered across the project — without grepping manually.
+
+## Current State
+
+**Working Directory**: !`pwd`
+
+**Git Root**: !`git rev-parse --show-toplevel 2>/dev/null || echo "Not a git repository"`
+
+## Marker Scan
+
+**High Priority (FIXME, HACK, XXX)**:
+!`git grep -rn -E '\b(FIXME|HACK|XXX)\b' -- ':!node_modules' ':!.git' 2>/dev/null || grep -rn -E '\b(FIXME|HACK|XXX)\b' --include='*' --exclude-dir=node_modules --exclude-dir=.git . 2>/dev/null || echo "No high-priority markers found"`
+
+**Standard (TODO, TASK, TEMP, DEPRECATED)**:
+!`git grep -rn -E '\b(TODO|TASK|TEMP|DEPRECATED)\b' -- ':!node_modules' ':!.git' 2>/dev/null || grep -rn -E '\b(TODO|TASK|TEMP|DEPRECATED)\b' --include='*' --exclude-dir=node_modules --exclude-dir=.git . 2>/dev/null || echo "No standard markers found"`
+
+**Informational (NOTE, WARN)**:
+!`git grep -rn -E '\b(NOTE|WARN)\b' -- ':!node_modules' ':!.git' 2>/dev/null || grep -rn -E '\b(NOTE|WARN)\b' --include='*' --exclude-dir=node_modules --exclude-dir=.git . 2>/dev/null || echo "No informational markers found"`
+
+## User Filter
+
+$ARGUMENTS
+
+---
+
+## Instructions
+
+Using the marker scan results above, present an organized summary:
+
+### 1. Summary counts
+
+Show a table of marker types and their total counts. Order by priority: FIXME > HACK > XXX > TODO > TASK > TEMP > DEPRECATED > NOTE > WARN.
+
+### 2. Organize by priority
+
+Group results into three tiers:
+- **Needs attention** — FIXME, HACK, XXX (things that are broken or fragile)
+- **Planned work** — TODO, TASK, TEMP, DEPRECATED (things that need doing)
+- **Informational** — NOTE, WARN (context for future readers)
+
+Within each tier, group by file or directory so related items stay together.
+
+### 3. Apply user filter
+
+If `$ARGUMENTS` was provided, filter results to only show markers matching that directory, file, or keyword. Ignore results outside the filter scope.
+
+### 4. Highlight patterns
+
+Call out anything notable:
+- Files with an unusually high concentration of markers
+- Very old TODOs (if recognizable from surrounding context)
+- FIXMEs that reference specific bugs or issues
+
+**This is read-only. Do not modify any files.**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@allthingsclaude/blueprints",
-  "version": "0.3.0-beta.23",
+  "version": "0.3.0-beta.25",
   "description": "Claude Code commands and agents for enhanced AI-assisted development workflows",
   "type": "module",
   "main": "dist/index.js",