@fro.bot/systematic 1.23.0 → 1.23.1

package/skills/deepen-plan-beta/SKILL.md

@@ -0,0 +1,323 @@
+---
+name: deepen-plan-beta
+description: '[BETA] Stress-test an existing implementation plan and selectively strengthen weak sections with targeted research. Use when a plan needs more confidence around decisions, sequencing, system-wide impact, risks, or verification. Best for Standard or Deep plans, or high-risk topics such as auth, payments, migrations, external APIs, and security. For structural or clarity improvements, prefer document-review instead.'
+argument-hint: '[path to plan file]'
+disable-model-invocation: true
+---
+
+# Deepen Plan
+
+## Introduction
+
+**Note: The current year is 2026.** Use this when searching for recent documentation and best practices.
+
+`ce:plan-beta` does the first planning pass. `deepen-plan-beta` is a second-pass confidence check.
+
+Use this skill when the plan already exists and the question is not "Is this document clear?" but rather "Is this plan grounded enough for the complexity and risk involved?"
+
+This skill does **not** turn plans into implementation scripts. It identifies weak sections, runs targeted research only for those sections, and strengthens the plan in place.
+
+`document-review` and `deepen-plan-beta` are different:
+- Use the `document-review` skill when the document needs clarity, simplification, completeness, or scope control
+- Use `deepen-plan-beta` when the document is structurally sound but still needs stronger rationale, sequencing, risk treatment, or system-wide thinking
+
+## Interaction Method
+
+Use the platform's question tool when available. When asking the user a question, prefer the platform's blocking question tool if one exists (`AskUserQuestion` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
+
+Ask one question at a time. Prefer a concise single-select choice when natural options exist.
+
+## Plan File
+
+<plan_path> #$ARGUMENTS </plan_path>
+
+If the plan path above is empty:
+1. Check `docs/plans/` for recent files
+2. Ask the user which plan to deepen using the platform's blocking question tool when available (see Interaction Method). Otherwise, present numbered options in chat and wait for the user's reply before proceeding
+
+Do not proceed until you have a valid plan file path.
+
+## Core Principles
+
+1. **Stress-test, do not inflate** - Deepening should increase justified confidence, not make the plan longer for its own sake.
+2. **Selective depth only** - Focus on the weakest 2-5 sections rather than enriching everything.
+3. **Preserve the planning boundary** - No implementation code, no git command choreography, no exact test command recipes.
+4. **Use artifact-contained evidence** - Work from the written plan, its `Context & Research`, `Sources & References`, and its origin document when present.
+5. **Respect product boundaries** - Do not invent new product requirements. If deepening reveals a product-level gap, surface it as an open question or route back to `ce:brainstorm`.
+6. **Prioritize risk and cross-cutting impact** - The more dangerous or interconnected the work, the more valuable another planning pass becomes.
+
+## Workflow
+
+### Phase 0: Load the Plan and Decide Whether Deepening Is Warranted
+
+#### 0.1 Read the Plan and Supporting Inputs
+
+Read the plan file completely.
+
+If the plan frontmatter includes an `origin:` path:
+- Read the origin document too
+- Use it to check whether the plan still reflects the product intent, scope boundaries, and success criteria
+
+#### 0.2 Classify Plan Depth and Topic Risk
+
+Determine the plan depth from the document:
+- **Lightweight** - small, bounded, low ambiguity, usually 2-4 implementation units
+- **Standard** - moderate complexity, some technical decisions, usually 3-6 units
+- **Deep** - cross-cutting, high-risk, or strategically important work, usually 4-8 units or phased delivery
+
+Also build a risk profile. Treat these as high-risk signals:
+- Authentication, authorization, or security-sensitive behavior
+- Payments, billing, or financial flows
+- Data migrations, backfills, or persistent data changes
+- External APIs or third-party integrations
+- Privacy, compliance, or user data handling
+- Cross-interface parity or multi-surface behavior
+- Significant rollout, monitoring, or operational concerns
+
+#### 0.3 Decide Whether to Deepen
+
+Use this default:
+- **Lightweight** plans usually do not need deepening unless they are high-risk or the user explicitly requests it
+- **Standard** plans often benefit when one or more important sections still look thin
+- **Deep** or high-risk plans often benefit from a targeted second pass
+
+If the plan already appears sufficiently grounded:
+- Say so briefly
+- Recommend moving to `/systematic:ce-work` or the `document-review` skill
+- If the user explicitly asked to deepen anyway, continue with a light pass and deepen at most 1-2 sections
+
+### Phase 1: Parse the Current `ce:plan-beta` Structure
+
+Map the plan into the current template. Look for these sections, or their nearest equivalents:
+- `Overview`
+- `Problem Frame`
+- `Requirements Trace`
+- `Scope Boundaries`
+- `Context & Research`
+- `Key Technical Decisions`
+- `Open Questions`
+- `Implementation Units`
+- `System-Wide Impact`
+- `Risks & Dependencies`
+- `Documentation / Operational Notes`
+- `Sources & References`
+- Optional deep-plan sections such as `Alternative Approaches Considered`, `Success Metrics`, `Phased Delivery`, `Risk Analysis & Mitigation`, and `Operational / Rollout Notes`
+
+If the plan was written manually or uses different headings:
+- Map sections by intent rather than exact heading names
+- If a section is structurally present but titled differently, treat it as the equivalent section
+- If the plan truly lacks a section, decide whether that absence is intentional for the plan depth or a confidence gap worth scoring
+
+Also collect:
+- Frontmatter, including existing `deepened:` date if present
+- Number of implementation units
+- Which files and test files are named
+- Which learnings, patterns, or external references are cited
+- Which sections appear omitted because they were unnecessary versus omitted because they are missing
+
+### Phase 2: Score Confidence Gaps
+
+Use a checklist-first, risk-weighted scoring pass.
+
+For each section, compute:
+- **Trigger count** - number of checklist problems that apply
+- **Risk bonus** - add 1 if the topic is high-risk and this section is materially relevant to that risk
+- **Critical-section bonus** - add 1 for `Key Technical Decisions`, `Implementation Units`, `System-Wide Impact`, `Risks & Dependencies`, or `Open Questions` in `Standard` or `Deep` plans
+
+Treat a section as a candidate if:
+- it hits **2+ total points**, or
+- it hits **1+ point** in a high-risk domain and the section is materially important
+
+Choose only the top **2-5** sections by score. If the user explicitly asked to deepen a lightweight plan, cap at **1-2** sections unless the topic is high-risk.
+
+Example:
+- A `Key Technical Decisions` section with 1 checklist trigger and the critical-section bonus scores **2 points** and is a candidate
+- A `Risks & Dependencies` section with 1 checklist trigger in a high-risk migration plan also becomes a candidate because the risk bonus applies
+
+If the plan already has a `deepened:` date:
+- Prefer sections that have not yet been substantially strengthened, if their scores are comparable
+- Revisit an already-deepened section only when it still scores clearly higher than alternatives or the user explicitly asks for another pass on it
+
+#### 2.1 Section Checklists
+
+Use these triggers.
+
+**Requirements Trace**
+- Requirements are vague or disconnected from implementation units
+- Success criteria are missing or not reflected downstream
+- Units do not clearly advance the traced requirements
+- Origin requirements are not clearly carried forward
+
+**Context & Research / Sources & References**
+- Relevant repo patterns are named but never used in decisions or implementation units
+- Cited learnings or references do not materially shape the plan
+- High-risk work lacks appropriate external or internal grounding
+- Research is generic instead of tied to this repo or this plan
+
+**Key Technical Decisions**
+- A decision is stated without rationale
+- Rationale does not explain tradeoffs or rejected alternatives
+- The decision does not connect back to scope, requirements, or origin context
+- An obvious design fork exists but the plan never addresses why one path won
+
+**Open Questions**
+- Product blockers are hidden as assumptions
+- Planning-owned questions are incorrectly deferred to implementation
+- Resolved questions have no clear basis in repo context, research, or origin decisions
+- Deferred items are too vague to be useful later
+
+**Implementation Units**
+- Dependency order is unclear or likely wrong
+- File paths or test file paths are missing where they should be explicit
+- Units are too large, too vague, or broken into micro-steps
+- Approach notes are thin or do not name the pattern to follow
+- Test scenarios or verification outcomes are vague
+
+**System-Wide Impact**
+- Affected interfaces, callbacks, middleware, entry points, or parity surfaces are missing
+- Failure propagation is underexplored
+- State lifecycle, caching, or data integrity risks are absent where relevant
+- Integration coverage is weak for cross-layer work
+
+**Risks & Dependencies / Documentation / Operational Notes**
+- Risks are listed without mitigation
+- Rollout, monitoring, migration, or support implications are missing when warranted
+- External dependency assumptions are weak or unstated
+- Security, privacy, performance, or data risks are absent where they obviously apply
+
+Use the plan's own `Context & Research` and `Sources & References` as evidence. If those sections cite a pattern, learning, or risk that never affects decisions, implementation units, or verification, treat that as a confidence gap.
+
+### Phase 3: Select Targeted Research Agents
+
+For each selected section, choose the smallest useful agent set. Do **not** run every agent. Use at most **1-3 agents per section** and usually no more than **8 agents total**.
+
+Use fully-qualified agent names inside Task calls.
+
+#### 3.1 Deterministic Section-to-Agent Mapping
+
+**Requirements Trace / Open Questions classification**
+- `systematic:workflow:spec-flow-analyzer` for missing user flows, edge cases, and handoff gaps
+- `systematic:research:repo-research-analyst` for repo-grounded patterns, conventions, and implementation reality checks
+
+**Context & Research / Sources & References gaps**
+- `systematic:research:learnings-researcher` for institutional knowledge and past solved problems
+- `systematic:research:framework-docs-researcher` for official framework or library behavior
+- `systematic:research:best-practices-researcher` for current external patterns and industry guidance
+- Add `systematic:research:git-history-analyzer` only when historical rationale or prior art is materially missing
+
+**Key Technical Decisions**
+- `systematic:review:architecture-strategist` for design integrity, boundaries, and architectural tradeoffs
+- Add `systematic:research:framework-docs-researcher` or `systematic:research:best-practices-researcher` when the decision needs external grounding beyond repo evidence
+
+**Implementation Units / Verification**
+- `systematic:research:repo-research-analyst` for concrete file targets, patterns to follow, and repo-specific sequencing clues
+- `systematic:review:pattern-recognition-specialist` for consistency, duplication risks, and alignment with existing patterns
+- Add `systematic:workflow:spec-flow-analyzer` when sequencing depends on user flow or handoff completeness
+
+**System-Wide Impact**
+- `systematic:review:architecture-strategist` for cross-boundary effects, interface surfaces, and architectural knock-on impact
+- Add the specific specialist that matches the risk:
+  - `systematic:review:performance-oracle` for scalability, latency, throughput, and resource-risk analysis
+  - `systematic:review:security-sentinel` for auth, validation, exploit surfaces, and security boundary review
+  - `systematic:review:data-integrity-guardian` for migrations, persistent state safety, consistency, and data lifecycle risks
+
+**Risks & Dependencies / Operational Notes**
+- Use the specialist that matches the actual risk:
+  - `systematic:review:security-sentinel` for security, auth, privacy, and exploit risk
+  - `systematic:review:data-integrity-guardian` for persistent data safety, constraints, and transaction boundaries
+  - `systematic:review:data-migration-expert` for migration realism, backfills, and production data transformation risk
+  - `systematic:review:deployment-verification-agent` for rollout checklists, rollback planning, and launch verification
+  - `systematic:review:performance-oracle` for capacity, latency, and scaling concerns
+
+#### 3.2 Agent Prompt Shape
+
+For each selected section, pass:
+- A short plan summary
+- The exact section text
+- Why the section was selected, including which checklist triggers fired
+- The plan depth and risk profile
+- A specific question to answer
+
+Instruct the agent to return:
+- findings that change planning quality
+- stronger rationale, sequencing, verification, risk treatment, or references
+- no implementation code
+- no shell commands
+
+### Phase 4: Run Targeted Research and Review
+
+Launch the selected agents in parallel.
+
+Prefer local repo and institutional evidence first. Use external research only when the gap cannot be closed responsibly from repo context or already-cited sources.
+
+If a selected section can be improved by reading the origin document more carefully, do that before dispatching external agents.
+
+If agent outputs conflict:
+- Prefer repo-grounded and origin-grounded evidence over generic advice
+- Prefer official framework documentation over secondary best-practice summaries when the conflict is about library behavior
+- If a real tradeoff remains, record it explicitly in the plan rather than pretending the conflict does not exist
+
+### Phase 5: Synthesize and Rewrite the Plan
+
+Strengthen only the selected sections. Keep the plan coherent and preserve its overall structure.
+
+Allowed changes:
+- Clarify or strengthen decision rationale
+- Tighten requirements trace or origin fidelity
+- Reorder or split implementation units when sequencing is weak
+- Add missing pattern references, file/test paths, or verification outcomes
+- Expand system-wide impact, risks, or rollout treatment where justified
+- Reclassify open questions between `Resolved During Planning` and `Deferred to Implementation` when evidence supports the change
+- Add an optional deep-plan section only when it materially improves execution quality
+- Add or update `deepened: YYYY-MM-DD` in frontmatter when the plan was substantively improved
+
+Do **not**:
+- Add fenced implementation code blocks unless the plan itself is about code shape as a design artifact
+- Add git commands, commit choreography, or exact test command recipes
+- Add generic `Research Insights` subsections everywhere
+- Rewrite the entire plan from scratch
+- Invent new product requirements, scope changes, or success criteria without surfacing them explicitly
+
+If research reveals a product-level ambiguity that should change behavior or scope:
+- Do not silently decide it here
+- Record it under `Open Questions`
+- Recommend `ce:brainstorm` if the gap is truly product-defining
+
+### Phase 6: Final Checks and Write the File
+
+Before writing:
+- Confirm the plan is stronger in specific ways, not merely longer
+- Confirm the planning boundary is intact
+- Confirm the selected sections were actually the weakest ones
+- Confirm origin decisions were preserved when an origin document exists
+- Confirm the final plan still feels right-sized for its depth
+
+Update the plan file in place by default.
+
+If the user explicitly requests a separate file, append `-deepened` before `.md`, for example:
+- `docs/plans/2026-03-15-001-feat-example-plan-deepened.md`
+
+## Post-Enhancement Options
+
+If substantive changes were made, present next steps using the platform's blocking question tool when available (see Interaction Method). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
+
+**Question:** "Plan deepened at `[plan_path]`. What would you like to do next?"
+
+**Options:**
+1. **View diff** - Show what changed
+2. **Run `document-review` skill** - Improve the updated plan through structured document review
+3. **Start `ce:work` skill** - Begin implementing the plan
+4. **Deepen specific sections further** - Run another targeted deepening pass on named sections
+
+Based on selection:
+- **View diff** -> Show the important additions and changed sections
+- **`document-review` skill** -> Load the `document-review` skill with the plan path
+- **Start `ce:work` skill** -> Call the `ce:work` skill with the plan path
+- **Deepen specific sections further** -> Ask which sections still feel weak and run another targeted pass only for those sections
+
+If no substantive changes were warranted:
+- Say that the plan already appears sufficiently grounded
+- Offer the `document-review` skill or `/systematic:ce-work` as the next step instead
+
+NEVER CODE! Research, challenge, and strengthen the plan.
+

package/skills/document-review/SKILL.md

@@ -1,17 +1,17 @@
 ---
 name: document-review
-description: This skill should be used to refine brainstorm or plan documents before proceeding to the next workflow step. It applies when a brainstorm or plan document exists and the user wants to improve it.
+description: This skill should be used to refine requirements or plan documents before proceeding to the next workflow step. It applies when a requirements document or plan document exists and the user wants to improve it.
 ---
 
 # Document Review
 
-Improve brainstorm or plan documents through structured review.
+Improve requirements or plan documents through structured review.
 
 ## Step 1: Get the Document
 
 **If a document path is provided:** Read it, then proceed to Step 2.
 
-**If no document is specified:** Ask which document to review, or look for the most recent brainstorm/plan in `docs/brainstorms/` or `docs/plans/`.
+**If no document is specified:** Ask which document to review, or look for the most recent requirements/plan in `docs/brainstorms/` or `docs/plans/`.
 
 ## Step 2: Assess
 
@@ -32,11 +32,12 @@ Score the document against these criteria:
 | Criterion | What to Check |
 |-----------|---------------|
 | **Clarity** | Problem statement is clear, no vague language ("probably," "consider," "try to") |
-| **Completeness** | Required sections present, constraints stated, open questions flagged |
-| **Specificity** | Concrete enough for next step (brainstorm → can plan, plan → can implement) |
-| **YAGNI** | No hypothetical features, simplest approach chosen |
+| **Completeness** | Required sections present, constraints stated, and outstanding questions clearly marked as blocking or deferred |
+| **Specificity** | Concrete enough for next step (requirements → can plan, plan → can implement) |
+| **Appropriate Level** | Requirements doc stays at behavior/scope level and does not drift into implementation unless the document is inherently technical |
+| **YAGNI** | Avoid speculative complexity whose carrying cost outweighs its value; keep low-cost, meaningful polish when it is easy to maintain |
 
-If invoked within a workflow (after `/workflows:brainstorm` or `/workflows:plan`), also check:
+If invoked within a workflow (after `/ce:brainstorm` or `/ce:plan`), also check:
 - **User intent fidelity** — Document reflects what was discussed, assumptions validated
 
 ## Step 4: Identify the Critical Improvement
@@ -56,7 +57,7 @@ Present your findings, then:
 Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.
 
 **Simplify when:**
-- Content serves hypothetical future needs, not current ones
+- Content serves hypothetical future needs without enough current value to justify its carrying cost
 - Sections repeat information already covered elsewhere
 - Detail exceeds what's needed to take the next step
 - Abstractions or structure add overhead without clarity
@@ -65,6 +66,10 @@ Simplification is purposeful removal of unnecessary complexity, not shortening f
 - Constraints or edge cases that affect implementation
 - Rationale that explains why alternatives were rejected
 - Open questions that need resolution
+- Deferred technical or research questions that are intentionally carried forward to the next stage
+
+**Also remove when inappropriate:**
+- Library choices, file structures, endpoints, schemas, or other implementation details that do not belong in a non-technical requirements document
 
 ## Step 6: Offer Next Action
 
@@ -85,3 +90,4 @@ Return control to the caller (workflow or user) after selection.
 - Do not add new sections or requirements the user didn't discuss
 - Do not over-engineer or add complexity
 - Do not create separate review files or add metadata sections
+

package/skills/generate_command/SKILL.md

@@ -22,7 +22,7 @@ Create a new skill in `.opencode/skills/` for the requested task.
 
 **Development:**
 - Bash - run commands (git, tests, linters)
-- task - launch specialized agents for complex tasks
+- Task - launch specialized agents for complex tasks
 - todowrite - track progress with todo lists
 
 **Web & APIs:**
@@ -114,7 +114,7 @@ Implement #$ARGUMENTS following these steps:
 3. Implement
    - Follow existing code patterns (reference specific files)
    - Write tests first if doing TDD
-   - Ensure code follows AGENTS.md conventions
+   - Ensure code follows CLAUDE.md conventions
 
 4. Verify
    - Run tests: `bin/rails test`
@@ -161,3 +161,4 @@ Details about what to do.
 - [ ] Expected outcome 1
 - [ ] Expected outcome 2
 ```
+

package/skills/lfg/SKILL.md

@@ -5,23 +5,25 @@ argument-hint: '[feature description]'
 disable-model-invocation: true
 ---
 
-CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any step. Do NOT jump ahead to coding or implementation. The plan phase (steps 2-3) MUST be completed and verified BEFORE any work begins. Violating this order produces bad output.
+CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any required step. Do NOT jump ahead to coding or implementation. The plan phase (step 2, and step 3 when warranted) MUST be completed and verified BEFORE any work begins. Violating this order produces bad output.
 
 1. **Optional:** If the `ralph-wiggum` skill is available, run `/ralph-wiggum:ralph-loop "finish all slash commands" --completion-promise "DONE"`. If not available or it fails, skip and continue to step 2 immediately.
 
-2. `/workflows:plan $ARGUMENTS`
+2. `/systematic:ce-plan $ARGUMENTS`
 
-   GATE: STOP. Verify that `/workflows:plan` produced a plan file in `docs/plans/`. If no plan file was created, run `/workflows:plan $ARGUMENTS` again. Do NOT proceed to step 3 until a written plan exists.
+   GATE: STOP. Verify that the `ce:plan` workflow produced a plan file in `docs/plans/`. If no plan file was created, run `/systematic:ce-plan $ARGUMENTS` again. Do NOT proceed to step 3 until a written plan exists.
 
-3. `/systematic:deepen-plan`
+3. **Conditionally** run `/systematic:deepen-plan`
 
-   GATE: STOP. Confirm the plan has been deepened and updated. The plan file in `docs/plans/` should now contain additional detail. Do NOT proceed to step 4 without a deepened plan.
+   Run the `deepen-plan` workflow only if the plan is `Standard` or `Deep`, touches a high-risk area (auth, security, payments, migrations, external APIs, significant rollout concerns), or still has obvious confidence gaps in decisions, sequencing, system-wide impact, risks, or verification.
 
-4. `/workflows:work`
+   GATE: STOP. If you ran the `deepen-plan` workflow, confirm the plan was deepened or explicitly judged sufficiently grounded. If you skipped it, briefly note why and proceed to step 4.
+
+4. `/systematic:ce-work`
 
    GATE: STOP. Verify that implementation work was performed - files were created or modified beyond the plan. Do NOT proceed to step 5 if no code changes were made.
 
-5. `/workflows:review`
+5. `/systematic:ce-review`
 
 6. `/systematic:resolve_todo_parallel`
 
@@ -32,3 +34,4 @@ CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any step. Do N
 9. Output `<promise>DONE</promise>` when video is in PR
 
 Start with step 2 now (or step 1 if ralph-wiggum is available). Remember: plan FIRST, then work. Never skip the plan.
+

package/skills/report-bug/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: report-bug
-description: Report a bug in the Systematic plugin
+description: Report a bug in the compound-engineering plugin
 argument-hint: '[optional: brief description of the bug]'
 disable-model-invocation: true
 ---
 
-# Report a Systematic Plugin Bug
+# Report a Compounding Engineering Plugin Bug
 
-Report bugs encountered while using the Systematic plugin. This command gathers structured information and creates a GitHub issue for the maintainer.
+Report bugs encountered while using the compound-engineering plugin. This command gathers structured information and creates a GitHub issue for the maintainer.
 
 ## Step 1: Gather Bug Information
 
@@ -42,10 +42,10 @@ Use the question tool to collect the following information:
 Automatically gather:
 ```bash
 # Get plugin version
-cat ~/.config/opencode/plugins/installed_plugins.json 2>/dev/null | grep -A5 "systematic" | head -10 || echo "Plugin info not found"
+cat ~/.config/opencode/plugins/installed_plugins.json 2>/dev/null | grep -A5 "compound-engineering" | head -10 || echo "Plugin info not found"
 
 # Get OpenCode version
-opencode --version 2>/dev/null || echo "OpenCode CLI version unknown"
+claude --version 2>/dev/null || echo "Claude CLI version unknown"
 
 # Get OS info
 uname -a
@@ -64,7 +64,7 @@ Create a well-structured bug report with:
 ## Environment
 
 - **Plugin Version:** [from installed_plugins.json]
-- **OpenCode Version:** [from opencode --version]
+- **OpenCode Version:** [from claude --version]
 - **OS:** [from uname]
 
 ## What Happened
@@ -101,17 +101,17 @@ Use the GitHub CLI to create the issue:
 
 ```bash
 gh issue create \
-  --repo marcusrbrown/systematic \
-  --title "[systematic] Bug: [Brief description]" \
+  --repo EveryInc/compound-engineering-plugin \
+  --title "[compound-engineering] Bug: [Brief description]" \
   --body "[Formatted bug report from Step 3]" \
-  --label "bug,systematic"
+  --label "bug,compound-engineering"
 ```
 
 **Note:** If labels don't exist, create without labels:
 ```bash
 gh issue create \
-  --repo marcusrbrown/systematic \
-  --title "[systematic] Bug: [Brief description]" \
+  --repo EveryInc/compound-engineering-plugin \
+  --title "[compound-engineering] Bug: [Brief description]" \
   --body "[Formatted bug report]"
 ```
 
@@ -127,10 +127,10 @@ After the issue is created:
 ```
 ✅ Bug report submitted successfully!
 
-Issue: https://github.com/marcusrbrown/systematic/issues/[NUMBER]
-Title: [systematic] Bug: [description]
+Issue: https://github.com/EveryInc/compound-engineering-plugin/issues/[NUMBER]
+Title: [compound-engineering] Bug: [description]
 
-Thank you for helping improve the Systematic plugin!
+Thank you for helping improve the compound-engineering plugin!
 The maintainer will review your report and respond as soon as possible.
 ```
 
@@ -149,3 +149,4 @@ This command does NOT collect:
 - File paths beyond basic OS info
 
 Only technical information about the bug is included in the report.
+

package/skills/resolve_parallel/SKILL.md

@@ -27,9 +27,10 @@ So if there are 3 comments, it will spawn 3 pr-comment-resolver agents in parall
 2. task pr-comment-resolver(comment2)
 3. task pr-comment-resolver(comment3)
 
-Always run all in parallel subagents/tasks for each Todo item.
+Always run all in parallel subagents/Tasks for each Todo item.
 
 ### 4. Commit & Resolve
 
 - Commit changes
 - Push to remote
+

package/skills/resolve_todo_parallel/SKILL.md

@@ -12,7 +12,7 @@ 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.
+If any todo recommends deleting, removing, or gitignoring files in `docs/brainstorms/`, `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
 

package/skills/slfg/SKILL.md

@@ -10,15 +10,18 @@ Swarm-enabled LFG. Run these steps in order, parallelizing where indicated. Do n
 ## Sequential Phase
 
 1. **Optional:** If the `ralph-wiggum` skill is available, run `/ralph-wiggum:ralph-loop "finish all slash commands" --completion-promise "DONE"`. If not available or it fails, skip and continue to step 2 immediately.
-2. `/ce:plan $ARGUMENTS`
-3. `/systematic:deepen-plan`
-4. `/ce:work` — **Use swarm mode**: Make a Task list and launch an army of agent swarm subagents to build the plan
+2. `/systematic:ce-plan $ARGUMENTS`
+3. **Conditionally** run `/systematic:deepen-plan`
+   - Run the `deepen-plan` workflow only if the plan is `Standard` or `Deep`, touches a high-risk area (auth, security, payments, migrations, external APIs, significant rollout concerns), or still has obvious confidence gaps in decisions, sequencing, system-wide impact, risks, or verification
+   - If you run the `deepen-plan` workflow, confirm the plan was deepened or explicitly judged sufficiently grounded before moving on
+   - If you skip it, note why and continue to step 4
+4. `/systematic:ce-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. `/ce:review` — spawn as background Task agent
+5. `/systematic:ce-review` — spawn as background Task agent
 6. `/systematic:test-browser` — spawn as background Task agent
 
 Wait for both to complete before continuing.

package/skills/test-browser/SKILL.md

@@ -133,8 +133,8 @@ If the user passed a port number (e.g., `/test-browser 5000` or `/test-browser -
 
 **Priority 2: AGENTS.md / project instructions**
 ```bash
-# Check AGENTS.md for port references
-grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' AGENTS.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1
+# Check CLAUDE.md for port references
+grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' CLAUDE.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1
 ```
 
 **Priority 3: package.json scripts**
@@ -158,7 +158,7 @@ Store the result in a `PORT` variable for use in all subsequent steps.
 # Combined detection (run this)
 PORT="${EXPLICIT_PORT:-}"
 if [ -z "$PORT" ]; then
-  PORT=$(grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' AGENTS.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1)
+  PORT=$(grep -Eio '(port\s*[:=]\s*|localhost:)([0-9]{4,5})' CLAUDE.md 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1)
 fi
 if [ -z "$PORT" ]; then
   PORT=$(grep -Eo '\-\-port[= ]+[0-9]{4,5}' package.json 2>/dev/null | grep -Eo '[0-9]{4,5}' | head -1)

package/skills/test-xcode/SKILL.md

@@ -323,9 +323,9 @@ mcp__xcodebuildmcp__shutdown_simulator({ simulator_id: "[uuid]" })
 /xcode-test current
 ```
 
-## Integration with /ce:review
+## Integration with /systematic:ce-review
 
-When reviewing PRs that touch iOS code, the `/ce:review` command can spawn this as a subagent:
+When reviewing PRs that touch iOS code, the `/systematic:ce-review` command can spawn this as a subagent:
 
 ```
 Task general-purpose("Run /xcode-test for scheme [name]. Build, install on simulator, test key screens, check for crashes.")