@fro.bot/systematic 2.7.3 → 2.8.0

package/agents/workflow/systematic-implementer.md

@@ -0,0 +1,39 @@
+---
+name: systematic-implementer
+description: Implements one plan unit in a fresh subagent context and reports bounded changes back to the orchestrator.
+mode: subagent
+---
+
+You are a focused implementer dispatched by a parent OpenCode session orchestrating a multi-unit plan. You implement one unit's worth of changes and report back to the orchestrator.
+
+## Role
+
+Execute exactly the assigned slice of the plan. Treat the parent session as the owner of sequencing, final verification, git operations, and release decisions.
+
+## Constraints
+
+- Do not stage files (`git add`), create commits, or run the project test suite. The orchestrator handles testing, staging, and committing after all parallel units complete.
+- Do not push to remote.
+- Do not edit the plan document, task list, checkboxes, or orchestration state. Report completion status to the orchestrator instead.
+- Stay within the assigned unit's scope unless the implementation cannot be completed safely without touching adjacent files. If that happens, make the smallest necessary change and call it out explicitly in your final response.
+- Do not start unrelated cleanup or refactors. If you see follow-up work, report it instead of doing it.
+
+## Approach
+
+1. Read the plan path and unit details provided by the orchestrator.
+2. Identify the unit's Goal, Files, Approach, Execution note, Patterns to follow, Test scenarios, and Verification criteria.
+3. Inspect the referenced files and local patterns before editing.
+4. Make the bounded file edits needed for the assigned unit.
+5. Run the narrowest affected test or check command relevant to the files you touched. If no targeted check exists, say so. Do not run the full project test suite.
+6. If the unit changes behavior, ensure the provided test scenarios cover happy paths, edge cases, error paths, and integration boundaries where applicable. Add or adjust targeted tests only when the assigned unit calls for it.
+7. Stop and report if the plan is ambiguous, the declared file scope is wrong, or a required dependency is missing.
+
+## Output
+
+Your final response to the orchestrator must include:
+
+- Summary of changes made.
+- Files modified.
+- Targeted checks run and their results.
+- Any deviations from the unit's declared Files list.
+- Any unresolved questions, blocked work, or issues requiring orchestrator attention before the next dispatch.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fro.bot/systematic",
-  "version": "2.7.3",
+  "version": "2.8.0",
   "description": "Structured engineering workflows for OpenCode",
   "type": "module",
   "homepage": "https://fro.bot/systematic",

package/skills/ce-work/SKILL.md

@@ -141,11 +141,22 @@ Determine how to proceed based on what was provided in `<input_document>`.
 
    Even with no file overlap, parallel subagents sharing a working directory face git index contention (concurrent staging/committing corrupts the index) and test interference (concurrent test runs pick up each other's in-progress changes). The parallel subagent constraints below mitigate these.
 
-   **Subagent dispatch** uses your available subagent or task spawning mechanism. For each unit, give the subagent:
+   **Subagent dispatch** uses OpenCode's `task` tool with the bundled `systematic-implementer` subagent:
+
+   ```typescript
+   task({
+     subagent_type: "systematic-implementer",
+     description: <unit goal>,
+     prompt: <unit prompt body>,
+   })
+   ```
+
+   `description` carries the one-line unit Goal. `prompt` carries the plan path plus the unit's Files, Approach, Execution note, Patterns, Test scenarios, Verification, and relevant resolved deferred questions. For each unit, give the subagent:
    - The full plan file path (for overall context)
    - The specific unit's Goal, Files, Approach, Execution note, Patterns, Test scenarios, and Verification
    - Any resolved deferred questions relevant to that unit
    - Instruction to check whether the unit's test scenarios cover all applicable categories (happy paths, edge cases, error paths, integration) and supplement gaps before writing tests
+   - Instruction not to edit the plan document, task list, checkboxes, or orchestration state. Subagents report completion status instead
 
    **Parallel subagent constraints** — when dispatching units in parallel (not serial or inline):
    - Instruct each subagent: "Do not stage files (`git add`), create commits, or run the project test suite. The orchestrator handles testing, staging, and committing after all parallel units complete."

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

@@ -1,416 +0,0 @@
----
-name: ce:work-beta
-description: "[BETA] Execute work with external delegate support. Same as ce:work but includes experimental Codex delegation mode for token-conserving code implementation."
-disable-model-invocation: true
-argument-hint: "[Plan doc path or description of work. Blank to auto use latest plan doc] [delegate:codex]"
----
-
-# Work Execution Command
-
-Execute work efficiently while maintaining quality and finishing features.
-
-## Introduction
-
-This command takes a work document (plan, specification, or todo file) or a bare prompt describing the work, and executes it systematically. The focus is on **shipping complete features** by understanding requirements quickly, following existing patterns, and maintaining quality throughout.
-
-**Beta rollout note:** Invoke `ce:work-beta` manually when you want to trial Codex delegation. During the beta period, planning and workflow handoffs remain pointed at stable `ce:work` to avoid dual-path orchestration complexity.
-
-## Input Document
-
-<input_document> #$ARGUMENTS </input_document>
-
-## Argument Parsing
-
-Parse `$ARGUMENTS` for the following optional tokens. Strip each recognized token before interpreting the remainder as the plan file path or bare prompt.
-
-| Token | Example | Effect |
-|-------|---------|--------|
-| `delegate:codex` | `delegate:codex` | Activate Codex delegation mode for plan execution |
-| `delegate:local` | `delegate:local` | Deactivate delegation even if enabled in config |
-
-All tokens are optional. When absent, fall back to the resolution chain below.
-
-**Fuzzy activation:** Also recognize imperative delegation-intent phrases such as "use codex", "delegate to codex", "codex mode", or "delegate mode" as equivalent to `delegate:codex`. A bare mention of "codex" in a prompt (e.g., "fix codex converter bugs") must NOT activate delegation -- only clear delegation intent triggers it.
-
-**Fuzzy deactivation:** Also recognize phrases such as "no codex", "local mode", "standard mode" as equivalent to `delegate:local`.
-
-### Settings Resolution Chain
-
-After extracting tokens from arguments, resolve the delegation state using this precedence chain:
-
-1. **Argument flag** -- `delegate:codex` or `delegate:local` from the current invocation (highest priority)
-2. **Config file** -- extract settings from the config block below. Value `codex` for `work_delegate` activates delegation; `false` deactivates.
-3. **Hard default** -- `false` (delegation off)
-
-**Config (pre-resolved):**
-!`cat "$(git rev-parse --show-toplevel 2>/dev/null)/.systematic/config.local.yaml" 2>/dev/null || cat "$(dirname "$(git rev-parse --path-format=absolute --git-common-dir 2>/dev/null)")/.systematic/config.local.yaml" 2>/dev/null || echo '__NO_CONFIG__'`
-
-If the block above contains YAML key-value pairs, extract values for the keys listed below.
-If it shows `__NO_CONFIG__`, the file does not exist — all settings fall through to defaults.
-If it shows an unresolved command string, read `.systematic/config.local.yaml` from the repo root using the native file-read tool (e.g., Read in OpenCode, read_file in Codex). If the file does not exist, all settings fall through to defaults.
-
-If any setting has an unrecognized value, fall through to the hard default for that setting.
-
-Config keys:
-- `work_delegate` -- `codex` or default `false`
-- `work_delegate_consent` -- `true` or default `false`
-- `work_delegate_sandbox` -- `yolo` (default) or `full-auto`
-- `work_delegate_decision` -- `auto` (default) or `ask`
-- `work_delegate_model` -- Codex model to use (default `gpt-5.4`). Passthrough — any valid model name accepted.
-- `work_delegate_effort` -- `minimal`, `low`, `medium`, `high` (default), or `xhigh`
-
-Store the resolved state for downstream consumption:
-- `delegation_active` -- boolean, whether delegation mode is on
-- `delegation_source` -- `argument` or `config` or `default` -- how delegation was resolved (used by environment guard to decide notification verbosity)
-- `sandbox_mode` -- `yolo` or `full-auto` (from config or default `yolo`)
-- `consent_granted` -- boolean (from config `work_delegate_consent`)
-- `delegate_model` -- string (from config or default `gpt-5.4`)
-- `delegate_effort` -- string (from config or default `high`)
-
----
-
-## Execution Workflow
-
-### Phase 0: Input Triage
-
-Determine how to proceed based on what was provided in `<input_document>`.
-
-**Plan document** (input is a file path to an existing plan, specification, or todo file) → skip to Phase 1.
-
-**Bare prompt** (input is a description of work, not a file path):
-
-1. **Scan the work area**
-
-   - Identify files likely to change based on the prompt
-   - Find existing test files for those areas (search for test/spec files that import, reference, or share names with the implementation files)
-   - Note local patterns and conventions in the affected areas
-
-2. **Assess complexity and route**
-
-   | Complexity | Signals | Action |
-   |-----------|---------|--------|
-   | **Trivial** | 1-2 files, no behavioral change (typo, config, rename) | Proceed to Phase 1 step 2 (environment setup), then implement directly — no task list, no execution loop. Apply Test Discovery if the change touches behavior-bearing code |
-   | **Small / Medium** | Clear scope, under ~10 files | Build a task list from discovery. Proceed to Phase 1 step 2 |
-   | **Large** | Cross-cutting, architectural decisions, 10+ files, touches auth/payments/migrations | Inform the user this would benefit from `/ce:brainstorm` or `/ce:plan` to surface edge cases and scope boundaries. Honor their choice. If proceeding, build a task list and continue to Phase 1 step 2 |
-
----
-
-### Phase 1: Quick Start
-
-1. **Read Plan and Clarify** _(skip if arriving from Phase 0 with a bare prompt)_
-
-   - 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
-
-2. **Setup Environment**
-
-   First, check the current branch:
-
-   ```bash
-   current_branch=$(git branch --show-current)
-   default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
-
-   # Fallback if remote HEAD isn't set
-   if [ -z "$default_branch" ]; then
-     default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master")
-   fi
-   ```
-
-   **If already on a feature branch** (not the default branch):
-
-   First, check whether the branch name is **meaningful** — a name like `feat/crowd-sniff` or `fix/email-validation` tells future readers what the work is about. Auto-generated worktree names (e.g., `worktree-jolly-beaming-raven`) or other opaque names do not.
-
-   If the branch name is meaningless or auto-generated, suggest renaming it before continuing:
-   ```bash
-   git branch -m <meaningful-name>
-   ```
-   Derive the new name from the plan title or work description (e.g., `feat/crowd-sniff`). Present the rename as a recommended option alongside continuing as-is.
-
-   Then ask: "Continue working on `[current_branch]`, or create a new branch?"
-   - If continuing (with or without rename), proceed to step 3
-   - If creating new, follow Option A or B below
-
-   **If on the default branch**, choose how to proceed:
-
-   **Option A: Create a new branch**
-   ```bash
-   git pull origin [default_branch]
-   git checkout -b feature-branch-name
-   ```
-   Use a meaningful name based on the work (e.g., `feat/user-authentication`, `fix/email-validation`).
-
-   **Option B: Use a worktree (recommended for parallel development)**
-   ```bash
-   skill: git-worktree
-   # The skill will create a new branch from the default branch in an isolated worktree
-   ```
-
-   **Option C: Continue on the default branch**
-   - Requires explicit user confirmation
-   - Only proceed after user explicitly says "yes, commit to [default_branch]"
-   - Never commit directly to the default branch without explicit permission
-
-   **Recommendation**: Use worktree if:
-   - You want to work on multiple features simultaneously
-   - You want to keep the default branch clean while experimenting
-   - You plan to switch between branches frequently
-
-3. **Create Todo List** _(skip if Phase 0 already built one, or if Phase 0 routed as Trivial)_
-   - 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
-   - Include dependencies between tasks
-   - Prioritize based on what needs to be done first
-   - Include testing and quality check tasks
-   - Keep tasks specific and completable
-
-4. **Choose Execution Strategy**
-
-   **Delegation routing gate:** If `delegation_active` is true AND the input is a plan file (not a bare prompt), read `references/codex-delegation-workflow.md` and follow its Pre-Delegation Checks and Delegation Decision flow. If all checks pass and delegation proceeds, force **serial execution** and proceed directly to Phase 2 using the workflow's batched execution loop. If any check disables delegation, fall through to the standard strategy table below. If delegation is active but the input is a bare prompt (no plan file), set `delegation_active` to false with a brief note: "Codex delegation requires a plan file -- using standard mode." and continue with the standard strategy selection below.
-
-   After creating the task list, decide how to execute based on the plan's size and dependency structure:
-
-   | Strategy | When to use |
-   |----------|-------------|
-   | **Inline** | 1-2 small tasks, or tasks needing user interaction mid-flight. **Default for bare-prompt work** — bare prompts rarely produce enough structured context to justify subagent dispatch |
-   | **Serial subagents** | 3+ tasks with dependencies between them. Each subagent gets a fresh context window focused on one unit — prevents context degradation across many tasks. Requires plan-unit metadata (Goal, Files, Approach, Test scenarios) |
-   | **Parallel subagents** | 3+ tasks that pass the Parallel Safety Check (below). Dispatch independent units simultaneously, run dependent units after their prerequisites complete. Requires plan-unit metadata |
-
-   **Parallel Safety Check** — required before choosing parallel dispatch:
-
-   1. Build a file-to-unit mapping from every candidate unit's `Files:` section (Create, Modify, and Test paths)
-   2. Check for intersection — any file path appearing in 2+ units means overlap
-   3. If any overlap is found, downgrade to serial subagents. Log the reason (e.g., "Units 2 and 4 share `config/routes.rb` — using serial dispatch"). Serial subagents still provide context-window isolation without shared-directory risks
-
-   Even with no file overlap, parallel subagents sharing a working directory face git index contention (concurrent staging/committing corrupts the index) and test interference (concurrent test runs pick up each other's in-progress changes). The parallel subagent constraints below mitigate these.
-
-   **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, Execution note, Patterns, Test scenarios, and Verification
-   - Any resolved deferred questions relevant to that unit
-   - Instruction to check whether the unit's test scenarios cover all applicable categories (happy paths, edge cases, error paths, integration) and supplement gaps before writing tests
-
-   **Parallel subagent constraints** — when dispatching units in parallel (not serial or inline):
-   - Instruct each subagent: "Do not stage files (`git add`), create commits, or run the project test suite. The orchestrator handles testing, staging, and committing after all parallel units complete."
-   - These constraints prevent git index contention and test interference between concurrent subagents
-
-   **Permission mode:** Omit the `mode` parameter when dispatching subagents so the user's configured permission settings apply. Do not pass `mode: "auto"` — it overrides user-level settings like `bypassPermissions`.
-
-   **After each subagent completes (serial mode):**
-   1. Review the subagent's diff — verify changes match the unit's scope and `Files:` list
-   2. Run the relevant test suite to confirm the tree is healthy
-   3. If tests fail, diagnose and fix before proceeding — do not dispatch dependent units on a broken tree
-   4. Update the plan checkboxes and task list
-   5. Dispatch the next unit
-
-   **After all parallel subagents in a batch complete:**
-   1. Wait for every subagent in the current parallel batch to finish before acting on any of their results
-   2. Cross-check for discovered file collisions: compare the actual files modified by all subagents in the batch (not just their declared `Files:` lists). Subagents may create or modify files not anticipated during planning — this is expected, since plans describe *what* not *how*. A collision only matters when 2+ subagents in the same batch modified the same file. In a shared working directory, only the last writer's version survives — the other unit's changes to that file are lost. If a collision is detected: commit all non-colliding files from all units first, then re-run the affected units serially for the shared file so each builds on the other's committed work
-   3. For each completed unit, in dependency order: review the diff, run the relevant test suite, stage only that unit's files, and commit with a conventional message derived from the unit's Goal
-   4. If tests fail after committing a unit's changes, diagnose and fix before committing the next unit
-   5. Update the plan checkboxes and task list
-   6. Dispatch the next batch of independent units, or the next dependent unit
-
-### Phase 2: Execute
-
-1. **Task Execution Loop**
-
-   For each task in priority order:
-
-   ```
-   while (tasks remain):
-     - Mark task as in-progress
-     - Read any referenced files from the plan or discovered during Phase 0
-     - Look for similar patterns in codebase
-     - Find existing test files for implementation files being changed (Test Discovery — see below)
-     - If delegation_active: branch to the Codex Delegation Execution Loop
-       (see `references/codex-delegation-workflow.md`)
-     - Otherwise: implement following existing conventions
-     - Add, update, or remove tests to match implementation changes (see Test Discovery below)
-     - Run System-Wide Test Check (see below)
-     - Run tests after changes
-     - Assess testing coverage: did this task change behavior? If yes, were tests written or updated? If no tests were added, is the justification deliberate (e.g., pure config, no behavioral change)?
-     - Mark task as completed
-     - 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
-
-   **Test Discovery** — Before implementing changes to a file, find its existing test files (search for test/spec files that import, reference, or share naming patterns with the implementation file). When a plan specifies test scenarios or test files, start there, then check for additional test coverage the plan may not have enumerated. Changes to implementation files should be accompanied by corresponding test updates — new tests for new behavior, modified tests for changed behavior, removed or updated tests for deleted behavior.
-
-   **Test Scenario Completeness** — Before writing tests for a feature-bearing unit, check whether the plan's `Test scenarios` cover all categories that apply to this unit. If a category is missing or scenarios are vague (e.g., "validates correctly" without naming inputs and expected outcomes), supplement from the unit's own context before writing tests:
-
-   | Category | When it applies | How to derive if missing |
-   |----------|----------------|------------------------|
-   | **Happy path** | Always for feature-bearing units | Read the unit's Goal and Approach for core input/output pairs |
-   | **Edge cases** | When the unit has meaningful boundaries (inputs, state, concurrency) | Identify boundary values, empty/nil inputs, and concurrent access patterns |
-   | **Error/failure paths** | When the unit has failure modes (validation, external calls, permissions) | Enumerate invalid inputs the unit should reject, permission/auth denials it should enforce, and downstream failures it should handle |
-   | **Integration** | When the unit crosses layers (callbacks, middleware, multi-service) | Identify the cross-layer chain and write a scenario that exercises it without mocks |
-
-   **System-Wide Test Check** — Before marking a task done, pause and ask:
-
-   | Question | What to do |
-   |----------|------------|
-   | **What fires when this runs?** Callbacks, middleware, observers, event handlers — trace two levels out from your change. | Read the actual code (not docs) for callbacks on models you touch, middleware in the request chain, `after_*` hooks. |
-   | **Do my tests exercise the real chain?** If every dependency is mocked, the test proves your logic works *in isolation* — it says nothing about the interaction. | Write at least one integration test that uses real objects through the full callback/middleware chain. No mocks for the layers that interact. |
-   | **Can failure leave orphaned state?** If your code persists state (DB row, cache, file) before calling an external service, what happens when the service fails? Does retry create duplicates? | Trace the failure path with real objects. If state is created before the risky call, test that failure cleans up or that retry is idempotent. |
-   | **What other interfaces expose this?** Mixins, DSLs, alternative entry points (Agent vs Chat vs ChatMethods). | Grep for the method/behavior in related classes. If parity is needed, add it now — not as a follow-up. |
-   | **Do error strategies align across layers?** Retry middleware + application fallback + framework error handling — do they conflict or create double execution? | List the specific error classes at each layer. Verify your rescue list matches what the lower layer actually raises. |
-
-   **When to skip:** Leaf-node changes with no callbacks, no state persistence, no parallel interfaces. If the change is purely additive (new helper method, new view partial), the check takes 10 seconds and the answer is "nothing fires, skip."
-
-   **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:
-
-   | Commit when... | Don't commit when... |
-   |----------------|---------------------|
-   | Logical unit complete (model, service, component) | Small part of a larger unit |
-   | Tests pass + meaningful progress | Tests failing |
-   | About to switch contexts (backend → frontend) | Purely scaffolding with no behavior |
-   | About to attempt risky/uncertain changes | Would need a "WIP" commit message |
-
-   **Heuristic:** "Can I write a commit message that describes a complete, valuable change? If yes, commit. If the message would be 'WIP' or 'partial X', wait."
-
-   If the plan has Implementation Units, use them as a starting guide for commit boundaries — but adapt based on what you find during implementation. A unit might need multiple commits if it's larger than expected, or small related units might land together. Use each unit's Goal to inform the commit message.
-
-   **Commit workflow:**
-   ```bash
-   # 1. Verify tests pass (use project's test command)
-   # Examples: bin/rails test, npm test, pytest, go test, etc.
-
-   # 2. Stage only files related to this logical unit (not `git add .`)
-   git add <files related to this logical unit>
-
-   # 3. Commit with conventional message
-   git commit -m "feat(scope): description of this unit"
-   ```
-
-   **Handling merge conflicts:** If conflicts arise during rebasing or merging, resolve them immediately. Incremental commits make conflict resolution easier since each commit is small and focused.
-
-   **Note:** Incremental commits use clean conventional messages without attribution footers. The final Phase 4 commit/PR includes the full attribution.
-
-   **Parallel subagent mode:** When units run as parallel subagents, the subagents do not commit — the orchestrator handles staging and committing after the entire parallel batch completes (see Parallel subagent constraints in Phase 1 Step 4). The commit guidance in this section applies to inline and serial execution, and to the orchestrator's commit decisions after parallel batch completion.
-
-3. **Follow Existing Patterns**
-
-   - 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; use AGENTS.md only if the repo still keeps a compatibility shim)
-   - When in doubt, grep for similar implementations
-
-4. **Test Continuously**
-
-   - Run relevant tests after each significant change
-   - Don't wait until the end to test
-   - Fix failures immediately
-   - Add new tests for new behavior, update tests for changed behavior, remove tests for deleted behavior
-   - **Unit tests with mocks prove logic in isolation. Integration tests with real objects prove the layers work together.** If your change touches callbacks, middleware, or error handling — you need both.
-
-5. **Simplify as You Go**
-
-   After completing a cluster of related implementation units (or every 2-3 units), review recently changed files for simplification opportunities — consolidate duplicated patterns, extract shared helpers, and improve code reuse and efficiency. This is especially valuable when using subagents, since each agent works with isolated context and can't see patterns emerging across units.
-
-   Don't simplify after every single unit — early patterns may look duplicated but diverge intentionally in later units. Wait for a natural phase boundary or when you notice accumulated complexity.
-
-   If a `/simplify` skill or equivalent is available, use it. Otherwise, review the changed files yourself for reuse and consolidation opportunities.
-
-6. **Figma Design Sync** (if applicable)
-
-   For UI work with Figma designs:
-
-   - Implement components following design specs
-   - Use figma-design-sync agent iteratively to compare
-   - Fix visual differences identified
-   - Repeat until implementation matches design
-
-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
-   - Keep user informed of major milestones
-
-### Phase 3-4: Quality Check and Ship It
-
-When all Phase 2 tasks are complete and execution transitions to quality check, read `references/shipping-workflow.md` for the full shipping workflow: quality checks, code review, final validation, PR creation, and notification.
-
----
-
-## Codex Delegation Mode
-
-When `delegation_active` is true after argument parsing, read `references/codex-delegation-workflow.md` for the complete delegation workflow: pre-checks, batching, prompt template, execution loop, and result classification.
-
----
-
-## Key Principles
-
-### Start Fast, Execute Faster
-
-- Get clarification once at the start, then execute
-- Don't wait for perfect understanding - ask questions and move
-- The goal is to **finish the feature**, not create perfect process
-
-### The Plan is Your Guide
-
-- Work documents should reference similar code and patterns
-- Load those references and follow them
-- Don't reinvent - match what exists
-
-### Test As You Go
-
-- Run tests after each change, not at the end
-- Fix failures immediately
-- Continuous testing prevents big surprises
-
-### Quality is Built In
-
-- Follow existing patterns
-- Write tests for new code
-- Run linting before pushing
-- Review every change — inline for simple additive work, full review for everything else
-
-### Ship Complete Features
-
-- Mark all tasks completed before moving on
-- Don't leave features 80% done
-- A finished feature that ships beats a perfect feature that doesn't
-
-## Common Pitfalls to Avoid
-
-- **Analysis paralysis** - Don't overthink, read the plan and execute
-- **Skipping clarifying questions** - Ask now, not after building wrong thing
-- **Ignoring plan references** - The plan has links for a reason
-- **Testing at the end** - Test continuously or suffer later
-- **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
-- **Skipping review** - Every change gets reviewed; only the depth varies

package/skills/ce-work-beta/references/codex-delegation-workflow.md

@@ -1,327 +0,0 @@
-# Codex Delegation Workflow
-
-When `delegation_active` is true, code implementation is delegated to the Codex CLI (`codex exec`) instead of being implemented directly. The orchestrating OpenCode agent retains control of planning, review, git operations, and orchestration.
-
-## Delegation Decision
-
-If `work_delegate_decision` is `ask`, present the recommendation and wait for the user's choice before proceeding.
-
-**When recommending Codex delegation:**
-
-> "Codex delegation active. [N] implementation units -- delegating in one batch."
-> 1. Delegate to Codex *(recommended)*
-> 2. Execute with OpenCode instead
-
-**When recommending Codex delegation, multiple batches:**
-
-> "Codex delegation active. [N] implementation units -- delegating in [X] batches."
-> 1. Delegate to Codex *(recommended)*
-> 2. Execute with OpenCode instead
-
-**When recommending OpenCode (all units are trivial):**
-
-> "Codex delegation active, but these are small changes where the cost of delegating outweighs having OpenCode do them."
-> 1. Execute with OpenCode *(recommended)*
-> 2. Delegate to Codex anyway
-
-If the user chooses the delegation option, proceed to Pre-Delegation Checks below. If the user chooses the OpenCode option, set `delegation_active` to false and return to standard execution in the parent skill.
-
-If `work_delegate_decision` is `auto` (the default), state the execution plan in one line and proceed without waiting: "Codex delegation active. Delegating [N] units in [X] batch(es)." If all units are trivial, set `delegation_active` to false and proceed: "Codex delegation active. All units are trivial -- executing with OpenCode."
-
-## Pre-Delegation Checks
-
-Run these checks **once before the first batch**. If any check fails, fall back to standard mode for the remainder of the plan execution. Do not re-run on subsequent batches.
-
-**0. Platform Gate**
-
-Codex delegation is only supported when the orchestrating agent is running in OpenCode. If the current session is Codex, Gemini CLI, OpenCode, or any other platform, set `delegation_active` to false and proceed in standard mode.
-
-**1. Environment Guard**
-
-Check whether the current agent is already running inside a Codex sandbox:
-
-```bash
-if [ -n "$CODEX_SANDBOX" ] || [ -n "$CODEX_SESSION_ID" ]; then
-  echo "inside_sandbox=true"
-else
-  echo "inside_sandbox=false"
-fi
-```
-
-If `inside_sandbox` is true, delegation would recurse or fail.
-
-- If `delegation_source` is `argument`: emit "Already inside Codex sandbox -- using standard mode." and set `delegation_active` to false.
-- If `delegation_source` is `config` or `default`: set `delegation_active` to false silently.
-
-**2. Availability Check**
-
-**Codex availability (pre-resolved):**
-!`command -v codex >/dev/null 2>&1 && echo "CODEX_AVAILABLE" || echo "CODEX_NOT_FOUND"`
-
-If the line above shows `CODEX_AVAILABLE`, proceed to the next check.
-If it shows `CODEX_NOT_FOUND`, the Codex CLI is not installed. Emit "Codex CLI not found (install via `npm install -g @openai/codex` or `brew install codex`) -- using standard mode." and set `delegation_active` to false.
-If it shows an unresolved command string, run `command -v codex` using a shell tool. If the command prints a path, proceed. If it fails or prints nothing, emit the same message and set `delegation_active` to false.
-
-**3. Consent Flow**
-
-If `consent_granted` is not true (from config `work_delegate_consent`):
-
-Present a one-time consent warning using the platform's blocking question tool (`question` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension)). The consent warning explains:
-- Delegation sends implementation units to `codex exec` as a structured prompt
-- **yolo mode** (`--yolo`): Full system access including network. Required for verification steps that run tests or install dependencies. **Recommended.**
-- **full-auto mode** (`--full-auto`): Workspace-write sandbox, no network access.
-
-Present the sandbox mode choice: (1) yolo (recommended), (2) full-auto.
-
-On acceptance:
-- Resolve the repo root: `git rev-parse --show-toplevel`. Write `work_delegate_consent: true` and `work_delegate_sandbox: <chosen-mode>` to `<repo-root>/.systematic/config.local.yaml`
-- To write: (1) if file or directory does not exist, create `<repo-root>/.systematic/` and write the YAML file; (2) if file exists, merge new keys preserving existing keys
-- Update `consent_granted` and `sandbox_mode` in the resolved state
-
-On decline:
-- Ask whether to disable delegation entirely for this project
-- If yes: write `work_delegate: false` to `<repo-root>/.systematic/config.local.yaml` (using the same repo root resolved above). To write: (1) if file or directory does not exist, create `<repo-root>/.systematic/` and write the YAML file; (2) if file exists, merge new keys preserving existing keys. Set `delegation_active` to false, proceed in standard mode
-- If no: set `delegation_active` to false for this invocation only, proceed in standard mode
-
-**Headless consent:** If running in a headless or non-interactive context, delegation proceeds only if `work_delegate_consent` is already `true` in the config file. If consent is not recorded, set `delegation_active` to false silently.
-
-## Batching
-
-Delegate all units in one batch. If the plan exceeds 5 units, split into batches at the plan's own phase boundaries, or in groups of roughly 5 -- never splitting units that share files. Skip delegation entirely if every unit is trivial.
-
-## Prompt Template
-
-At the start of delegated execution, create a per-run OS-temp scratch directory via `mktemp -d` and capture its **absolute path** for all downstream use. All scratch files for this invocation live under that directory. Do not use `.context/` — these scratch files are per-run throwaway that get cleaned up when delegated execution ends (see Cleanup below), matching the repo Scratch Space convention for one-shot artifacts. Do not pass unresolved shell-variable strings to non-shell tools (Write, Read); use the absolute path returned by `mktemp -d`.
-
-```bash
-SCRATCH_DIR="$(mktemp -d -t ce-work-codex-XXXXXX)"
-echo "$SCRATCH_DIR"
-```
-
-Refer to the echoed absolute path as `<scratch-dir>` throughout the rest of this workflow.
-
-Before each batch, write a prompt file to `<scratch-dir>/prompt-batch-<batch-num>.md`.
-
-Build the prompt from the batch's implementation units using these XML-tagged sections:
-
-```xml
-<task>
-[For a single-unit batch: Goal from the implementation unit.
-For a multi-unit batch: list each unit with its Goal, stating the concrete
-job, repository context, and expected end state for each.]
-</task>
-
-<files>
-[Combined file list from all units in the batch -- files to create, modify, or read.]
-</files>
-
-<patterns>
-[File paths from all units' "Patterns to follow" fields. If no patterns:
-"No explicit patterns referenced -- follow existing conventions in the
-modified files."]
-</patterns>
-
-<approach>
-[For a single-unit batch: Approach from the unit.
-For a multi-unit batch: list each unit's approach, noting dependencies
-and suggested ordering.]
-</approach>
-
-<constraints>
-- Do NOT run git commit, git push, or create PRs -- the orchestrating agent handles all git operations
-- Restrict all modifications to files within the repository root
-- Keep changes tightly scoped to the stated task -- avoid unrelated refactors, renames, or cleanup
-- Resolve the task fully before stopping -- do not stop at the first plausible answer
-- If you discover mid-execution that you need to modify files outside the repo root, complete what you can within the repo and report what you could not do via the result schema issues field
-</constraints>
-
-<testing>
-Before writing tests, check whether the plan's test scenarios cover all
-categories that apply to each unit. Supplement gaps before writing tests:
-- Happy path: core input/output pairs from each unit's goal
-- Edge cases: boundary values, empty/nil inputs, type mismatches
-- Error/failure paths: invalid inputs, permission denials, downstream failures
-- Integration: cross-layer scenarios that mocks alone won't prove
-
-Write tests that name specific inputs and expected outcomes. If your changes
-touch code with callbacks, middleware, or event handlers, verify the
-interaction chain works end-to-end.
-</testing>
-
-<verify>
-After implementing, run ALL test files together in a single command (not
-per-file). Cross-file contamination (e.g., mocked globals leaking between
-test files) only surfaces when tests run in the same process. If tests
-fail, fix the issues and re-run until they pass. Do not report status
-"completed" unless verification passes. This is your responsibility --
-the orchestrator will not re-run verification independently.
-
-[Test and lint commands from the project. Use the union of all units'
-verification commands as a single combined invocation.]
-</verify>
-
-<output_contract>
-Report your result via the --output-schema mechanism. Fill in every field:
-- status: "completed" ONLY if all changes were made AND verification passes,
-  "partial" if incomplete, "failed" if no meaningful progress
-- files_modified: array of file paths you changed
-- issues: array of strings describing any problems, gaps, or out-of-scope
-  work discovered
-- summary: one-paragraph description of what was done
-- verification_summary: what you ran to verify (command and outcome).
-  Example: "Ran `bun test` -- 14 tests passed, 0 failed."
-  If no verification was possible, say why.
-</output_contract>
-```
-
-## Result Schema
-
-Write the result schema to `<scratch-dir>/result-schema.json` (using the absolute path captured at the start) once at the start of delegated execution:
-
-```json
-{
-  "type": "object",
-  "properties": {
-    "status": { "enum": ["completed", "partial", "failed"] },
-    "files_modified": { "type": "array", "items": { "type": "string" } },
-    "issues": { "type": "array", "items": { "type": "string" } },
-    "summary": { "type": "string" },
-    "verification_summary": { "type": "string" }
-  },
-  "required": ["status", "files_modified", "issues", "summary", "verification_summary"],
-  "additionalProperties": false
-}
-```
-
-Each batch's result is written to `<scratch-dir>/result-batch-<batch-num>.json` via the `-o` flag. On plan failure, files are left in place for debugging.
-
-If the result JSON is absent or malformed after a successful exit code, classify as task failure.
-
-## Execution Loop
-
-Initialize a `consecutive_failures` counter at 0 before the first batch.
-
-**Clean-baseline preflight:** Before the first batch, verify there are no uncommitted changes to tracked files:
-
-```bash
-git diff --quiet HEAD
-```
-
-This intentionally ignores untracked files. Only staged or unstaged modifications to tracked files make rollback unsafe. However, if untracked files exist at paths in the batch's planned Files list, rollback (`git clean -fd -- <paths>`) would delete them. If such overlaps are detected, warn the user and recommend committing or stashing those files before proceeding.
-
-If tracked files are dirty, stop and present options: (1) commit current changes, (2) stash explicitly (`git stash push -m "pre-delegation"`), (3) continue in standard mode (sets `delegation_active` to false). Do not auto-stash user changes.
-
-**Delegation invocation:** For each batch, execute these as **separate Bash tool calls** (not combined into one):
-
-**Step A — Launch (background, separate Bash call):**
-
-Write the prompt file, then make a single Bash tool call with `run_in_background: true` set on the tool parameter. This call returns immediately and has no timeout ceiling.
-
-Substitute the literal absolute path captured at setup for every `<scratch-dir>` below. Each Bash tool call starts a fresh shell, so the `$SCRATCH_DIR` variable from the setup snippet is not preserved — an unresolved `$SCRATCH_DIR` would expand empty and break result detection.
-
-```bash
-# Substitute the resolved sandbox_mode value (yolo or full-auto) from the skill state
-SANDBOX_MODE="<sandbox_mode>"
-
-# Resolve sandbox flag
-if [ "$SANDBOX_MODE" = "full-auto" ]; then
-  SANDBOX_FLAG="--full-auto"
-else
-  SANDBOX_FLAG="--dangerously-bypass-approvals-and-sandbox"
-fi
-
-codex exec \
-  $SANDBOX_FLAG \
-  --output-schema "<scratch-dir>/result-schema.json" \
-  -o "<scratch-dir>/result-batch-<batch-num>.json" \
-  - < "<scratch-dir>/prompt-batch-<batch-num>.md"
-```
-
-**Conditional flags** — only include each line when the corresponding skill-state value is set:
-
-- If `delegate_model` is set, insert `  -m "<delegate_model>" \` as a line before `$SANDBOX_FLAG`.
-- If `delegate_effort` is set, insert `  -c 'model_reasoning_effort="<delegate_effort>"' \` as a line before `$SANDBOX_FLAG`.
-
-When either value is unset, omit its line entirely — Codex resolves the default from the user's `~/.codex/config.toml` (and ultimately the CLI's own built-in default). Do not substitute a placeholder string for unset values.
-
-Critical: `run_in_background: true` must be set as a **Bash tool parameter**, not as a shell `&` suffix. The tool parameter is what removes the timeout ceiling. A shell `&` inside a foreground Bash call still hits the 2-minute default timeout.
-
-Quoting is critical for the `-c` flag when present: use single quotes around the entire key=value and double quotes around the TOML string value inside. Example: `-c 'model_reasoning_effort="high"'`.
-
-Do not improvise CLI flags or modify this invocation template beyond the documented conditional insertions.
-
-**Step B — Poll (foreground, separate Bash calls):**
-
-After the launch call returns, make a **new, separate** foreground Bash tool call that polls for the result file. This keeps the agent's turn active so the user cannot interfere with the working tree.
-
-Substitute the literal absolute path captured at setup for `<scratch-dir>`. The shell variable from Step A does not survive across separate Bash tool calls.
-
-```bash
-RESULT_FILE="<scratch-dir>/result-batch-<batch-num>.json"
-for i in $(seq 1 6); do
-  test -s "$RESULT_FILE" && echo "DONE" && exit 0
-  sleep 10
-done
-echo "Waiting for Codex..."
-```
-
-If the output is "Waiting for Codex...", issue the same polling command again as another separate Bash call. Repeat until the output is "DONE", then read the result file and proceed to classification.
-
-**Polling termination conditions:** Stop polling when any of these conditions is met:
-
-- **Result file appears** (output is "DONE") -- proceed to result classification normally.
-- **Background process exits with non-zero code** -- classify as CLI failure (row 1). Rollback and fall back to standard mode.
-- **Background process exits with zero code but result file is absent** -- classify as task failure (row 2: exit 0, result JSON missing). Rollback and increment `consecutive_failures`.
-- **5 polling rounds** elapse (~5 minutes) without the result file appearing and without a background process notification -- treat as a hung process. Classify as CLI failure (row 1). Rollback and fall back to standard mode.
-
-**Result classification:** Codex is responsible for running verification internally and fixing failures before reporting -- the orchestrator does not re-run verification independently.
-
-| # | Signal | Classification | Action |
-|---|--------|---------------|--------|
-| 1 | Exit code != 0 | CLI failure | Rollback to HEAD. Fall back to standard mode for ALL remaining work. |
-| 2 | Exit code 0, result JSON missing or malformed | Task failure | Rollback to HEAD. Increment `consecutive_failures`. |
-| 3 | Exit code 0, `status: "failed"` | Task failure | Rollback to HEAD. Increment `consecutive_failures`. |
-| 4 | Exit code 0, `status: "partial"` | Partial success | Keep the diff. Complete remaining work locally, verify, and commit. Increment `consecutive_failures`. |
-| 5 | Exit code 0, `status: "completed"` | Success | Commit changes. Reset `consecutive_failures` to 0. |
-
-**Result handoff — surface to user:** After reading the result JSON and before committing or rolling back, display a summary so the user sees what happened. Format:
-
-> **Codex batch <batch-num> — <classification>**
-> <summary from result JSON>
->
-> **Files:** <comma-separated list from files_modified>
-> **Verification:** <verification_summary from result JSON>
-> **Issues:** <issues list, or "None">
-
-On failure or partial results, include the classification reason (e.g., "status: failed", "result JSON missing") so the user understands why the orchestrator is rolling back or completing locally.
-
-Keep this brief — the goal is transparency, not a wall of text. One short block per batch.
-
-**Rollback procedure:**
-
-```bash
-git checkout -- .
-git clean -fd -- <paths from the batch's combined Files list>
-```
-
-Do NOT use bare `git clean -fd` without path arguments.
-
-**Commit on success:**
-
-```bash
-git add $(git diff --name-only HEAD; git ls-files --others --exclude-standard)
-git commit -m "feat(<scope>): <batch summary>"
-```
-
-**Between batches** (plans split into multiple batches): Report what completed, test results, and what's next. Continue immediately unless the user intervenes -- the checkpoint exists so the user *can* steer, not so they *must*.
-
-**Circuit breaker:** After 3 consecutive failures, set `delegation_active` to false and emit: "Codex delegation disabled after 3 consecutive failures -- completing remaining units in standard mode."
-
-**Scratch cleanup:** No explicit cleanup needed — OS temp handles eventual cleanup (macOS `$TMPDIR` periodic purge; Linux/WSL `/tmp` reboot or periodic cleanup). Leaving `<scratch-dir>` in place after the run also preserves intermediate artifacts for debugging if anything went wrong.
-
-## Mixed-Model Attribution
-
-When some units are executed by Codex and others locally:
-- If all units used delegation: attribute to the Codex model
-- If all units used standard mode: attribute to the current agent's model
-- If mixed: note which units were delegated in the PR description and credit both models

package/skills/ce-work-beta/references/shipping-workflow.md

@@ -1,129 +0,0 @@
-# Shipping Workflow
-
-This file contains the shipping workflow (Phase 3-4). Load it only when all Phase 2 tasks are complete and execution transitions to quality check.
-
-## Phase 3: Quality Check
-
-1. **Run Core Quality Checks**
-
-   Always run before submitting:
-
-   ```bash
-   # Run full test suite (use project's test command)
-   # Examples: bin/rails test, npm test, pytest, go test, etc.
-
-   # Run linting (per AGENTS.md)
-   # Use linting-agent before pushing to origin
-   ```
-
-2. **Code Review** (REQUIRED)
-
-   Every change gets reviewed before shipping. The depth scales with the change's risk profile, but review itself is never skipped.
-
-   **Tier 2: Full review (default)** -- REQUIRED unless Tier 1 criteria are explicitly met. Invoke the `ce-code-review` skill with `mode:autofix` to run specialized reviewer agents, auto-apply safe fixes, and record residual downstream work in the per-run artifact. When the plan file path is known, pass it as `plan:<path>`. This is the mandatory default -- proceed to Tier 1 only after confirming every criterion below.
-
-   **Tier 1: Inline self-review** -- A lighter alternative permitted only when **all four** criteria are true. Before choosing Tier 1, explicitly state which criteria apply and why. If any criterion is uncertain, use Tier 2.
-   - Purely additive (new files only, no existing behavior modified)
-   - Single concern (one skill, one component -- not cross-cutting)
-   - Pattern-following (implementation mirrors an existing example with no novel logic)
-   - Plan-faithful (no scope growth, no deferred questions resolved with surprising answers)
-
-3. **Residual Work Gate** (REQUIRED when Tier 2 ran)
-
-   After Tier 2 code review completes, inspect the Residual Actionable Work summary it returned (or read the run artifact directly if the summary was not emitted). If one or more residual `downstream-resolver` findings remain, do not proceed to Final Validation until the user decides how to handle them.
-
-   Ask the user using the platform's blocking question tool (`question` in OpenCode with `ToolSearch select:question` pre-loaded if needed, `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension)). Fall back to numbered options in chat only when the harness genuinely lacks a blocking tool. Never silently skip the gate.
-
-   Stem: `Code review found N residual finding(s) the skill did not auto-fix. How should the agent proceed?`
-
-   Options (four or fewer, self-contained labels):
-   - `Apply/fix now` — loop back into review with focused fixes; the agent investigates each finding, applies changes where safe, and re-runs review.
-   - `File tickets via project tracker` — load `references/tracker-defer.md` in Interactive mode; the agent files tickets in the project's detected tracker (or `gh` fallback, or leaves them in the report if no sink exists) and proceeds to Final Validation.
-   - `Accept and proceed` — record the residual findings verbatim in a durable "Known Residuals" sink before shipping. If a PR will be created or updated in Phase 4, include them in the PR description's "Known Residuals" section (the agent owns this when calling `ce-commit-push-pr`). If the user later chooses the no-PR `ce-commit` path, create `docs/residual-review-findings/<branch-or-head-sha>.md`, include the accepted findings and source review-run context, stage it with the implementation commit, and mention the file path in the final summary. The user has acknowledged the risk, but the findings must not live only in the transient session.
-   - `Stop — do not ship` — abort the shipping workflow. The user will handle findings manually before re-invoking.
-
-   Skip this gate entirely when the review reported `Residual actionable work: none.` or when only Tier 1 (inline self-review) was used. Do not proceed past this gate on an `Accept and proceed` decision until the agent has recorded whether the durable sink is `PR Known Residuals` or `docs/residual-review-findings/<branch-or-head-sha>.md`.
-
-4. **Final Validation**
-   - All tasks marked completed
-   - Testing addressed -- tests pass and new/changed behavior has corresponding test coverage (or an explicit justification for why tests are not needed)
-   - Linting passes
-   - Code follows existing patterns
-   - Figma designs match (if applicable)
-   - No console errors or warnings
-   - If the plan has a `Requirements` section (or legacy `Requirements Trace`), verify each requirement is satisfied by the completed work
-   - If any `Deferred to Implementation` questions were noted, confirm they were resolved during execution
-
-5. **Prepare Operational Validation Plan** (REQUIRED)
-   - Add a `## Post-Deploy Monitoring & Validation` section to the PR description for every change.
-   - Include concrete:
-     - Log queries/search terms
-     - Metrics or dashboards to watch
-     - Expected healthy signals
-     - Failure signals and rollback/mitigation trigger
-     - Validation window and owner
-   - If there is truly no production/runtime impact, still include the section with: `No additional operational monitoring required` and a one-line reason.
-
-## Phase 4: Ship It
-
-1. **Prepare Evidence Context**
-
-   Do not invoke `ce-demo-reel` directly in this step. Evidence capture belongs to the PR creation or PR description update flow, where the final PR diff and description context are available.
-
-   Note whether the completed work has observable behavior (UI rendering, CLI output, API/library behavior with a runnable example, generated artifacts, or workflow output). The `ce-commit-push-pr` skill will ask whether to capture evidence only when evidence is possible.
-
-2. **Update Plan Status**
-
-   If the input document has YAML frontmatter with a `status` field, update it to `completed`:
-   ```
-   status: active  ->  status: completed
-   ```
-
-3. **Commit and Create Pull Request**
-
-   Load the `ce-commit-push-pr` skill to handle committing, pushing, and PR creation. The skill handles convention detection, branch safety, logical commit splitting, adaptive PR descriptions, and attribution badges.
-
-   When providing context for the PR description, include:
-   - The plan's summary and key decisions
-   - Testing notes (tests added/modified, manual testing performed)
-   - Evidence context from step 1, so `ce-commit-push-pr` can decide whether to ask about capturing evidence
-   - Figma design link (if applicable)
-   - The Post-Deploy Monitoring & Validation section (see Phase 3 Step 5)
-   - Any "Known Residuals" accepted in the Phase 3 Residual Work Gate, rendered as a dedicated section in the PR body with severity, file:line, and title per finding
-
-   If the user prefers to commit without creating a PR, load the `ce-commit` skill instead.
-
-4. **Notify User**
-   - Summarize what was completed
-   - Link to PR (if one was created)
-   - Note any follow-up work needed
-   - Suggest next steps if applicable
-
-## Quality Checklist
-
-Before creating PR, verify:
-
-- [ ] All clarifying questions asked and answered
-- [ ] All tasks marked completed
-- [ ] Testing addressed -- tests pass AND new/changed behavior has corresponding test coverage (or an explicit justification for why tests are not needed)
-- [ ] Linting passes (use linting-agent)
-- [ ] Code follows existing patterns
-- [ ] Figma designs match implementation (if applicable)
-- [ ] Evidence decision handled by `ce-commit-push-pr` when the change has observable behavior
-- [ ] Commit messages follow conventional format
-- [ ] PR description includes Post-Deploy Monitoring & Validation section (or explicit no-impact rationale)
-- [ ] Code review completed (inline self-review or full `ce-code-review`)
-- [ ] PR description includes summary, testing notes, and evidence when captured
-- [ ] PR description includes Compound Engineered badge with accurate model and harness
-
-## Code Review Tiers
-
-Every change gets reviewed. The tier determines depth, not whether review happens.
-
-**Tier 2 (full review)** -- REQUIRED default. Invoke `ce-code-review mode:autofix` with `plan:<path>` when available. Safe fixes are applied automatically; residual work is recorded in the run artifact for downstream routing. Always use this tier unless all four Tier 1 criteria are explicitly confirmed.
-
-**Tier 1 (inline self-review)** -- permitted only when all four are true (state each explicitly before choosing):
-- Purely additive (new files only, no existing behavior modified)
-- Single concern (one skill, one component -- not cross-cutting)
-- Pattern-following (mirrors an existing example, no novel logic)
-- Plan-faithful (no scope growth, no surprising deferred-question resolutions)