@fro.bot/systematic 2.0.2 → 2.1.0

package/skills/reproduce-bug/SKILL.md

@@ -1,101 +1,195 @@
 ---
 name: reproduce-bug
-description: Reproduce and investigate a bug using logs, console inspection, and browser screenshots
-argument-hint: '[GitHub issue number]'
-disable-model-invocation: true
+description: Systematically reproduce and investigate a bug from a GitHub issue. Use when the user provides a GitHub issue number or URL for a bug they want reproduced or investigated.
+argument-hint: '[GitHub issue number or URL]'
 ---
 
-# Reproduce Bug Command
+# Reproduce Bug
 
-Look at github issue #$ARGUMENTS and read the issue description and comments.
+A framework-agnostic, hypothesis-driven workflow for reproducing and investigating bugs from issue reports. Works across any language, framework, or project type.
 
-## Phase 1: Log Investigation
+## Phase 1: Understand the Issue
 
-Run the following agents in parallel to investigate the bug:
+Fetch and analyze the bug report to extract structured information before touching the codebase.
 
-1. task rails-console-explorer(issue_description)
-2. task appsignal-log-investigator(issue_description)
+### Fetch the issue
 
-Think about the places it could go wrong looking at the codebase. Look for logging output we can look for.
+If no issue number or URL was provided as an argument, ask the user for one before proceeding (using the platform's question tool -- e.g., `question` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini -- or present a prompt and wait for a reply).
 
-Run the agents again to find any logs that could help us reproduce the bug.
+```bash
+gh issue view $ARGUMENTS --json title,body,comments,labels,assignees
+```
 
-Keep running these agents until you have a good idea of what is going on.
+If the argument is a URL rather than a number, extract the issue number or pass the URL directly to `gh`.
 
-## Phase 2: Visual Reproduction with Playwright
+### Extract key details
 
-If the bug is UI-related or involves user flows, use Playwright to visually reproduce it:
+Read the issue and comments, then identify:
 
-### Step 1: Verify Server is Running
+- **Reported symptoms** -- what the user observed (error message, wrong output, visual glitch, crash)
+- **Expected behavior** -- what should have happened instead
+- **Reproduction steps** -- any steps the reporter provided
+- **Environment clues** -- browser, OS, version, user role, data conditions
+- **Frequency** -- always reproducible, intermittent, or one-time
 
-```
-mcp__plugin_compound-engineering_pw__browser_navigate({ url: "http://localhost:3000" })
-mcp__plugin_compound-engineering_pw__browser_snapshot({})
-```
+If the issue lacks reproduction steps or is ambiguous, note what is missing -- this shapes the investigation strategy.
 
-If server not running, inform user to start `bin/dev`.
+## Phase 2: Hypothesize
 
-### Step 2: Navigate to Affected Area
+Before running anything, form theories about the root cause. This focuses the investigation and prevents aimless exploration.
 
-Based on the issue description, navigate to the relevant page:
+### Search for relevant code
 
-```
-mcp__plugin_compound-engineering_pw__browser_navigate({ url: "http://localhost:3000/[affected_route]" })
-mcp__plugin_compound-engineering_pw__browser_snapshot({})
-```
+Use the native content-search tool (e.g., Grep in OpenCode) to find code paths related to the reported symptoms. Search for:
+
+- Error messages or strings mentioned in the issue
+- Feature names, route paths, or UI labels described in the report
+- Related model/service/controller names
+
+### Form hypotheses
+
+Based on the issue details and code search results, write down 2-3 plausible hypotheses. Each should identify:
+
+- **What** might be wrong (e.g., "race condition in session refresh", "nil check missing on optional field")
+- **Where** in the codebase (specific files and line ranges)
+- **Why** it would produce the reported symptoms
+
+Rank hypotheses by likelihood. Start investigating the most likely one first.
+
+## Phase 3: Reproduce
 
-### Step 3: Capture Screenshots
+Attempt to trigger the bug. The reproduction strategy depends on the bug type.
 
-Take screenshots at each step of reproducing the bug:
+### Route A: Test-based reproduction (backend, logic, data bugs)
 
+Write or find an existing test that exercises the suspected code path:
+
+1. Search for existing test files covering the affected code using the native file-search tool (e.g., Glob in OpenCode)
+2. Run existing tests to see if any already fail
+3. If no test covers the scenario, write a minimal failing test that demonstrates the reported behavior
+4. A failing test that matches the reported symptoms confirms the bug
+
+### Route B: Browser-based reproduction (UI, visual, interaction bugs)
+
+Use the `agent-browser` CLI for browser automation. Do not use any alternative browser MCP integration or built-in browser-control tool. See the `agent-browser` skill for setup and detailed CLI usage.
+
+#### Verify server is running
+
+```bash
+agent-browser open http://localhost:${PORT:-3000}
+agent-browser snapshot -i
 ```
-mcp__plugin_compound-engineering_pw__browser_take_screenshot({ filename: "bug-[issue]-step-1.png" })
+
+If the server is not running, ask the user to start their development server and provide the correct port.
+
+To detect the correct port, check project instruction files (`AGENTS.md`, `AGENTS.md`) for port references, then `package.json` dev scripts, then `.env` files, falling back to `3000`.
+
+#### Follow reproduction steps
+
+Navigate to the affected area and execute the steps from the issue:
+
+```bash
+agent-browser open "http://localhost:${PORT}/[affected_route]"
+agent-browser snapshot -i
 ```
 
-### Step 4: Follow User Flow
+Use `agent-browser` commands to interact with the page:
+- `agent-browser click @ref` -- click elements
+- `agent-browser fill @ref "text"` -- fill form fields
+- `agent-browser snapshot -i` -- capture current state
+- `agent-browser screenshot bug-evidence.png` -- save visual evidence
 
-Reproduce the exact steps from the issue:
+#### Capture the bug state
 
-1. **Read the issue's reproduction steps**
-2. **Execute each step using Playwright:**
-   - `browser_click` for clicking elements
-   - `browser_type` for filling forms
-   - `browser_snapshot` to see the current state
-   - `browser_take_screenshot` to capture evidence
+When the bug is reproduced:
+1. Take a screenshot of the error state
+2. Check for console errors: look at browser output and any visible error messages
+3. Record the exact sequence of steps that triggered it
 
-3. **Check for console errors:**
-   ```
-   mcp__plugin_compound-engineering_pw__browser_console_messages({ level: "error" })
-   ```
+### Route C: Manual / environment-specific reproduction
 
-### Step 5: Capture Bug State
+For bugs that require specific data conditions, user roles, external service state, or cannot be automated:
 
-When you reproduce the bug:
+1. Document what conditions are needed
+2. Ask the user (using the platform's question tool -- e.g., `question` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini -- or present options and wait for a reply) whether they can set up the required conditions
+3. Guide them through manual reproduction steps if needed
 
-1. Take a screenshot of the bug state
-2. Capture console errors
-3. Document the exact steps that triggered it
+### If reproduction fails
+
+If the bug cannot be reproduced after trying the most likely hypotheses:
+
+1. Revisit the remaining hypotheses
+2. Check if the bug is environment-specific (version, OS, browser, data-dependent)
+3. Search the codebase for recent changes to the affected area: `git log --oneline -20 -- [affected_files]`
+4. Document what was tried and what conditions might be missing
+
+## Phase 4: Investigate
+
+Dig deeper into the root cause using whatever observability the project offers.
+
+### Check logs and traces
+
+Search for errors, warnings, or unexpected behavior around the time of reproduction. What to check depends on the bug and what the project has available:
+
+- **Application logs** -- search local log output (dev server stdout, log files) for error patterns, stack traces, or warnings using the native content-search tool
+- **Error tracking** -- check for related exceptions in the project's error tracker (Sentry, AppSignal, Bugsnag, Datadog, etc.)
+- **Browser console** -- for UI bugs, check developer console output for JavaScript errors, failed network requests, or CORS issues
+- **Database state** -- if the bug involves data, inspect relevant records for unexpected values, missing associations, or constraint violations
+- **Request/response cycle** -- check server logs for the specific request: status codes, params, timing, middleware behavior
+
+### Trace the code path
+
+Starting from the entry point identified in Phase 2, trace the execution path:
+
+1. Read the relevant source files using the native file-read tool
+2. Identify where the behavior diverges from expectations
+3. Check edge cases: nil/null values, empty collections, boundary conditions, race conditions
+4. Look for recent changes that may have introduced the bug: `git log --oneline -10 -- [file]`
+
+## Phase 5: Document Findings
+
+Summarize everything discovered during the investigation.
+
+### Compile the report
+
+Organize findings into:
+
+1. **Root cause** -- what is actually wrong and where (with file paths and line numbers, e.g., `app/services/example_service.rb:42`)
+2. **Reproduction steps** -- verified steps to trigger the bug (mark as confirmed or unconfirmed)
+3. **Evidence** -- screenshots, test output, log excerpts, console errors
+4. **Suggested fix** -- if a fix is apparent, describe it with the specific code changes needed
+5. **Open questions** -- anything still unclear or needing further investigation
+
+### Present to user before any external action
+
+Present the full report to the user. Do not post comments to the GitHub issue or take any external action without explicit confirmation.
+
+Ask the user (using the platform's question tool, or present options and wait):
 
 ```
-mcp__plugin_compound-engineering_pw__browser_take_screenshot({ filename: "bug-[issue]-reproduced.png" })
+Investigation complete. How to proceed?
+
+1. Post findings to the issue as a comment
+2. Start working on a fix
+3. Just review the findings (no external action)
 ```
 
-## Phase 3: Document Findings
+If the user chooses to post to the issue:
 
-**Reference Collection:**
+```bash
+gh issue comment $ARGUMENTS --body "$(cat <<'EOF'
+## Bug Investigation
 
-- [ ] Document all research findings with specific file paths (e.g., `app/services/example_service.rb:42`)
-- [ ] Include screenshots showing the bug reproduction
-- [ ] List console errors if any
-- [ ] Document the exact reproduction steps
+**Root Cause:** [summary]
 
-## Phase 4: Report Back
+**Reproduction Steps (verified):**
+1. [step]
+2. [step]
 
-Add a comment to the issue with:
+**Relevant Code:** [file:line references]
 
-1. **Findings** - What you discovered about the cause
-2. **Reproduction Steps** - Exact steps to reproduce (verified)
-3. **Screenshots** - Visual evidence of the bug (upload captured screenshots)
-4. **Relevant Code** - File paths and line numbers
-5. **Suggested Fix** - If you have one
+**Suggested Fix:** [description if applicable]
+EOF
+)"
+```
 

package/skills/resolve-pr-parallel/SKILL.md

@@ -1,7 +1,7 @@
 ---
-name: resolve_pr_parallel
+name: resolve-pr-parallel
 description: Resolve all PR comments using parallel processing. Use when addressing PR review feedback, resolving review threads, or batch-fixing PR comments.
-argument-hint: "[optional: PR number or current PR]"
+argument-hint: '[optional: PR number or current PR]'
 disable-model-invocation: true
 allowed-tools: Bash(gh *), Bash(git *), Read
 ---
@@ -12,7 +12,7 @@ Resolve all unresolved PR review comments by spawning parallel agents for each t
 
 ## Context Detection
 
-OpenCode automatically detects git context:
+Detect git context from the current working directory:
 - Current branch and associated PR
 - All PR comments and review threads
 - Works with any PR by specifying the number
@@ -21,7 +21,7 @@ OpenCode automatically detects git context:
 
 ### 1. Analyze
 
-Fetch unresolved review threads using the GraphQL script:
+Fetch unresolved review threads using the GraphQL script at [scripts/get-pr-comments](scripts/get-pr-comments):
 
 ```bash
 bash scripts/get-pr-comments PR_NUMBER
@@ -37,7 +37,7 @@ gh api repos/{owner}/{repo}/pulls/PR_NUMBER/comments
 
 ### 2. Plan
 
-Create a todowrite list of all unresolved items grouped by type:
+Create a task list of all unresolved items grouped by type (e.g., `todowrite` in OpenCode, `update_plan` in Codex):
 - Code changes requested
 - Questions to answer
 - Style/convention fixes
@@ -45,20 +45,24 @@ Create a todowrite list of all unresolved items grouped by type:
 
 ### 3. Implement (PARALLEL)
 
-Spawn a `pr-comment-resolver` agent for each unresolved item in parallel.
+Spawn a `systematic:workflow:pr-comment-resolver` agent for each unresolved item.
 
-If there are 3 comments, spawn 3 agents:
+If there are 3 comments, spawn 3 agents — one per comment. Prefer running all agents in parallel; if the platform does not support parallel dispatch, run them sequentially.
 
-1. task pr-comment-resolver(comment1)
-2. task pr-comment-resolver(comment2)
-3. task pr-comment-resolver(comment3)
+Keep parent-context pressure bounded:
+- If there are 1-4 unresolved items, direct parallel returns are fine
+- If there are 5+ unresolved items, launch in batches of at most 4 agents at a time
+- Require each resolver agent to return a short status summary to the parent: comment/thread handled, files changed, tests run or skipped, any blocker that still needs human attention, and for question-only threads the substantive reply text so the parent can post or verify it
 
-Always run all in parallel subagents/Tasks for each Todo item.
+If the PR is large enough that even batched short returns are likely to get noisy, use a per-run scratch directory such as `.context/systematic/resolve-pr-parallel/<run-id>/`:
+- Have each resolver write a compact artifact for its thread there
+- Return only a completion summary to the parent
+- Re-read only the artifacts that are needed to resolve threads, answer reviewer questions, or summarize the batch
 
 ### 4. Commit & Resolve
 
 - Commit changes with a clear message referencing the PR feedback
-- Resolve each thread programmatically:
+- Resolve each thread programmatically using [scripts/resolve-pr-thread](scripts/resolve-pr-thread):
 
 ```bash
 bash scripts/resolve-pr-thread THREAD_ID
@@ -76,6 +80,8 @@ bash scripts/get-pr-comments PR_NUMBER
 
 Should return an empty array `[]`. If threads remain, repeat from step 1.
 
+If a scratch directory was used and the user did not ask to inspect it, clean it up after verification succeeds.
+
 ## Scripts
 
 - [scripts/get-pr-comments](scripts/get-pr-comments) - GraphQL query for unresolved review threads
@@ -87,3 +93,4 @@ Should return an empty array `[]`. If threads remain, repeat from step 1.
 - Changes committed and pushed
 - Threads resolved via GraphQL (marked as resolved on GitHub)
 - Empty result from get-pr-comments on verify
+

package/skills/resolve-todo-parallel/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: resolve-todo-parallel
-description: Use this skill when there are multiple unresolved CLI todo files and you want to resolve them in parallel, document learnings, and clean up completed entries in one disciplined pass.
+description: Resolve all pending CLI todos using parallel processing, compound on lessons learned, then clean up completed todos.
 argument-hint: '[optional: specific todo ID or pattern]'
 ---
 
@@ -10,9 +10,11 @@ Resolve all TODO comments using parallel processing, document lessons learned, t
 
 ### 1. Analyze
 
-Get all unresolved TODOs from the /todos/*.md directory
+Get all unresolved TODOs from `.context/systematic/todos/*.md` and legacy `todos/*.md`
 
-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 Systematic workflow artifacts that are intentional and permanent.
+Residual actionable work may come from `ce:review-beta mode:autonomous` after its in-skill `safe_auto` pass. Treat those todos as normal unresolved work items; the review skill has already decided they should not be auto-fixed inline.
+
+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 systematic pipeline artifacts that are intentional and permanent.
 
 ### 2. Plan
 
@@ -20,7 +22,7 @@ Create a task list of all unresolved items grouped by type (e.g., `todowrite` in
 
 ### 3. Implement (PARALLEL)
 
-Spawn a `pr-comment-resolver` agent for each unresolved item.
+Spawn a `systematic:workflow:pr-comment-resolver` agent for each unresolved item.
 
 If there are 3 items, spawn 3 agents — one per item. Prefer running all agents in parallel; if the platform does not support parallel dispatch, run them sequentially respecting the dependency order from step 2.
 
@@ -52,9 +54,9 @@ GATE: STOP. Verify that the compound skill produced a solution document in `docs
 
 ### 6. Clean Up Completed Todos
 
-List all todos and identify those with `done` or `resolved` status, then delete them to keep the todo list clean and actionable.
+Search both `.context/systematic/todos/` and legacy `todos/` for files with `done`, `resolved`, or `complete` status, then delete them to keep the todo list clean and actionable.
 
-If a scratch directory was used and the user did not ask to inspect it, clean it up after todo cleanup succeeds.
+If a per-run scratch directory was created at `.context/systematic/resolve-todo-parallel/<run-id>/`, and the user did not ask to inspect it, delete that specific `<run-id>/` directory after todo cleanup succeeds. Do not delete any other `.context/` subdirectories.
 
 After cleanup, output a summary:
 
@@ -63,3 +65,4 @@ Todos resolved: [count]
 Lessons documented: [path to solution doc, or "skipped"]
 Todos cleaned up: [count deleted]
 ```
+

package/skills/setup/SKILL.md

@@ -1,174 +1,22 @@
 ---
 name: setup
-description: Configure which review agents run for your project. Auto-detects stack and writes systematic.local.md.
+description: Configure project-level settings for systematic workflows. Currently a placeholder — review agent selection is handled automatically by ce:review.
 disable-model-invocation: true
 ---
 
 # Systematic Setup
 
-## Interaction Method
+Project-level configuration for systematic workflows.
 
-If `question` is available, use it for all prompts below.
+## Current State
 
-If not, present each question as a numbered list and wait for a reply before proceeding to the next step. For multiSelect questions, accept comma-separated numbers (e.g. `1, 3`). Never skip or auto-configure.
+Review agent selection is handled automatically by the `ce:review` skill, which uses intelligent tiered selection based on diff content. No per-project configuration is needed for code reviews.
 
-Interactive setup for `systematic.local.md` — configures which agents run during `/ce:review` and `/ce:work`.
+If this skill is invoked, inform the user:
 
-## Step 1: Check Existing Config
+> Review agent configuration is no longer needed — `ce:review` automatically selects the right reviewers based on your diff. Project-specific review context (e.g., "we serve 10k req/s" or "watch for N+1 queries") belongs in your project's AGENTS.md or AGENTS.md, where all agents already read it.
 
-Read `systematic.local.md` in the project root. If it exists, display current settings summary and use question:
+## Future Use
 
-```
-question: "Settings file already exists. What would you like to do?"
-header: "Config"
-options:
-  - label: "Reconfigure"
-    description: "Run the interactive setup again from scratch"
-  - label: "View current"
-    description: "Show the file contents, then stop"
-  - label: "Cancel"
-    description: "Keep current settings"
-```
+This skill is reserved for future project-level configuration needs beyond review agent selection.
 
-If "View current": read and display the file, then stop.
-If "Cancel": stop.
-
-## Step 2: Detect and Ask
-
-Auto-detect the project stack:
-
-```bash
-test -f Gemfile && test -f config/routes.rb && echo "rails" || \
-test -f Gemfile && echo "ruby" || \
-test -f tsconfig.json && echo "typescript" || \
-test -f package.json && echo "javascript" || \
-test -f pyproject.toml && echo "python" || \
-test -f requirements.txt && echo "python" || \
-echo "general"
-```
-
-Use question:
-
-```
-question: "Detected {type} project. How would you like to configure?"
-header: "Setup"
-options:
-  - label: "Auto-configure (Recommended)"
-    description: "Use smart defaults for {type}. Done in one click."
-  - label: "Customize"
-    description: "Choose stack, focus areas, and review depth."
-```
-
-### If Auto-configure → Skip to Step 4 with defaults:
-
-- **Rails:** `[kieran-rails-reviewer, dhh-rails-reviewer, code-simplicity-reviewer, security-sentinel, performance-oracle]`
-- **Python:** `[kieran-python-reviewer, code-simplicity-reviewer, security-sentinel, performance-oracle]`
-- **TypeScript:** `[kieran-typescript-reviewer, code-simplicity-reviewer, security-sentinel, performance-oracle]`
-- **General:** `[code-simplicity-reviewer, security-sentinel, performance-oracle, architecture-strategist]`
-
-### If Customize → Step 3
-
-## Step 3: Customize (3 questions)
-
-**a. Stack** — confirm or override:
-
-```
-question: "Which stack should we optimize for?"
-header: "Stack"
-options:
-  - label: "{detected_type} (Recommended)"
-    description: "Auto-detected from project files"
-  - label: "Rails"
-    description: "Ruby on Rails — adds DHH-style and Rails-specific reviewers"
-  - label: "Python"
-    description: "Python — adds Pythonic pattern reviewer"
-  - label: "TypeScript"
-    description: "TypeScript — adds type safety reviewer"
-```
-
-Only show options that differ from the detected type.
-
-**b. Focus areas** — multiSelect:
-
-```
-question: "Which review areas matter most?"
-header: "Focus"
-multiSelect: true
-options:
-  - label: "Security"
-    description: "Vulnerability scanning, auth, input validation (security-sentinel)"
-  - label: "Performance"
-    description: "N+1 queries, memory leaks, complexity (performance-oracle)"
-  - label: "Architecture"
-    description: "Design patterns, SOLID, separation of concerns (architecture-strategist)"
-  - label: "Code simplicity"
-    description: "Over-engineering, YAGNI violations (code-simplicity-reviewer)"
-```
-
-**c. Depth:**
-
-```
-question: "How thorough should reviews be?"
-header: "Depth"
-options:
-  - label: "Thorough (Recommended)"
-    description: "Stack reviewers + all selected focus agents."
-  - label: "Fast"
-    description: "Stack reviewers + code simplicity only. Less context, quicker."
-  - label: "Comprehensive"
-    description: "All above + git history, data integrity, agent-native checks."
-```
-
-## Step 4: Build Agent List and Write File
-
-**Stack-specific agents:**
-- Rails → `kieran-rails-reviewer, dhh-rails-reviewer`
-- Python → `kieran-python-reviewer`
-- TypeScript → `kieran-typescript-reviewer`
-- General → (none)
-
-**Focus area agents:**
-- Security → `security-sentinel`
-- Performance → `performance-oracle`
-- Architecture → `architecture-strategist`
-- Code simplicity → `code-simplicity-reviewer`
-
-**Depth:**
-- Thorough: stack + selected focus areas
-- Fast: stack + `code-simplicity-reviewer` only
-- Comprehensive: all above + `git-history-analyzer, data-integrity-guardian, agent-native-reviewer`
-
-**Plan review agents:** stack-specific reviewer + `code-simplicity-reviewer`.
-
-Write `systematic.local.md`:
-
-```markdown
----
-review_agents: [{computed agent list}]
-plan_review_agents: [{computed plan agent list}]
----
-
-# Review Context
-
-Add project-specific review instructions here.
-These notes are passed to all review agents during /ce:review and /ce:work.
-
-Examples:
-- "We use Turbo Frames heavily — check for frame-busting issues"
-- "Our API is public — extra scrutiny on input validation"
-- "Performance-critical: we serve 10k req/s on this endpoint"
-```
-
-## Step 5: Confirm
-
-```
-Saved to systematic.local.md
-
-Stack:        {type}
-Review depth: {depth}
-Agents:       {count} configured
-              {agent list, one per line}
-
-Tip: Edit the "Review Context" section to add project-specific instructions.
-     Re-run this setup anytime to reconfigure.
-```

package/skills/slfg/SKILL.md

@@ -9,28 +9,32 @@ 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. `/systematic:ce-plan $ARGUMENTS`
+1. **Optional:** If the `ralph-loop` skill is available, run `/ralph-loop: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. **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
+4. `/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. `/systematic:ce-review` — spawn as background Task agent
+5. `/ce:review mode:report-only` — spawn as background Task agent
 6. `/systematic:test-browser` — spawn as background Task agent
 
 Wait for both to complete before continuing.
 
+## Autofix Phase
+
+7. `/ce:review mode:autofix` — run sequentially after the parallel phase so it can safely mutate the checkout, apply `safe_auto` fixes, and emit residual todos for step 8
+
 ## Finalize Phase
 
-7. `/systematic:resolve_todo_parallel` — resolve any findings from the review
-8. `/systematic:feature-video` — record the final walkthrough and add to PR
-9. Output `<promise>DONE</promise>` when video is in PR
+8. `/systematic:todo-resolve` — resolve findings, compound on learnings, clean up completed todos
+9. `/systematic:feature-video` — record the final walkthrough and add to PR
+10. Output `<promise>DONE</promise>` when video is in PR
 
 Start with step 1 now.