@fro.bot/systematic 2.33.3 → 3.0.1

package/skills/ce-compound/SKILL.md

@@ -273,12 +273,10 @@ After the learning is written and the refresh decision is made, check whether th
 
 Based on problem type, optionally invoke specialized agents to review the documentation:
 
-- **performance_issue** → `systematic:review:performance-oracle`
-- **security_issue** → `systematic:review:security-sentinel`
-- **database_issue** → `systematic:review:data-integrity-guardian`
+- **performance_issue** → `systematic:review:performance-reviewer`
+- **security_issue** → `systematic:review:security-reviewer`
+- **database_issue** → `systematic:review:data-migrations-reviewer`
 - Any code-heavy issue → always run `systematic:review:code-simplicity-reviewer`, and additionally run the kieran reviewer that matches the repo's primary stack:
-  - Ruby/Rails → also run `systematic:review:kieran-rails-reviewer`
-  - Python → also run `systematic:review:kieran-python-reviewer`
   - TypeScript/JavaScript → also run `systematic:review:kieran-typescript-reviewer`
   - Other stacks → no kieran reviewer needed
 
@@ -397,8 +395,8 @@ Subagent Results:
   ✓ Session History: 3 prior sessions on same branch, 2 failed approaches surfaced
 
 Specialized Agent Reviews (Auto-Triggered):
-  ✓ performance-oracle: Validated query optimization approach
-  ✓ kieran-rails-reviewer: Code examples meet Rails conventions
+  ✓ performance-reviewer: Validated query optimization approach
+  ✓ kieran-typescript-reviewer: Code examples meet TypeScript conventions
   ✓ code-simplicity-reviewer: Solution is appropriately minimal
 
 File created:
@@ -464,16 +462,14 @@ Writes the final learning directly into `docs/solutions/`.
 Based on problem type, these agents can enhance documentation:
 
 ### Code Quality & Review
-- **systematic:review:kieran-rails-reviewer**: Reviews code examples for Rails best practices
-- **systematic:review:kieran-python-reviewer**: Reviews code examples for Python best practices
 - **systematic:review:kieran-typescript-reviewer**: Reviews code examples for TypeScript best practices
 - **systematic:review:code-simplicity-reviewer**: Ensures solution code is minimal and clear
 - **systematic:review:pattern-recognition-specialist**: Identifies anti-patterns or repeating issues
 
 ### Specific Domain Experts
-- **systematic:review:performance-oracle**: Analyzes performance_issue category solutions
-- **systematic:review:security-sentinel**: Reviews security_issue solutions for vulnerabilities
-- **systematic:review:data-integrity-guardian**: Reviews database_issue migrations and queries
+- **systematic:review:performance-reviewer**: Analyzes performance_issue category solutions
+- **systematic:review:security-reviewer**: Reviews security_issue solutions for vulnerabilities
+- **systematic:review:data-migrations-reviewer**: Reviews database_issue migrations and queries
 
 ### Enhancement & Research
 - **systematic:research:best-practices-researcher**: Enriches solution with industry best practices

package/skills/ce-ideate/references/post-ideation-workflow.md

@@ -51,27 +51,27 @@ Keep the presentation concise. Allow brief follow-up questions and lightweight c
 
 ## Phase 5: Persistence (Opt-In, Mode-Aware)
 
-Persistence is opt-in. The terminal review loop is a complete ideation cycle. Refinement loops happen in conversation with no file or network cost. Persistence triggers only when the user explicitly chooses to save, share, or hand off (selected in Phase 6).
+Persistence is opt-in. The terminal review loop is a complete ideation cycle. Refinement loops happen in conversation with no file or network cost. Persistence triggers only when the user explicitly chooses to save or hand off (selected in Phase 6).
 
-When the user picks an option in Phase 6 that requires a durable record (Open and iterate in Proof, Brainstorm, Save and end), ensure a record exists first. When the user chooses to keep refining, no record is needed unless the user asks.
+When the user picks an option in Phase 6 that requires a durable record (Brainstorm, Save and end), ensure a record exists first. When the user chooses to keep refining, no record is needed unless the user asks.
 
 **Mode-determined defaults:**
 
 | Action | Repo mode default | Elsewhere mode default |
 |---|---|---|
-| Save | `docs/ideation/YYYY-MM-DD-<topic>-ideation.md` | Proof |
-| Share | Proof (additional) | Proof (primary) |
+| Save | `docs/ideation/YYYY-MM-DD-<topic>-ideation.md` | Local file (custom path if no repo context) |
 | Brainstorm handoff | `ce-brainstorm` | `ce-brainstorm` (universal-brainstorming) |
 | End | Conversation only is fine | Conversation only is fine |
 
-Either mode can also use the other destination on explicit request ("save to Proof even though this is repo mode", "save to a local file even though this is elsewhere"). Honor such overrides directly.
+Both modes persist via local file save. Elsewhere mode without an obvious repo path should ask the user for a save location (current working directory, `/tmp`, or a custom path) using the same file structure as repo mode.
 
-### 5.1 File Save (default for repo mode; on request for elsewhere mode)
+### 5.1 File Save (default for both modes)
 
-1. Ensure `docs/ideation/` exists
+1. Ensure `docs/ideation/` exists (repo mode) or confirm the chosen save location (elsewhere mode)
 2. Choose the file path:
-   - `docs/ideation/YYYY-MM-DD-<topic>-ideation.md`
-   - `docs/ideation/YYYY-MM-DD-open-ideation.md` when no focus exists
+   - `docs/ideation/YYYY-MM-DD-<topic>-ideation.md` (repo mode)
+   - `docs/ideation/YYYY-MM-DD-open-ideation.md` when no focus exists (repo mode)
+   - user-selected path (elsewhere mode)
 3. Write or update the ideation document
 
 Use this structure and omit clearly irrelevant fields only when necessary:
@@ -111,46 +111,17 @@ If resuming:
 - update the existing file in place
 - preserve explored markers
 
-### 5.2 Proof Save (default for elsewhere mode; on request for repo mode)
-
-Hand off the ideation content to the `ce-proof` skill in HITL review mode. This uploads the doc, runs an iterative review loop (user annotates in Proof, agent ingests feedback and applies tracked edits), and (in repo mode) syncs the reviewed markdown back to `docs/ideation/`.
-
-Load the `ce-proof` skill in HITL-review mode with:
-
-- **source content:** the survivors and rejection summary from Phase 4 (in repo mode, this is the file written in 5.1; in elsewhere mode, render to a temp file as the source for upload)
-- **doc title:** `Ideation: <topic>` or the H1 of the ideation doc
-- **identity:** `ai:systematic` / `Systematic`
-- **recommended next step:** `/ce-brainstorm` (shown in the proof skill's final terminal output)
-
-The Proof failure ladder in Phase 6.5 governs what happens when this hand-off fails.
-
-**Caller-aware return.** The return-rule bullets below describe the default control flow, but the next step depends on which Phase 6 option invoked the Proof save. Apply the right branch for the caller:
-
-- **§6.2 Open and iterate in Proof.** Behavior is mode-aware:
-    - *Repo mode:* return to the Phase 6 menu on every status. The Proof-reviewed content is now synced locally, and the user typically has a follow-up action in the repo (brainstorm toward a plan, save and end, or keep refining).
-    - *Elsewhere mode:* on a successful Proof return (`proceeded` or `done_for_now`), exit cleanly — narrate that the artifact lives at `docUrl` (including any stale-local note if applicable) and stop. Proof iteration is often the terminal act in elsewhere mode; forcing another menu choice after the user already got what they came for produces decision fatigue. Only the `aborted` branch returns to the Phase 6 menu so the user can retry or pick another path.
-- **§6.3 Brainstorm a selected idea.** On a successful Proof return (`proceeded` or `done_for_now`), do **not** stop at the Phase 6 menu — after applying the per-status handling below (including any stale-local pull offer), continue into §6.3's remaining bullets (mark the chosen idea as `Explored`, then load `ce-brainstorm`). Only the `aborted` branch returns to the Phase 6 menu, since no durable record was written.
-- **§6.4 Save and end.** On a successful Proof return (`proceeded` or `done_for_now`), exit cleanly: narrate that the ideation was saved, surface the `docUrl` (and the local-path note if applicable), and stop. Do **not** re-ask the Phase 6 question — the user already chose to end. Only the `aborted` branch returns to the Phase 6 menu so the user can retry or pick a different path.
-
-When the proof skill returns control:
-
-- `status: proceeded` with `localSynced: true` → the ideation doc on disk now reflects the review. Apply the caller-aware return rule above for the invoking branch.
-- `status: proceeded` with `localSynced: false` → the reviewed version lives in Proof at `docUrl` but the local copy is stale. Offer to pull the Proof doc to `localPath` using the proof skill's Pull workflow. Apply the caller-aware return rule above; if the pull was declined, include a one-line note that `<localPath>` is stale vs. Proof so the next handoff (or final exit narration) doesn't read the old content silently. Placement: above the Phase 6 menu when the caller-aware rule returns to it, in the handoff preamble to `ce-brainstorm` for §6.3, or alongside the final save/exit narration for §6.2 elsewhere / §6.4.
-- `status: done_for_now` → the doc on disk may be stale if the user edited in Proof before leaving. Offer to pull the Proof doc to `localPath` so the local ideation artifact stays in sync, then apply the caller-aware return rule above. `done_for_now` means the user stopped the HITL loop — it does not mean they ended the whole ideation session unless the caller-aware rule exits (§6.2 elsewhere mode or §6.4). If the pull was declined, include the stale-local note at the placement described in the previous bullet.
-- `status: aborted` → fall back to the Phase 6 menu without changes, regardless of caller. No durable record was written, so §6.3 must not proceed with the brainstorm handoff and §6.4 must not end — the menu lets the user retry or pick another path.
-
 ## Phase 6: Refine or Hand Off
 
 Ask what should happen next using the platform's blocking question tool: `question` in OpenCode (call `ToolSearch` with `select:question` first if its schema isn't loaded), `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 no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.
 
 **Question:** "What should the agent do next?"
 
-Offer these four options (labels are self-contained with the distinguishing word front-loaded so options stay distinct when truncated):
+Offer these three options (labels are self-contained with the distinguishing word front-loaded so options stay distinct when truncated):
 
-1. **Refine the ideation in conversation (or stop here — no save)** — add ideas, re-evaluate, or deepen analysis. No file or network side effects; ending the conversation at any point after this pick is a valid no-save exit.
-2. **Open and iterate in Proof** — save the ideation to Proof and enter the proof skill's HITL review loop: iterate via comments in the Proof editor; reviewed edits sync back to `docs/ideation/` in repo mode.
-3. **Brainstorm a selected idea** — load `ce-brainstorm` with the chosen idea as the seed. The orchestrator first writes a durable record using the mode default in Phase 5.
-4. **Save and end** — persist the ideation using the mode default (file in repo mode, Proof in elsewhere mode), then end.
+1. **Refine the ideation in conversation (or stop here — no save)** — add ideas, re-evaluate, or deepen analysis. No file side effects; ending the conversation at any point after this pick is a valid no-save exit.
+2. **Brainstorm a selected idea** — load `ce-brainstorm` with the chosen idea as the seed. The orchestrator first writes a durable record using the mode default in Phase 5.
+3. **Save and end** — persist the ideation to a local file using the mode default (Phase 5.1), then end.
 
 No-save exit is supported without a dedicated menu option. Pick option 1 and stop the conversation, or use the question tool's free-text escape to say so directly — persistence is opt-in and the terminal review loop is already a complete ideation cycle.
 
@@ -164,64 +135,29 @@ Route refinement by intent:
 - `re-evaluate` or `raise the bar` -> return to Phase 3
 - `dig deeper on idea #N` -> expand only that idea's analysis
 
-No persistence triggers during refinement. The user can choose Save and end (or Brainstorm, or Open and iterate in Proof) when they are ready to persist.
+No persistence triggers during refinement. The user can choose Save and end (or Brainstorm) when they are ready to persist.
 
 Ending after refinement — or without any refinement at all — is a valid no-save exit. There is no required next step; stopping the conversation here leaves no durable artifact, which matches the opt-in persistence contract.
 
-### 6.2 Open and Iterate in Proof
-
-Invoke the Proof HITL review path via §5.2 with §6.2 as the caller. In repo mode, ensure the local file exists first (run §5.1) so the HITL sync-back has a target; in elsewhere mode, §5.2 renders to a temp file as usual. Honor Phase 5's "ensure a record exists first" contract either way.
-
-Apply §5.2's caller-aware return rule for the §6.2 branch — behavior is mode-aware. In repo mode, return to the Phase 6 menu on every status so the user can pick a follow-up (brainstorm toward a plan, save-and-end, or keep refining) now that the Proof review is reflected in the local file. In elsewhere mode, exit cleanly on a successful Proof return since Proof iteration is often the terminal act — the artifact lives at `docUrl` and is the canonical record; only the `aborted` status returns to the menu.
-
-If the Proof handoff fails, the §6.5 Proof Failure Ladder governs recovery.
-
-### 6.3 Brainstorm a Selected Idea
+### 6.2 Brainstorm a Selected Idea
 
-- Write or update the durable record per the mode default in Phase 5 (file in repo mode, Proof in elsewhere mode). When this routes through §5.2 Proof Save, apply §5.2's caller-aware return rule: continue into the next bullet on a successful Proof return instead of bouncing back to the Phase 6 menu. If Proof returned `aborted` (no durable record written), go back to the Phase 6 menu and do **not** proceed with the brainstorm handoff.
+- Write or update the durable record per the mode default in Phase 5 (5.1 file save)
 - Mark the chosen idea as `Explored` in the saved record
 - Load the `ce-brainstorm` skill with the chosen idea as the seed
 
-**Repo mode only:** do **not** skip brainstorming and go straight to `ce-plan` from ideation output — `ce-plan` wants brainstorm-grounded requirements. In elsewhere modes, ideation (or ideation + Proof iteration) is a legitimate terminal state; brainstorming is optional deeper development of one idea, not a required next rung on an implementation ladder that does not exist in these modes.
+**Repo mode only:** do **not** skip brainstorming and go straight to `ce-plan` from ideation output — `ce-plan` wants brainstorm-grounded requirements. In elsewhere modes, ideation is a legitimate terminal state; brainstorming is optional deeper development of one idea, not a required next rung on an implementation ladder that does not exist in these modes.
 
-### 6.4 Save and End
+### 6.3 Save and End
 
-Persist via the mode default (5.1 in repo mode, 5.2 in elsewhere mode), then end. If the user instead asked to use the non-default destination, honor that explicit request.
+Persist via the mode default (5.1), then end. If the user instead asked to use a non-default destination (custom path), honor that explicit request.
 
-When the path lands in a Proof save (5.2), apply §5.2's caller-aware return rule for the §6.4 branch: on a successful Proof return, exit cleanly — narrate the save, surface the `docUrl` (and any stale-local note if the pull was declined), and stop. Do **not** loop back to the Phase 6 menu; the user already chose to end. Only a `status: aborted` from Proof returns to the menu so the user can retry or pick another path (file save, custom path, or keep refining). The §6.5 Proof Failure Ladder still governs persistent Proof failures and ends at the Phase 6 menu — that failure-recovery path is distinct from the successful-save exit described here.
-
-When the path lands in a file save (5.1):
-
-- offer to commit only the ideation doc
+- offer to commit only the ideation doc (repo mode)
 - do not create a branch
 - do not push
 - if the user declines, leave the file uncommitted
 
 After the file save (and optional commit), end the session — do not return to the Phase 6 menu.
 
-### 6.5 Proof Failure Ladder
-
-The `ce-proof` skill performs single-retry-once internally on transient failures (`STALE_BASE`, `BASE_TOKEN_REQUIRED`) before surfacing failure. The proof skill's return contract does not expose typed error classes to callers — the orchestrator cannot distinguish retryable vs terminal failures from outside.
-
-**Orchestrator-side retry harness (intentionally minimal):** wrap the proof skill invocation in **one** additional best-effort retry with a short pause (~2 seconds). The proof skill already retried internally, so this catches transient races at the orchestrator boundary without compounding latency. Do not classify error types from outside the skill — no detection mechanism exists.
-
-Distinguish create-failure from ops-failure by inspecting whether the proof skill returned a `docUrl` before failing:
-
-- **Create-failure** (no `docUrl` returned): retry the create.
-- **Ops-failure** (a `docUrl` was returned, but a later operation failed): retry only the failing operation. **Do not recreate** the document.
-
-**Failure narration.** Narrate the single retry to the terminal so the pause does not look like a hang ("Retrying Proof... attempt 2/2"). On persistent failure, narrate that retry exhausted before showing the fallback menu.
-
-**Fallback menu after persistent failure.** Use the platform's blocking question tool. Present these options (omit option (a) if no repo exists at CWD):
-
-- "Save to `docs/ideation/` instead" (repo-mode default destination, available when CWD is inside a git repo)
-- "Save to a custom path the user provides" (validate writable; create parent dirs)
-- "Skip save and keep the ideation in conversation" (no persistence)
-
-If proof returned a partial `docUrl` before failing, surface that URL alongside the fallback options so the user can recover or share the partial record.
-
-After the fallback completes (any path), continue back to the Phase 6 menu so the user can still refine, iterate in Proof, brainstorm, or save and end.
-
 ## Quality Bar
 
 Before finishing, check:
@@ -235,6 +171,6 @@ Before finishing, check:
 - if sub-agents were used, they improved diversity without replacing the core workflow
 - every rejected idea has a reason
 - survivors are materially better than a naive "give me ideas" list
-- persistence followed user choice — terminal-only sessions did not write a file or call Proof
+- persistence followed user choice — terminal-only sessions did not write a file
 - when persistence did trigger, the mode default was respected unless the user explicitly overrode it
 - acting on an idea routes to `ce-brainstorm`, not directly to implementation

package/skills/ce-plan/SKILL.md

@@ -224,8 +224,8 @@ Prepare a concise planning context summary (a paragraph or two) to pass as input
 
 Run these agents in parallel:
 
-- Task systematic:research:repo-research-analyst(Scope: technology, architecture, patterns. {planning context summary})
-- Task systematic:research:learnings-researcher(planning context summary)
+- task systematic:research:repo-research-analyst(Scope: technology, architecture, patterns. {planning context summary})
+- task systematic:research:learnings-researcher(planning context summary)
 Collect:
 - Technology stack and versions (used in section 1.2 to make sharper external research decisions)
 - Architectural patterns and conventions to follow
@@ -293,8 +293,8 @@ Announce the decision briefly before continuing. Examples:
 
 If Step 1.2 indicates external research is useful, run these agents in parallel:
 
-- Task systematic:research:best-practices-researcher(planning context summary)
-- Task systematic:research:framework-docs-researcher(planning context summary)
+- task systematic:research:best-practices-researcher(planning context summary)
+- task systematic:research:framework-docs-researcher(planning context summary)
 
 #### 1.4 Consolidate Research
 
@@ -322,7 +322,7 @@ This ensures flow analysis (Phase 1.5) runs and the confidence check (Phase 5.3)
 
 For **Standard** or **Deep** plans, or when user flow completeness is still unclear, run:
 
-- Task systematic:workflow:spec-flow-analyzer(planning context summary, research findings)
+- task systematic:workflow:spec-flow-analyzer(planning context summary, research findings)
 
 Use the output to:
 - Identify missing edge cases, state transitions, or handoff gaps
@@ -790,7 +790,7 @@ Then continue to Phase 5.2 without a blocking question.
 
 **REQUIRED: Write the plan file to disk before presenting any options.**
 
-Use the Write tool to save the complete plan to:
+Use the write tool to save the complete plan to:
 
 ```text
 docs/plans/YYYY-MM-DD-NNN-<type>-<descriptive-name>-plan.md

package/skills/ce-plan/references/deepening-workflow.md

@@ -125,17 +125,16 @@ Use fully-qualified agent names inside Task calls.
 **System-Wide Impact**
 - `ce-architecture-strategist` for cross-boundary effects, interface surfaces, and architectural knock-on impact
 - Add the specific specialist that matches the risk:
-  - `ce-performance-oracle` for scalability, latency, throughput, and resource-risk analysis
-  - `ce-security-sentinel` for auth, validation, exploit surfaces, and security boundary review
-  - `ce-data-integrity-guardian` for migrations, persistent state safety, consistency, and data lifecycle risks
+  - `ce-performance-reviewer` for scalability, latency, throughput, and resource-risk analysis
+  - `ce-security-reviewer` for auth, validation, exploit surfaces, and security boundary review
+  - `ce-data-migrations-reviewer` for migrations, persistent state safety, consistency, and data lifecycle risks
 
 **Risks & Dependencies / Operational Notes**
 - Use the specialist that matches the actual risk:
-  - `ce-security-sentinel` for security, auth, privacy, and exploit risk
-  - `ce-data-integrity-guardian` for persistent data safety, constraints, and transaction boundaries
-  - `ce-data-migration-expert` for migration realism, backfills, and production data transformation risk
+  - `ce-security-reviewer` for security, auth, privacy, and exploit risk
+  - `ce-data-migrations-reviewer` for persistent data safety, constraints, transaction boundaries, and migration realism
   - `ce-deployment-verification-agent` for rollout checklists, rollback planning, and launch verification
-  - `ce-performance-oracle` for capacity, latency, and scaling concerns
+  - `ce-performance-reviewer` for capacity, latency, and scaling concerns
 
 **Agent Prompt Shape:**
 

package/skills/ce-plan/references/plan-handoff.md

@@ -40,29 +40,13 @@ After document-review completes, present the options using the platform's blocki
 **Options:**
 1. **Start `ce:work`** (recommended) - Begin implementing this plan in the current session
 2. **Create Issue** - Create a tracked issue from this plan in your configured issue tracker (GitHub or Linear)
-3. **Open in Proof (web app) — review and comment to iterate with the agent** - Open the doc in Every's Proof editor, iterate with the agent via comments, or copy a link to share with others
-4. **Done for now** - Pause; the plan file is saved and can be resumed later
+3. **Done for now** - Pause; the plan file is saved and can be resumed later
 
 **Surface additional document review contextually, not as a menu fixture:** When the prior document-review pass surfaced residual P0/P1 findings that the user has not addressed, mention them adjacent to the menu and offer another review pass in prose (e.g., "Document review flagged 2 P1 findings you may want to address — want me to run another pass before you pick?"). Do not add it to the option list.
 
 Based on selection:
 - **Start `ce:work`** -> Call `ce:work` with the plan path
 - **Create Issue** -> Follow the Issue Creation section below
-- **Open in Proof (web app) — review and comment to iterate with the agent** -> Load the `ce-proof` skill in HITL-review mode with:
-  - source file: `docs/plans/<plan_filename>.md`
-  - doc title: `Plan: <plan title from frontmatter>`
-  - identity: `ai:systematic` / `Systematic`
-  - recommended next step: `ce:work` (shown in the ce-proof skill's final terminal output)
-
-  Follow `references/hitl-review.md` in the ce-proof skill. It uploads the plan, prompts the user for review in Proof's web UI, ingests each thread by reading it fresh and replying in-thread, applies agreed edits as tracked suggestions, and syncs the final markdown back to the plan file atomically on proceed.
-
-  When the ce-proof skill returns:
-  - `status: proceeded` with `localSynced: true` -> the plan on disk now reflects the review. Re-run `ce-doc-review` on the updated plan before re-rendering the menu — HITL can materially rewrite the plan body, so the prior ce-doc-review pass no longer covers the current file and section 5.3.8 requires a review before any handoff option is offered. Then return to the post-generation options with the refreshed residual findings.
-  - `status: proceeded` with `localSynced: false` -> the reviewed version lives in Proof at `docUrl` but the local copy is stale. Offer to pull the Proof doc to `localPath` using the ce-proof skill's Pull workflow. If the pull happened, re-run `ce-doc-review` on the pulled file before re-rendering the options (same 5.3.8 rationale — the local plan was materially updated by the pull). If the pull was declined, include a one-line note above the menu that `<localPath>` is stale vs. Proof — otherwise `Start ce:work` or `Create Issue` will silently use the pre-review copy.
-  - `status: done_for_now` -> the plan on disk may be stale if the user edited in Proof before leaving. Offer to pull the Proof doc to `localPath` so the local plan file stays in sync. If the pull happened, re-run `ce-doc-review` on the pulled file before re-rendering the options (same 5.3.8 rationale). If the pull was declined, include the stale-local note above the menu. `done_for_now` means the user stopped the HITL loop — it does not mean they ended the whole plan session; they may still want to start work or create an issue.
-  - `status: aborted` -> fall back to the options without changes.
-
-  If the initial upload fails (network error, Proof API down), retry once after a short wait. If it still fails, tell the user the upload didn't succeed and briefly explain why, then return to the options — don't leave them wondering why the option did nothing.
 - **Done for now** -> Display a brief confirmation that the plan file is saved and end the turn
 - **If the user asks for another document review** (either from the contextual prompt when P0/P1 findings remain, or by free-form request) -> Load the `ce-doc-review` skill with the plan path for another pass, then return to the options
 - **Other** -> Accept free text for revisions and loop back to options

package/skills/ce-plan/references/universal-planning.md

@@ -107,8 +107,4 @@ After structuring the plan, ask the user how they want to receive it using the p
    - Use filename convention: `YYYY-MM-DD-<descriptive-name>-plan.md`
    - Start the document with a `# Title` heading, followed by `Created: YYYY-MM-DD` on the next line. No YAML frontmatter.
 
-2. **Open in Proof (web app) — review and comment to iterate with the agent** — Open the doc in Every's Proof editor, iterate with the agent via comments, or copy a link to share with others. Load the `ce-proof` skill to create and open the document.
-
-3. **Save to disk AND open in Proof** — Do both: write the markdown file to disk and open the doc in Proof for review.
-
 Do not offer `ce:work` (software-only) or issue creation (not applicable to non-software plans).

package/skills/ce-review/SKILL.md

@@ -46,7 +46,7 @@ All tokens are optional. Each one present means one less thing to infer. When ab
 - **Skip all user questions.** Never pause for approval or clarification once scope has been established.
 - **Apply only `safe_auto -> review-fixer` findings.** Leave `gated_auto`, `manual`, `human`, and `release` work unresolved.
 - **Write a run artifact** under `.context/systematic/ce-review/<run-id>/` summarizing findings, applied fixes, residual actionable work, and advisory outputs.
-- **Create durable todo files only for unresolved actionable findings** whose final owner is `downstream-resolver`. Load the `todo-create` skill for the canonical directory path and naming convention.
+- **Create durable todo files only for unresolved actionable findings** whose final owner is `downstream-resolver`. Load the `todos` skill (Create section) for the canonical directory path and naming convention.
 - **Never commit, push, or create a PR** from autofix mode. Parent workflows own those decisions.
 
 ### Report-only mode rules
@@ -101,7 +101,7 @@ Routing rules:
 
 ## Reviewers
 
-17 reviewer personas in layered conditionals, plus CE-specific agents. See the persona catalog included below for the full catalog.
+13 reviewer personas in layered conditionals, plus CE-specific agents. See the persona catalog included below for the full catalog.
 
 **Always-on (every review):**
 
@@ -131,22 +131,17 @@ Routing rules:
 
 | Agent | Select when diff touches... |
 |-------|---------------------------|
-| `systematic:review:dhh-rails-reviewer` | Rails architecture, service objects, session/auth choices, or Hotwire-vs-SPA boundaries |
-| `systematic:review:kieran-rails-reviewer` | Rails application code where conventions, naming, and maintainability are in play |
-| `systematic:review:kieran-python-reviewer` | Python modules, endpoints, scripts, or services |
 | `systematic:review:kieran-typescript-reviewer` | TypeScript components, services, hooks, utilities, or shared types |
-| `systematic:review:julik-frontend-races-reviewer` | Stimulus/Turbo controllers, DOM events, timers, animations, or async UI flows |
 
 **CE conditional (migration-specific):**
 
 | Agent | Select when diff includes migration files |
 |-------|------------------------------------------|
-| `systematic:review:schema-drift-detector` | Cross-references schema.rb against included migrations |
 | `systematic:review:deployment-verification-agent` | Produces deployment checklist with SQL verification queries |
 
 ## Review Scope
 
-Every review spawns all 4 always-on personas plus the 2 CE always-on agents, then adds whichever cross-cutting and stack-specific conditionals fit the diff. The model naturally right-sizes: a small config change triggers 0 conditionals = 6 reviewers. A Rails auth feature might trigger security + reliability + kieran-rails + dhh-rails = 10 reviewers.
+Every review spawns all 4 always-on personas plus the 2 CE always-on agents, then adds whichever cross-cutting and stack-specific conditionals fit the diff. The model naturally right-sizes: a small config change triggers 0 conditionals = 6 reviewers. An auth feature touching data migrations might trigger security + reliability + data-migrations = 9 reviewers.
 
 ## Protected Artifacts
 
@@ -343,7 +338,7 @@ Read the diff and file list from Stage 1. The 4 always-on personas and 2 CE alwa
 
 **`previous-comments` is PR-only.** Only select this persona when Stage 1 gathered PR metadata (PR number or URL was provided as an argument, or `gh pr view` returned metadata for the current branch). Skip it entirely for standalone branch reviews with no associated PR -- there are no prior comments to check.
 
-Stack-specific personas are additive. A Rails UI change may warrant `kieran-rails` plus `julik-frontend-races`; a TypeScript API diff may warrant `kieran-typescript` plus `api-contract` and `reliability`.
+Stack-specific personas are additive. A TypeScript API diff may warrant `kieran-typescript` plus `api-contract` and `reliability`.
 
 For CE conditional agents, check if the diff includes files matching `db/migrate/*.rb`, `db/schema.rb`, or data backfill scripts.
 
@@ -358,10 +353,7 @@ Review team:
 - agent-native-reviewer (always)
 - learnings-researcher (always)
 - security -- new endpoint in routes.rb accepts user-provided redirect URL
-- kieran-rails -- controller and Turbo flow changed in app/controllers and app/views
-- dhh-rails -- diff adds service objects around ordinary Rails CRUD
 - data-migrations -- adds migration 20260303_add_index_to_orders
-- schema-drift-detector -- migration files present
 ```
 
 This is progress reporting, not a blocking confirmation.
@@ -383,7 +375,7 @@ Persona sub-agents do focused, scoped work and should use a fast mid-tier model
 
 Use the platform's mid-tier model for all persona and CE sub-agents. In OpenCode, pass `model: "sonnet"` in the Agent tool call. On other platforms, use the equivalent mid-tier (e.g., `gpt-4o` in Codex). If the platform has no model override mechanism or the available model names are unknown, omit the model parameter and let agents inherit the default -- a working review on the parent model is better than a broken dispatch from an unrecognized model name.
 
-CE always-on agents (agent-native-reviewer, learnings-researcher) and CE conditional agents (schema-drift-detector, deployment-verification-agent) also use the mid-tier model since they perform scoped, focused work.
+CE always-on agents (agent-native-reviewer, learnings-researcher) and CE conditional agents (deployment-verification-agent) also use the mid-tier model since they perform scoped, focused work.
 
 The orchestrator (this skill) stays on the default model because it handles intent discovery, reviewer selection, finding merge/dedup, and synthesis -- tasks that benefit from stronger reasoning.
 
@@ -446,7 +438,7 @@ Detail-tier fields (`why_it_matters`, `evidence`) are in the artifact file only.
 
 **CE always-on agents** (agent-native-reviewer, learnings-researcher) are dispatched as standard Agent calls in parallel with the persona agents. Give them the same review context bundle the personas receive: entry mode, any PR metadata gathered in Stage 1, intent summary, review base branch name when known, `BASE:` marker, file list, diff, and `UNTRACKED:` scope notes. Do not invoke them with a generic "review this" prompt. Their output is unstructured and synthesized separately in Stage 6.
 
-**CE conditional agents** (schema-drift-detector, deployment-verification-agent) are also dispatched as standard Agent calls when applicable. Pass the same review context bundle plus the applicability reason (for example, which migration files triggered the agent). For schema-drift-detector specifically, pass the resolved review base branch explicitly so it never assumes `main`. Their output is unstructured and must be preserved for Stage 6 synthesis just like the CE always-on agents.
+**CE conditional agents** (deployment-verification-agent) are also dispatched as standard Agent calls when applicable. Pass the same review context bundle plus the applicability reason (for example, which migration files triggered the agent). Their output is unstructured and must be preserved for Stage 6 synthesis just like the CE always-on agents.
 
 ### Stage 5: Merge findings
 
@@ -512,10 +504,9 @@ Assemble the final report using **pipe-delimited markdown tables for findings**
 7. **Filtered (not validated).** Include when Stage 5b produced any findings with `validated: false`. Render as a pipe-delimited table with columns `#`, `File`, `Issue`, `Reviewer`, `Confidence`, `Validator reason`. These findings are surfaced for human review — they are not removed from the report. The validator found evidence that the issue may not be real in the code as written, was not introduced by this diff, or is already handled elsewhere; the human reviewer makes the final call. Omit this section when no findings were filtered.
 8. **Learnings & Past Solutions.** Surface learnings-researcher results: if past solutions are relevant, flag them as "Known Pattern" with links to docs/solutions/ files.
 9. **Agent-Native Gaps.** Surface agent-native-reviewer results. Omit section if no gaps found.
-10. **Schema Drift Check.** If schema-drift-detector ran, summarize whether drift was found. If drift exists, list the unrelated schema objects and the required cleanup command. If clean, say so briefly.
-11. **Deployment Notes.** If deployment-verification-agent ran, surface the key Go/No-Go items: blocking pre-deploy checks, the most important verification queries, rollback caveats, and monitoring focus areas. Keep the checklist actionable rather than dropping it into Coverage.
-12. **Coverage.** Suppressed count, residual risks, testing gaps, failed/timed-out reviewers, validator failures, and any intent uncertainty carried by non-interactive modes.
-13. **Verdict.** Ready to merge / Ready with fixes / Not ready. Fix order if applicable. When an `explicit` plan has unaddressed requirements, the verdict must reflect it — a PR that's code-clean but missing planned requirements is "Not ready" unless the omission is intentional. When an `inferred` plan has unaddressed requirements, note it in the verdict reasoning but do not block on it alone.
+10. **Deployment Notes.** If deployment-verification-agent ran, surface the key Go/No-Go items: blocking pre-deploy checks, the most important verification queries, rollback caveats, and monitoring focus areas. Keep the checklist actionable rather than dropping it into Coverage.
+11. **Coverage.** Suppressed count, residual risks, testing gaps, failed/timed-out reviewers, validator failures, and any intent uncertainty carried by non-interactive modes.
+12. **Verdict.** Ready to merge / Ready with fixes / Not ready. Fix order if applicable. When an `explicit` plan has unaddressed requirements, the verdict must reflect it — a PR that's code-clean but missing planned requirements is "Not ready" unless the omission is intentional. When an `inferred` plan has unaddressed requirements, note it in the verdict reasoning but do not block on it alone.
 
 Do not include time estimates.
 
@@ -715,7 +706,7 @@ After presenting findings and verdict (Stage 6), route the next steps by mode. R
   }
   ```
   Capture `branch` and `head_sha` at dispatch time (before any autofixes land), and write the file after the verdict is finalized. This file is additive -- pre-existing artifacts that predate this field are still valid, and downstream skills fall back to file mtime when it is missing.
-- In autofix mode, create durable todo files only for unresolved actionable findings whose final owner is `downstream-resolver`. Load the `todo-create` skill for the canonical directory path, naming convention, YAML frontmatter structure, and template. Each todo should map the finding's severity to the todo priority (`P0`/`P1` -> `p1`, `P2` -> `p2`, `P3` -> `p3`) and set `status: ready` since these findings have already been triaged by synthesis.
+- In autofix mode, create durable todo files only for unresolved actionable findings whose final owner is `downstream-resolver`. Load the `todos` skill (Create section) for the canonical directory path, naming convention, YAML frontmatter structure, and template. Each todo should map the finding's severity to the todo priority (`P0`/`P1` -> `p1`, `P2` -> `p2`, `P3` -> `p3`) and set `status: ready` since these findings have already been triaged by synthesis.
 - Do not create todos for `advisory` findings, `owner: human`, `owner: release`, or protected-artifact cleanup suggestions.
 - If only advisory outputs remain, create no todos.
 - Interactive mode may offer to externalize residual actionable work after fixes, but it is not required to finish the review.

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

@@ -1,6 +1,6 @@
 # Persona Catalog
 
-17 reviewer personas organized into always-on, cross-cutting conditional, and stack-specific conditional layers, plus CE-specific agents. The orchestrator uses this catalog to select which reviewers to spawn for each review.
+13 reviewer personas organized into always-on, cross-cutting conditional, and stack-specific conditional layers, plus CE-specific agents. The orchestrator uses this catalog to select which reviewers to spawn for each review.
 
 ## Always-on (4 personas + 2 CE agents)
 
@@ -37,17 +37,13 @@ Spawned when the orchestrator identifies relevant patterns in the diff. The orch
 | `cli-readiness` | `systematic:review:cli-readiness-reviewer` | CLI command definitions, argument parsing, CLI framework usage, command handler implementations |
 | `previous-comments` | `systematic:review:previous-comments-reviewer` | **PR-only.** Reviewing a PR that has existing review comments or review threads from prior review rounds. Skip entirely when no PR metadata was gathered in Stage 1. |
 
-## Stack-Specific Conditional (5 personas)
+## Stack-Specific Conditional (1 persona)
 
 These reviewers keep their original opinionated lens. They are additive with the cross-cutting personas above, not replacements for them.
 
 | Persona | Agent | Select when diff touches... |
 |---------|-------|---------------------------|
-| `dhh-rails` | `systematic:review:dhh-rails-reviewer` | Rails architecture, service objects, authentication/session choices, Hotwire-vs-SPA boundaries, or abstractions that may fight Rails conventions |
-| `kieran-rails` | `systematic:review:kieran-rails-reviewer` | Rails controllers, models, views, jobs, components, routes, or other application-layer Ruby code where clarity and conventions matter |
-| `kieran-python` | `systematic:review:kieran-python-reviewer` | Python modules, endpoints, services, scripts, or typed domain code |
 | `kieran-typescript` | `systematic:review:kieran-typescript-reviewer` | TypeScript components, services, hooks, utilities, or shared types |
-| `julik-frontend-races` | `systematic:review:julik-frontend-races-reviewer` | Stimulus/Turbo controllers, DOM event wiring, timers, async UI flows, animations, or frontend state transitions with race potential |
 
 ## CE Conditional Agents (migration-specific)
 
@@ -55,7 +51,6 @@ These CE-native agents provide specialized analysis beyond what the persona agen
 
 | Agent | Focus |
 |-------|-------|
-| `systematic:review:schema-drift-detector` | Cross-references schema.rb changes against included migrations to catch unrelated drift |
 | `systematic:review:deployment-verification-agent` | Produces Go/No-Go deployment checklist with SQL verification queries and rollback procedures |
 
 ## Selection rules

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

@@ -135,7 +135,6 @@ This fails because: no pipe-delimited tables, no severity-grouped `###` headers,
 - **Filtered (not validated) section** -- findings where Stage 5b returned `validated: false`. Rendered as a pipe-delimited table with columns `#`, `File`, `Issue`, `Reviewer`, `Confidence`, `Validator reason`. These findings are surfaced for human review, not removed. Omit this section when Stage 5b produced no filtered findings.
 - **Learnings & Past Solutions section** -- results from learnings-researcher, with links to docs/solutions/ files
 - **Agent-Native Gaps section** -- results from agent-native-reviewer. Omit if no gaps found.
-- **Schema Drift Check section** -- results from schema-drift-detector. Omit if the agent did not run.
 - **Deployment Notes section** -- key checklist items from deployment-verification-agent. Omit if the agent did not run.
 - **Coverage section** -- suppressed count, residual risks, testing gaps, failed reviewers
 - **Summary uses blockquotes** for verdict, reasoning, and fix order

package/skills/ce-work/SKILL.md

@@ -296,7 +296,7 @@ Determine how to proceed based on what was provided in `<input_document>`.
    For UI work with Figma designs:
 
    - Implement components following design specs
-   - Use figma-design-sync agent iteratively to compare
+   - Use design-iterator agent iteratively to compare
    - Fix visual differences identified
    - Repeat until implementation matches design
 

package/skills/deepen-plan/SKILL.md

@@ -234,17 +234,16 @@ Use fully-qualified agent names inside Task calls.
 **System-Wide Impact**
 - `systematic:review:architecture-strategist` for cross-boundary effects, interface surfaces, and architectural knock-on impact
 - Add the specific specialist that matches the risk:
-  - `systematic:review:performance-oracle` for scalability, latency, throughput, and resource-risk analysis
-  - `systematic:review:security-sentinel` for auth, validation, exploit surfaces, and security boundary review
-  - `systematic:review:data-integrity-guardian` for migrations, persistent state safety, consistency, and data lifecycle risks
+  - `systematic:review:performance-reviewer` for scalability, latency, throughput, and resource-risk analysis
+  - `systematic:review:security-reviewer` for auth, validation, exploit surfaces, and security boundary review
+  - `systematic:review:data-migrations-reviewer` for migrations, persistent state safety, consistency, and data lifecycle risks
 
 **Risks & Dependencies / Operational Notes**
 - Use the specialist that matches the actual risk:
-  - `systematic:review:security-sentinel` for security, auth, privacy, and exploit risk
-  - `systematic:review:data-integrity-guardian` for persistent data safety, constraints, and transaction boundaries
-  - `systematic:review:data-migration-expert` for migration realism, backfills, and production data transformation risk
+  - `systematic:review:security-reviewer` for security, auth, privacy, and exploit risk
+  - `systematic:review:data-migrations-reviewer` for persistent data safety, constraints, transaction boundaries, and migration realism
   - `systematic:review:deployment-verification-agent` for rollout checklists, rollback planning, and launch verification
-  - `systematic:review:performance-oracle` for capacity, latency, and scaling concerns
+  - `systematic:review:performance-reviewer` for capacity, latency, and scaling concerns
 
 #### 3.2 Agent Prompt Shape
 

package/skills/document-review/SKILL.md

@@ -23,7 +23,7 @@ The caller receives findings with their original classifications intact and deci
 
 Callers invoke headless mode by including `mode:headless` in the skill arguments, e.g.:
 ```
-Skill("systematic:document-review", "mode:headless docs/plans/my-plan.md")
+skill("systematic:document-review", "mode:headless docs/plans/my-plan.md")
 ```
 
 
@@ -35,7 +35,7 @@ If `mode:headless` is not present, the skill runs in its default interactive mod
 
 **If no document is specified (interactive mode):** Ask which document to review, or find the most recent in `docs/brainstorms/` or `docs/plans/` using a file-search/glob tool (e.g., Glob in OpenCode).
 
-**If no document is specified (headless mode):** Output "Review failed: headless mode requires a document path. Re-invoke with: Skill(\"systematic:document-review\", \"mode:headless <path>\")" without dispatching agents.
+**If no document is specified (headless mode):** Output "Review failed: headless mode requires a document path. Re-invoke with: skill(\"systematic:document-review\", \"mode:headless <path>\")" without dispatching agents.
 
 ### Classify Document Type
 

package/skills/git-commit-push-pr/SKILL.md

@@ -80,7 +80,7 @@ EOF
 
 If the PR is not open or the commit range cannot be resolved, report the issue and stop.
 
-**Evidence decision:** Preserve any existing `## Demo` or `## Screenshots` block from the current body by default. If the user's focus asks to refresh or remove evidence, honor that intent. If no evidence block exists and one would benefit the reader, load the `feature-video` skill to capture evidence, then splice the result as a `## Demo` section into the body file.
+**Evidence decision:** Preserve any existing `## Demo` or `## Screenshots` block from the current body by default. If the user's focus asks to refresh or remove evidence, honor that intent.
 
 **Compare and confirm** — briefly explain what the new description covers differently from the old one. This helps the user decide whether to apply; the description itself does not narrate these differences. Summarize from the body already in context (from the bash call that wrote `body_file`); do not `cat` the temp file, which would re-emit the body.
 
@@ -198,7 +198,6 @@ Use this branch diff (not the working-tree diff) for the evidence decision. If t
 
 **Evidence decision (before delegation).** If the branch diff changes observable behavior (UI, CLI output, API behavior with runnable code, generated artifacts, workflow output) and evidence is not otherwise blocked (unavailable credentials, paid services, deploy-only infrastructure, hardware), ask: "This PR has observable behavior. Capture evidence for the PR description?"
 
-- **Capture now** -- load the `feature-video` skill with a target description inferred from the branch diff. feature-video returns `Tier`, `Description`, and `URL`. Note the captured evidence so it can be spliced into the PR body as a `## Demo` section. If capture returns `Tier: skipped` or `URL: "none"`, proceed with no evidence.
 - **Use existing evidence** -- ask for the URL or markdown embed, then splice it into the PR body as a `## Demo` section before applying.
 - **Skip** -- proceed with no evidence section.
 

package/skills/lfg/SKILL.md

@@ -21,7 +21,7 @@ CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any required s
 
    Pass the plan file path from step 2 so ce:review can verify requirements completeness.
 
-5. `/systematic:todo-resolve`
+5. `/systematic:todos` (resolve)
 
 6. `/systematic:test-browser`
 

package/skills/onboarding/SKILL.md

@@ -389,19 +389,8 @@ After writing, inform the user that `ONBOARDING.md` has been generated. Offer ne
 
 Options:
 1. Open the file for review
-2. Share to Proof
-3. Done
+2. Done
 
 Based on selection:
 - **Open for review** -> Open `ONBOARDING.md` using the current platform's file-open or editor mechanism
-- **Share to Proof** -> Upload the document:
-  ```bash
-  CONTENT=$(cat ONBOARDING.md)
-  TITLE="Onboarding: <project name from inventory>"
-  RESPONSE=$(curl -s -X POST https://www.proofeditor.ai/share/markdown \
-    -H "Content-Type: application/json" \
-    -d "$(jq -n --arg title "$TITLE" --arg markdown "$CONTENT" --arg by "ai:compound" '{title: $title, markdown: $markdown, by: $by}')")
-  PROOF_URL=$(echo "$RESPONSE" | jq -r '.tokenUrl')
-  ```
-  Display `View & collaborate in Proof: <PROOF_URL>` if successful, then return to the options
 - **Done** -> No further action

package/skills/orchestrating-subagents/SKILL.md

@@ -82,8 +82,8 @@ Dispatch multiple foreground subagents in the same turn. OpenCode runs them conc
 
 ```typescript
 // Dispatch independent review subagents together
-task({ subagent_type: "security-sentinel", description: "Security review", prompt: "..." })
-task({ subagent_type: "performance-oracle", description: "Performance review", prompt: "..." })
+task({ subagent_type: "security-reviewer", description: "Security review", prompt: "..." })
+task({ subagent_type: "performance-reviewer", description: "Performance review", prompt: "..." })
 task({ subagent_type: "correctness-reviewer", description: "Correctness review", prompt: "..." })
 // All three run; orchestrator synthesizes results after all complete
 ```