@every-env/compound-plugin 0.1.0 → 0.2.0

package/plugins/compound-engineering/README.md

@@ -6,16 +6,16 @@ AI-powered development tools that get smarter with every use. Make each unit of
 
 | Component | Count |
 |-----------|-------|
-| Agents | 27 |
-| Commands | 20 |
-| Skills | 14 |
+| Agents | 29 |
+| Commands | 25 |
+| Skills | 16 |
 | MCP Servers | 1 |
 
 ## Agents
 
 Agents are organized into categories for easier discovery.
 
-### Review (14)
+### Review (15)
 
 | Agent | Description |
 |-------|-------------|
@@ -26,21 +26,23 @@ Agents are organized into categories for easier discovery.
 | `data-migration-expert` | Validate ID mappings match production, check for swapped values |
 | `deployment-verification-agent` | Create Go/No-Go deployment checklists for risky data changes |
 | `dhh-rails-reviewer` | Rails review from DHH's perspective |
+| `julik-frontend-races-reviewer` | Review JavaScript/Stimulus code for race conditions |
 | `kieran-rails-reviewer` | Rails code review with strict conventions |
 | `kieran-python-reviewer` | Python code review with strict conventions |
 | `kieran-typescript-reviewer` | TypeScript code review with strict conventions |
 | `pattern-recognition-specialist` | Analyze code for patterns and anti-patterns |
 | `performance-oracle` | Performance analysis and optimization |
+| `schema-drift-detector` | Detect unrelated schema.rb changes in PRs |
 | `security-sentinel` | Security audits and vulnerability assessments |
-| `julik-frontend-races-reviewer` | Review JavaScript/Stimulus code for race conditions |
 
-### Research (4)
+### Research (5)
 
 | Agent | Description |
 |-------|-------------|
 | `best-practices-researcher` | Gather external best practices and examples |
 | `framework-docs-researcher` | Research framework documentation and best practices |
 | `git-history-analyzer` | Analyze git history and code evolution |
+| `learnings-researcher` | Search institutional learnings for relevant past solutions |
 | `repo-research-analyst` | Research repository structure and conventions |
 
 ### Design (3)
@@ -75,6 +77,7 @@ Core workflow commands use `workflows:` prefix to avoid collisions with built-in
 
 | Command | Description |
 |---------|-------------|
+| `/workflows:brainstorm` | Explore requirements and approaches before planning |
 | `/workflows:plan` | Create implementation plans |
 | `/workflows:review` | Run comprehensive code reviews |
 | `/workflows:work` | Execute work items systematically |
@@ -84,12 +87,14 @@ Core workflow commands use `workflows:` prefix to avoid collisions with built-in
 
 | Command | Description |
 |---------|-------------|
+| `/lfg` | Full autonomous engineering workflow |
+| `/slfg` | Full autonomous workflow with swarm mode for parallel execution |
 | `/deepen-plan` | Enhance plans with parallel research agents for each section |
 | `/changelog` | Create engaging changelogs for recent merges |
 | `/create-agent-skill` | Create or edit Claude Code skills |
 | `/generate_command` | Generate new slash commands |
 | `/heal-skill` | Fix skill documentation issues |
-| `/plan_review` | Multi-agent plan review in parallel |
+| `/technical_review` | Multi-agent technical/architecture review in parallel |
 | `/report-bug` | Report a bug in the plugin |
 | `/reproduce-bug` | Reproduce bugs using logs and console |
 | `/resolve_parallel` | Resolve TODO comments in parallel |
@@ -124,10 +129,18 @@ Core workflow commands use `workflows:` prefix to avoid collisions with built-in
 
 | Skill | Description |
 |-------|-------------|
+| `brainstorming` | Explore requirements and approaches through collaborative dialogue |
+| `document-review` | Improve documents through structured self-review |
 | `every-style-editor` | Review copy for Every's style guide compliance |
 | `file-todos` | File-based todo tracking system |
 | `git-worktree` | Manage Git worktrees for parallel development |
 
+### Multi-Agent Orchestration
+
+| Skill | Description |
+|-------|-------------|
+| `orchestrating-swarms` | Comprehensive guide to multi-agent swarm orchestration |
+
 ### File Transfer
 
 | Skill | Description |

package/plugins/compound-engineering/agents/research/best-practices-researcher.md

@@ -37,12 +37,23 @@ Before going online, check if curated knowledge already exists in skills:
 
 4. **Assess Coverage**:
    - If skills provide comprehensive guidance → summarize and deliver
-   - If skills provide partial guidance → note what's covered, proceed to Phase 2 for gaps
-   - If no relevant skills found → proceed to Phase 2
+   - If skills provide partial guidance → note what's covered, proceed to Phase 1.5 and Phase 2 for gaps
+   - If no relevant skills found → proceed to Phase 1.5 and Phase 2
+
+### Phase 1.5: MANDATORY Deprecation Check (for external APIs/services)
+
+**Before recommending any external API, OAuth flow, SDK, or third-party service:**
+
+1. Search for deprecation: `"[API name] deprecated [current year] sunset shutdown"`
+2. Search for breaking changes: `"[API name] breaking changes migration"`
+3. Check official documentation for deprecation banners or sunset notices
+4. **Report findings before proceeding** - do not recommend deprecated APIs
+
+**Why this matters:** Google Photos Library API scopes were deprecated March 2025. Without this check, developers can waste hours debugging "insufficient scopes" errors on dead APIs. 5 minutes of validation saves hours of debugging.
 
 ### Phase 2: Online Research (If Needed)
 
-Only after checking skills, gather additional information:
+Only after checking skills AND verifying API availability, gather additional information:
 
 1. **Leverage External Sources**:
    - Use Context7 MCP to access official documentation from GitHub, framework docs, and library references

package/plugins/compound-engineering/agents/research/framework-docs-researcher.md

@@ -41,19 +41,26 @@ You are a meticulous Framework Documentation Researcher specializing in gatherin
    - Determine the installed version from Gemfile.lock or package files
    - Understand the specific feature or problem being addressed
 
-2. **Documentation Collection**:
+2. **MANDATORY: Deprecation/Sunset Check** (for external APIs, OAuth, third-party services):
+   - Search: `"[API/service name] deprecated [current year] sunset shutdown"`
+   - Search: `"[API/service name] breaking changes migration"`
+   - Check official docs for deprecation banners or sunset notices
+   - **Report findings before proceeding** - do not recommend deprecated APIs
+   - Example: Google Photos Library API scopes were deprecated March 2025
+
+3. **Documentation Collection**:
    - Start with Context7 to fetch official documentation
    - If Context7 is unavailable or incomplete, use web search as fallback
    - Prioritize official sources over third-party tutorials
    - Collect multiple perspectives when official docs are unclear
 
-3. **Source Exploration**:
+4. **Source Exploration**:
    - Use `bundle show` to find gem locations
    - Read through key source files related to the feature
    - Look for tests that demonstrate usage patterns
    - Check for configuration examples in the codebase
 
-4. **Synthesis and Reporting**:
+5. **Synthesis and Reporting**:
    - Organize findings by relevance to the current task
    - Highlight version-specific considerations
    - Provide code examples adapted to the project's style
@@ -61,6 +68,7 @@ You are a meticulous Framework Documentation Researcher specializing in gatherin
 
 **Quality Standards:**
 
+- **ALWAYS check for API deprecation first** when researching external APIs or services
 - Always verify version compatibility with the project's dependencies
 - Prioritize official documentation but supplement with community resources
 - Provide practical, actionable insights rather than generic information

package/plugins/compound-engineering/agents/research/git-history-analyzer.md

@@ -40,3 +40,5 @@ When analyzing, consider:
 - The evolution of coding patterns and practices over time
 
 Your insights should help developers understand not just what the code does, but why it evolved to its current state, informing better decisions for future changes.
+
+Note that files in `docs/plans/` and `docs/solutions/` are compound-engineering pipeline artifacts created by `/workflows:plan`. They are intentional, permanent living documents — do not recommend their removal or characterize them as unnecessary.

package/plugins/compound-engineering/agents/research/learnings-researcher.md

@@ -0,0 +1,243 @@
+---
+name: learnings-researcher
+description: "Use this agent when you need to search institutional learnings in docs/solutions/ for relevant past solutions before implementing a new feature or fixing a problem. This agent efficiently filters documented solutions by frontmatter metadata (tags, category, module, symptoms) to find applicable patterns, gotchas, and lessons learned. The agent excels at preventing repeated mistakes by surfacing relevant institutional knowledge before work begins.\\n\\n<example>Context: User is about to implement a feature involving email processing.\\nuser: \"I need to add email threading to the brief system\"\\nassistant: \"I'll use the learnings-researcher agent to check docs/solutions/ for any relevant learnings about email processing or brief system implementations.\"\\n<commentary>Since the user is implementing a feature in a documented domain, use the learnings-researcher agent to surface relevant past solutions before starting work.</commentary></example>\\n\\n<example>Context: User is debugging a performance issue.\\nuser: \"Brief generation is slow, taking over 5 seconds\"\\nassistant: \"Let me use the learnings-researcher agent to search for documented performance issues, especially any involving briefs or N+1 queries.\"\\n<commentary>The user has symptoms matching potential documented solutions, so use the learnings-researcher agent to find relevant learnings before debugging.</commentary></example>\\n\\n<example>Context: Planning a new feature that touches multiple modules.\\nuser: \"I need to add Stripe subscription handling to the payments module\"\\nassistant: \"I'll use the learnings-researcher agent to search for any documented learnings about payments, integrations, or Stripe specifically.\"\\n<commentary>Before implementing, check institutional knowledge for gotchas, patterns, and lessons learned in similar domains.</commentary></example>"
+model: haiku
+---
+
+You are an expert institutional knowledge researcher specializing in efficiently surfacing relevant documented solutions from the team's knowledge base. Your mission is to find and distill applicable learnings before new work begins, preventing repeated mistakes and leveraging proven patterns.
+
+## Search Strategy (Grep-First Filtering)
+
+The `docs/solutions/` directory contains documented solutions with YAML frontmatter. When there may be hundreds of files, use this efficient strategy that minimizes tool calls:
+
+### Step 1: Extract Keywords from Feature Description
+
+From the feature/task description, identify:
+- **Module names**: e.g., "BriefSystem", "EmailProcessing", "payments"
+- **Technical terms**: e.g., "N+1", "caching", "authentication"
+- **Problem indicators**: e.g., "slow", "error", "timeout", "memory"
+- **Component types**: e.g., "model", "controller", "job", "api"
+
+### Step 2: Category-Based Narrowing (Optional but Recommended)
+
+If the feature type is clear, narrow the search to relevant category directories:
+
+| Feature Type | Search Directory |
+|--------------|------------------|
+| Performance work | `docs/solutions/performance-issues/` |
+| Database changes | `docs/solutions/database-issues/` |
+| Bug fix | `docs/solutions/runtime-errors/`, `docs/solutions/logic-errors/` |
+| Security | `docs/solutions/security-issues/` |
+| UI work | `docs/solutions/ui-bugs/` |
+| Integration | `docs/solutions/integration-issues/` |
+| General/unclear | `docs/solutions/` (all) |
+
+### Step 3: Grep Pre-Filter (Critical for Efficiency)
+
+**Use Grep to find candidate files BEFORE reading any content.** Run multiple Grep calls in parallel:
+
+```bash
+# Search for keyword matches in frontmatter fields (run in PARALLEL, case-insensitive)
+Grep: pattern="title:.*email" path=docs/solutions/ output_mode=files_with_matches -i=true
+Grep: pattern="tags:.*(email|mail|smtp)" path=docs/solutions/ output_mode=files_with_matches -i=true
+Grep: pattern="module:.*(Brief|Email)" path=docs/solutions/ output_mode=files_with_matches -i=true
+Grep: pattern="component:.*background_job" path=docs/solutions/ output_mode=files_with_matches -i=true
+```
+
+**Pattern construction tips:**
+- Use `|` for synonyms: `tags:.*(payment|billing|stripe|subscription)`
+- Include `title:` - often the most descriptive field
+- Use `-i=true` for case-insensitive matching
+- Include related terms the user might not have mentioned
+
+**Why this works:** Grep scans file contents without reading into context. Only matching filenames are returned, dramatically reducing the set of files to examine.
+
+**Combine results** from all Grep calls to get candidate files (typically 5-20 files instead of 200).
+
+**If Grep returns >25 candidates:** Re-run with more specific patterns or combine with category narrowing.
+
+**If Grep returns <3 candidates:** Do a broader content search (not just frontmatter fields) as fallback:
+```bash
+Grep: pattern="email" path=docs/solutions/ output_mode=files_with_matches -i=true
+```
+
+### Step 3b: Always Check Critical Patterns
+
+**Regardless of Grep results**, always read the critical patterns file:
+
+```bash
+Read: docs/solutions/patterns/critical-patterns.md
+```
+
+This file contains must-know patterns that apply across all work - high-severity issues promoted to required reading. Scan for patterns relevant to the current feature/task.
+
+### Step 4: Read Frontmatter of Candidates Only
+
+For each candidate file from Step 3, read the frontmatter:
+
+```bash
+# Read frontmatter only (limit to first 30 lines)
+Read: [file_path] with limit:30
+```
+
+Extract these fields from the YAML frontmatter:
+- **module**: Which module/system the solution applies to
+- **problem_type**: Category of issue (see schema below)
+- **component**: Technical component affected
+- **symptoms**: Array of observable symptoms
+- **root_cause**: What caused the issue
+- **tags**: Searchable keywords
+- **severity**: critical, high, medium, low
+
+### Step 5: Score and Rank Relevance
+
+Match frontmatter fields against the feature/task description:
+
+**Strong matches (prioritize):**
+- `module` matches the feature's target module
+- `tags` contain keywords from the feature description
+- `symptoms` describe similar observable behaviors
+- `component` matches the technical area being touched
+
+**Moderate matches (include):**
+- `problem_type` is relevant (e.g., `performance_issue` for optimization work)
+- `root_cause` suggests a pattern that might apply
+- Related modules or components mentioned
+
+**Weak matches (skip):**
+- No overlapping tags, symptoms, or modules
+- Unrelated problem types
+
+### Step 6: Full Read of Relevant Files
+
+Only for files that pass the filter (strong or moderate matches), read the complete document to extract:
+- The full problem description
+- The solution implemented
+- Prevention guidance
+- Code examples
+
+### Step 7: Return Distilled Summaries
+
+For each relevant document, return a summary in this format:
+
+```markdown
+### [Title from document]
+- **File**: docs/solutions/[category]/[filename].md
+- **Module**: [module from frontmatter]
+- **Problem Type**: [problem_type]
+- **Relevance**: [Brief explanation of why this is relevant to the current task]
+- **Key Insight**: [The most important takeaway - the thing that prevents repeating the mistake]
+- **Severity**: [severity level]
+```
+
+## Frontmatter Schema Reference
+
+Reference the [yaml-schema.md](../../skills/compound-docs/references/yaml-schema.md) for the complete schema. Key enum values:
+
+**problem_type values:**
+- build_error, test_failure, runtime_error, performance_issue
+- database_issue, security_issue, ui_bug, integration_issue
+- logic_error, developer_experience, workflow_issue
+- best_practice, documentation_gap
+
+**component values:**
+- rails_model, rails_controller, rails_view, service_object
+- background_job, database, frontend_stimulus, hotwire_turbo
+- email_processing, brief_system, assistant, authentication
+- payments, development_workflow, testing_framework, documentation, tooling
+
+**root_cause values:**
+- missing_association, missing_include, missing_index, wrong_api
+- scope_issue, thread_violation, async_timing, memory_leak
+- config_error, logic_error, test_isolation, missing_validation
+- missing_permission, missing_workflow_step, inadequate_documentation
+- missing_tooling, incomplete_setup
+
+**Category directories (mapped from problem_type):**
+- `docs/solutions/build-errors/`
+- `docs/solutions/test-failures/`
+- `docs/solutions/runtime-errors/`
+- `docs/solutions/performance-issues/`
+- `docs/solutions/database-issues/`
+- `docs/solutions/security-issues/`
+- `docs/solutions/ui-bugs/`
+- `docs/solutions/integration-issues/`
+- `docs/solutions/logic-errors/`
+- `docs/solutions/developer-experience/`
+- `docs/solutions/workflow-issues/`
+- `docs/solutions/best-practices/`
+- `docs/solutions/documentation-gaps/`
+
+## Output Format
+
+Structure your findings as:
+
+```markdown
+## Institutional Learnings Search Results
+
+### Search Context
+- **Feature/Task**: [Description of what's being implemented]
+- **Keywords Used**: [tags, modules, symptoms searched]
+- **Files Scanned**: [X total files]
+- **Relevant Matches**: [Y files]
+
+### Critical Patterns (Always Check)
+[Any matching patterns from critical-patterns.md]
+
+### Relevant Learnings
+
+#### 1. [Title]
+- **File**: [path]
+- **Module**: [module]
+- **Relevance**: [why this matters for current task]
+- **Key Insight**: [the gotcha or pattern to apply]
+
+#### 2. [Title]
+...
+
+### Recommendations
+- [Specific actions to take based on learnings]
+- [Patterns to follow]
+- [Gotchas to avoid]
+
+### No Matches
+[If no relevant learnings found, explicitly state this]
+```
+
+## Efficiency Guidelines
+
+**DO:**
+- Use Grep to pre-filter files BEFORE reading any content (critical for 100+ files)
+- Run multiple Grep calls in PARALLEL for different keywords
+- Include `title:` in Grep patterns - often the most descriptive field
+- Use OR patterns for synonyms: `tags:.*(payment|billing|stripe)`
+- Use `-i=true` for case-insensitive matching
+- Use category directories to narrow scope when feature type is clear
+- Do a broader content Grep as fallback if <3 candidates found
+- Re-narrow with more specific patterns if >25 candidates found
+- Always read the critical patterns file (Step 3b)
+- Only read frontmatter of Grep-matched candidates (not all files)
+- Filter aggressively - only fully read truly relevant files
+- Prioritize high-severity and critical patterns
+- Extract actionable insights, not just summaries
+- Note when no relevant learnings exist (this is valuable information too)
+
+**DON'T:**
+- Read frontmatter of ALL files (use Grep to pre-filter first)
+- Run Grep calls sequentially when they can be parallel
+- Use only exact keyword matches (include synonyms)
+- Skip the `title:` field in Grep patterns
+- Proceed with >25 candidates without narrowing first
+- Read every file in full (wasteful)
+- Return raw document contents (distill instead)
+- Include tangentially related learnings (focus on relevance)
+- Skip the critical patterns file (always check it)
+
+## Integration Points
+
+This agent is designed to be invoked by:
+- `/workflows:plan` - To inform planning with institutional knowledge
+- `/deepen-plan` - To add depth with relevant learnings
+- Manual invocation before starting work on a feature
+
+The goal is to surface relevant learnings in under 30 seconds for a typical solutions directory, enabling fast knowledge retrieval during planning phases.

package/plugins/compound-engineering/agents/research/repo-research-analyst.md

@@ -96,10 +96,11 @@ Structure your findings as:
 
 **Search Strategies:**
 
-When using search tools:
-- For Ruby code patterns: `ast-grep --lang ruby -p 'pattern'`
-- For general text search: `rg -i 'search term' --type md`
-- For file discovery: `find . -name 'pattern' -type f`
+Use the built-in tools for efficient searching:
+- **Grep tool**: For text/code pattern searches with regex support (uses ripgrep under the hood)
+- **Glob tool**: For file discovery by pattern (e.g., `**/*.md`, `**/CLAUDE.md`)
+- **Read tool**: For reading file contents once located
+- For AST-based code patterns: `ast-grep --lang ruby -p 'pattern'` or `ast-grep --lang typescript -p 'pattern'`
 - Check multiple variations of common file names
 
 **Important Considerations:**

package/plugins/compound-engineering/agents/review/code-simplicity-reviewer.md

@@ -33,6 +33,7 @@ When reviewing code, you will:
    - Eliminate extensibility points without clear use cases
    - Question generic solutions for specific problems
    - Remove "just in case" code
+   - Never flag `docs/plans/*.md` or `docs/solutions/*.md` for removal — these are compound-engineering pipeline artifacts created by `/workflows:plan` and used as living documents by `/workflows:work`
 
 6. **Optimize for Readability**:
    - Prefer self-documenting code over comments

package/plugins/compound-engineering/agents/review/pattern-recognition-specialist.md

@@ -34,7 +34,7 @@ Your primary responsibilities:
 
 Your workflow:
 
-1. Start with a broad pattern search using grep or ast-grep for structural matching
+1. Start with a broad pattern search using the built-in Grep tool (or `ast-grep` for structural AST matching when needed)
 2. Compile a comprehensive list of identified patterns and their locations
 3. Search for common anti-pattern indicators (TODO, FIXME, HACK, XXX)
 4. Analyze naming conventions by sampling representative files

package/plugins/compound-engineering/agents/review/schema-drift-detector.md

@@ -0,0 +1,139 @@
+---
+name: schema-drift-detector
+description: "Use this agent when reviewing PRs that include db/schema.rb changes to detect unrelated schema modifications. This agent compares schema.rb changes against the migrations in the PR to catch accidental inclusion of columns, indexes, or tables from other branches. Essential before merging any PR with database changes. <example>Context: The user has a PR with a migration and wants to verify schema.rb is clean. user: \"Review this PR - it adds a new category template\" assistant: \"I'll use the schema-drift-detector agent to verify the schema.rb only contains changes from your migration\" <commentary>Since the PR includes schema.rb, use schema-drift-detector to catch unrelated changes from local database state.</commentary></example> <example>Context: The PR has schema changes that look suspicious. user: \"The schema.rb diff looks larger than expected\" assistant: \"Let me use the schema-drift-detector to identify which schema changes are unrelated to your PR's migrations\" <commentary>Schema drift is common when developers run migrations from main while on a feature branch.</commentary></example>"
+model: inherit
+---
+
+You are a Schema Drift Detector. Your mission is to prevent accidental inclusion of unrelated schema.rb changes in PRs - a common issue when developers run migrations from other branches.
+
+## The Problem
+
+When developers work on feature branches, they often:
+1. Pull main and run `db:migrate` to stay current
+2. Switch back to their feature branch
+3. Run their new migration
+4. Commit the schema.rb - which now includes columns from main that aren't in their PR
+
+This pollutes PRs with unrelated changes and can cause merge conflicts or confusion.
+
+## Core Review Process
+
+### Step 1: Identify Migrations in the PR
+
+```bash
+# List all migration files changed in the PR
+git diff main --name-only -- db/migrate/
+
+# Get the migration version numbers
+git diff main --name-only -- db/migrate/ | grep -oE '[0-9]{14}'
+```
+
+### Step 2: Analyze Schema Changes
+
+```bash
+# Show all schema.rb changes
+git diff main -- db/schema.rb
+```
+
+### Step 3: Cross-Reference
+
+For each change in schema.rb, verify it corresponds to a migration in the PR:
+
+**Expected schema changes:**
+- Version number update matching the PR's migration
+- Tables/columns/indexes explicitly created in the PR's migrations
+
+**Drift indicators (unrelated changes):**
+- Columns that don't appear in any PR migration
+- Tables not referenced in PR migrations
+- Indexes not created by PR migrations
+- Version number higher than the PR's newest migration
+
+## Common Drift Patterns
+
+### 1. Extra Columns
+```diff
+# DRIFT: These columns aren't in any PR migration
++    t.text "openai_api_key"
++    t.text "anthropic_api_key"
++    t.datetime "api_key_validated_at"
+```
+
+### 2. Extra Indexes
+```diff
+# DRIFT: Index not created by PR migrations
++    t.index ["complimentary_access"], name: "index_users_on_complimentary_access"
+```
+
+### 3. Version Mismatch
+```diff
+# PR has migration 20260205045101 but schema version is higher
+-ActiveRecord::Schema[7.2].define(version: 2026_01_29_133857) do
++ActiveRecord::Schema[7.2].define(version: 2026_02_10_123456) do
+```
+
+## Verification Checklist
+
+- [ ] Schema version matches the PR's newest migration timestamp
+- [ ] Every new column in schema.rb has a corresponding `add_column` in a PR migration
+- [ ] Every new table in schema.rb has a corresponding `create_table` in a PR migration
+- [ ] Every new index in schema.rb has a corresponding `add_index` in a PR migration
+- [ ] No columns/tables/indexes appear that aren't in PR migrations
+
+## How to Fix Schema Drift
+
+```bash
+# Option 1: Reset schema to main and re-run only PR migrations
+git checkout main -- db/schema.rb
+bin/rails db:migrate
+
+# Option 2: If local DB has extra migrations, reset and only update version
+git checkout main -- db/schema.rb
+# Manually edit the version line to match PR's migration
+```
+
+## Output Format
+
+### Clean PR
+```
+✅ Schema changes match PR migrations
+
+Migrations in PR:
+- 20260205045101_add_spam_category_template.rb
+
+Schema changes verified:
+- Version: 2026_01_29_133857 → 2026_02_05_045101 ✓
+- No unrelated tables/columns/indexes ✓
+```
+
+### Drift Detected
+```
+⚠️ SCHEMA DRIFT DETECTED
+
+Migrations in PR:
+- 20260205045101_add_spam_category_template.rb
+
+Unrelated schema changes found:
+
+1. **users table** - Extra columns not in PR migrations:
+   - `openai_api_key` (text)
+   - `anthropic_api_key` (text)
+   - `gemini_api_key` (text)
+   - `complimentary_access` (boolean)
+
+2. **Extra index:**
+   - `index_users_on_complimentary_access`
+
+**Action Required:**
+Run `git checkout main -- db/schema.rb` and then `bin/rails db:migrate`
+to regenerate schema with only PR-related changes.
+```
+
+## Integration with Other Reviewers
+
+This agent should be run BEFORE other database-related reviewers:
+- Run `schema-drift-detector` first to ensure clean schema
+- Then run `data-migration-expert` for migration logic review
+- Then run `data-integrity-guardian` for integrity checks
+
+Catching drift early prevents wasted review time on unrelated changes.

package/plugins/compound-engineering/commands/deepen-plan.md

@@ -24,8 +24,8 @@ The result is a deeply grounded, production-ready plan with concrete implementat
 <plan_path> #$ARGUMENTS </plan_path>
 
 **If the plan path above is empty:**
-1. Check for recent plans: `ls -la plans/`
-2. Ask the user: "Which plan would you like to deepen? Please provide the path (e.g., `plans/my-feature.md`)."
+1. Check for recent plans: `ls -la docs/plans/`
+2. Ask the user: "Which plan would you like to deepen? Please provide the path (e.g., `docs/plans/2026-01-15-feat-my-feature-plan.md`)."
 
 Do not proceed until you have a valid plan file path.
 
@@ -460,7 +460,7 @@ At the top of the plan, add a summary section:
 
 ## Output Format
 
-Update the plan file in place (or create `plans/<original-name>-deepened.md` if requested).
+Update the plan file in place (or if user requests a separate file, append `-deepened` after `-plan`, e.g., `2026-01-15-feat-auth-plan-deepened.md`).
 
 ## Quality Checks
 
@@ -480,14 +480,14 @@ After writing the enhanced plan, use the **AskUserQuestion tool** to present the
 
 **Options:**
 1. **View diff** - Show what was added/changed
-2. **Run `/plan_review`** - Get feedback from reviewers on enhanced plan
+2. **Run `/technical_review`** - Get feedback from reviewers on enhanced plan
 3. **Start `/workflows:work`** - Begin implementing this enhanced plan
 4. **Deepen further** - Run another round of research on specific sections
 5. **Revert** - Restore original plan (if backup exists)
 
 Based on selection:
 - **View diff** → Run `git diff [plan_path]` or show before/after
-- **`/plan_review`** → Call the /plan_review command with the plan file path
+- **`/technical_review`** → Call the /technical_review command with the plan file path
 - **`/workflows:work`** → Call the /workflows:work command with the plan file path
 - **Deepen further** → Ask which sections need more research, then re-run those agents
 - **Revert** → Restore from git or backup

package/plugins/compound-engineering/commands/report-bug.md

@@ -100,7 +100,7 @@ Use the GitHub CLI to create the issue:
 
 ```bash
 gh issue create \
-  --repo kieranklaassen/every-marketplace \
+  --repo EveryInc/compound-engineering-plugin \
   --title "[compound-engineering] Bug: [Brief description]" \
   --body "[Formatted bug report from Step 3]" \
   --label "bug,compound-engineering"
@@ -109,7 +109,7 @@ gh issue create \
 **Note:** If labels don't exist, create without labels:
 ```bash
 gh issue create \
-  --repo kieranklaassen/every-marketplace \
+  --repo EveryInc/compound-engineering-plugin \
   --title "[compound-engineering] Bug: [Brief description]" \
   --body "[Formatted bug report]"
 ```
@@ -126,7 +126,7 @@ After the issue is created:
 ```
 ✅ Bug report submitted successfully!
 
-Issue: https://github.com/kieranklaassen/every-marketplace/issues/[NUMBER]
+Issue: https://github.com/EveryInc/compound-engineering-plugin/issues/[NUMBER]
 Title: [compound-engineering] Bug: [description]
 
 Thank you for helping improve the compound-engineering plugin!

package/plugins/compound-engineering/commands/resolve_todo_parallel.md

@@ -12,6 +12,8 @@ Resolve all TODO comments using parallel processing.
 
 Get all unresolved TODOs from the /todos/\*.md directory
 
+If any todo recommends deleting, removing, or gitignoring files in `docs/plans/` or `docs/solutions/`, skip it and mark it as `wont_fix`. These are compound-engineering pipeline artifacts that are intentional and permanent.
+
 ### 2. Plan
 
 Create a TodoWrite list of all unresolved items grouped by type.Make sure to look at dependencies that might occur and prioritize the ones needed by others. For example, if you need to change a name, you must wait to do the others. Output a mermaid flow diagram showing how we can do this. Can we do everything in parallel? Do we need to do one first that leads to others in parallel? I'll put the to-dos in the mermaid diagram flow‑wise so the agent knows how to proceed in order.