@allthingsclaude/blueprints 0.3.0-beta.24 → 0.3.0-beta.26

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/agents/plan.md

@@ -323,7 +323,7 @@ Examples (assuming 2 plans already exist — `PLAN_00_INITIAL.md` and `PLAN_01_A
 
 ## Update Active Plan Tracker (MANDATORY)
 
-**This step is NOT optional.** After writing the plan file, you MUST create or update `{{STATE_FILE}}`. Other commands (`/auto`, `/kickoff`, `/implement`, `/parallelize`) depend on this file to detect the active plan. If STATE.md is missing, the entire workflow breaks.
+**This step is NOT optional.** After writing the plan file, you MUST create or update `{{STATE_FILE}}`. Other commands (`/autopilot`, `/kickoff`, `/implement`, `/parallelize`) depend on this file to detect the active plan. If STATE.md is missing, the entire workflow breaks.
 
 ```bash
 mkdir -p $(dirname {{STATE_FILE}})

package/content/agents/showcase.md

@@ -326,7 +326,7 @@ The hero is the first impression — make it count.
 
 ## Integration with Other Commands
 
-When called from `/auto`, `/implement`, or `/parallelize`:
+When called from `/autopilot`, `/implement`, or `/parallelize`:
 - This agent handles any plan task tagged as "landing page", "homepage design", "marketing page", or similar
 - It replaces the generic implement agent for these specific tasks
 - After completion, control returns to the calling workflow

package/content/commands/{auto.md → autopilot.md}

@@ -4,7 +4,7 @@ argument-hint: [--full] [feature description or plan name]
 author: "@markoradak"
 ---
 
-# Auto Mode
+# Autopilot Mode
 
 Full autonomous development loop. I'll take it from idea to committed code on a feature branch.
 
@@ -34,9 +34,9 @@ $ARGUMENTS
 
 ---
 
-## Auto Mode Protocol
+## Autopilot Protocol
 
-You are now in **AUTO MODE** — a full development loop that orchestrates the entire workflow from idea to committed code. Follow these steps precisely and in order.
+You are now in **AUTOPILOT MODE** — a full development loop that orchestrates the entire workflow from idea to committed code. Follow these steps precisely and in order.
 
 ### Step 0: Parse Arguments
 
@@ -296,7 +296,7 @@ Review security report:
 After everything is done (or stopped), provide a final summary:
 
 ```markdown
-**Auto Mode Complete**
+**Autopilot Complete**
 
 **Branch**: `feat/{name}`
 **Plan**: {NAME}
@@ -319,14 +319,14 @@ After everything is done (or stopped), provide a final summary:
 **Next Steps**:
 - Review changes: `git log main..feat/{name} --oneline`
 - Create PR when ready: `gh pr create`
-- Or continue working: `/auto` (will resume from STATE.md)
+- Or continue working: `/autopilot` (will resume from STATE.md)
 ```
 
 ---
 
 ## Commit Checkpoint Rules
 
-Auto mode commits **early and often** using the commit agent (`subagent_type="commit"`). The commit agent determines the right prefix (`feat:`, `fix:`, `refactor:`, `chore:`, `docs:`, etc.) based on the changes.
+Autopilot commits **early and often** using the commit agent (`subagent_type="commit"`). The commit agent determines the right prefix (`feat:`, `fix:`, `refactor:`, `chore:`, `docs:`, etc.) based on the changes.
 
 **When to commit:**
 - After bootstrap scaffolding is created
@@ -395,7 +395,7 @@ Auto mode commits **early and often** using the commit agent (`subagent_type="co
 - Mark all tasks as `✅` in the plan's task tables
 - Set `**Status**` to `✅ Complete`
 
-If `/auto` is interrupted or paused, ensure STATE.md reflects where it stopped so the next `/auto` run can resume correctly. Plan document checkboxes are updated by the implement/parallelize agents.
+If `/autopilot` is interrupted or paused, ensure STATE.md reflects where it stopped so the next `/autopilot` run can resume correctly. Plan document checkboxes are updated by the implement/parallelize agents.
 
 ### Keep the User Informed
 - Brief status updates between major steps

package/content/commands/brainstorm.md

@@ -26,7 +26,7 @@ Before brainstorming, quickly assess the current project:
 **Is this an empty/new project?** If there are fewer than 5 source files and no meaningful project configuration, this is likely a **new project**. In that case:
 - Mention to the user that this looks like a new project and brainstorming is a great starting point
 - The brainstorm should focus heavily on **tech stack decisions** (see Step 1 below)
-- When brainstorming is complete, suggest `/auto` which will handle planning, bootstrapping, and implementation end-to-end
+- When brainstorming is complete, suggest `/autopilot` which will handle planning, bootstrapping, and implementation end-to-end
 
 ## Brainstorming Framework
 
@@ -112,7 +112,7 @@ Throughout brainstorming, actively use the `/critique`, `/verify`, and `/challen
 
 If the user shares images during brainstorming (screenshots, mockups, design references, wireframes, inspiration), **track their file paths**. These are critical for downstream plan creation.
 
-When brainstorming is complete and you suggest `/plan` or `/auto`:
+When brainstorming is complete and you suggest `/plan` or `/autopilot`:
 - Mention the collected image paths in your handoff so the plan agent copies them to `{{TASKS_DIR}}/references/`
 - If images were shared via the conversation (e.g., user provided a file path or pasted a screenshot), note them explicitly in the brainstorm summary
 
@@ -140,14 +140,14 @@ Once we've thoroughly explored the problem space, settled on a tech stack, and c
 | Command | What it does |
 |---|---|
 | `/bootstrap {NAME}` | Generate a plan + bootstrap script to scaffold the project. Good when you want to review the scaffolding before building. |
-| `/auto {NAME}` | Full autonomous loop — planning, bootstrapping, implementation, and commit. Good when you want to go hands-off. |
+| `/autopilot {NAME}` | Full autonomous loop — planning, bootstrapping, implementation, and commit. Good when you want to go hands-off. |
 
 **For existing projects:**
 
 | Command | What it does |
 |---|---|
 | `/plan {NAME}` | Capture brainstorming findings into a structured implementation plan. Good when you want to review before implementing. |
-| `/auto {NAME}` | Full autonomous loop — planning, implementation, validation, and commit. Good when you want to go hands-off. |
+| `/autopilot {NAME}` | Full autonomous loop — planning, implementation, validation, and commit. Good when you want to go hands-off. |
 
 Always present the relevant options and let the user choose how they want to proceed.
 

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/showcase.md

@@ -49,7 +49,7 @@ If no references are provided, the agent will ask you to choose a style directio
 
 ### How It Integrates
 
-- In `/auto` or `/implement` — if the plan includes a landing page task, the showcase agent is used instead of the generic implement agent for that task
+- In `/autopilot` or `/implement` — if the plan includes a landing page task, the showcase agent is used instead of the generic implement agent for that task
 - In `/parallelize` — landing page work can be a dedicated stream using the showcase agent
 - Standalone — run `/showcase` directly to design a landing page from scratch or redesign an existing one
 

package/package.json

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