@fro.bot/systematic 2.0.2 → 2.0.3

package/skills/ce-review-beta/references/findings-schema.json

@@ -0,0 +1,128 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "Code Review Findings",
+  "description": "Structured output schema for code review sub-agents",
+  "type": "object",
+  "required": ["reviewer", "findings", "residual_risks", "testing_gaps"],
+  "properties": {
+    "reviewer": {
+      "type": "string",
+      "description": "Persona name that produced this output (e.g., 'correctness', 'security')"
+    },
+    "findings": {
+      "type": "array",
+      "description": "List of code review findings. Empty array if no issues found.",
+      "items": {
+        "type": "object",
+        "required": [
+          "title",
+          "severity",
+          "file",
+          "line",
+          "why_it_matters",
+          "autofix_class",
+          "owner",
+          "requires_verification",
+          "confidence",
+          "evidence",
+          "pre_existing"
+        ],
+        "properties": {
+          "title": {
+            "type": "string",
+            "description": "Short, specific issue title. 10 words or fewer.",
+            "maxLength": 100
+          },
+          "severity": {
+            "type": "string",
+            "enum": ["P0", "P1", "P2", "P3"],
+            "description": "Issue severity level"
+          },
+          "file": {
+            "type": "string",
+            "description": "Relative file path from repository root"
+          },
+          "line": {
+            "type": "integer",
+            "description": "Primary line number of the issue",
+            "minimum": 1
+          },
+          "why_it_matters": {
+            "type": "string",
+            "description": "Impact and failure mode -- not 'what is wrong' but 'what breaks'"
+          },
+          "autofix_class": {
+            "type": "string",
+            "enum": ["safe_auto", "gated_auto", "manual", "advisory"],
+            "description": "Reviewer's conservative recommendation for how this issue should be handled after synthesis"
+          },
+          "owner": {
+            "type": "string",
+            "enum": ["review-fixer", "downstream-resolver", "human", "release"],
+            "description": "Who should own the next action for this finding after synthesis"
+          },
+          "requires_verification": {
+            "type": "boolean",
+            "description": "Whether any fix for this finding must be re-verified with targeted tests or a follow-up review pass"
+          },
+          "suggested_fix": {
+            "type": ["string", "null"],
+            "description": "Concrete minimal fix. Omit or null if no good fix is obvious -- a bad suggestion is worse than none."
+          },
+          "confidence": {
+            "type": "number",
+            "description": "Reviewer confidence in this finding, calibrated per persona",
+            "minimum": 0.0,
+            "maximum": 1.0
+          },
+          "evidence": {
+            "type": "array",
+            "description": "Code-grounded evidence: snippets, line references, or pattern descriptions. At least 1 item.",
+            "items": { "type": "string" },
+            "minItems": 1
+          },
+          "pre_existing": {
+            "type": "boolean",
+            "description": "True if this issue exists in unchanged code unrelated to the current diff"
+          }
+        }
+      }
+    },
+    "residual_risks": {
+      "type": "array",
+      "description": "Risks the reviewer noticed but could not confirm as findings",
+      "items": { "type": "string" }
+    },
+    "testing_gaps": {
+      "type": "array",
+      "description": "Missing test coverage the reviewer identified",
+      "items": { "type": "string" }
+    }
+  },
+
+  "_meta": {
+    "confidence_thresholds": {
+      "suppress": "Below 0.60 -- do not report. Finding is speculative noise.",
+      "flag": "0.60-0.69 -- include only when the persona's calibration says the issue is actionable at that confidence.",
+      "report": "0.70+ -- report with full confidence."
+    },
+    "severity_definitions": {
+      "P0": "Critical breakage, exploitable vulnerability, data loss/corruption. Must fix before merge.",
+      "P1": "High-impact defect likely hit in normal usage, breaking contract. Should fix.",
+      "P2": "Moderate issue with meaningful downside (edge case, perf regression, maintainability trap). Fix if straightforward.",
+      "P3": "Low-impact, narrow scope, minor improvement. User's discretion."
+    },
+    "autofix_classes": {
+      "safe_auto": "Local, deterministic code or test fix suitable for the in-skill fixer in autonomous mode.",
+      "gated_auto": "Concrete fix exists, but it changes behavior, permissions, contracts, or other sensitive areas that deserve explicit approval.",
+      "manual": "Actionable issue that should become residual work rather than an in-skill autofix.",
+      "advisory": "Informational or operational item that should be surfaced in the report only."
+    },
+    "owners": {
+      "review-fixer": "The in-skill fixer can own this when policy allows.",
+      "downstream-resolver": "Turn this into residual work for later resolution.",
+      "human": "A person must make a judgment call before code changes should continue.",
+      "release": "Operational or rollout follow-up; do not convert into code-fix work automatically."
+    }
+  }
+}

package/skills/ce-review-beta/references/persona-catalog.md

@@ -0,0 +1,50 @@
+# Persona Catalog
+
+8 reviewer personas organized in two tiers, plus CE-specific agents. The orchestrator uses this catalog to select which reviewers to spawn for each review.
+
+## Always-on (3 personas + 2 CE agents)
+
+Spawned on every review regardless of diff content.
+
+**Persona agents (structured JSON output):**
+
+| Persona | Agent | Focus |
+|---------|-------|-------|
+| `correctness` | `systematic:review:correctness-reviewer` | Logic errors, edge cases, state bugs, error propagation, intent compliance |
+| `testing` | `systematic:review:testing-reviewer` | Coverage gaps, weak assertions, brittle tests, missing edge case tests |
+| `maintainability` | `systematic:review:maintainability-reviewer` | Coupling, complexity, naming, dead code, premature abstraction |
+
+**CE agents (unstructured output, synthesized separately):**
+
+| Agent | Focus |
+|-------|-------|
+| `systematic:review:agent-native-reviewer` | Verify new features are agent-accessible |
+| `systematic:research:learnings-researcher` | Search docs/solutions/ for past issues related to this PR's modules and patterns |
+
+## Conditional (5 personas)
+
+Spawned when the orchestrator identifies relevant patterns in the diff. The orchestrator reads the full diff and reasons about selection -- this is agent judgment, not keyword matching.
+
+| Persona | Agent | Select when diff touches... |
+|---------|-------|---------------------------|
+| `security` | `systematic:review:security-reviewer` | Auth middleware, public endpoints, user input handling, permission checks, secrets management |
+| `performance` | `systematic:review:performance-reviewer` | Database queries, ORM calls, loop-heavy data transforms, caching layers, async/concurrent code |
+| `api-contract` | `systematic:review:api-contract-reviewer` | Route definitions, serializer/interface changes, event schemas, exported type signatures, API versioning |
+| `data-migrations` | `systematic:review:data-migrations-reviewer` | Migration files, schema changes, backfill scripts, data transformations |
+| `reliability` | `systematic:review:reliability-reviewer` | Error handling, retry logic, circuit breakers, timeouts, background jobs, async handlers, health checks |
+
+## CE Conditional Agents (migration-specific)
+
+These CE-native agents provide specialized analysis beyond what the persona agents cover. Spawn them when the diff includes database migrations, schema.rb, or data backfills.
+
+| Agent | Focus |
+|-------|-------|
+| `systematic:review:schema-drift-detector` | Cross-references schema.rb changes against included migrations to catch unrelated drift |
+| `systematic:review:deployment-verification-agent` | Produces Go/No-Go deployment checklist with SQL verification queries and rollback procedures |
+
+## Selection rules
+
+1. **Always spawn all 3 always-on personas** plus the 2 CE always-on agents.
+2. **For each conditional persona**, the orchestrator reads the diff and decides whether the persona's domain is relevant. This is a judgment call, not a keyword match.
+3. **For CE conditional agents**, spawn when the diff includes migration files (`db/migrate/*.rb`, `db/schema.rb`) or data backfill scripts.
+4. **Announce the team** before spawning with a one-line justification per conditional reviewer selected.

package/skills/ce-review-beta/references/review-output-template.md

@@ -0,0 +1,115 @@
+# Code Review Output Template
+
+Use this **exact format** when presenting synthesized review findings. Findings are grouped by severity, not by reviewer.
+
+**IMPORTANT:** Use pipe-delimited markdown tables (`| col | col |`). Do NOT use ASCII box-drawing characters.
+
+## Example
+
+```markdown
+## Code Review Results
+
+**Scope:** merge-base with the review base branch -> working tree (14 files, 342 lines)
+**Intent:** Add order export endpoint with CSV and JSON format support
+**Mode:** autonomous
+
+**Reviewers:** correctness, testing, maintainability, security, api-contract
+- security -- new public endpoint accepts user-provided format parameter
+- api-contract -- new /api/orders/export route with response schema
+
+### P0 -- Critical
+
+| # | File | Issue | Reviewer | Confidence | Route |
+|---|------|-------|----------|------------|-------|
+| 1 | `orders_controller.rb:42` | User-supplied ID in account lookup without ownership check | security | 0.92 | `gated_auto -> downstream-resolver` |
+
+### P1 -- High
+
+| # | File | Issue | Reviewer | Confidence | Route |
+|---|------|-------|----------|------------|-------|
+| 2 | `export_service.rb:87` | Loads all orders into memory -- unbounded for large accounts | performance | 0.85 | `safe_auto -> review-fixer` |
+| 3 | `export_service.rb:91` | No pagination -- response size grows linearly with order count | api-contract, performance | 0.80 | `manual -> downstream-resolver` |
+
+### P2 -- Moderate
+
+| # | File | Issue | Reviewer | Confidence | Route |
+|---|------|-------|----------|------------|-------|
+| 4 | `export_service.rb:45` | Missing error handling for CSV serialization failure | correctness | 0.75 | `safe_auto -> review-fixer` |
+
+### P3 -- Low
+
+| # | File | Issue | Reviewer | Confidence | Route |
+|---|------|-------|----------|------------|-------|
+| 5 | `export_helper.rb:12` | Format detection could use early return instead of nested conditional | maintainability | 0.70 | `advisory -> human` |
+
+### Applied Fixes
+
+- `safe_auto`: Added bounded export pagination guard and CSV serialization failure test coverage in this run
+
+### Residual Actionable Work
+
+| # | File | Issue | Route | Next Step |
+|---|------|-------|-------|-----------|
+| 1 | `orders_controller.rb:42` | Ownership check missing on export lookup | `gated_auto -> downstream-resolver` | Create residual todo and require explicit approval before behavior change |
+| 2 | `export_service.rb:91` | Pagination contract needs a broader API decision | `manual -> downstream-resolver` | Create residual todo with contract and client impact details |
+
+### Pre-existing Issues
+
+| # | File | Issue | Reviewer |
+|---|------|-------|----------|
+| 1 | `orders_controller.rb:12` | Broad rescue masking failed permission check | correctness |
+
+### Learnings & Past Solutions
+
+- [Known Pattern] `docs/solutions/export-pagination.md` -- previous export pagination fix applies to this endpoint
+
+### Agent-Native Gaps
+
+- New export endpoint has no CLI/agent equivalent -- agent users cannot trigger exports
+
+### Schema Drift Check
+
+- Clean: schema.rb changes match the migrations in scope
+
+### Deployment Notes
+
+- Pre-deploy: capture baseline row counts before enabling the export backfill
+- Verify: `SELECT COUNT(*) FROM exports WHERE status IS NULL;` should stay at `0`
+- Rollback: keep the old export path available until the backfill has been validated
+
+### Coverage
+
+- Suppressed: 2 findings below 0.60 confidence
+- Residual risks: No rate limiting on export endpoint
+- Testing gaps: No test for concurrent export requests
+
+---
+
+> **Verdict:** Ready with fixes
+>
+> **Reasoning:** 1 critical auth bypass must be fixed. The memory/pagination issues (P1) should be addressed for production safety.
+>
+> **Fix order:** P0 auth bypass -> P1 memory/pagination -> P2 error handling if straightforward
+```
+
+## Formatting Rules
+
+- **Pipe-delimited markdown tables** -- never ASCII box-drawing characters
+- **Severity-grouped sections** -- `### P0 -- Critical`, `### P1 -- High`, `### P2 -- Moderate`, `### P3 -- Low`. Omit empty severity levels.
+- **Always include file:line location** for code review issues
+- **Reviewer column** shows which persona(s) flagged the issue. Multiple reviewers = cross-reviewer agreement.
+- **Confidence column** shows the finding's confidence score
+- **Route column** shows the synthesized handling decision as ``<autofix_class> -> <owner>``.
+- **Header includes** scope, intent, and reviewer team with per-conditional justifications
+- **Mode line** -- include `interactive`, `autonomous`, or `report-only`
+- **Applied Fixes section** -- include only when a fix phase ran in this review invocation
+- **Residual Actionable Work section** -- include only when unresolved actionable findings were handed off for later work
+- **Pre-existing section** -- separate table, no confidence column (these are informational)
+- **Learnings & Past Solutions section** -- results from learnings-researcher, with links to docs/solutions/ files
+- **Agent-Native Gaps section** -- results from agent-native-reviewer. Omit if no gaps found.
+- **Schema Drift Check section** -- results from schema-drift-detector. Omit if the agent did not run.
+- **Deployment Notes section** -- key checklist items from deployment-verification-agent. Omit if the agent did not run.
+- **Coverage section** -- suppressed count, residual risks, testing gaps, failed reviewers
+- **Summary uses blockquotes** for verdict, reasoning, and fix order
+- **Horizontal rule** (`---`) separates findings from verdict
+- **`###` headers** for each section -- never plain text headers

package/skills/ce-review-beta/references/subagent-template.md

@@ -0,0 +1,56 @@
+# Sub-agent Prompt Template
+
+This template is used by the orchestrator to spawn each reviewer sub-agent. Variable substitution slots are filled at spawn time.
+
+---
+
+## Template
+
+```
+You are a specialist code reviewer.
+
+<persona>
+{persona_file}
+</persona>
+
+<scope-rules>
+{diff_scope_rules}
+</scope-rules>
+
+<output-contract>
+Return ONLY valid JSON matching the findings schema below. No prose, no markdown, no explanation outside the JSON object.
+
+{schema}
+
+Rules:
+- Suppress any finding below your stated confidence floor (see your Confidence calibration section).
+- Every finding MUST include at least one evidence item grounded in the actual code.
+- Set pre_existing to true ONLY for issues in unchanged code that are unrelated to this diff. If the diff makes the issue newly relevant, it is NOT pre-existing.
+- You are operationally read-only. You may use non-mutating inspection commands, including read-oriented `git` / `gh` commands, to gather evidence. Do not edit files, change branches, commit, push, create PRs, or otherwise mutate the checkout or repository state.
+- Set `autofix_class` conservatively. Use `safe_auto` only when the fix is local, deterministic, and low-risk. Use `gated_auto` when a concrete fix exists but changes behavior/contracts/permissions. Use `manual` for actionable residual work. Use `advisory` for report-only items that should not become code-fix work.
+- Set `owner` to the default next actor for this finding: `review-fixer`, `downstream-resolver`, `human`, or `release`.
+- Set `requires_verification` to true whenever the likely fix needs targeted tests, a focused re-review, or operational validation before it should be trusted.
+- suggested_fix is optional. Only include it when the fix is obvious and correct. A bad suggestion is worse than none.
+- If you find no issues, return an empty findings array. Still populate residual_risks and testing_gaps if applicable.
+</output-contract>
+
+<review-context>
+Intent: {intent_summary}
+
+Changed files: {file_list}
+
+Diff:
+{diff}
+</review-context>
+```
+
+## Variable Reference
+
+| Variable | Source | Description |
+|----------|--------|-------------|
+| `{persona_file}` | Agent markdown file content | The full persona definition (identity, failure modes, calibration, suppress conditions) |
+| `{diff_scope_rules}` | `references/diff-scope.md` content | Primary/secondary/pre-existing tier rules |
+| `{schema}` | `references/findings-schema.json` content | The JSON schema reviewers must conform to |
+| `{intent_summary}` | Stage 2 output | 2-3 line description of what the change is trying to accomplish |
+| `{file_list}` | Stage 1 output | List of changed files from the scope step |
+| `{diff}` | Stage 1 output | The actual diff content to review |

package/skills/ce-work/SKILL.md

@@ -25,9 +25,11 @@ This command takes a work document (plan, specification, or todo file) and execu
    - Read the work document completely
    - Treat the plan as a decision artifact, not an execution script
    - If the plan includes sections such as `Implementation Units`, `Work Breakdown`, `Requirements Trace`, `Files`, `Test Scenarios`, or `Verification`, use those as the primary source material for execution
+   - Check for `Execution note` on each implementation unit — these carry the plan's execution posture signal for that unit (for example, test-first or characterization-first). Note them when creating tasks.
    - Check for a `Deferred to Implementation` or `Implementation-Time Unknowns` section — these are questions the planner intentionally left for you to resolve during execution. Note them before starting so they inform your approach rather than surprising you mid-task
    - Check for a `Scope Boundaries` section — these are explicit non-goals. Refer back to them if implementation starts pulling you toward adjacent work
    - Review any references or links provided in the plan
+   - If the user explicitly asks for TDD, test-first, or characterization-first execution in this session, honor that request even if the plan has no `Execution note`
    - If anything is unclear or ambiguous, ask clarifying questions now
    - Get user approval to proceed
    - **Do not skip this** - better to ask questions now than build the wrong thing
@@ -79,6 +81,7 @@ This command takes a work document (plan, specification, or todo file) and execu
 3. **Create Todo List**
    - Use your available task tracking tool (e.g., todowrite, task lists) to break the plan into actionable tasks
    - Derive tasks from the plan's implementation units, dependencies, files, test targets, and verification criteria
+   - Carry each unit's `Execution note` into the task when present
    - For each unit, read the `Patterns to follow` field before implementing — these point to specific files or conventions to mirror
    - Use each unit's `Verification` field as the primary "done" signal for that task
    - Do not expect the plan to contain implementation code, micro-step TDD instructions, or exact shell commands
@@ -99,7 +102,7 @@ This command takes a work document (plan, specification, or todo file) and execu
 
    **Subagent dispatch** uses your available subagent or task spawning mechanism. For each unit, give the subagent:
    - The full plan file path (for overall context)
-   - The specific unit's Goal, Files, Approach, Patterns, Test scenarios, and Verification
+   - The specific unit's Goal, Files, Approach, Execution note, Patterns, Test scenarios, and Verification
    - Any resolved deferred questions relevant to that unit
 
    After each subagent completes, update the plan checkboxes and task list before dispatching the next dependent unit.
@@ -125,6 +128,14 @@ This command takes a work document (plan, specification, or todo file) and execu
      - Evaluate for incremental commit (see below)
    ```
 
+   When a unit carries an `Execution note`, honor it. For test-first units, write the failing test before implementation for that unit. For characterization-first units, capture existing behavior before changing it. For units without an `Execution note`, proceed pragmatically.
+
+   Guardrails for execution posture:
+   - Do not write the test and implementation in the same step when working test-first
+   - Do not skip verifying that a new test fails before implementing the fix or feature
+   - Do not over-implement beyond the current behavior slice when working test-first
+   - Skip test-first discipline for trivial renames, pure configuration, and pure styling work
+
    **System-Wide Test Check** — Before marking a task done, pause and ask:
 
    | Question | What to do |
@@ -139,7 +150,6 @@ This command takes a work document (plan, specification, or todo file) and execu
 
    **When this matters most:** Any change that touches models with callbacks, error handling with fallback/retry, or functionality exposed through multiple interfaces.
 
-
 2. **Incremental Commits**
 
    After completing each task, evaluate whether to create an incremental commit:
@@ -176,7 +186,7 @@ This command takes a work document (plan, specification, or todo file) and execu
    - The plan should reference similar code - read those files first
    - Match naming conventions exactly
    - Reuse existing components where possible
-   - Follow project coding standards (see AGENTS.md)
+   - Follow project coding standards (see AGENTS.md; use AGENTS.md only if the repo still keeps a compatibility shim)
    - When in doubt, grep for similar implementations
 
 4. **Test Continuously**
@@ -282,7 +292,7 @@ This command takes a work document (plan, specification, or todo file) and execu
    | `[CONTEXT]` | Context window (if known) | 200K, 1M |
    | `[THINKING]` | Thinking level (if known) | extended thinking |
    | `[HARNESS]` | Tool running you | OpenCode, Codex, Gemini CLI |
-   | `[HARNESS_URL]` | Link to that tool | `https://claude.com/claude-code` |
+   | `[HARNESS_URL]` | Link to that tool | `https://opencode.ai` |
    | `[VERSION]` | `plugin.json` → `version` | 2.40.0 |
 
    Subagents creating commits/PRs are equally responsible for accurate attribution.
@@ -360,7 +370,6 @@ This command takes a work document (plan, specification, or todo file) and execu
 
    ---
 
-   [![Systematic v[VERSION]](https://img.shields.io/badge/Systematic-v[VERSION]-6366f1)](https://github.com/EveryInc/systematic)
    🤖 Generated with [MODEL] ([CONTEXT] context, [THINKING]) via [HARNESS](HARNESS_URL)
    EOF
    )"
@@ -478,4 +487,3 @@ For most features: tests + linting + following patterns is sufficient.
 - **Forgetting to track progress** - Update task status as you go or lose track of what's done
 - **80% done syndrome** - Finish the feature, don't move on early
 - **Over-reviewing simple changes** - Save reviewer agents for complex work
-

package/skills/ce-work-beta/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ce:work-beta
-description: 'Use this skill when executing a plan with the ce:work workflow but you also want optional external delegate execution for implementation-heavy tasks. Ideal for large tasks where token conservation matters and acceptance criteria are already clear.'
+description: '[BETA] Execute work plans with external delegate support. Same as ce:work but includes experimental Codex delegation mode for token-conserving code implementation.'
 argument-hint: '[plan file, specification, or todo file path]'
 disable-model-invocation: true
 ---
@@ -151,7 +151,6 @@ This command takes a work document (plan, specification, or todo file) and execu
 
    **When this matters most:** Any change that touches models with callbacks, error handling with fallback/retry, or functionality exposed through multiple interfaces.
 
-
 2. **Incremental Commits**
 
    After completing each task, evaluate whether to create an incremental commit:
@@ -216,7 +215,15 @@ This command takes a work document (plan, specification, or todo file) and execu
    - Fix visual differences identified
    - Repeat until implementation matches design
 
-6. **Track Progress**
+7. **Frontend Design Guidance** (if applicable)
+
+   For UI tasks without a Figma design -- where the implementation touches view, template, component, layout, or page files, creates user-visible routes, or the plan contains explicit UI/frontend/design language:
+
+   - Load the `frontend-design` skill before implementing
+   - Follow its detection, guidance, and verification flow
+   - If the skill produced a verification screenshot, it satisfies Phase 4's screenshot requirement -- no need to capture separately. If the skill fell back to mental review (no browser access), Phase 4's screenshot capture still applies
+
+8. **Track Progress**
    - Keep the task list updated as you complete tasks
    - Note any blockers or unexpected discoveries
    - Create new tasks if scope expands
@@ -238,7 +245,7 @@ This command takes a work document (plan, specification, or todo file) and execu
 
 2. **Consider Reviewer Agents** (Optional)
 
-   Use for complex, risky, or large changes. Read agents from your local workflow settings frontmatter (`review_agents`). If no settings file exists, invoke the `setup` skill to create one.
+   Use for complex, risky, or large changes. Read agents from `systematic.local.md` frontmatter (`review_agents`). If no settings file, invoke the `setup` skill to create one.
 
    Run configured agents in parallel with task tool. Present findings and address critical issues.
 
@@ -294,7 +301,7 @@ This command takes a work document (plan, specification, or todo file) and execu
    | `[CONTEXT]` | Context window (if known) | 200K, 1M |
    | `[THINKING]` | Thinking level (if known) | extended thinking |
    | `[HARNESS]` | Tool running you | OpenCode, Codex, Gemini CLI |
-   | `[HARNESS_URL]` | Link to that tool | `https://claude.com/claude-code` |
+   | `[HARNESS_URL]` | Link to that tool | `https://opencode.ai` |
    | `[VERSION]` | `plugin.json` → `version` | 2.40.0 |
 
    Subagents creating commits/PRs are equally responsible for accurate attribution.
@@ -372,7 +379,6 @@ This command takes a work document (plan, specification, or todo file) and execu
 
    ---
 
-   [![Systematic v[VERSION]](https://img.shields.io/badge/Systematic-v[VERSION]-6366f1)](https://github.com/marcusrbrown/systematic)
    🤖 Generated with [MODEL] ([CONTEXT] context, [THINKING]) via [HARNESS](HARNESS_URL)
    EOF
    )"
@@ -439,7 +445,7 @@ This mode integrates with the existing Phase 1 Step 4 strategy selection as a **
 
 External delegation activates when any of these conditions are met:
 - The user says "use codex for this work", "delegate to codex", or "delegate mode"
-- A plan implementation unit contains `Execution target: external-delegate` in its Execution note (set by ce:plan-beta or ce:plan)
+- A plan implementation unit contains `Execution target: external-delegate` in its Execution note (set by ce:plan)
 
 The specific delegate tool is resolved at execution time. Currently the only supported delegate is Codex CLI. Future delegates can be added without changing plan files.
 
@@ -462,7 +468,7 @@ When external delegation is active, follow this workflow for each tagged task. D
 
    Verify the delegate CLI is installed. If not found, print "Delegate CLI not installed - continuing with standard mode." and proceed normally.
 
-2. **Build prompt** — For each task, assemble a prompt from the plan's implementation unit (Goal, Files, Approach, and project conventions). Include rules: no git commits, no PRs, run `git status` and `git diff --stat` when done. Never embed credentials or tokens in the prompt - pass auth through environment variables.
+2. **Build prompt** — For each task, assemble a prompt from the plan's implementation unit (Goal, Files, Approach, Conventions from `systematic.local.md`). Include rules: no git commits, no PRs, run `git status` and `git diff --stat` when done. Never embed credentials or tokens in the prompt - pass auth through environment variables.
 
 3. **Write prompt to file** — Save the assembled prompt to a unique temporary file to avoid shell quoting issues and cross-task races. Use a unique filename per task.
 

package/skills/claude-permissions-optimizer/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: claude-permissions-optimizer
 context: fork
-description: Use this skill when you want to reduce OpenCode permission prompts by safely allowlisting frequently used Bash commands based on real session history. Best for permission fatigue and repetitive approvals without broadly weakening safety.
+description: Optimize Claude Code permissions by finding safe Bash commands from session history and auto-applying them to settings.json. Can run from any coding agent but targets Claude Code specifically. Use when experiencing permission fatigue, too many permission prompts, wanting to optimize permissions, or needing to set up allowlists. Triggers on "optimize permissions", "reduce permission prompts", "allowlist commands", "too many permission prompts", "permission fatigue", "permission setup", or complaints about clicking approve too often.
 subtask: true
 ---
 
-# OpenCode Permissions Optimizer
+# Claude Permissions Optimizer
 
 Find safe Bash commands that are causing unnecessary permission prompts and auto-allow them in `settings.json` -- evidence-based, not prescriptive.
 
@@ -13,19 +13,19 @@ This skill identifies commands safe to auto-allow based on actual session histor
 
 ## Pre-check: Confirm environment
 
-Determine whether you are currently running inside OpenCode or a different coding agent (Codex, Gemini CLI, Cursor, etc.).
+Determine whether you are currently running inside Claude Code or a different coding agent (Codex, Gemini CLI, Cursor, etc.).
 
-**If running inside OpenCode:** Proceed directly to Step 1.
+**If running inside Claude Code:** Proceed directly to Step 1.
 
 **If running in a different agent:** Inform the user before proceeding:
 
-> "This skill analyzes OpenCode session history and writes to OpenCode settings.json. You're currently in [agent name], but I can still optimize your OpenCode permissions from here -- the results will apply next time you use OpenCode."
+> "This skill analyzes Claude Code session history and writes to Claude Code's settings.json. You're currently in [agent name], but I can still optimize your Claude Code permissions from here -- the results will apply next time you use Claude Code."
 
-Then proceed to Step 1 normally. The skill works from any environment as long as `~/.config/opencode/` (or `$OPENCODE_CONFIG_DIR`) exists on the machine.
+Then proceed to Step 1 normally. The skill works from any environment as long as `~/.claude/` (or `$CLAUDE_CONFIG_DIR`) exists on the machine.
 
 ## Step 1: Choose Analysis Scope
 
-Ask the user how broadly to analyze using the platform's blocking question tool (`question` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini). If no question tool is available, present the numbered options and wait for the user's reply.
+Ask the user how broadly to analyze using the platform's blocking question tool (`question` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini). If no question tool is available, present the numbered options and wait for the user's reply.
 
 1. **All projects** (Recommended) -- sessions across every project
 2. **This project only** -- sessions for the current working directory
@@ -123,8 +123,8 @@ Use `greenRawCount` (the number of unique raw commands the green patterns cover)
 
 The recommendations table is already displayed. Use the platform's blocking question tool to ask for the decision:
 
-1. **Apply all to user settings** (`~/.config/opencode/settings.json`)
-2. **Apply all to project settings** (`.opencode/settings.json`)
+1. **Apply all to user settings** (`~/.claude/settings.json`)
+2. **Apply all to project settings** (`.claude/settings.json`)
 3. **Skip**
 
 If the user wants to exclude specific items, they can reply in free text (e.g., "all except 3 and 7 to user settings"). The numbered table is already visible for reference -- no need to re-list items in the question tool.
@@ -146,16 +146,17 @@ For each target settings file:
 After successful verification:
 
 ```
-Applied N rules to ~/.config/opencode/settings.json
-Applied M rules to .opencode/settings.json
+Applied N rules to ~/.claude/settings.json
+Applied M rules to .claude/settings.json
 
 These commands will no longer trigger permission prompts.
 ```
 
-If `.opencode/settings.json` was modified and is tracked by git, mention that committing it would benefit teammates.
+If `.claude/settings.json` was modified and is tracked by git, mention that committing it would benefit teammates.
 
 ## Edge Cases
 
 - **No project context** (running outside a project): Only offer user-level settings as write target.
-- **Settings file doesn't exist**: Create it with `{ "permissions": { "allow": [] } }`. For `.opencode/settings.json`, also create the `.opencode/` directory if needed.
-- **Deny rules**: If a deny rule already blocks a command, warn rather than adding an allow rule (deny takes precedence in OpenCode).
+- **Settings file doesn't exist**: Create it with `{ "permissions": { "allow": [] } }`. For `.claude/settings.json`, also create the `.claude/` directory if needed.
+- **Deny rules**: If a deny rule already blocks a command, warn rather than adding an allow rule (deny takes precedence in Claude Code).
+