@fro.bot/systematic 2.0.1 → 2.0.3

package/skills/git-worktree/SKILL.md

@@ -16,6 +16,7 @@ This skill provides a unified interface for managing Git worktrees across your d
 - **Interactive confirmations** at each step
 - **Automatic .gitignore management** for worktree directory
 - **Automatic .env file copying** from main repo to new worktrees
+- **Automatic dev tool trusting** for mise and direnv configs with review-safe guardrails
 
 ## CRITICAL: Always Use the Manager Script
 
@@ -23,12 +24,15 @@ This skill provides a unified interface for managing Git worktrees across your d
 
 The script handles critical setup that raw git commands don't:
 1. Copies `.env`, `.env.local`, `.env.test`, etc. from main repo
-2. Ensures `.worktrees` is in `.gitignore`
-3. Creates consistent directory structure
+2. Trusts dev tool configs with branch-aware safety rules:
+   - mise: auto-trust only when unchanged from a trusted baseline branch
+   - direnv: auto-allow only for trusted base branches; review worktrees stay manual
+3. Ensures `.worktrees` is in `.gitignore`
+4. Creates consistent directory structure
 
 ```bash
 # ✅ CORRECT - Always use the script
-bash scripts/worktree-manager.sh create feature-name
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-name
 
 # ❌ WRONG - Never do this directly
 git worktree add .worktrees/feature-name -b feature-name main
@@ -38,8 +42,8 @@ git worktree add .worktrees/feature-name -b feature-name main
 
 Use this skill in these scenarios:
 
-1. **Code Review (`/workflows:review`)**: If NOT already on the target branch (PR branch or requested branch), offer worktree for isolated review
-2. **Feature Work (`/workflows:work`)**: Always ask if user wants parallel worktree or live branch work
+1. **Code Review (`/ce:review`)**: If NOT already on the target branch (PR branch or requested branch), offer worktree for isolated review
+2. **Feature Work (`/ce:work`)**: Always ask if user wants parallel worktree or live branch work
 3. **Parallel Development**: When working on multiple features simultaneously
 4. **Cleanup**: After completing work in a worktree
 
@@ -47,7 +51,7 @@ Use this skill in these scenarios:
 
 ### In OpenCode Workflows
 
-The skill is automatically called from `/workflows:review` and `/workflows:work` commands:
+The skill is automatically called from `/ce:review` and `/ce:work` commands:
 
 ```
 # For review: offers worktree if not on PR branch
@@ -60,19 +64,19 @@ You can also invoke the skill directly from bash:
 
 ```bash
 # Create a new worktree (copies .env files automatically)
-bash scripts/worktree-manager.sh create feature-login
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-login
 
 # List all worktrees
-bash scripts/worktree-manager.sh list
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh list
 
 # Switch to a worktree
-bash scripts/worktree-manager.sh switch feature-login
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh switch feature-login
 
 # Copy .env files to an existing worktree (if they weren't copied)
-bash scripts/worktree-manager.sh copy-env feature-login
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh copy-env feature-login
 
 # Clean up completed worktrees
-bash scripts/worktree-manager.sh cleanup
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
 ```
 
 ## Commands
@@ -87,7 +91,7 @@ Creates a new worktree with the given branch name.
 
 **Example:**
 ```bash
-bash scripts/worktree-manager.sh create feature-login
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-login
 ```
 
 **What happens:**
@@ -95,7 +99,11 @@ bash scripts/worktree-manager.sh create feature-login
 2. Updates the base branch from remote
 3. Creates new worktree and branch
 4. **Copies all .env files from main repo** (.env, .env.local, .env.test, etc.)
-5. Shows path for cd-ing to the worktree
+5. **Trusts dev tool configs** with branch-aware safety rules:
+   - trusted bases (`main`, `develop`, `dev`, `trunk`, `staging`, `release/*`) compare against themselves
+   - other branches compare against the default branch
+   - direnv auto-allow is skipped on non-trusted bases because `.envrc` can source unchecked files
+6. Shows path for cd-ing to the worktree
 
 ### `list` or `ls`
 
@@ -103,7 +111,7 @@ Lists all available worktrees with their branches and current status.
 
 **Example:**
 ```bash
-bash scripts/worktree-manager.sh list
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh list
 ```
 
 **Output shows:**
@@ -118,7 +126,7 @@ Switches to an existing worktree and cd's into it.
 
 **Example:**
 ```bash
-bash scripts/worktree-manager.sh switch feature-login
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh switch feature-login
 ```
 
 **Optional:**
@@ -130,7 +138,7 @@ Interactively cleans up inactive worktrees with confirmation.
 
 **Example:**
 ```bash
-bash scripts/worktree-manager.sh cleanup
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
 ```
 
 **What happens:**
@@ -149,34 +157,34 @@ bash scripts/worktree-manager.sh cleanup
 
 # You respond: yes
 # Script runs (copies .env files automatically):
-bash scripts/worktree-manager.sh create pr-123-feature-name
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create pr-123-feature-name
 
 # You're now in isolated worktree for review with all env vars
 cd .worktrees/pr-123-feature-name
 
 # After review, return to main:
 cd ../..
-bash scripts/worktree-manager.sh cleanup
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
 ```
 
 ### Parallel Feature Development
 
 ```bash
 # For first feature (copies .env files):
-bash scripts/worktree-manager.sh create feature-login
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-login
 
 # Later, start second feature (also copies .env files):
-bash scripts/worktree-manager.sh create feature-notifications
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh create feature-notifications
 
 # List what you have:
-bash scripts/worktree-manager.sh list
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh list
 
 # Switch between them as needed:
-bash scripts/worktree-manager.sh switch feature-login
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh switch feature-login
 
 # Return to main and cleanup when done:
 cd .
-bash scripts/worktree-manager.sh cleanup
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
 ```
 
 ## Key Design Principles
@@ -204,7 +212,7 @@ bash scripts/worktree-manager.sh cleanup
 
 ## Integration with Workflows
 
-### `/workflows:review`
+### `/ce:review`
 
 Instead of always creating a worktree:
 
@@ -217,7 +225,7 @@ Instead of always creating a worktree:
    - no → proceed with PR diff on current branch
 ```
 
-### `/workflows:work`
+### `/ce:work`
 
 Always offer choice:
 
@@ -242,7 +250,7 @@ Switch out of the worktree first (to main repo), then cleanup:
 
 ```bash
 cd $(git rev-parse --show-toplevel)
-bash scripts/worktree-manager.sh cleanup
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh cleanup
 ```
 
 ### Lost in a worktree?
@@ -250,7 +258,7 @@ bash scripts/worktree-manager.sh cleanup
 See where you are:
 
 ```bash
-bash scripts/worktree-manager.sh list
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh list
 ```
 
 ### .env files missing in worktree?
@@ -258,7 +266,7 @@ bash scripts/worktree-manager.sh list
 If a worktree was created without .env files (e.g., via raw `git worktree add`), copy them:
 
 ```bash
-bash scripts/worktree-manager.sh copy-env feature-name
+bash ${CLAUDE_PLUGIN_ROOT}/skills/git-worktree/scripts/worktree-manager.sh copy-env feature-name
 ```
 
 Navigate back to main:
@@ -300,3 +308,4 @@ cd $(git rev-parse --show-toplevel)
 - No repository duplication
 - Shared git objects for efficiency
 - Much faster than cloning or stashing/switching
+

package/skills/lfg/SKILL.md

@@ -7,11 +7,11 @@ disable-model-invocation: true
 
 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.
+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. `/systematic:ce-plan $ARGUMENTS`
+2. `/ce:plan $ARGUMENTS`
 
-   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.
+   GATE: STOP. Verify that the `ce:plan` workflow produced a plan file in `docs/plans/`. If no plan file was created, run `/ce:plan $ARGUMENTS` again. Do NOT proceed to step 3 until a written plan exists.
 
 3. **Conditionally** run `/systematic:deepen-plan`
 
@@ -19,13 +19,13 @@ CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any required s
 
    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`
+4. `/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. `/systematic:ce-review`
+5. `/ce:review`
 
-6. `/systematic:resolve_todo_parallel`
+6. `/systematic:resolve-todo-parallel`
 
 7. `/systematic:test-browser`
 
@@ -33,5 +33,5 @@ CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any required s
 
 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.
+Start with step 2 now (or step 1 if ralph-loop is available). Remember: plan FIRST, then work. Never skip the plan.
 

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]
 ```
+