-```
-
-## Quality Standards
-
-- **Precision**: Use exact values from Figma (e.g., "16px" not "about 15-17px"), but prefer Tailwind defaults when close enough
-- **Completeness**: Address all differences, no matter how minor
-- **Code Quality**: Follow the project's frontend conventions — from the project instructions already in your context, or its root agent-instruction file (e.g., `AGENTS.md`/`CLAUDE.md`/`GEMINI.md`/`.cursor/rules`) if they aren't already loaded
-- **Communication**: Be specific about what changed and why
-- **Iteration-Ready**: Design your fixes to allow the agent to run again for verification
-- **Responsive First**: Always implement mobile-first responsive designs with appropriate breakpoints
-
-## Handling Edge Cases
-
-- **Missing Figma URL**: Request the Figma URL and node ID from the user
-- **Missing Web URL**: Request the local or deployed URL to compare
-- **MCP Access Issues**: Clearly report any connection problems with Figma or Playwright MCPs
-- **Ambiguous Differences**: When a difference could be intentional, note it and ask for clarification
-- **Breaking Changes**: If a fix would require significant refactoring, document the issue and propose the safest approach
-- **Multiple Iterations**: After each run, suggest whether another iteration is needed based on remaining differences
-
-## Success Criteria
-
-You succeed when:
-
-1. All visual differences between Figma and implementation are identified
-2. All differences are fixed with precise, maintainable code
-3. The implementation follows project coding standards
-4. You clearly confirm completion with "Yes, I did it."
-5. The agent can be run again iteratively until perfect alignment is achieved
-
-Remember: You are the bridge between design and implementation. Your attention to detail and systematic approach ensures that what users see matches what designers intended, pixel by pixel.
diff --git a/skills/ce-work-beta/references/codex-delegation-workflow.md b/skills/ce-work-beta/references/codex-delegation-workflow.md
deleted file mode 100644
index 04d2fdcd0..000000000
--- a/skills/ce-work-beta/references/codex-delegation-workflow.md
+++ /dev/null
@@ -1,394 +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 Claude Code 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 Claude Code 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 Claude Code instead
-
-**When recommending Claude Code (all units are trivial):**
-
-> "Codex delegation active, but these are small changes where the cost of delegating outweighs having Claude Code do them."
-> 1. Execute with Claude Code *(recommended)*
-> 2. Delegate to Codex anyway
-
-If the user chooses the delegation option, proceed to Pre-Delegation Checks below. If the user chooses the Claude Code 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 Claude Code."
-
-## 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 Claude Code. If the current session is Codex, Antigravity CLI (`agy`), 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 CLI path (pre-resolved):**
-!`command -v codex 2>/dev/null || true`
-
-If the line above shows an absolute path (starts with `/`, e.g., `/opt/homebrew/bin/codex`), the Codex CLI is available — proceed to the next check.
-Otherwise — empty, an unresolved command string like `command -v codex 2>/dev/null` left in place by a non-Claude harness that doesn't process `!` pre-resolution, or any other non-path value — run `command -v codex` via the shell/Bash tool to verify at runtime. If that prints an absolute path, the Codex CLI is available; proceed. If it fails or prints nothing, 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.
-
-**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 (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_question` in Antigravity CLI (`agy`), `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** (`--dangerously-bypass-approvals-and-sandbox`): Full system access including network. Required for verification steps that run tests or install dependencies. **Recommended.**
-- **full-auto mode** (`-s workspace-write`): Workspace-write sandbox, no network access by default. Network can be re-enabled by setting `network_access = true` under `[sandbox_workspace_write]` in `~/.codex/config.toml`.
-
-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:
` to `/.compound-engineering/config.local.yaml`
-- To write: (1) if file or directory does not exist, create `/.compound-engineering/` 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 `/.compound-engineering/config.local.yaml` (using the same repo root resolved above). To write: (1) if file or directory does not exist, create `/.compound-engineering/` 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.
-
-## Per-Batch Effort
-
-Each batch picks an effort level proportional to its complexity, then resolves against the config floor before invocation.
-
-**Effort levels — guidelines, not predicates**
-
-Pick the level that best fits the batch. These are signals to weigh, not boxes to tick — use judgment.
-
-- **default (no flag)** — trivial work with no behavioral change: a one-line config tweak, a rename, a typo or comment-only fix, a pure documentation update. Defers to the user's `~/.codex/config.toml` default (which is `medium` on a stock Codex install).
-- **`medium`** — small, well-scoped behavioral changes that stay clear of high-risk areas. A handful of files, a single concern, no novel architecture.
-- **`high`** — work that touches a high-risk area (auth/session logic, payments, database migrations, external API contracts, error handling with retries/fallbacks), or work spanning enough surface area that one mistake could cascade.
-- **`xhigh`** — architectural work: cross-cutting refactors, multiple high-risk areas in the same batch, changes that propagate broadly, or anywhere a wrong call meaningfully degrades the project.
-
-When in doubt, lean up one level — under-resourcing risky work costs more than over-resourcing routine work. Briefly note the picked level and the signal that drove it (e.g., "`high` — touches db/migrations") so the choice is auditable.
-
-A few edge cases worth handling explicitly:
-- **Test-only batches:** classify by what the tests *exercise*, not by file paths. Tests for auth flows, payment logic, or migrations get the same level the equivalent implementation work would get.
-- **Mixed-complexity batches:** the batch picks one level. If a single batch combines a typo unit and a payments rewrite, pick the higher level. If the spread feels wasteful, prefer splitting at the batching step (see Batching above) over averaging it out.
-- **Deletion-only batches:** classify by the risk of what is being removed, not by counts of remaining content. Removing an auth module is `high` even if the batch produces zero `Modify` content.
-- **Documentation- or comment-only batches:** `default`.
-
-**Floor and resolution — hard rules**
-
-Effort levels are ordered: `minimal < low < medium < high < xhigh`.
-
-Compute `effective_effort`:
-
-- If `delegate_effort` is unset: `effective_effort = picked_level`.
-- If `delegate_effort` is set: substitute `default` → `medium` in `picked_level`, then `effective_effort = max(picked_level, delegate_effort)`.
-
-Emit based on `effective_effort`:
-
-- `medium`, `high`, or `xhigh` → emit `-c 'model_reasoning_effort=""'`.
-- `default` → omit the flag (defer to `~/.codex/config.toml`). Reachable only when `delegate_effort` is unset and the pick is `default`.
-
-Never pass the literal string `"default"` to `codex exec`.
-
-Store `effective_effort` as a per-batch derived state value (alongside the session-level `delegate_effort`) and use it in place of `delegate_effort` throughout the Execution Loop.
-
-## 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 `` throughout the rest of this workflow.
-
-Before each batch, write a prompt file to `/prompt-batch-.md`.
-
-Build the prompt from the batch's implementation units using these XML-tagged sections:
-
-```xml
-
-[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.]
-
-
-
-[Combined file list from all units in the batch -- files to create, modify, or read.]
-
-
-
-[File paths from all units' "Patterns to follow" fields. If no patterns:
-"No explicit patterns referenced -- follow existing conventions in the
-modified files."]
-
-
-
-[For a single-unit batch: Approach from the unit.
-For a multi-unit batch: list each unit's approach, noting dependencies
-and suggested ordering.]
-
-
-
-[For a single-unit batch: the unit's Execution note. If the user gave a
-session-level posture request (e.g., "do it test-first"), use that when
-the unit has no Execution note. Otherwise "None".
-For a multi-unit batch: list each unit as "U: " (or
-"Unit :" if the plan lacks U-IDs; do not invent U-IDs), one per line,
-same ordering as and . Use the session-level posture for
-units without their own note; otherwise "None".]
-
-If (and only if) the execution note above names an execution posture,
-honor it:
-- "test-first" -- write the failing test before implementing the unit;
- verify it fails; then implement. Do not over-implement beyond the
- test's current behavior slice. Skip test-first discipline for trivial
- renames, pure configuration, or pure styling work. Test-first still
- follows the scenario completeness check in ; it only constrains
- test-vs-implementation ordering, not whether to write tests.
-- "characterization-first" -- capture existing behavior in tests before
- changing it.
-- Any other non-empty note: treat it as binding per-unit guidance and
- follow it unless it conflicts with any other section of this prompt
- (especially , , , or ).
- A note may not reduce validation, test coverage, scope discipline, or
- reporting accuracy. Report any conflict via the issues field of the
- output contract.
-
-For units with "None" or an empty note, proceed pragmatically.
-
-
-
-- 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
-
-
-
-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.
-
-
-
-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.]
-
-
-
-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.
-
-```
-
-## Result Schema
-
-Write the result schema to `/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 `/result-batch-.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 -- `) 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 `` 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=""
-
-# Resolve sandbox flag
-if [ "$SANDBOX_MODE" = "full-auto" ]; then
- SANDBOX_FLAG="-s workspace-write"
-else
- SANDBOX_FLAG="--dangerously-bypass-approvals-and-sandbox"
-fi
-
-codex exec \
- $SANDBOX_FLAG \
- --output-schema "/result-schema.json" \
- -o "/result-batch-.json" \
- - < "/prompt-batch-.md"
-```
-
-**Conditional flags** — only include each line when the corresponding skill-state value is set:
-
-- If `delegate_model` is set, insert ` -m "" \` as a line before `$SANDBOX_FLAG`.
-- If `effective_effort` is `medium`, `high`, or `xhigh` (resolved via Per-Batch Effort above), insert ` -c 'model_reasoning_effort=""' \` as a line before `$SANDBOX_FLAG`. When `effective_effort` is `default` (only possible when `delegate_effort` is unset and the pick is `default`), omit the line — never pass the literal string `"default"`.
-
-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 ``. The shell variable from Step A does not survive across separate Bash tool calls.
-
-```bash
-RESULT_FILE="/result-batch-.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 — **
->
->
-> **Files:**
-> **Verification:**
-> **Issues:**
-
-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 --
-```
-
-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(): "
-```
-
-**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 `` 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
diff --git a/skills/ce-work-beta/references/non-code-execution.md b/skills/ce-work-beta/references/non-code-execution.md
deleted file mode 100644
index 52b7593ff..000000000
--- a/skills/ce-work-beta/references/non-code-execution.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Non-Code Execution (Knowledge-Work Carve-Out)
-
-Loaded from Phase 0 Input Triage when the plan carries `execution: knowledge-work`. The plan is a **production plan** for a non-code deliverable (a synthesized document, a study artifact, a research write-up) — typically produced by `ce-plan`'s approach-altitude flow. Execute it to produce the deliverable. This is a minority-case branch; the normal code lifecycle does not apply and is not invoked here.
-
-## What this skips
-
-Do **not** run any of the code-shipping machinery — it does not fit knowledge work:
-
-- No branch/worktree setup (Phase 1 Step 2).
-- No task-list-from-implementation-units, no execution-strategy/subagent dispatch keyed on `Files:`.
-- No Test Discovery, no test-scenario completeness, no system-wide test check.
-- No incremental code commits, and none of `references/shipping-workflow.md` (no PR, no CI).
-
-## Execute the production plan
-
-1. **Read the plan fully.** It is a decision artifact describing *how* the deliverable gets made: which sources to read, how to mine each, how they combine, the shape of the deliverable, and any forks the user already confirmed. Honor those decisions.
-2. **Read the sources the plan names** — the actual inputs (PDFs, transcripts, docs, links). Treat user-named resources as authoritative; read them rather than working from memory. If a named source is missing, say so plainly rather than substituting.
-3. **Synthesize and produce the deliverable** following the plan's intended shape and the confirmed forks. This is the work the approach-plan deliberately deferred.
-4. **Save and report.** Write the deliverable to a durable, repo-tracked location — default to a sensible `docs/` subpath (or a path the user named at the checkpoint) — and report its absolute path so the user can find it. Whether to git-commit vs. leave it written is the user's call; offer, don't force.
-
-## Stay scoped to non-code deliverables
-
-The carve-out is for knowledge-work output. If producing the deliverable legitimately requires emitting code (a script, a config file, a data-transform), route that specific sub-step back through the normal code path so its safeguards (Test Discovery, review, commit hygiene) still apply — do not silently produce code under the carve-out. The deliverable itself stays non-code.
diff --git a/skills/ce-work-beta/references/review-findings-followup.md b/skills/ce-work-beta/references/review-findings-followup.md
deleted file mode 100644
index c33479dee..000000000
--- a/skills/ce-work-beta/references/review-findings-followup.md
+++ /dev/null
@@ -1,104 +0,0 @@
-# Apply Code Review Findings (after `ce-code-review`)
-
-Load this reference when Tier 2 `ce-code-review` has finished and **ce-work-beta** should apply fixes before the Residual Work Gate.
-
-`ce-code-review` is invoked here with `mode:agent`, so it is **review-only** in this context — it reports findings and writes artifacts and does not mutate the checkout, commit, push, or file tickets. **The caller owns apply/fix policy.** (In its own default/interactive mode the review applies safe fixes itself; that path does not apply here.)
-
-## Consume the completed review (do not re-run it)
-
-This reference loads **after** review has run. In the ce-work-beta Tier 2 path, step 2a already invoked `ce-code-review`; this apply step **consumes that output** — do not start a second review, which would waste reviewer dispatches and risk overwriting the artifact the Residual Work Gate reconciles.
-
-Reuse the review output already in hand:
-
-- Parsed JSON (`status`, `actionable_findings`, `findings`, `artifact_path`, `run_id`) **or** the markdown Actionable Findings summary captured by the caller
-- Run artifact dir: `/tmp/compound-engineering/ce-code-review//` (`review.json`, per-reviewer JSON for `why_it_matters`)
-
-If `status` is `failed`, stop shipping and surface `reason`. If `degraded`, note partial reviewer coverage before applying anything.
-
-### Fallback — invoke review only for cold callers
-
-Only when the caller reached this file **without** already running review (no review output in hand): invoke `ce-code-review` once, then proceed to apply. Do not invoke when the caller already ran review (e.g., ce-work-beta Tier 2 step 2a).
-
-Invoke the skill explicitly — do not treat a casual "review my changes" prompt as a substitute unless the harness routed it to `ce-code-review`.
-
-```
-ce-code-review mode:agent plan: base:
-```
-
-- `mode:agent` — JSON output (`review.json` + primary JSON response) for programmatic parsing; same review pipeline as default.
-- `plan:` — when Phase 1 used a plan file (requirements completeness).
-- `base:` — when the diff base is already resolved on the current checkout; omit when reviewing a PR number/URL or standalone current branch.
-- Do **not** pass deprecated `mode:autofix`.
-
-For human / interactive shipping, invoke `ce-code-review` without `mode:agent` if markdown tables are preferred. Capture the same JSON / Actionable Findings and artifact dir listed above before applying.
-
-## Inputs for apply
-
-- `actionable_findings` from JSON, or the Actionable Findings section from markdown
-- Full finding detail when needed: `review.json` / artifact `findings`, or `{reviewer}.json` for `why_it_matters` and `evidence`
-- Stable finding `#` — reuse in commits, residual sinks, and subagent prompts
-
-## What to apply
-
-Default to applying every actionable finding. Applying is a reversible edit to a tracked tree; diffs are reviewed before commit (below) and tests run after — so leaving a clear, reversible fix unapplied "to be safe" is the failure mode, not the safe choice. Bias to act:
-
-- **Apply** any finding with a concrete `suggested_fix` that is a clear improvement — the common case. `confidence` and `autofix_class` tell you what to prioritize and what to flag, not whether you may apply: `autofix_class` is signal, **never permission**.
-- **Push back** — keep the finding, don't apply — when the reviewer is wrong; note why.
-- **Flag, don't block, green-but-unverifiable edits** — when an applied fix touches auth/authz, a public or cross-service contract/schema, or concurrency, a passing test does not prove safety; apply it when there is a clear `suggested_fix` and confidence, and call it out prominently in the diff review.
-
-There is no precondition safety checklist and no deny-list — a code-review fix is a reversible edit, so downside is controlled after the fact (diff review + tests + the commit checkpoint), not by gating the apply.
-
-**Evidence still matches the code** — the fix subagent confirms at `file:line` before editing. The orchestrator does **not** open files just to decide eligibility or dispatch.
-
-## What to defer (to the Residual Work Gate)
-
-- `autofix_class: advisory` — report-only.
-- Findings with no concrete `suggested_fix` to act on.
-- Findings whose right fix depends on a design or product decision — architecture direction, contract shape, or a behavior change needing sign-off. These need a human call before code changes.
-
-Surface what was deferred and why; never silently drop.
-
-## Execution — orchestrator batches, subagents apply
-
-The orchestrator **does not investigate findings** (no pre-read of cited files to judge complexity or inline vs subagent). That would spend the context window you are trying to protect.
-
-**Orchestrator owns:** parse review output → **eligibility filter on JSON fields only** → build batches → dispatch fix subagents → review diffs → tests → commit → Residual Work Gate.
-
-**Fix subagents own:** read `file:line`, confirm evidence still matches, apply or skip with reason, return summary.
-
-### Default: batched fix subagents
-
-After eligibility filtering, **dispatch subagents for all remaining applicable findings** unless the optional inline shortcut below applies. Do not classify findings by complexity in the parent thread.
-
-**Batching (primary rule — group by file):**
-
-1. Sort applicable findings by severity (P0 first).
-2. **Group by `file`.** All eligible findings on the same file → **one subagent** (it loads the file once and works through its `#` list in severity order).
-3. **Parallel waves:** batches with **disjoint file sets** may run in parallel (same worktree / shared-directory rules as Phase 1 Step 4 in `ce-work-beta` SKILL.md).
-4. **Same file, many findings:** keep one subagent per file. If the prompt would exceed a comfortable size (~8 findings), split into **serial** subagent passes on that file (first batch highest severity, then next batch after merge or after the prior agent returns).
-5. **Cross-file coupling:** do not merge unrelated files into one subagent just to reduce agent count — file grouping is the default. Only co-batch multiple files when findings explicitly reference the same small edit surface (rare); when in doubt, separate by file.
-
-**Subagent prompt (per batch):** the assigned findings only (`#`, severity, file, line, title, `suggested_fix`, `requires_verification`; add `why_it_matters` from `{reviewer}.json` in the run artifact when useful), plus:
-- Work through assigned `#` in severity order; at each `file:line`, skip with a one-line reason if evidence no longer matches
-- Apply the mechanical bar from § What to apply / What not to apply — skip anything that needs design judgment
-- Do not re-run `ce-code-review`
-- Shared-directory fallback: do not stage or commit — return which `#` were applied or skipped and which files changed
-
-**After each wave:** orchestrator reviews diffs (scope = assigned `#` only), runs tests (`requires_verification: true` on any applied finding → at least targeted tests; multi-file → broader suite), commits (`fix(review): apply findings #…`) unless worktree-isolated subagents merge per Phase 1. Repeat until all batches complete.
-
-### Optional inline shortcut (skip subagent spawn)
-
-Use **only** when **all** of the following hold:
-
-- Exactly **one** eligible finding after JSON filtering, **and**
-- The orchestrator **already** has that file's relevant region in context from Phase 2 work this session (no new Read/Grep expedition)
-
-Otherwise dispatch a subagent — even for a single finding. When unsure, dispatch.
-
-### Summary (required)
-
-Report: batches dispatched, `#` applied vs skipped (with reasons from subagents), artifact path, tests run.
-
-## Handoff to Residual Work Gate
-
-Any actionable finding not applied in this pass is **residual work** — proceed to the Residual Work Gate with an updated count. Do not re-invoke `ce-code-review` solely to re-apply the same findings unless the diff changed materially after fixes.
diff --git a/skills/ce-work-beta/references/shipping-workflow.md b/skills/ce-work-beta/references/shipping-workflow.md
deleted file mode 100644
index ba5d6904d..000000000
--- a/skills/ce-work-beta/references/shipping-workflow.md
+++ /dev/null
@@ -1,146 +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 the project's configured lint command / active instructions)
- # Use linting-agent before pushing to origin
- ```
-
-2. **Simplify** (conditional — separate from code review tiers)
-
- Before code review, invoke **`ce-simplify-code`** when the diff is non-mechanical and large enough to benefit (default: **>=30 changed lines**). Skip when the diff is purely mechanical (formatting, dependency bumps, lint-only fixes, generated artifacts).
-
- This step refines reuse, quality, and efficiency on the **current diff** so any later review sees cleaner code. It is not a substitute for Tier 1 or Tier 2 review.
-
- Pass `plan:` or a scope hint when the plan or user narrowed what changed. If the skill is unavailable on the harness, skip or do a brief manual pass for obvious duplicate/dead code — do not escalate to Tier 2 because simplify was skipped.
-
-3. **Code Review**
-
- Use **Tier 1** when the harness provides a built-in review. Use **Tier 2** only when escalation criteria below match — **not** because Tier 1 is missing.
-
- **Tier 1 -- harness-native review (default when available).** Run the harness built-in code review (e.g., `/review` in Claude Code). Address blocking and suggested findings inline before Final Validation. Skip the Residual Work Gate.
-
- **Tier 2 -- `ce-code-review` (escalation only).** Two steps — **review is not fix.**
-
- **2a. Review (read-only).** Invoke `ce-code-review` with `mode:agent` (and `plan:` when known; add `base:[` when the diff base is already resolved). Parse JSON or Actionable Findings. Do not pass `mode:autofix`.
-
- **2b. Apply fixes (caller-owned).** Load `references/review-findings-followup.md`: filter on JSON, batch by file, dispatch fix subagents. Then proceed to the Residual Work Gate.
-
- **When Tier 1 is unavailable and Tier 2 criteria are not met:** skip a dedicated review step. Phase 2 testing, simplify (when run), lint, and Final Validation still apply. Note in the shipping summary: `Code review: skipped (no Tier 1 tool; Tier 2 criteria not met).`
-
- Escalate to Tier 2 when **any** of the following is true:
-
- - **Sensitive surface touched.** The diff modifies any of: authentication or authorization, payments or billing, data migrations or backfills, cryptography or secret handling, security-relevant configuration, public API or library contracts, or dependency manifests.
- - **Large and diffuse change.** The diff exceeds >=400 changed lines **and** spans more than 3 directories or 2 distinct subsystems. Either alone is a soft signal; together they are an escalation trigger.
- - **Very large change.** The diff exceeds >=1,000 changed lines regardless of diffusion.
- - **Plan or task explicitly requests it.** The plan, the originating task, or another instruction in scope calls for a full / deep / thorough code review.
-
- When the change is small, concentrated, and outside the sensitive surface list, Tier 1 is sufficient -- do not escalate "to be safe."
-
-4. **Residual Work Gate** (REQUIRED when Tier 2 ran)
-
- After Tier 2 code review and review-findings followup, inspect the **Actionable Findings** summary (or read the run artifact at `/tmp/compound-engineering/ce-code-review//`). If one or more actionable `downstream-resolver` findings were not applied in followup, do not proceed to Final Validation until the user decides how to handle them.
-
- Ask the user using the platform's blocking question tool (`AskUserQuestion` in Claude Code with `ToolSearch select:AskUserQuestion` pre-loaded if needed, `request_user_input` in Codex, `ask_question` in Antigravity CLI (`agy`), `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 left N actionable finding(s) not yet fixed. How should the agent proceed?`
-
- Options (four or fewer, self-contained labels):
- - `Apply/fix now` — load `references/review-findings-followup.md`, dispatch batched fix subagents for remaining eligible findings, run tests, commit if needed.
- - `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/.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 `Actionable findings: none.` (and followup applied everything mechanical) or when only Tier 1 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/.md`.
-
-5. **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
-
-6. **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 Validation Context**
-
- Do not try to launch a dedicated CE evidence-capture workflow. Modern harnesses provide their own browser, screenshot, terminal recording, and artifact capture tools; use those directly only when the user asks or when the artifact already exists.
-
- Note whether the completed work has observable behavior (UI rendering, CLI output, API/library behavior with a runnable example, generated artifacts, or workflow output), and summarize any manual validation performed. If the user supplied evidence (URL, markdown embed, local artifact path), pass it to `ce-commit-push-pr` as PR-description context.
-
-2. **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 6)
- - 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.
-
-3. **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)
-- [ ] Validation/evidence context passed to `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)
-- [ ] Simplify: `ce-simplify-code` when diff >=30 lines (or skipped with reason)
-- [ ] Code review: Tier 1 completed, or Tier 2 when escalated, or skipped (no Tier 1 + Tier 2 criteria not met — note in summary)
-- [ ] PR description includes summary, testing notes, and evidence when captured
-- [ ] PR description includes Compound Engineered badge with accurate model and harness
-
-## Code Review Tiers
-
-**Tier 1** when the harness has built-in review. **Tier 2** (`ce-code-review` + followup) only when escalation criteria match — missing Tier 1 is not a reason to escalate.
-
-**Tier 1 -- harness-native review.** Built-in command or skill (e.g., `/review`). Fix findings inline.
-
-**Tier 2 -- `ce-code-review` (escalation).** (2a) Review-only via `mode:agent`. (2b) Batched fix subagents per `references/review-findings-followup.md`; residuals → Residual Work Gate.
-
-**Skip dedicated review** when no Tier 1 and Tier 2 criteria not met (document in summary).
-
-Escalate to Tier 2 when any of these holds:
-- Sensitive surface touched (auth/authz, payments/billing, data migrations or backfills, cryptography or secrets, security-relevant config, public API or library contracts, dependency manifests)
-- Large and diffuse change (>=400 changed lines AND >3 directories or 2 subsystems)
-- Very large change (>=1,000 changed lines)
-- Plan or task explicitly requests a full / deep / thorough code review
diff --git a/skills/ce-work-beta/references/tracker-defer.md b/skills/ce-work-beta/references/tracker-defer.md
deleted file mode 100644
index de1f38cd4..000000000
--- a/skills/ce-work-beta/references/tracker-defer.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Tracker Detection and Defer Execution
-
-This reference covers how residual actionable findings are filed in the project's tracker. Loaded by caller workflows (for example `ce-work` Residual Work Gate, or `lfg` residual handling) — not by `ce-code-review`, which stops after the report.
-
----
-
-## Execution Modes
-
-Tracker-defer has two execution modes. The caller selects one; the detection, fallback chain, and ticket composition are shared.
-
-### Interactive mode
-
-Used by `ce-work` Residual Work Gate and similar caller flows when the user chooses to file tickets. All user-facing prompts fire:
-
-- First Defer of the session with a generic (non-named) label confirms the effective tracker choice.
-- Execution failures prompt with Retry / Fall back to next sink / Convert to Skip.
-- Labels in the routing question reflect `named_sink_available` (name the tracker) vs fallback generics.
-
-### Non-interactive mode
-
-Used by autonomous callers like `lfg` that must not prompt. All blocking questions are skipped; the fallback chain is executed silently in order. Behavior:
-
-- No confirmation on the first generic-label Defer; proceed directly.
-- On execution failure, automatically fall to the next tier without prompting. Record the failure.
-- On total chain exhaustion (every tier failed or no sink available), return findings in the `no_sink` bucket so the caller can route them to another surface (e.g., inline them in a PR description).
-- Return a structured result: `{ filed: [{ finding_id, tracker, url }], failed: [{ finding_id, tracker, reason }], no_sink: [{ finding_id, title, severity, file, line }] }`.
-
-The caller decides how to surface the result to the user. The non-interactive mode treats "no sink available" as a data-producing outcome, not a prompt trigger.
-
----
-
-## Detection
-
-The agent determines the project's tracker from whatever documentation is obvious. Primary source: the project's active instructions and conventions already in its context — no need to open or name specific instruction files. Read a file directly only when the relevant instructions aren't already in context: a subdirectory-scoped instruction file governing the area you're working in, or when you're a fresh subagent that wasn't given the project's instructions. Supplementary signals (when primary documentation is ambiguous): `CONTRIBUTING.md`, `README.md`, PR templates under `.github/`, visible tracker URLs in the repo.
-
-A tracker can be surfaced via MCP tool (e.g., a Linear MCP server), CLI (e.g., `gh`), or direct API. All are acceptable. The detection output is a tuple with two availability flags — one for the named tracker specifically (drives label confidence in Interactive mode) and one for the full fallback chain (drives whether Defer is offered at all):
-
-```
-{ tracker_name, confidence, named_sink_available, any_sink_available }
-```
-
-Where:
-- `tracker_name` — human-readable name ("Linear", "GitHub Issues", "Jira"), or `null` when detection cannot identify a specific tracker
-- `confidence` — `high` when the tracker is named explicitly in documentation (or via a linked URL to a specific project/workspace) and is unambiguously the project's canonical tracker; `low` when the signal is thin, conflicting, or implied only
-- `named_sink_available` — `true` only when the agent can actually invoke the detected tracker (MCP tool is loaded, CLI is authenticated, or API credentials are in environment); `false` when the tracker is documented but no tool reaches it, or when no tracker is found at all. Drives label confidence: inline tracker naming requires this to be `true`.
-- `any_sink_available` — `true` when any tier in the fallback chain (named tracker or GitHub Issues via `gh`) can be invoked this session. Drives whether Defer is offered in Interactive mode, and drives the `no_sink` bucket in Non-interactive mode.
-
-Detection is reasoning-based. Do not maintain an enumerated checklist of files to read. Read the obvious sources and form a confident conclusion; when the obvious sources don't resolve, the label falls back to generic wording and the agent confirms with the user before executing (Interactive mode only).
-
----
-
-## Probe timing and caching
-
-Availability probes run **at most once per session** and **only when Defer execution is imminent**. Never speculatively at review start, never per-Defer, never per-walk-through-finding. The cached tuple is reused for every Defer action in the same run.
-
-Typical probe sequence:
-
-1. Consult the project's instructions already in context for tracker references — don't open or name specific instruction files; read one directly only when the relevant instructions aren't in context (subdirectory scope, or a fresh subagent). If nothing found, set `tracker_name = null`, `confidence = low`.
-2. **Probe the named tracker when one was found.** For GitHub Issues, run `gh auth status` and `gh repo view --json hasIssuesEnabled`. For Linear or other connector/MCP-backed trackers, first discover available tools via the platform's tool-discovery primitive (e.g., `ToolSearch` in Claude Code) rather than assuming absence from an unloaded tool, then verify the discovered tool is responsive. For API-backed trackers, verify credentials wherever the platform exposes them (environment, connector auth, or a documented secrets location) — not only shell env vars. Set `named_sink_available` from the probe result.
-3. **Probe the GitHub Issues fallback to compute `any_sink_available`.** Even when the named tracker was found and probed, `gh` matters for the `no_sink` bucket decision so that a run with no documented tracker but working `gh` still offers Defer.
- - If `named_sink_available = true`: `any_sink_available = true` (no further probes needed).
- - Otherwise, probe GitHub Issues via `gh auth status` + `gh repo view --json hasIssuesEnabled` (skip if already probed in step 2). If it works, `any_sink_available = true`.
- - Otherwise, `any_sink_available = false`.
-
-When Interactive mode's routing question is skipped entirely (R2 zero-findings case), no probes run. When the cached tuple is reused across a session, any `named_sink_available = true` from the session's first probe stays cached — do not re-probe per Defer.
-
----
-
-## Label logic (Interactive mode)
-
-- When `confidence = high` AND `named_sink_available = true`: the routing question's option C and the walk-through's per-finding Defer option both include the tracker name verbatim. Example: `File a Linear ticket per finding`, `Defer — file a Linear ticket`.
-- When `any_sink_available = true` but either `confidence = low` or `named_sink_available = false` (a fallback tier is working instead): the labels read generically — `File an issue per finding`, `Defer — file a ticket`. Before executing the first Defer of the session, the agent confirms the effective tracker choice with the user using the platform's blocking question tool.
-- When `any_sink_available = false`: option C is omitted from the routing question, option B (Defer) is omitted from the walk-through per-finding options, and the agent tells the user why in the routing question's stem.
-
-Non-interactive mode skips label decisions entirely — it acts silently on the detected sink.
-
----
-
-## Fallback chain
-
-When the named tracker is unavailable or no tracker is named, fall back in this order. Prefer the project's detected tracker; use `gh` only when no named tracker was found or the named one is unreachable.
-
-1. **Named tracker** (MCP tool, CLI, or API the agent can invoke directly, identified via Detection above)
-2. **GitHub Issues via `gh`** — when `gh auth status` succeeds and the current repo has issues enabled (`gh repo view --json hasIssuesEnabled` returns `true`)
-3. **No sink** — findings remain in the review report's residual-work section (Interactive mode) or are returned in the `no_sink` bucket for the caller to route (Non-interactive mode). The agent does not re-display them through a transient surface.
-
-Previously this chain included a third in-session fallback tier. That tier was removed because in-session tasks do not survive past the session and therefore do not meet the "durable filing" intent of a Defer action. When no durable tracker exists, the correct behavior is to leave findings in the report (Interactive) or return them to the caller (Non-interactive).
-
----
-
-## Ticket composition
-
-Every Defer action creates a ticket with the following content, adapted to the tracker's capabilities:
-
-- **Title:** the merged finding's `title` (schema-capped at 10 words).
-- **Body:**
- - Plain-English problem statement — reads the persona-produced `why_it_matters` from the contributing reviewer's artifact file at `/tmp/compound-engineering/ce-code-review//{reviewer}.json`, using the same `file + line_bucket(line, +/-3) + normalize(title)` matching agent mode uses (see SKILL.md Stage 6 detail enrichment). Falls back to the merged finding's `title`, `severity`, `file`, and `suggested_fix` (when present) when no artifact match is available — these fields are guaranteed in the merge-tier compact return.
- - Suggested fix (when present in the finding's `suggested_fix`).
- - Evidence (direct quotes from the reviewer's artifact).
- - Metadata block: `Severity: `, `Confidence: `, `Reviewer(s): ]`, `Finding ID: `.
-- **Labels** (when the tracker supports labels): severity tag (`P0`, `P1`, `P2`, `P3`) and, when the tracker convention supports it, a category label sourced from the reviewer name.
-- **Length cap:** when the composed body would exceed a tracker's body length limit, truncate with `... (continued in ce-code-review run artifact: /tmp/compound-engineering/ce-code-review//)` and include the finding_id in both the truncated body and the metadata block so the artifact is discoverable.
-
-The finding_id is a stable fingerprint composed as `normalize(file) + line_bucket(line, +/-3) + normalize(title)` — the same fingerprint used by the merge pipeline.
-
----
-
-## Failure path
-
-When ticket creation fails at execution (API error, auth expiry mid-session, rate limit, malformed body rejected, 4xx/5xx response):
-
-**Interactive mode:** surface the failure inline and ask the user using the platform's blocking question tool.
-
-Stem:
-> Defer failed: returned . How should the agent handle this finding?
-
-Options:
-- `Retry on ` — re-attempt the same tracker once more (useful for transient errors)
-- `Fall back to next sink` — move this finding's Defer to the next tier in the fallback chain (e.g., from Linear to GitHub Issues)
-- `Convert to Skip — record the failure` — abandon this Defer, note the failure in the completion report's failure section, and continue the walk-through or bulk flow
-
-**Non-interactive mode:** do not prompt. Automatically fall through to the next tier. If every tier fails, record the finding in the `failed` bucket of the structured return and continue. If the chain exhausts with no sink ever available, the finding ends up in the `no_sink` bucket.
-
-When a high-confidence named tracker fails at execution, the cached `named_sink_available` is set to `false` for the rest of the session. Subsequent Defer actions fall straight through to the next tier without retrying a confirmed-broken sink. `any_sink_available` is only downgraded to `false` when every tier has been confirmed broken — a failed Linear call that succeeds via `gh` keeps `any_sink_available = true`.
-
-Only when `ToolSearch` explicitly returns no match or the tool call errors — or on a platform with no blocking question tool — fall back to numbered options and waiting for the user's reply (Interactive mode only).
-
----
-
-## Per-tracker behavior
-
-Concrete behavior per tracker at execution time. The agent may invoke any of these through the appropriate interface (MCP, CLI, or API) — the choice depends on what is available in the current environment.
-
-| Tracker | Interface | Invocation sketch | Body format | Labels |
-|---------|-----------|-------------------|-------------|--------|
-| Linear | MCP (preferred) or API | Create issue in the project/workspace identified by documentation; assign to the reporter if the MCP tool exposes user context | Markdown | Severity priority field if the MCP exposes it; otherwise include severity in body |
-| GitHub Issues | `gh issue create` | Repo defaults to the current repo. Use `--label` for severity tag when labels exist; omit `--label` if the repo has no label fixture. Fall back to a label-less issue on first failure. | Markdown | `--label P0` / `--label P1` / etc. when labels exist |
-| Jira | MCP or API | Create issue in the project identified by documentation; Jira's markdown dialect differs from GitHub's — use plain text in the body when MCP does not handle conversion | Plain text when MCP does not handle markdown | Severity priority field |
-| No sink available | — | Interactive: Defer option omitted, findings remain in the report's residual-work section. Non-interactive: findings returned in the `no_sink` bucket for caller routing. | — | — |
-
-When uncertain, prefer "drop with explicit user-facing notice" over "pass through silently and hope." A Defer that produces no durable artifact and no user message is data loss.
-
----
-
-## Cross-platform notes
-
-The question-tool name varies by platform. In Interactive mode, use the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_question` in Antigravity CLI (`agy`), `ask_user` in Pi (requires the `pi-ask-user` extension)). In Claude Code the tool should already be loaded from the Interactive-mode pre-load step — if it isn't, call `ToolSearch` with query `select:AskUserQuestion` now. Fall back to numbered options in chat only when the harness genuinely lacks a blocking tool — `ToolSearch` returns no match, the tool call explicitly fails, or the runtime mode does not expose it (e.g., Codex edit modes without `request_user_input`). A pending schema load is not a fallback trigger. Never silently skip the question.
-
-Non-interactive mode is platform-agnostic: it never prompts, so the platform's question tool is not relevant.
diff --git a/src/converters/claude-to-copilot.ts b/src/converters/claude-to-copilot.ts
index 0bb57623f..18c6fcd3a 100644
--- a/src/converters/claude-to-copilot.ts
+++ b/src/converters/claude-to-copilot.ts
@@ -127,7 +127,7 @@ export function transformContentForCopilot(body: string): string {
// The lookbehind ensures we only match at word boundaries or after common delimiters,
// avoiding corruption of URLs, code identifiers, or unrelated namespace:value patterns.
// Note: / is intentionally excluded — slash commands are already handled in step 2.
- // Captures colons in the name segment so multi-colon refs like ce:work:beta → ce-work-beta.
+ // Captures colons in the name segment so multi-colon refs like ce:foo:bar → ce-foo-bar.
result = result.replace(/(?<=^|[\s,.()`'"])ce:([a-z*][a-z0-9_*:-]*)/gim, (_, name: string) => `ce-${name.replace(/:/g, "-")}`)
// 4. Rewrite .claude/ paths to .github/ and ~/.claude/ to ~/.copilot/
diff --git a/src/data/plugin-legacy-artifacts.ts b/src/data/plugin-legacy-artifacts.ts
index b7e494c55..eb56820f1 100644
--- a/src/data/plugin-legacy-artifacts.ts
+++ b/src/data/plugin-legacy-artifacts.ts
@@ -70,6 +70,7 @@ const EXTRA_LEGACY_ARTIFACTS_BY_PLUGIN: Record =
"ce-session-extract",
"ce-session-inventory",
"ce-update",
+ "ce-work-beta",
"changelog",
"claude-permissions-optimizer",
"compound-docs",
@@ -253,6 +254,7 @@ const EXTRA_LEGACY_ARTIFACTS_BY_PLUGIN: Record =
"ce:plan",
"ce:review",
"ce:work",
+ "ce:work-beta",
"changelog",
"codify",
"compound",
diff --git a/src/utils/legacy-cleanup.ts b/src/utils/legacy-cleanup.ts
index 29d63f28b..9a07ab6a2 100644
--- a/src/utils/legacy-cleanup.ts
+++ b/src/utils/legacy-cleanup.ts
@@ -109,6 +109,7 @@ export const STALE_SKILL_DIRS = [
"ce-sessions",
"ce-slack-research",
"ce-update",
+ "ce-work-beta",
// ce-session-inventory and ce-session-extract were script-host skills called
// only from ce-session-historian via the Skill tool. That dispatch path
@@ -401,6 +402,9 @@ const LEGACY_PROMPT_DESCRIPTION_ALIASES: Record = {
"Transform feature descriptions or requirements into implementation plans grounded in repo patterns and research.",
],
"ce-work-beta.md": [
+ // Last shipped ce-work-beta description (the file was deleted, so this is
+ // the final live frontmatter description preserved for upgrade cleanup).
+ "[BETA] Execute ce-work with external delegate support.",
"[BETA] Execute work with external delegate support. Same as ce-work but includes experimental Codex delegation mode for token-conserving code implementation.",
"[BETA] Execute work with external delegate support. Same as ce:work but includes experimental Codex delegation mode for token-conserving code implementation.",
],
@@ -468,6 +472,10 @@ const LEGACY_ONLY_SKILL_DESCRIPTIONS: Record = {
"[BETA] Structured code review using tiered persona agents, confidence-gated findings, and a merge/dedup pipeline. Use when reviewing code changes before creating a PR.",
"ce-review-beta":
"[BETA] Structured code review using tiered persona agents, confidence-gated findings, and a merge/dedup pipeline. Use when reviewing code changes before creating a PR.",
+ "ce:work-beta":
+ "[BETA] Execute ce-work with external delegate support.",
+ "ce-work-beta":
+ "[BETA] Execute ce-work with external delegate support.",
"ce-onboarding":
"Generate or regenerate ONBOARDING.md to help new contributors understand a codebase. Use when the user asks to 'create onboarding docs', 'generate ONBOARDING.md', 'document this project for new developers', 'write onboarding documentation', 'vonboard', 'vonboarding', 'prepare this repo for a new contributor', 'refresh the onboarding doc', or 'update ONBOARDING.md'. Also use when someone needs to onboard a new team member and wants a written artifact, or when a codebase lacks onboarding documentation and the user wants to generate one.",
"ce-andrew-kane-gem-writer":
@@ -860,9 +868,22 @@ async function loadLegacyFingerprints(): Promise {
for (const [fileName, skillName] of Object.entries(LEGACY_PROMPT_CURRENT_SKILL_FOR_FILE)) {
const currentPath = skillIndex.get(skillName)
- if (!currentPath) continue
- const description = await readDescription(currentPath)
- if (description) prompts.set(fileName, description)
+ if (currentPath) {
+ const description = await readDescription(currentPath)
+ if (description) prompts.set(fileName, description)
+ continue
+ }
+ // The mapped skill no longer ships (fully retired, e.g. ce-work-beta).
+ // Seed the prompt fingerprint with any historical alias so cleanup can
+ // still match and sweep the orphaned wrapper on upgrade. The specific
+ // value is not significant — isLegacyPromptWrapper unions the full
+ // LEGACY_PROMPT_DESCRIPTION_ALIASES list when matching; this only has to
+ // be a non-empty description to clear descriptionsMatch's guard. Mirrors
+ // the LEGACY_ONLY_SKILL_DESCRIPTIONS / LEGACY_ONLY_AGENT_DESCRIPTIONS
+ // fallbacks above; the prompts dir is cross-plugin, so a description
+ // fingerprint (not a name-only match) is required to sweep safely.
+ const historicalFingerprint = LEGACY_PROMPT_DESCRIPTION_ALIASES[fileName]?.[0]
+ if (historicalFingerprint) prompts.set(fileName, historicalFingerprint)
}
return { skills, agents, prompts }
diff --git a/tests/copilot-converter.test.ts b/tests/copilot-converter.test.ts
index 6ba260de9..d449fff36 100644
--- a/tests/copilot-converter.test.ts
+++ b/tests/copilot-converter.test.ts
@@ -478,9 +478,9 @@ Task best-practices-researcher(topic)`
})
test("replaces multi-colon ce: references fully", () => {
- const input = "run ce:work:beta and ce:review:deep"
+ const input = "run ce:foo:bar and ce:baz:qux"
const result = transformContentForCopilot(input)
- expect(result).toBe("run ce-work-beta and ce-review-deep")
+ expect(result).toBe("run ce-foo-bar and ce-baz-qux")
expect(result).not.toContain(":")
})
diff --git a/tests/legacy-cleanup.test.ts b/tests/legacy-cleanup.test.ts
index 8f9e2a300..afd686f51 100644
--- a/tests/legacy-cleanup.test.ts
+++ b/tests/legacy-cleanup.test.ts
@@ -225,6 +225,24 @@ describe("cleanupStaleSkillDirs", () => {
expect(await exists(path.join(root, "workflows:plan"))).toBe(false)
})
+ test("removes a retired ce-work-beta skill dir via its last-shipped description", async () => {
+ // Regression: once ce-work-beta is removed from the plugin, loadLegacyFingerprints
+ // can no longer read its (deleted) SKILL.md, so the fingerprint comes from
+ // LEGACY_ONLY_SKILL_DESCRIPTIONS. Without that entry, skills.get("ce-work-beta")
+ // stays undefined and isLegacyPluginOwned returns false before deleting, leaving
+ // the stale install dir behind on upgrade.
+ const root = await fs.mkdtemp(path.join(os.tmpdir(), "cleanup-retired-skill-"))
+ await createDir(
+ path.join(root, "ce-work-beta"),
+ skillContent("ce-work-beta", "[BETA] Execute ce-work with external delegate support."),
+ )
+
+ const removed = await cleanupStaleSkillDirs(root)
+
+ expect(removed).toBe(1)
+ expect(await exists(path.join(root, "ce-work-beta"))).toBe(false)
+ })
+
test("returns 0 when directory does not exist", async () => {
const removed = await cleanupStaleSkillDirs("/tmp/nonexistent-cleanup-dir-12345")
expect(removed).toBe(0)
@@ -621,10 +639,10 @@ describe("cleanupStalePrompts", () => {
),
)
await createFile(
- path.join(root, "ce-work-beta.md"),
+ path.join(root, "ce-work.md"),
legacyWorkflowPromptContent(
- "ce:work-beta",
- (await pluginDescription("skills/ce-work-beta/SKILL.md"))
+ "ce:work",
+ (await pluginDescription("skills/ce-work/SKILL.md"))
.replaceAll("ce-", "ce:"),
),
)
@@ -633,7 +651,7 @@ describe("cleanupStalePrompts", () => {
expect(removed).toBe(2)
expect(await exists(path.join(root, "ce-plan.md"))).toBe(false)
- expect(await exists(path.join(root, "ce-work-beta.md"))).toBe(false)
+ expect(await exists(path.join(root, "ce-work.md"))).toBe(false)
})
test("removes wrappers whose description has drifted (matches a known historical alias)", async () => {
@@ -695,6 +713,27 @@ describe("cleanupStalePrompts", () => {
expect(await exists(path.join(root, "ce-brainstorm.md"))).toBe(false)
})
+ test("removes a retired ce-work-beta prompt wrapper built from the last shipped skill", async () => {
+ // Regression: a ce-work-beta.md wrapper generated from the final live skill
+ // carried the description "[BETA] Execute ce-work with external delegate
+ // support." After the skill is deleted, that exact description must still be
+ // recognized (seeded from LEGACY_PROMPT_DESCRIPTION_ALIASES) or the retired
+ // slash prompt is classified foreign and left behind on upgrade.
+ const root = await fs.mkdtemp(path.join(os.tmpdir(), "cleanup-retired-prompt-"))
+ await createFile(
+ path.join(root, "ce-work-beta.md"),
+ promptWrapperContent(
+ "ce-work-beta",
+ "[BETA] Execute ce-work with external delegate support.",
+ ),
+ )
+
+ const removed = await cleanupStalePrompts(root)
+
+ expect(removed).toBe(1)
+ expect(await exists(path.join(root, "ce-work-beta.md"))).toBe(false)
+ })
+
test("preserves wrappers whose description was never shipped by compound-engineering", async () => {
// Defense-in-depth against a sibling plugin installed into the same
// `~/.codex/prompts/` directory. `renderPrompt` in
diff --git a/tests/pipeline-review-contract.test.ts b/tests/pipeline-review-contract.test.ts
index f2a0058c7..584f7ea28 100644
--- a/tests/pipeline-review-contract.test.ts
+++ b/tests/pipeline-review-contract.test.ts
@@ -50,38 +50,6 @@ describe("ce-work review contract", () => {
expect(content).not.toContain("[HARNESS_URL]")
})
- test("ce-work-beta mirrors review and commit delegation", async () => {
- const beta = await readRepoFile("skills/ce-work-beta/SKILL.md")
- // Review/commit content extracted to references/shipping-workflow.md
- const shipping = await readRepoFile("skills/ce-work-beta/references/shipping-workflow.md")
-
- // Extracted content in reference file: Simplify step at position 2,
- // Code Review at position 3
- expect(shipping).toContain("2. **Simplify**")
- expect(shipping).toContain("3. **Code Review**")
- expect(shipping).toContain("`ce-commit-push-pr` skill")
- expect(shipping).toContain("`ce-commit` skill")
-
- // Negative assertions stay on SKILL.md
- expect(beta).not.toContain("Consider Code Review")
- expect(beta).not.toContain("gh pr create")
- })
-
- test("ce-work-beta mirrors residual work gate sentinel with ce-work", async () => {
- const workShipping = await readRepoFile(
- "skills/ce-work/references/shipping-workflow.md",
- )
- const betaShipping = await readRepoFile(
- "skills/ce-work-beta/references/shipping-workflow.md",
- )
-
- expect(workShipping).toContain("Actionable findings: none.")
- expect(betaShipping).toContain("Actionable findings: none.")
- expect(betaShipping).not.toContain("Residual actionable work: none.")
- expect(betaShipping).toContain("not yet fixed")
- expect(betaShipping).not.toContain("skill did not auto-fix")
- })
-
test("includes per-task testing deliberation in execution loop", async () => {
const content = await readRepoFile("skills/ce-work/SKILL.md")
@@ -110,23 +78,6 @@ describe("ce-work review contract", () => {
expect(shipping).not.toContain("Tests pass (run project's test command)")
})
- test("ce-work-beta mirrors testing deliberation and checklist changes", async () => {
- const beta = await readRepoFile("skills/ce-work-beta/SKILL.md")
- // Checklist extracted to references/shipping-workflow.md
- const shipping = await readRepoFile("skills/ce-work-beta/references/shipping-workflow.md")
-
- // Testing deliberation stays in SKILL.md (Phase 2 content)
- expect(beta).toContain("Assess testing coverage")
-
- // New checklist language in reference file
- expect(shipping).toContain("Testing addressed")
-
- // Old language removed from both
- expect(beta).not.toContain("Tests pass (run project's test command)")
- expect(beta).not.toContain("- All tests pass")
- expect(shipping).not.toContain("Tests pass (run project's test command)")
- })
-
test("SKILL.md stub points to shipping-workflow reference", async () => {
const content = await readRepoFile("skills/ce-work/SKILL.md")
@@ -139,18 +90,6 @@ describe("ce-work review contract", () => {
expect(content).not.toContain("## Code Review Tiers")
})
- test("ce:work-beta SKILL.md stub points to shipping-workflow reference", async () => {
- const content = await readRepoFile("skills/ce-work-beta/SKILL.md")
-
- // Stub references the shipping-workflow file
- expect(content).toContain("`references/shipping-workflow.md`")
-
- // Extracted content is not in SKILL.md
- expect(content).not.toContain("3. **Code Review**")
- expect(content).not.toContain("## Quality Checklist")
- expect(content).not.toContain("## Code Review Tiers")
- })
-
test("ce:work remains the stable non-delegating surface", async () => {
const content = await readRepoFile("skills/ce-work/SKILL.md")
@@ -160,131 +99,7 @@ describe("ce-work review contract", () => {
})
})
-describe("ce:work-beta codex delegation contract", () => {
- test("has argument parsing with delegate tokens", async () => {
- const content = await readRepoFile("skills/ce-work-beta/SKILL.md")
-
- // Argument parsing section exists with delegation tokens
- expect(content).toContain("## Argument Parsing")
- expect(content).toContain("`delegate:codex`")
- expect(content).toContain("`delegate:local`")
-
- // Resolution chain present
- expect(content).toContain("### Settings Resolution Chain")
- expect(content).toContain("work_delegate")
- expect(content).toContain("config.local.yaml")
- })
-
- test("argument-hint includes delegate:codex for discoverability", async () => {
- const content = await readRepoFile("skills/ce-work-beta/SKILL.md")
-
- expect(content).toContain("argument-hint:")
- expect(content).toContain("delegate:codex")
- })
-
- test("remains manual-invocation beta during rollout", async () => {
- const content = await readRepoFile("skills/ce-work-beta/SKILL.md")
-
- expect(content).toContain("disable-model-invocation: true")
- expect(content).toContain("Invoke `ce-work-beta` manually")
- expect(content).toContain("planning and workflow handoffs remain pointed at stable `ce-work`")
- })
-
- test("SKILL.md has delegation routing stub pointing to reference", async () => {
- const content = await readRepoFile("skills/ce-work-beta/SKILL.md")
-
- expect(content).toContain("## Codex Delegation Mode")
- expect(content).toContain("references/codex-delegation-workflow.md")
- // Delegation details are NOT in SKILL.md body — they're in the reference
- expect(content).not.toContain("### Pre-Delegation Checks")
- expect(content).not.toContain("### Prompt Template")
- expect(content).not.toContain("### Execution Loop")
- })
-
- test("delegation routing gate in Phase 1 Step 4", async () => {
- const content = await readRepoFile("skills/ce-work-beta/SKILL.md")
-
- const gateIdx = content.indexOf("Delegation routing gate")
- const strategyTableIdx = content.indexOf("| **Inline**")
- expect(gateIdx).toBeGreaterThan(0)
- expect(gateIdx).toBeLessThan(strategyTableIdx)
- expect(content).toContain("Codex delegation requires a plan file")
- })
-
- test("delegation branches in Phase 2 task loop", async () => {
- const content = await readRepoFile("skills/ce-work-beta/SKILL.md")
-
- expect(content).toContain("If delegation_active: branch to the Codex Delegation Execution Loop")
- })
-
- test("delegation reference has all required sections", async () => {
- const content = await readRepoFile("skills/ce-work-beta/references/codex-delegation-workflow.md")
-
- // Pre-delegation checks
- expect(content).toContain("## Pre-Delegation Checks")
- expect(content).toContain("Platform Gate")
- expect(content).toContain("CODEX_SANDBOX")
- expect(content).toContain("command -v codex")
- expect(content).toContain("Consent Flow")
-
- // Batching
- expect(content).toContain("## Batching")
-
- // Prompt template
- expect(content).toContain("## Prompt Template")
- expect(content).toContain("")
- expect(content).toContain("")
- expect(content).toContain("")
- expect(content).toContain("")
- expect(content).toContain("test-first")
- expect(content).toContain("characterization-first")
- expect(content).toContain("the orchestrator will not re-run verification independently")
-
- // Result schema and execution loop
- expect(content).toContain("## Result Schema")
- expect(content).toContain("## Execution Loop")
- expect(content).toContain("codex exec")
-
- // Circuit breaker
- expect(content).toContain("consecutive_failures")
- expect(content).toContain("3 consecutive failures")
-
- // Rollback safety
- expect(content).toContain("git diff --quiet HEAD")
- expect(content).toContain("git checkout -- .")
- expect(content).toContain("Do NOT use bare `git clean -fd` without path arguments")
-
- // Mixed-model attribution
- expect(content).toContain("## Mixed-Model Attribution")
- })
-
- test("delegation reference has decision prompts for ask mode", async () => {
- const content = await readRepoFile("skills/ce-work-beta/references/codex-delegation-workflow.md")
-
- expect(content).toContain("## Delegation Decision")
- expect(content).toContain("work_delegate_decision")
- expect(content).toContain("Execute with Claude Code instead")
- expect(content).toContain("Delegate to Codex anyway")
- expect(content).toContain("the cost of delegating outweighs having Claude Code do them")
- })
-
- test("settings resolution includes delegation decision setting", async () => {
- const content = await readRepoFile("skills/ce-work-beta/SKILL.md")
-
- expect(content).toContain("work_delegate_decision")
- expect(content).toContain("`auto`")
- expect(content).toContain("`ask`")
- })
-
- test("has frontend design guidance ported from beta", async () => {
- const content = await readRepoFile("skills/ce-work-beta/SKILL.md")
-
- expect(content).toContain("**Frontend Design Guidance**")
- expect(content).toContain("Apply the frontend guidance embedded in this skill")
- })
-})
-
-describe("ce:plan remains neutral during ce:work-beta rollout", () => {
+describe("ce-plan stays neutral on delegation", () => {
test("removes delegation-specific execution posture guidance", async () => {
const content = await readRepoFile("skills/ce-plan/SKILL.md")
diff --git a/tests/plugin-legacy-artifacts.test.ts b/tests/plugin-legacy-artifacts.test.ts
index c6fbbac8c..4b836a711 100644
--- a/tests/plugin-legacy-artifacts.test.ts
+++ b/tests/plugin-legacy-artifacts.test.ts
@@ -50,6 +50,12 @@ describe("plugin legacy artifacts", () => {
expect(artifacts.prompts).toContain("report-bug.md")
expect(artifacts.prompts).toContain("workflows-review.md")
expect(artifacts.prompts).toContain("technical_review.md")
+
+ // ce-work-beta is fully retired: both its skill dir and its Codex
+ // slash-prompt wrapper (~/.codex/prompts/ce-work-beta.md) must be
+ // enumerated so flat installs without a manifest still sweep them.
+ expect(artifacts.skills).toContain("ce-work-beta")
+ expect(artifacts.prompts).toContain("ce-work-beta.md")
})
test("Codex legacy detection ignores current bundle skills/agents not in the historical allow-list", () => {
diff --git a/tests/release-metadata.test.ts b/tests/release-metadata.test.ts
index 540d33ac2..72cd26bdf 100644
--- a/tests/release-metadata.test.ts
+++ b/tests/release-metadata.test.ts
@@ -147,7 +147,7 @@ describe("release metadata", () => {
expect(counts).toEqual({
agents: 0,
- skills: 27,
+ skills: 26,
mcpServers: 0,
})
})
diff --git a/tests/review-skill-contract.test.ts b/tests/review-skill-contract.test.ts
index e7c13d90c..172102ee2 100644
--- a/tests/review-skill-contract.test.ts
+++ b/tests/review-skill-contract.test.ts
@@ -625,7 +625,6 @@ describe("ce-code-review contract", () => {
test("ce-work shipping-workflow enforces a residual-work gate after Tier 2 review", async () => {
for (const path of [
"skills/ce-work/references/shipping-workflow.md",
- "skills/ce-work-beta/references/shipping-workflow.md",
]) {
const workflow = await readRepoFile(path)
await expect(readRepoFile(path.replace("shipping-workflow.md", "tracker-defer.md"))).resolves.toContain(
diff --git a/tests/skill-conventions.test.ts b/tests/skill-conventions.test.ts
index f79b61fef..53a72f4db 100644
--- a/tests/skill-conventions.test.ts
+++ b/tests/skill-conventions.test.ts
@@ -149,7 +149,6 @@ const EXPECTED_USER_INVOKED_SKILLS = new Set([
"ce-promote",
"ce-setup",
"ce-test-xcode",
- "ce-work-beta",
"lfg",
])