@every-env/compound-plugin 0.1.1 → 0.2.0

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

@@ -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/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.

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

@@ -0,0 +1,31 @@
+---
+name: slfg
+description: Full autonomous engineering workflow using swarm mode for parallel execution
+argument-hint: "[feature description]"
+---
+
+Swarm-enabled LFG. Run these steps in order, parallelizing where indicated.
+
+## Sequential Phase
+
+1. `/ralph-wiggum:ralph-loop "finish all slash commands" --completion-promise "DONE"`
+2. `/workflows:plan $ARGUMENTS`
+3. `/compound-engineering:deepen-plan`
+4. `/workflows:work` — **Use swarm mode**: Make a Task list and launch an army of agent swarm subagents to build the plan
+
+## Parallel Phase
+
+After work completes, launch steps 5 and 6 as **parallel swarm agents** (both only need code to be written):
+
+5. `/workflows:review` — spawn as background Task agent
+6. `/compound-engineering:test-browser` — spawn as background Task agent
+
+Wait for both to complete before continuing.
+
+## Finalize Phase
+
+7. `/compound-engineering:resolve_todo_parallel` — resolve any findings from the review
+8. `/compound-engineering:feature-video` — record the final walkthrough and add to PR
+9. Output `<promise>DONE</promise>` when video is in PR
+
+Start with step 1 now.

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

@@ -0,0 +1,7 @@
+---
+name: technical_review
+description: Have multiple specialized agents review the technical approach and architecture of a plan in parallel
+argument-hint: "[plan file path or plan content]"
+---
+
+Have @agent-dhh-rails-reviewer @agent-kieran-rails-reviewer @agent-code-simplicity-reviewer review the technical approach in this plan in parallel.

package/plugins/compound-engineering/commands/workflows/brainstorm.md

@@ -85,10 +85,19 @@ Use **AskUserQuestion tool** to present next steps:
 **Question:** "Brainstorm captured. What would you like to do next?"
 
 **Options:**
-1. **Proceed to planning** - Run `/workflows:plan` (will auto-detect this brainstorm)
-2. **Refine design further** - Continue exploring
+1. **Review and refine** - Improve the document through structured self-review
+2. **Proceed to planning** - Run `/workflows:plan` (will auto-detect this brainstorm)
 3. **Done for now** - Return later
 
+**If user selects "Review and refine":**
+
+Load the `document-review` skill and apply it to the brainstorm document.
+
+When document-review returns "Review complete", present next steps:
+
+1. **Move to planning** - Continue to `/workflows:plan` with this document
+2. **Done for now** - Brainstorming complete. To start planning later: `/workflows:plan [document-path]`
+
 ## Output Summary
 
 When complete, display:

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

@@ -21,53 +21,83 @@ Captures problem solutions while context is fresh, creating structured documenta
 /workflows:compound [brief context]    # Provide additional context hint
 ```
 
-## Execution Strategy: Parallel Subagents
+## Execution Strategy: Two-Phase Orchestration
 
-This command launches multiple specialized subagents IN PARALLEL to maximize efficiency:
+<critical_requirement>
+**Only ONE file gets written - the final documentation.**
 
-### 1. **Context Analyzer** (Parallel)
+Phase 1 subagents return TEXT DATA to the orchestrator. They must NOT use Write, Edit, or create any files. Only the orchestrator (Phase 2) writes the final documentation file.
+</critical_requirement>
+
+### Phase 1: Parallel Research
+
+<parallel_tasks>
+
+Launch these subagents IN PARALLEL. Each returns text data to the orchestrator.
+
+#### 1. **Context Analyzer**
    - Extracts conversation history
    - Identifies problem type, component, symptoms
-   - Validates against CORA schema
+   - Validates against schema
    - Returns: YAML frontmatter skeleton
 
-### 2. **Solution Extractor** (Parallel)
+#### 2. **Solution Extractor**
    - Analyzes all investigation steps
    - Identifies root cause
    - Extracts working solution with code examples
    - Returns: Solution content block
 
-### 3. **Related Docs Finder** (Parallel)
+#### 3. **Related Docs Finder**
    - Searches `docs/solutions/` for related documentation
    - Identifies cross-references and links
    - Finds related GitHub issues
    - Returns: Links and relationships
 
-### 4. **Prevention Strategist** (Parallel)
+#### 4. **Prevention Strategist**
    - Develops prevention strategies
    - Creates best practices guidance
    - Generates test cases if applicable
    - Returns: Prevention/testing content
 
-### 5. **Category Classifier** (Parallel)
+#### 5. **Category Classifier**
    - Determines optimal `docs/solutions/` category
    - Validates category against schema
    - Suggests filename based on slug
    - Returns: Final path and filename
 
-### 6. **Documentation Writer** (Parallel)
-   - Assembles complete markdown file
-   - Validates YAML frontmatter
-   - Formats content for readability
-   - Creates the file in correct location
+</parallel_tasks>
+
+### Phase 2: Assembly & Write
+
+<sequential_tasks>
+
+**WAIT for all Phase 1 subagents to complete before proceeding.**
+
+The orchestrating agent (main conversation) performs these steps:
+
+1. Collect all text results from Phase 1 subagents
+2. Assemble complete markdown file from the collected pieces
+3. Validate YAML frontmatter against schema
+4. Create directory if needed: `mkdir -p docs/solutions/[category]/`
+5. Write the SINGLE final file: `docs/solutions/[category]/[filename].md`
 
-### 7. **Optional: Specialized Agent Invocation** (Post-Documentation)
-   Based on problem type detected, automatically invoke applicable agents:
-   - **performance_issue** → `performance-oracle`
-   - **security_issue** → `security-sentinel`
-   - **database_issue** → `data-integrity-guardian`
-   - **test_failure** → `cora-test-reviewer`
-   - Any code-heavy issue → `kieran-rails-reviewer` + `code-simplicity-reviewer`
+</sequential_tasks>
+
+### Phase 3: Optional Enhancement
+
+**WAIT for Phase 2 to complete before proceeding.**
+
+<parallel_tasks>
+
+Based on problem type, optionally invoke specialized agents to review the documentation:
+
+- **performance_issue** → `performance-oracle`
+- **security_issue** → `security-sentinel`
+- **database_issue** → `data-integrity-guardian`
+- **test_failure** → `cora-test-reviewer`
+- Any code-heavy issue → `kieran-rails-reviewer` + `code-simplicity-reviewer`
+
+</parallel_tasks>
 
 ## What It Captures
 
@@ -110,18 +140,25 @@ This command launches multiple specialized subagents IN PARALLEL to maximize eff
 - integration-issues/
 - logic-errors/
 
+## Common Mistakes to Avoid
+
+| ❌ Wrong | ✅ Correct |
+|----------|-----------|
+| Subagents write files like `context-analysis.md`, `solution-draft.md` | Subagents return text data; orchestrator writes one final file |
+| Research and assembly run in parallel | Research completes → then assembly runs |
+| Multiple files created during workflow | Single file: `docs/solutions/[category]/[filename].md` |
+
 ## Success Output
 
 ```
-✓ Parallel documentation generation complete
+✓ Documentation complete
 
-Primary Subagent Results:
+Subagent Results:
   ✓ Context Analyzer: Identified performance_issue in brief_system
-  ✓ Solution Extractor: Extracted 3 code fixes
-  ✓ Related Docs Finder: Found 2 related issues
-  ✓ Prevention Strategist: Generated test cases
-  ✓ Category Classifier: docs/solutions/performance-issues/
-  ✓ Documentation Writer: Created complete markdown
+  ✓ Solution Extractor: 3 code fixes
+  ✓ Related Docs Finder: 2 related issues
+  ✓ Prevention Strategist: Prevention strategies, test suggestions
+  ✓ Category Classifier: `performance-issues`
 
 Specialized Agent Reviews (Auto-Triggered):
   ✓ performance-oracle: Validated query optimization approach

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

@@ -498,25 +498,25 @@ After writing the plan file, use the **AskUserQuestion tool** to present these o
 **Options:**
 1. **Open plan in editor** - Open the plan file for review
 2. **Run `/deepen-plan`** - Enhance each section with parallel research agents (best practices, performance, UI)
-3. **Run `/plan_review`** - Get feedback from reviewers (DHH, Kieran, Simplicity)
-4. **Start `/workflows:work`** - Begin implementing this plan locally
-5. **Start `/workflows:work` on remote** - Begin implementing in Claude Code on the web (use `&` to run in background)
-6. **Create Issue** - Create issue in project tracker (GitHub/Linear)
-7. **Simplify** - Reduce detail level
+3. **Run `/technical_review`** - Technical feedback from code-focused reviewers (DHH, Kieran, Simplicity)
+4. **Review and refine** - Improve the document through structured self-review
+5. **Start `/workflows:work`** - Begin implementing this plan locally
+6. **Start `/workflows:work` on remote** - Begin implementing in Claude Code on the web (use `&` to run in background)
+7. **Create Issue** - Create issue in project tracker (GitHub/Linear)
 
 Based on selection:
 - **Open plan in editor** → Run `open docs/plans/<plan_filename>.md` to open the file in the user's default editor
 - **`/deepen-plan`** → Call the /deepen-plan command with the plan file path to enhance with research
-- **`/plan_review`** → Call the /plan_review command with the plan file path
+- **`/technical_review`** → Call the /technical_review command with the plan file path
+- **Review and refine** → Load `document-review` skill.
 - **`/workflows:work`** → Call the /workflows:work command with the plan file path
 - **`/workflows:work` on remote** → Run `/workflows:work docs/plans/<plan_filename>.md &` to start work in background for Claude Code web
 - **Create Issue** → See "Issue Creation" section below
-- **Simplify** → Ask "What should I simplify?" then regenerate simpler version
 - **Other** (automatically provided) → Accept free text for rework or specific changes
 
 **Note:** If running `/workflows:plan` with ultrathink enabled, automatically run `/deepen-plan` after plan creation for maximum depth and grounding.
 
-Loop back to options after Simplify or Other changes until user selects `/workflows:work` or `/plan_review`.
+Loop back to options after Simplify or Other changes until user selects `/workflows:work` or `/technical_review`.
 
 ## Issue Creation
 
@@ -546,6 +546,6 @@ When user selects "Create Issue", detect their project tracker from CLAUDE.md:
 
 5. **After creation:**
    - Display the issue URL
-   - Ask if they want to proceed to `/workflows:work` or `/plan_review`
+   - Ask if they want to proceed to `/workflows:work` or `/technical_review`
 
 NEVER CODE! Just research and write the plan.

package/plugins/compound-engineering/commands/workflows/review.md

@@ -48,6 +48,17 @@ Ensure that the code is ready for analysis (either in worktree or on current bra
 
 </task_list>
 
+#### Protected Artifacts
+
+<protected_artifacts>
+The following paths are compound-engineering pipeline artifacts and must never be flagged for deletion, removal, or gitignore by any review agent:
+
+- `docs/plans/*.md` — Plan files created by `/workflows:plan`. These are living documents that track implementation progress (checkboxes are checked off by `/workflows:work`).
+- `docs/solutions/*.md` — Solution documents created during the pipeline.
+
+If a review agent flags any file in these directories for cleanup or removal, discard that finding during synthesis. Do not create a todo for it.
+</protected_artifacts>
+
 #### Parallel Agents to review the PR:
 
 <parallel_tasks>
@@ -207,6 +218,7 @@ Remove duplicates, prioritize by severity and impact.
 <synthesis_tasks>
 
 - [ ] Collect findings from all parallel agents
+- [ ] Discard any findings that recommend deleting or gitignoring files in `docs/plans/` or `docs/solutions/` (see Protected Artifacts above)
 - [ ] Categorize by type: security, performance, architecture, quality, etc.
 - [ ] Assign severity levels: 🔴 CRITICAL (P1), 🟡 IMPORTANT (P2), 🔵 NICE-TO-HAVE (P3)
 - [ ] Remove duplicate or overlapping findings

package/plugins/compound-engineering/commands/workflows/work.md

@@ -181,7 +181,7 @@ This command takes a work document (plan, specification, or todo file) and execu
    - **kieran-rails-reviewer**: Verify Rails conventions (Rails projects)
    - **performance-oracle**: Check for performance issues
    - **security-sentinel**: Scan for security vulnerabilities
-   - **cora-test-reviewer**: Review test quality (CORA projects)
+   - **cora-test-reviewer**: Review test quality (Rails projects with comprehensive test coverage)
 
    Run reviewers in parallel with Task tool:
 
@@ -292,6 +292,76 @@ This command takes a work document (plan, specification, or todo file) and execu
 
 ---
 
+## Swarm Mode (Optional)
+
+For complex plans with multiple independent workstreams, enable swarm mode for parallel execution with coordinated agents.
+
+### When to Use Swarm Mode
+
+| Use Swarm Mode when... | Use Standard Mode when... |
+|------------------------|---------------------------|
+| Plan has 5+ independent tasks | Plan is linear/sequential |
+| Multiple specialists needed (review + test + implement) | Single-focus work |
+| Want maximum parallelism | Simpler mental model preferred |
+| Large feature with clear phases | Small feature or bug fix |
+
+### Enabling Swarm Mode
+
+To trigger swarm execution, say:
+
+> "Make a Task list and launch an army of agent swarm subagents to build the plan"
+
+Or explicitly request: "Use swarm mode for this work"
+
+### Swarm Workflow
+
+When swarm mode is enabled, the workflow changes:
+
+1. **Create Team**
+   ```
+   Teammate({ operation: "spawnTeam", team_name: "work-{timestamp}" })
+   ```
+
+2. **Create Task List with Dependencies**
+   - Parse plan into TaskCreate items
+   - Set up blockedBy relationships for sequential dependencies
+   - Independent tasks have no blockers (can run in parallel)
+
+3. **Spawn Specialized Teammates**
+   ```
+   Task({
+     team_name: "work-{timestamp}",
+     name: "implementer",
+     subagent_type: "general-purpose",
+     prompt: "Claim implementation tasks, execute, mark complete",
+     run_in_background: true
+   })
+
+   Task({
+     team_name: "work-{timestamp}",
+     name: "tester",
+     subagent_type: "general-purpose",
+     prompt: "Claim testing tasks, run tests, mark complete",
+     run_in_background: true
+   })
+   ```
+
+4. **Coordinate and Monitor**
+   - Team lead monitors task completion
+   - Spawn additional workers as phases unblock
+   - Handle plan approval if required
+
+5. **Cleanup**
+   ```
+   Teammate({ operation: "requestShutdown", target_agent_id: "implementer" })
+   Teammate({ operation: "requestShutdown", target_agent_id: "tester" })
+   Teammate({ operation: "cleanup" })
+   ```
+
+See the `orchestrating-swarms` skill for detailed swarm patterns and best practices.
+
+---
+
 ## Key Principles
 
 ### Start Fast, Execute Faster

package/plugins/compound-engineering/skills/compound-docs/SKILL.md

@@ -61,7 +61,7 @@ Extract from conversation history:
 
 **Required information:**
 
-- **Module name**: Which CORA module had the problem
+- **Module name**: Which module or component had the problem
 - **Symptom**: Observable error/behavior (exact error messages)
 - **Investigation attempts**: What didn't work and why
 - **Root cause**: Technical explanation of actual problem
@@ -249,7 +249,7 @@ But **NEVER auto-promote**. User decides via decision menu (Option 2).
 
 **Template for critical pattern addition:**
 
-When user selects Option 2 (Add to Required Reading), use the template from `assets/critical-pattern-template.md` to structure the pattern entry. Number it sequentially based on existing patterns in `docs/solutions/patterns/cora-critical-patterns.md`.
+When user selects Option 2 (Add to Required Reading), use the template from `assets/critical-pattern-template.md` to structure the pattern entry. Number it sequentially based on existing patterns in `docs/solutions/patterns/critical-patterns.md`.
 </step>
 
 </critical_sequence>
@@ -270,7 +270,7 @@ File created:
 
 What's next?
 1. Continue workflow (recommended)
-2. Add to Required Reading - Promote to critical patterns (cora-critical-patterns.md)
+2. Add to Required Reading - Promote to critical patterns (critical-patterns.md)
 3. Link related issues - Connect to similar problems
 4. Add to existing skill - Add to a learning skill (e.g., hotwire-native)
 5. Create new skill - Extract into new learning skill
@@ -295,7 +295,7 @@ User selects this when:
 Action:
 1. Extract pattern from the documentation
 2. Format as ❌ WRONG vs ✅ CORRECT with code examples
-3. Add to `docs/solutions/patterns/cora-critical-patterns.md`
+3. Add to `docs/solutions/patterns/critical-patterns.md`
 4. Add cross-reference back to this doc
 5. Confirm: "✓ Added to Required Reading. All subagents will see this pattern before code generation."
 
@@ -317,7 +317,7 @@ Action:
 4. Confirm: "✓ Added to [skill-name] skill in [file]"
 
 Example: For Hotwire Native Tailwind variants solution:
-- Add to `hotwire-native/references/resources.md` under "CORA-Specific Resources"
+- Add to `hotwire-native/references/resources.md` under "Project-Specific Resources"
 - Add to `hotwire-native/references/examples.md` with link to solution doc
 
 **Option 5: Create new skill**
@@ -397,11 +397,11 @@ Documentation is successful when ALL of the following are true:
 - Present multiple matches
 - Let user choose: new doc, update existing, or link as duplicate
 
-**Module not in CORA-MODULES.md:**
+**Module not in modules documentation:**
 
 - Warn but don't block
 - Proceed with documentation
-- Suggest: "Add [Module] to CORA-MODULES.md if not there"
+- Suggest: "Add [Module] to modules documentation if not there"
 
 ---
 
@@ -488,7 +488,7 @@ File created:
 
 What's next?
 1. Continue workflow (recommended)
-2. Add to Required Reading - Promote to critical patterns (cora-critical-patterns.md)
+2. Add to Required Reading - Promote to critical patterns (critical-patterns.md)
 3. Link related issues - Connect to similar problems
 4. Add to existing skill - Add to a learning skill (e.g., hotwire-native)
 5. Create new skill - Extract into new learning skill

package/plugins/compound-engineering/skills/compound-docs/assets/critical-pattern-template.md

@@ -1,6 +1,6 @@
 # Critical Pattern Template
 
-Use this template when adding a pattern to `docs/solutions/patterns/cora-critical-patterns.md`:
+Use this template when adding a pattern to `docs/solutions/patterns/critical-patterns.md`:
 
 ---
 

package/plugins/compound-engineering/skills/compound-docs/assets/resolution-template.md

@@ -1,5 +1,5 @@
 ---
-module: [Module name or "CORA" for system-wide]
+module: [Module name or "System" for system-wide]
 date: [YYYY-MM-DD]
 problem_type: [build_error|test_failure|runtime_error|performance_issue|database_issue|security_issue|ui_bug|integration_issue|logic_error]
 component: [rails_model|rails_controller|rails_view|service_object|background_job|database|frontend_stimulus|hotwire_turbo|email_processing|brief_system|assistant|authentication|payments]
@@ -19,7 +19,7 @@ tags: [keyword1, keyword2, keyword3]
 [1-2 sentence clear description of the issue and what the user experienced]
 
 ## Environment
-- Module: [Name or "CORA system"]
+- Module: [Name or "System-wide"]
 - Rails Version: [e.g., 7.1.2]
 - Affected Component: [e.g., "Email Processing model", "Brief System service", "Authentication controller"]
 - Date: [YYYY-MM-DD when this was solved]
@@ -78,7 +78,7 @@ tags: [keyword1, keyword2, keyword3]
 
 ## Prevention
 
-[How to avoid this problem in future CORA development:]
+[How to avoid this problem in future development:]
 - [Specific coding practice, check, or pattern to follow]
 - [What to watch out for]
 - [How to catch this early]

package/plugins/compound-engineering/skills/compound-docs/references/yaml-schema.md

@@ -4,7 +4,7 @@
 
 ## Required Fields
 
-- **module** (string): Module name (e.g., "EmailProcessing") or "CORA" for system-wide issues
+- **module** (string): Module name (e.g., "EmailProcessing") or "System" for system-wide issues
 - **date** (string): ISO 8601 date (YYYY-MM-DD)
 - **problem_type** (enum): One of [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** (enum): One of [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]