oh-my-opencode 5.0.0-beta.79 → 5.0.0-beta.80

package/dist/config-migration/category-deep-split.d.ts

@@ -0,0 +1,3 @@
+import type { ConfigMigrationTransformResult } from "./transform-types";
+export declare const CATEGORY_DEEP_SPLIT_MIGRATION_ID = "2026-09-category-deep-split";
+export declare function transformCategoryDeepSplit(document: unknown): ConfigMigrationTransformResult;

package/dist/config-migration/migration-plans.d.ts

@@ -5,6 +5,7 @@ export type LegacyConfigMigrationPlan = {
     readonly id: string;
     readonly inspect: (sources: Parameters<MigrationTransform>[0]) => ConfigMigrationTransformResult;
     readonly mode?: "merge" | "replace-target";
+    readonly shouldRun?: (target: Readonly<Record<string, unknown>>) => boolean;
     readonly sources: readonly MigrationSourceDescriptor[];
     readonly targetPath: string;
     readonly transform: MigrationTransform;

package/dist/features/builtin-commands/templates/hyperplan.d.ts

@@ -1 +1 @@
-export declare const HYPERPLAN_TEMPLATE = "You are running the `/hyperplan` command \u2014 adversarial multi-agent planning via team-mode.\n\nLOAD THE HYPERPLAN SKILL IMMEDIATELY:\n\n```\nskill(name=\"hyperplan\")\n```\n\nAfter loading the skill, follow its 7-phase workflow EXACTLY using this user request.\n\nRoster contract: call `team_create` with category members `unspecified-low`, `unspecified-high`, `ultrabrain`, and `artistry`. Include `deep` only if the category is enabled; if `deep` is disabled or unavailable, retry without only that member and state the degraded roster.\n\n<user-request>\n$ARGUMENTS\n</user-request>\n\nIf team-mode is unavailable (`team_*` tools missing), instruct the user to set `team_mode.enabled: true` in `~/.omo/omo.jsonc` and restart opencode.";
+export declare const HYPERPLAN_TEMPLATE = "You are running the `/hyperplan` command \u2014 adversarial multi-agent planning via team-mode.\n\nLOAD THE HYPERPLAN SKILL IMMEDIATELY:\n\n```\nskill(name=\"hyperplan\")\n```\n\nAfter loading the skill, follow its 7-phase workflow EXACTLY using this user request.\n\nRoster contract: call `team_create` with category members `unspecified-low`, `unspecified-high`, `ultrabrain`, and `artistry`. Include `deep-low` only if the category is enabled; if `deep-low` is disabled or unavailable, retry without only that member and state the degraded roster.\n\n<user-request>\n$ARGUMENTS\n</user-request>\n\nIf team-mode is unavailable (`team_*` tools missing), instruct the user to set `team_mode.enabled: true` in `~/.omo/omo.jsonc` and restart opencode.";

package/dist/features/builtin-commands/templates/refactor-sections/team-mode-addendum.d.ts

@@ -1 +1 @@
-export declare const REFACTOR_TEAM_MODE_ADDENDUM = "\n---\n\n# Team Mode Protocol (active when team_* tools are present)\n\nTeam mode is enabled for this session. The rules below **override Phase 4-6** above. Follow this protocol instead of the in-session step-by-step execution.\n\n## Phase 4 override: Plan agent staffing requirement\n\nWhen invoking the Plan agent in Phase 4.1, append this additional requirement to the prompt:\n\n```\n7. (REQUIRED when team mode is active) Output a Team Staffing Recommendation section with these fields \u2014 missing fields fail Phase 5.0:\n   - total_atomic_steps: integer\n   - file_independent_steps: integer (parallelizable, no cross-file blocker)\n   - cross_file_dependent_steps: integer (has blockers)\n   - per_step_assignment: [{step_id, assigned_to: 'quick' | 'unspecified-low', blockedBy: [step_ids], rationale}]\n   - dispatch_path_recommendation: 'team' | 'legacy' with reason\n   - rationale for the composition\n```\n\n**Classification rules** the plan agent must apply to each step:\n- `quick`: mechanical edits \u2014 LSP rename, extract variable, inline, simple move, signature change without call-site logic.\n- `unspecified-low`: logic-preserving refactors that need reasoning \u2014 extract function, restructure conditional, pattern transformation, cross-file API change.\n- Recommend `team` path when `file_independent_steps >= 3`; recommend `legacy` otherwise.\n\n## Phase 5 override: Dispatch path selection\n\nRead the Team Staffing Recommendation from Phase 4. If any required field is missing, fail here and re-request the plan with the exact missing field names. Do not proceed with a partial plan.\n\nThen choose the path:\n\n- **Team path (5.1-T)**: when the plan recommends `team` AND `file_independent_steps >= 3`. Members execute in parallel, Lead orchestrates, a `deep` verifier lives outside the team.\n- **Legacy path (5.1-L)**: otherwise. Use the original 5.1 / 5.2 / 5.3 flow from above.\n\nRecord the chosen path in the TodoWrite list.\n\n## Phase 5.1-T: `refactor-squad` team execution\n\n**Precondition checks** (fail hard if any step fails):\n\n1. Load the `team-mode` skill via the `skill` tool for lifecycle, message protocol, and limits.\n2. Call `team_list` and verify no active `refactor-squad` run exists; if one does, shutdown + delete the orphan before proceeding.\n3. If `~/.omo/teams/refactor-squad/config.json` is missing, write it using the spec below.\n\n**Team spec** (`~/.omo/teams/refactor-squad/config.json`):\n\n```json\n{\n  \"name\": \"refactor-squad\",\n  \"lead\": { \"kind\": \"subagent_type\", \"subagent_type\": \"sisyphus\" },\n  \"members\": [\n    {\n      \"kind\": \"category\",\n      \"category\": \"quick\",\n      \"prompt\": \"You handle mechanical refactoring steps (LSP rename, extract variable, inline, simple move, signature change). Use LSP tools for correctness. Apply the task description's per-step instructions verbatim \u2014 no scope expansion. After edits, run lsp_diagnostics on touched files. Report via team_send_message(teamRunId=<id>, to=\"lead\", summary=<files touched>, body=<lsp status + diff summary>) + team_task_update(status=completed). Never run tests \u2014 the external verifier handles that. Never git add, never --continue.\"\n    },\n    { \"kind\": \"category\", \"category\": \"quick\", \"prompt\": \"Same contract as peer quick worker.\" },\n    {\n      \"kind\": \"category\",\n      \"category\": \"unspecified-low\",\n      \"prompt\": \"You handle logic-preserving refactors that need reasoning (extract function, restructure conditional, pattern transformation, cross-file API change). Read the task description's plan step carefully. Use the ast-grep skill helper or sg CLI to preview structural rewrites first, review the preview, then execute. If the step is ambiguous or would require out-of-scope changes, STOP and send team_send_message(teamRunId=<id>, to=\"lead\", summary=\"UNCLEAR\", body=<reason>) + team_task_update(status=pending). Same reporting contract as peer quick workers. Never run tests.\"\n    },\n    { \"kind\": \"category\", \"category\": \"unspecified-low\", \"prompt\": \"Same contract as peer unspecified-low worker.\" }\n  ]\n}\n```\n\nRationale for this composition:\n- **4 workers = team mode's parallel cap.** 5+ just queues.\n- **No verifier team member.** Verification needs `deep` reasoning (or `unspecified-high` fallback). In-team category routing downcasts to sisyphus-junior, which is weaker than required \u2014 the verifier runs OUTSIDE the team as a `task(category=\"deep\")`.\n- **quick \u00D7 2** for mechanical edits, **unspecified-low \u00D7 2** for reasoning edits \u2014 mirrors the plan's split.\n\n**Team lifecycle** (one team, reused until Phase 6 cleanup):\n\n1. `team_create(teamName=\"refactor-squad\")`. Record `teamRunId`.\n2. Broadcast the refactor Intent Card ONCE (keep task descriptions slim):\n   ```\n   team_send_message(\n     teamRunId=<id>, to=\"*\", kind=\"announcement\",\n     summary=\"refactor-intent\",\n     body=<codemap summary + constraints + established patterns from Phase 2>\n   )\n   ```\n3. Broadcast the verification spec ONCE:\n   ```\n   team_send_message(\n     teamRunId=<id>, to=\"*\", kind=\"announcement\",\n     summary=\"verify-spec\",\n     body=<exact test/typecheck/lint commands + expected pass counts + regression indicators from Phase 3.4>\n   )\n   ```\n4. For each plan step, `team_task_create(teamRunId=<id>, subject=\"refactor step <N>: <short>\", description=<per-step instructions from plan, including target files and line ranges, rollback strategy>, blockedBy=<from plan's per_step_assignment>)`.\n\n**Lead monitoring loop**:\n\nWhile any team task is `pending | claimed | in_progress`:\n\n- Wait for `<system-reminder>` or member messages. Avoid tight polling; a single `team_status` check is acceptable if no notification arrives within roughly 10 seconds of expected completion.\n- On a worker completion report, immediately dispatch an **external verifier** \u2014 verification runs OUTSIDE the team because team-member category routing downcasts to sisyphus-junior:\n  ```\n  task(\n    category=\"deep\",\n    load_skills=[],\n    run_in_background=true,\n    description=\"verify step <N>\",\n    prompt=<files touched + verify-spec commands + instruction to return \"PASS\" or \"FAIL:<failing test + specific error + suggested revert hunks>\">\n  )\n  ```\n  If `deep` is unavailable, fall back to `category=\"unspecified-high\"`. Do not create a commit checkpoint until the verifier returns PASS.\n- On a verifier PASS: make the commit checkpoint for that step (see original 5.3). Proceed.\n- On a verifier FAIL: Lead decides:\n  - **Retry with fix hint**: `team_task_update(status=pending)` on the original step + `team_send_message(teamRunId=<id>, to=<original member>, summary=\"retry\", body=<specific failure from verifier>)`. Runtime reassigns.\n  - **Escalate**: after three FAIL cycles on the same step, STOP and consult the user with full evidence.\n- On a member UNCLEAR message: re-harvest context via a targeted `task()` outside the team, broadcast an updated Intent Card fragment, then reassign.\n\nProceed to Phase 6 only when every team task is `completed` AND every paired verifier task returned PASS.\n\n## Phase 6 override: Team cleanup before summary\n\nIf Phase 5 used the team path, dismantle `refactor-squad` BEFORE producing the 6.6 summary. Every exit path \u2014 success, escalation, abort \u2014 must cleanup; orphan teams poison the next session's precondition check.\n\n1. `team_shutdown_request` for each member, then `team_approve_shutdown` if members do not self-approve within a reasonable window.\n2. `team_delete(teamRunId=<id>)`.\n3. `team_list` to confirm no residual `refactor-squad` run.\n\nThe `~/.omo/teams/refactor-squad/config.json` declaration stays on disk; next session reuses it.\n\nAppend to the 6.6 summary a \"Dispatch path\" line and, when team path was used, team metrics (teamRunId, tasks created, verifier runs, team lifetime).\n\n## MUST NOT (team mode)\n\n- Lead never edits files directly \u2014 orchestrate only.\n- Do not inline the Intent Card or verify-spec into task descriptions \u2014 rely on the broadcasts.\n- Do not recreate the team mid-session.\n- Do not run tests from Lead \u2014 the external verifier owns that lane.\n- Do not put `oracle` / `librarian` / `deep` into the team spec \u2014 oracle/librarian are team-ineligible, and `deep` under category routing downcasts to sisyphus-junior. Use them via `task()` outside the team when needed.\n";
+export declare const REFACTOR_TEAM_MODE_ADDENDUM = "\n---\n\n# Team Mode Protocol (active when team_* tools are present)\n\nTeam mode is enabled for this session. The rules below **override Phase 4-6** above. Follow this protocol instead of the in-session step-by-step execution.\n\n## Phase 4 override: Plan agent staffing requirement\n\nWhen invoking the Plan agent in Phase 4.1, append this additional requirement to the prompt:\n\n```\n7. (REQUIRED when team mode is active) Output a Team Staffing Recommendation section with these fields \u2014 missing fields fail Phase 5.0:\n   - total_atomic_steps: integer\n   - file_independent_steps: integer (parallelizable, no cross-file blocker)\n   - cross_file_dependent_steps: integer (has blockers)\n   - per_step_assignment: [{step_id, assigned_to: 'quick' | 'unspecified-low', blockedBy: [step_ids], rationale}]\n   - dispatch_path_recommendation: 'team' | 'legacy' with reason\n   - rationale for the composition\n```\n\n**Classification rules** the plan agent must apply to each step:\n- `quick`: mechanical edits \u2014 LSP rename, extract variable, inline, simple move, signature change without call-site logic.\n- `unspecified-low`: logic-preserving refactors that need reasoning \u2014 extract function, restructure conditional, pattern transformation, cross-file API change.\n- Recommend `team` path when `file_independent_steps >= 3`; recommend `legacy` otherwise.\n\n## Phase 5 override: Dispatch path selection\n\nRead the Team Staffing Recommendation from Phase 4. If any required field is missing, fail here and re-request the plan with the exact missing field names. Do not proceed with a partial plan.\n\nThen choose the path:\n\n- **Team path (5.1-T)**: when the plan recommends `team` AND `file_independent_steps >= 3`. Members execute in parallel, Lead orchestrates, a `deep-high` verifier lives outside the team.\n- **Legacy path (5.1-L)**: otherwise. Use the original 5.1 / 5.2 / 5.3 flow from above.\n\nRecord the chosen path in the TodoWrite list.\n\n## Phase 5.1-T: `refactor-squad` team execution\n\n**Precondition checks** (fail hard if any step fails):\n\n1. Load the `team-mode` skill via the `skill` tool for lifecycle, message protocol, and limits.\n2. Call `team_list` and verify no active `refactor-squad` run exists; if one does, shutdown + delete the orphan before proceeding.\n3. If `~/.omo/teams/refactor-squad/config.json` is missing, write it using the spec below.\n\n**Team spec** (`~/.omo/teams/refactor-squad/config.json`):\n\n```json\n{\n  \"name\": \"refactor-squad\",\n  \"lead\": { \"kind\": \"subagent_type\", \"subagent_type\": \"sisyphus\" },\n  \"members\": [\n    {\n      \"kind\": \"category\",\n      \"category\": \"quick\",\n      \"prompt\": \"You handle mechanical refactoring steps (LSP rename, extract variable, inline, simple move, signature change). Use LSP tools for correctness. Apply the task description's per-step instructions verbatim \u2014 no scope expansion. After edits, run lsp_diagnostics on touched files. Report via team_send_message(teamRunId=<id>, to=\"lead\", summary=<files touched>, body=<lsp status + diff summary>) + team_task_update(status=completed). Never run tests \u2014 the external verifier handles that. Never git add, never --continue.\"\n    },\n    { \"kind\": \"category\", \"category\": \"quick\", \"prompt\": \"Same contract as peer quick worker.\" },\n    {\n      \"kind\": \"category\",\n      \"category\": \"unspecified-low\",\n      \"prompt\": \"You handle logic-preserving refactors that need reasoning (extract function, restructure conditional, pattern transformation, cross-file API change). Read the task description's plan step carefully. Use the ast-grep skill helper or sg CLI to preview structural rewrites first, review the preview, then execute. If the step is ambiguous or would require out-of-scope changes, STOP and send team_send_message(teamRunId=<id>, to=\"lead\", summary=\"UNCLEAR\", body=<reason>) + team_task_update(status=pending). Same reporting contract as peer quick workers. Never run tests.\"\n    },\n    { \"kind\": \"category\", \"category\": \"unspecified-low\", \"prompt\": \"Same contract as peer unspecified-low worker.\" }\n  ]\n}\n```\n\nRationale for this composition:\n- **4 workers = team mode's parallel cap.** 5+ just queues.\n- **No verifier team member.** Verification needs `deep-high` reasoning (or `unspecified-high` fallback). In-team category routing downcasts to sisyphus-junior, which is weaker than required \u2014 the verifier runs OUTSIDE the team as a `task(category=\"deep-high\")`.\n- **quick \u00D7 2** for mechanical edits, **unspecified-low \u00D7 2** for reasoning edits \u2014 mirrors the plan's split.\n\n**Team lifecycle** (one team, reused until Phase 6 cleanup):\n\n1. `team_create(teamName=\"refactor-squad\")`. Record `teamRunId`.\n2. Broadcast the refactor Intent Card ONCE (keep task descriptions slim):\n   ```\n   team_send_message(\n     teamRunId=<id>, to=\"*\", kind=\"announcement\",\n     summary=\"refactor-intent\",\n     body=<codemap summary + constraints + established patterns from Phase 2>\n   )\n   ```\n3. Broadcast the verification spec ONCE:\n   ```\n   team_send_message(\n     teamRunId=<id>, to=\"*\", kind=\"announcement\",\n     summary=\"verify-spec\",\n     body=<exact test/typecheck/lint commands + expected pass counts + regression indicators from Phase 3.4>\n   )\n   ```\n4. For each plan step, `team_task_create(teamRunId=<id>, subject=\"refactor step <N>: <short>\", description=<per-step instructions from plan, including target files and line ranges, rollback strategy>, blockedBy=<from plan's per_step_assignment>)`.\n\n**Lead monitoring loop**:\n\nWhile any team task is `pending | claimed | in_progress`:\n\n- Wait for `<system-reminder>` or member messages. Avoid tight polling; a single `team_status` check is acceptable if no notification arrives within roughly 10 seconds of expected completion.\n- On a worker completion report, immediately dispatch an **external verifier** \u2014 verification runs OUTSIDE the team because team-member category routing downcasts to sisyphus-junior:\n  ```\n  task(\n    category=\"deep-high\",\n    load_skills=[],\n    run_in_background=true,\n    description=\"verify step <N>\",\n    prompt=<files touched + verify-spec commands + instruction to return \"PASS\" or \"FAIL:<failing test + specific error + suggested revert hunks>\">\n  )\n  ```\n  If `deep-high` is unavailable, fall back to `category=\"unspecified-high\"`. Do not create a commit checkpoint until the verifier returns PASS.\n- On a verifier PASS: make the commit checkpoint for that step (see original 5.3). Proceed.\n- On a verifier FAIL: Lead decides:\n  - **Retry with fix hint**: `team_task_update(status=pending)` on the original step + `team_send_message(teamRunId=<id>, to=<original member>, summary=\"retry\", body=<specific failure from verifier>)`. Runtime reassigns.\n  - **Escalate**: after three FAIL cycles on the same step, STOP and consult the user with full evidence.\n- On a member UNCLEAR message: re-harvest context via a targeted `task()` outside the team, broadcast an updated Intent Card fragment, then reassign.\n\nProceed to Phase 6 only when every team task is `completed` AND every paired verifier task returned PASS.\n\n## Phase 6 override: Team cleanup before summary\n\nIf Phase 5 used the team path, dismantle `refactor-squad` BEFORE producing the 6.6 summary. Every exit path \u2014 success, escalation, abort \u2014 must cleanup; orphan teams poison the next session's precondition check.\n\n1. `team_shutdown_request` for each member, then `team_approve_shutdown` if members do not self-approve within a reasonable window.\n2. `team_delete(teamRunId=<id>)`.\n3. `team_list` to confirm no residual `refactor-squad` run.\n\nThe `~/.omo/teams/refactor-squad/config.json` declaration stays on disk; next session reuses it.\n\nAppend to the 6.6 summary a \"Dispatch path\" line and, when team path was used, team metrics (teamRunId, tasks created, verifier runs, team lifetime).\n\n## MUST NOT (team mode)\n\n- Lead never edits files directly \u2014 orchestrate only.\n- Do not inline the Intent Card or verify-spec into task descriptions \u2014 rely on the broadcasts.\n- Do not recreate the team mid-session.\n- Do not run tests from Lead \u2014 the external verifier owns that lane.\n- Do not put `oracle` / `librarian` / a deep lane into the team spec \u2014 oracle/librarian are team-ineligible, and a deep lane under category routing downcasts to sisyphus-junior. Use them via `task()` outside the team when needed.\n";

package/dist/features/builtin-commands/templates/remove-ai-slops.d.ts

@@ -1,2 +1,2 @@
 export declare const REMOVE_AI_SLOPS_TEMPLATE = "# Remove AI Slops Command\n\n## Codex Harness Tool Compatibility\n\nThis command includes examples for the OpenCode harness. In Codex, do not call OpenCode-only tools such as `call_omo_agent(...)`, `task(...)`, `background_output(...)`, or `team_*(...)` literally. Translate those examples to Codex native tools:\n\n| OpenCode example | Codex tool to use |\n| --- | --- |\n| `call_omo_agent(subagent_type=\"explore\", ...)` | `multi_agent_v1.spawn_agent({\"message\":\"TASK: act as an explorer. ...\",\"agent_type\":\"explorer\",\"fork_context\":false})` |\n| `call_omo_agent(subagent_type=\"librarian\", ...)` | `multi_agent_v1.spawn_agent({\"message\":\"TASK: act as a librarian. ...\",\"agent_type\":\"librarian\",\"fork_context\":false})` |\n| `task(subagent_type=\"plan\", ...)` | `multi_agent_v1.spawn_agent({\"message\":\"TASK: act as a planning agent. ...\",\"agent_type\":\"plan\",\"fork_context\":false})` |\n| `task(subagent_type=\"oracle\", ...)` | `multi_agent_v1.spawn_agent({\"message\":\"TASK: act as a rigorous reviewer. ...\",\"agent_type\":\"lazycodex-gate-reviewer\",\"fork_context\":false})` |\n| `task(category=\"...\", ...)` | `multi_agent_v1.spawn_agent({\"message\":\"TASK: act as an implementation or QA worker. ...\",\"fork_context\":false})` |\n| `background_output(task_id=\"...\")` | `multi_agent_v1.wait_agent(...)` for mailbox signals |\n| `team_*(...)` | Use Codex native subagents via `multi_agent_v1.spawn_agent` and `multi_agent_v1.wait_agent`; use `multi_agent_v1.send_input` and `multi_agent_v1.close_agent` only when exposed in the active tools list |\n\nCodex exposes ONE of two subagent tool surfaces per session; check your own tool list and route accordingly. If `multi_agent_v1.*` tools exist, use the table above as written. If instead a flat `spawn_agent` with a required `task_name` exists (`multi_agent_v2`), rewrite every `multi_agent_v1.*` example: `multi_agent_v1.spawn_agent({...,\"fork_context\":false})` becomes `spawn_agent({\"task_name\":\"<lowercase_digits_underscores>\",\"message\":...,\"agent_type\":...,\"fork_turns\":\"none\"})` (`\"all\"` only when full parent history is truly required); `send_input` becomes `send_message`; do not call `close_agent`/`resume_agent` (finished agents end on their own; `followup_task` re-tasks one, `interrupt_agent` stops one); `wait_agent` takes only `timeout_ms` and returns on any child mailbox activity. `agent_type` works the same on both surfaces. If a code block below conflicts with this section, this section wins.\n\nWhen translating `load_skills=[...]`, include the requested skill names in the spawned agent's `message`. If a code block below conflicts with this section, this section wins.\n\n## What this command does\nAnalyzes all files changed in the current branch (compared to parent commit), removes AI-generated code smells in parallel, then critically reviews the changes to ensure safety and behavior preservation. Fixes any issues found during review.\n\n## Step 0: Task Planning\n\nUse TodoWrite to create the task list:\n1. Get changed files from branch\n2. Run $omo:remove-ai-slops on each file in parallel\n3. Critically review all changes\n4. Fix any issues found\n\n## Role Definition\nYou are a senior code quality engineer specialized in identifying and removing AI-generated code patterns while preserving original functionality. You have deep expertise in code review, refactoring safety, and behavioral preservation.\n\n## Process\n\n### Phase 1: Identify Changed Files\nDetect the repository base branch dynamically, then get all changed files in the current branch:\n```bash\nBASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo \"main\")\ngit diff $(git merge-base \"$BASE_BRANCH\" HEAD)..HEAD --name-only\n```\n\nIf `git symbolic-ref refs/remotes/origin/HEAD` is unavailable, detect the base branch at runtime using the repo's configured remote default branch. Only fall back to `main` as a last resort.\n\n### Phase 2: Parallel AI Slop Removal\nFor each changed file, spawn an agent in parallel using the Task tool with the $omo:remove-ai-slops skill:\n\n```\ntask(category=\"quick\", load_skills=[\"remove-ai-slops\"], run_in_background=true, description=\"Remove AI slops from {filename}\", prompt=\"Remove AI slops from: {file_path}\")\n```\n\n**CRITICAL**: Launch ALL agents in a SINGLE message with multiple Task tool calls for maximum parallelism.\n\nBefore running $omo:remove-ai-slops on each file, save a file-specific rollback artifact that captures only the delta introduced by the slop-removal pass. Use a safe pattern such as generating a per-file patch and reverse-applying it if review fails.\n\nDo NOT use `git checkout -- {file_path}` or any rollback that discards pre-existing branch changes in the file.\n\n### Phase 3: Critical Review\nAfter all $omo:remove-ai-slops agents complete, perform a critical review with the following checklist:\n\n**Safety Verification**:\n- [ ] No functional logic was accidentally removed\n- [ ] All error handling is preserved\n- [ ] Type hints remain correct and complete\n- [ ] Import statements are still valid\n- [ ] No breaking changes to public APIs\n\n**Behavior Preservation**:\n- [ ] Return values unchanged\n- [ ] Side effects unchanged\n- [ ] Exception behavior unchanged\n- [ ] Edge case handling preserved\n\n**Code Quality**:\n- [ ] Removed changes are genuinely AI slop (not intentional patterns)\n- [ ] Remaining code follows project conventions\n- [ ] No orphaned code or dead references\n\n### Phase 4: Fix Issues\nIf any issues are found during critical review:\n1. Identify the specific problem\n2. Explain why it's a problem\n3. Revert only the $omo:remove-ai-slops delta using the saved per-file patch or an equivalent reverse-apply workflow\n4. If remaining ai-slops are found after reverting, remove them by editing the file yourself - with parallel tool calls, per-file\n5. Verify the fix doesn't introduce new issues\n\n## Output Format\n\n### Summary Report\n```\n## AI Slop Removal Summary\n\n### Files Processed\n- file1.py: X changes\n- file2.py: Y changes\n\n### Critical Review Results\n- Safety: PASS/FAIL\n- Behavior: PASS/FAIL\n- Quality: PASS/FAIL\n\n### Issues Found & Fixed\n1. [Issue description] -> [Fix applied]\n\n### Final Status\n[CLEAN / ISSUES FIXED / REQUIRES ATTENTION]\n```\n\n## Quality Assurance\n- NEVER remove code that serves a functional purpose\n- ALWAYS verify changes compile/parse correctly\n- ALWAYS preserve test coverage\n- If uncertain about a change, err on the side of keeping the original code";
-export declare const REMOVE_AI_SLOPS_TEAM_MODE_ADDENDUM = "\n---\n\n# Team Mode Protocol (active when team_* tools are present)\n\nTeam mode is enabled for this session. The rules below **override Phase 2-4** of the legacy flow above. Follow this protocol instead of the per-file fire-and-forget `task()` dispatch.\n\n## Phase 2 (team): `slop-squad` setup\n\n**Precondition checks** (fail hard if any step fails):\n\n1. Load the `team-mode` skill via the `skill` tool for lifecycle, message protocol, broadcast rules, 32KB message cap, and 4 parallel worker cap.\n2. Call `team_list` and verify no active run named `slop-squad` exists. If one does, it is an orphan from a crashed prior session \u2014 `team_shutdown_request` + `team_approve_shutdown` + `team_delete` it before proceeding. Do not rename the team or run concurrent sessions under the same name.\n3. If `~/.omo/teams/slop-squad/config.json` is missing, write it using the spec below.\n\n**Team spec** (`~/.omo/teams/slop-squad/config.json`):\n\n```json\n{\n  \"name\": \"slop-squad\",\n  \"lead\": { \"kind\": \"subagent_type\", \"subagent_type\": \"sisyphus\" },\n  \"members\": [\n    {\n      \"kind\": \"category\",\n      \"category\": \"quick\",\n      \"prompt\": \"You run $omo:remove-ai-slops on ONE file per task. Load $omo:remove-ai-slops via the skill tool. Read the task description for the file path. Apply the skill's detection criteria verbatim. After edits: run lsp_diagnostics on the file. Report via team_send_message(teamRunId=<id>, to=\"lead\", summary=<change count>, body=<full $omo:remove-ai-slops report>) + team_task_update(status=completed). On ambiguity: send team_send_message(teamRunId=<id>, to=\"lead\", summary=\"UNCLEAR\", body=<reason>) + team_task_update(status=pending). Never git add, never run tests, never touch other files.\"\n    },\n    { \"kind\": \"category\", \"category\": \"quick\", \"prompt\": \"Same contract as peer quick worker.\" },\n    { \"kind\": \"category\", \"category\": \"quick\", \"prompt\": \"Same contract as peer quick worker.\" },\n    {\n      \"kind\": \"category\",\n      \"category\": \"unspecified-low\",\n      \"prompt\": \"You are the FIX worker. You claim rework tasks that the lead creates after the external reviewer flags issues. Read the reviewer's per-hunk rollback instructions in the task description, apply the reverse patch, then run $omo:remove-ai-slops ONLY on the non-rolled-back remainder. Same reporting contract as quick peers. Handle UNCLEAR escalations the same way.\"\n    }\n  ]\n}\n```\n\nRationale for this composition:\n- **4 workers = team mode's parallel cap.** A fifth member just queues.\n- **Reviewer is NOT a team member** \u2014 review demands stronger reasoning than category routing provides (team category members are downcast to sisyphus-junior). The reviewer runs OUTSIDE the team as a `deep` task; see Phase 3.\n- **quick \u00D7 3** absorbs the mass of per-file slop removal. **unspecified-low \u00D7 1** is the rework lane for fixes triggered by reviewer findings.\n\n**Team lifecycle** (create once, reuse until Phase 5 cleanup):\n\n1. `team_create(teamName=\"slop-squad\")`. Record `teamRunId` \u2014 every subsequent team call needs it.\n2. Broadcast the detection criteria ONCE so each task description stays minimal:\n   ```\n   team_send_message(\n     teamRunId=<id>, to=\"*\", kind=\"announcement\",\n     summary=\"slop-criteria\",\n     body=<the 9 slop categories + KEEP rules; reference the $omo:remove-ai-slops skill content>\n   )\n   ```\n3. Before spawning tasks, save a per-file rollback artifact that captures only the delta the slop-removal pass will introduce. Do NOT use `git checkout -- <file>` \u2014 that would discard pre-existing branch changes.\n4. For each changed file, `team_task_create(teamRunId=<id>, subject=\"slop: <file>\", description=<file path + rollback artifact path + reporting format>, blockedBy=[])`.\n\n## Phase 3 (team): Incremental reviewer dispatch\n\nWhile any team task is `pending | claimed | in_progress`:\n\n- Wait for `<system-reminder>` or member messages. Do NOT tight-poll `team_status`; the runtime notifies on state changes. A single `team_status` check is acceptable if no notification arrives within roughly 10 seconds of expected completion.\n- On each worker completion report:\n  - Log the report to the pending final summary (no blocking).\n  - Immediately dispatch an **external reviewer** \u2014 review runs OUTSIDE the team because team-member category routing downcasts to sisyphus-junior:\n    ```\n    task(\n      category=\"deep\",\n      load_skills=[],\n      run_in_background=true,\n      description=\"slop review: <file>\",\n      prompt=<file path + full worker report + Safety/Behavior/Quality checklist + instruction to output \"PASS\" or \"FAIL:<per-hunk rollback instructions>\">\n    )\n    ```\n    If `deep` is unavailable in this session, fall back to `category=\"unspecified-high\"`.\n- On a reviewer task returning FAIL:\n  - Create a rework team task: `team_task_create(subject=\"rework: <file>\", description=<reverse-patch hunks from reviewer + \"then run $omo:remove-ai-slops on remaining non-rolled-back issues only\">)`. The `unspecified-low` fix member claims it.\n  - Create a new reviewer task paired to the rework completion (same incremental pattern).\n- Loop until every file has a PASS from the reviewer AND no team task is outstanding.\n\n## Phase 4 (team): Fix issues\n\nFixes happen incrementally during Phase 3's loop via rework tasks \u2014 this phase is already handled when the loop exits. Any remaining manual fix that neither worker nor fix member could resolve is handled by Lead here, editing files directly.\n\n## Phase 5 (team): Team cleanup\n\nBefore producing the summary report, dismantle the team on EVERY exit path \u2014 success, escalation, abort \u2014 otherwise the next session's Phase 2 precondition check catches the orphan.\n\n1. `team_shutdown_request` for each member, then `team_approve_shutdown` if members do not self-approve within a reasonable window.\n2. `team_delete(teamRunId=<id>)`.\n3. `team_list` to confirm no residual `slop-squad` run.\n\nThe `~/.omo/teams/slop-squad/config.json` declaration file stays on disk; it is reused next session.\n\n## MUST NOT (team mode)\n\n- Lead never edits files directly \u2014 orchestrate only. If editing is needed, it goes into a team task.\n- Do not inline the full slop-criteria into every task description; rely on the Phase 2 broadcast.\n- Do not call `team_create` again mid-session. One team per resolution.\n- Do not put `oracle` / `librarian` into the team spec \u2014 they are team-ineligible; call them via `task()` outside the team when needed.\n";
+export declare const REMOVE_AI_SLOPS_TEAM_MODE_ADDENDUM = "\n---\n\n# Team Mode Protocol (active when team_* tools are present)\n\nTeam mode is enabled for this session. The rules below **override Phase 2-4** of the legacy flow above. Follow this protocol instead of the per-file fire-and-forget `task()` dispatch.\n\n## Phase 2 (team): `slop-squad` setup\n\n**Precondition checks** (fail hard if any step fails):\n\n1. Load the `team-mode` skill via the `skill` tool for lifecycle, message protocol, broadcast rules, 32KB message cap, and 4 parallel worker cap.\n2. Call `team_list` and verify no active run named `slop-squad` exists. If one does, it is an orphan from a crashed prior session \u2014 `team_shutdown_request` + `team_approve_shutdown` + `team_delete` it before proceeding. Do not rename the team or run concurrent sessions under the same name.\n3. If `~/.omo/teams/slop-squad/config.json` is missing, write it using the spec below.\n\n**Team spec** (`~/.omo/teams/slop-squad/config.json`):\n\n```json\n{\n  \"name\": \"slop-squad\",\n  \"lead\": { \"kind\": \"subagent_type\", \"subagent_type\": \"sisyphus\" },\n  \"members\": [\n    {\n      \"kind\": \"category\",\n      \"category\": \"quick\",\n      \"prompt\": \"You run $omo:remove-ai-slops on ONE file per task. Load $omo:remove-ai-slops via the skill tool. Read the task description for the file path. Apply the skill's detection criteria verbatim. After edits: run lsp_diagnostics on the file. Report via team_send_message(teamRunId=<id>, to=\"lead\", summary=<change count>, body=<full $omo:remove-ai-slops report>) + team_task_update(status=completed). On ambiguity: send team_send_message(teamRunId=<id>, to=\"lead\", summary=\"UNCLEAR\", body=<reason>) + team_task_update(status=pending). Never git add, never run tests, never touch other files.\"\n    },\n    { \"kind\": \"category\", \"category\": \"quick\", \"prompt\": \"Same contract as peer quick worker.\" },\n    { \"kind\": \"category\", \"category\": \"quick\", \"prompt\": \"Same contract as peer quick worker.\" },\n    {\n      \"kind\": \"category\",\n      \"category\": \"unspecified-low\",\n      \"prompt\": \"You are the FIX worker. You claim rework tasks that the lead creates after the external reviewer flags issues. Read the reviewer's per-hunk rollback instructions in the task description, apply the reverse patch, then run $omo:remove-ai-slops ONLY on the non-rolled-back remainder. Same reporting contract as quick peers. Handle UNCLEAR escalations the same way.\"\n    }\n  ]\n}\n```\n\nRationale for this composition:\n- **4 workers = team mode's parallel cap.** A fifth member just queues.\n- **Reviewer is NOT a team member** \u2014 review demands stronger reasoning than category routing provides (team category members are downcast to sisyphus-junior). The reviewer runs OUTSIDE the team as a `deep-high` task; see Phase 3.\n- **quick \u00D7 3** absorbs the mass of per-file slop removal. **unspecified-low \u00D7 1** is the rework lane for fixes triggered by reviewer findings.\n\n**Team lifecycle** (create once, reuse until Phase 5 cleanup):\n\n1. `team_create(teamName=\"slop-squad\")`. Record `teamRunId` \u2014 every subsequent team call needs it.\n2. Broadcast the detection criteria ONCE so each task description stays minimal:\n   ```\n   team_send_message(\n     teamRunId=<id>, to=\"*\", kind=\"announcement\",\n     summary=\"slop-criteria\",\n     body=<the 9 slop categories + KEEP rules; reference the $omo:remove-ai-slops skill content>\n   )\n   ```\n3. Before spawning tasks, save a per-file rollback artifact that captures only the delta the slop-removal pass will introduce. Do NOT use `git checkout -- <file>` \u2014 that would discard pre-existing branch changes.\n4. For each changed file, `team_task_create(teamRunId=<id>, subject=\"slop: <file>\", description=<file path + rollback artifact path + reporting format>, blockedBy=[])`.\n\n## Phase 3 (team): Incremental reviewer dispatch\n\nWhile any team task is `pending | claimed | in_progress`:\n\n- Wait for `<system-reminder>` or member messages. Do NOT tight-poll `team_status`; the runtime notifies on state changes. A single `team_status` check is acceptable if no notification arrives within roughly 10 seconds of expected completion.\n- On each worker completion report:\n  - Log the report to the pending final summary (no blocking).\n  - Immediately dispatch an **external reviewer** \u2014 review runs OUTSIDE the team because team-member category routing downcasts to sisyphus-junior:\n    ```\n    task(\n      category=\"deep-high\",\n      load_skills=[],\n      run_in_background=true,\n      description=\"slop review: <file>\",\n      prompt=<file path + full worker report + Safety/Behavior/Quality checklist + instruction to output \"PASS\" or \"FAIL:<per-hunk rollback instructions>\">\n    )\n    ```\n    If `deep-high` is unavailable in this session, fall back to `category=\"unspecified-high\"`.\n- On a reviewer task returning FAIL:\n  - Create a rework team task: `team_task_create(subject=\"rework: <file>\", description=<reverse-patch hunks from reviewer + \"then run $omo:remove-ai-slops on remaining non-rolled-back issues only\">)`. The `unspecified-low` fix member claims it.\n  - Create a new reviewer task paired to the rework completion (same incremental pattern).\n- Loop until every file has a PASS from the reviewer AND no team task is outstanding.\n\n## Phase 4 (team): Fix issues\n\nFixes happen incrementally during Phase 3's loop via rework tasks \u2014 this phase is already handled when the loop exits. Any remaining manual fix that neither worker nor fix member could resolve is handled by Lead here, editing files directly.\n\n## Phase 5 (team): Team cleanup\n\nBefore producing the summary report, dismantle the team on EVERY exit path \u2014 success, escalation, abort \u2014 otherwise the next session's Phase 2 precondition check catches the orphan.\n\n1. `team_shutdown_request` for each member, then `team_approve_shutdown` if members do not self-approve within a reasonable window.\n2. `team_delete(teamRunId=<id>)`.\n3. `team_list` to confirm no residual `slop-squad` run.\n\nThe `~/.omo/teams/slop-squad/config.json` declaration file stays on disk; it is reused next session.\n\n## MUST NOT (team mode)\n\n- Lead never edits files directly \u2014 orchestrate only. If editing is needed, it goes into a team task.\n- Do not inline the full slop-criteria into every task description; rely on the Phase 2 broadcast.\n- Do not call `team_create` again mid-session. One team per resolution.\n- Do not put `oracle` / `librarian` into the team spec \u2014 they are team-ineligible; call them via `task()` outside the team when needed.\n";