oh-my-opencode 4.9.2 → 4.11.0

package/dist/config/validate.d.ts

@@ -0,0 +1,8 @@
+import { type OhMyOpenCodeConfig } from "./schema";
+export type PluginConfigValidation = {
+    readonly valid: boolean;
+    readonly messages: readonly string[];
+    readonly path: string | null;
+    readonly config: OhMyOpenCodeConfig;
+};
+export declare function validatePluginConfig(directory: string): PluginConfigValidation;

package/dist/create-hooks.d.ts

@@ -2,6 +2,7 @@ import type { AvailableSkill } from "./agents/dynamic-agent-prompt-builder";
 import type { HookName, OhMyOpenCodeConfig } from "./config";
 import type { LoadedSkill } from "./features/opencode-skill-loader/types";
 import type { BackgroundManager } from "./features/background-agent";
+import type { MonitorManager } from "./features/monitor";
 import type { ModelFallbackControllerAccessor } from "./hooks/model-fallback";
 import type { PluginContext } from "./plugin/types";
 import type { ModelCacheState } from "./plugin-state";
@@ -24,6 +25,7 @@ export declare function createHooks(args: {
     modelCacheState: ModelCacheState;
     backgroundManager: BackgroundManager;
     modelFallbackControllerAccessor?: ModelFallbackControllerAccessor;
+    monitorManager?: MonitorManager;
     isHookEnabled: (hookName: HookName) => boolean;
     safeHookEnabled: boolean;
     mergedSkills: LoadedSkill[];
@@ -45,6 +47,7 @@ export declare function createHooks(args: {
     teamModeStatusInjector: ReturnType<typeof import("./hooks").createTeamModeStatusInjector> | null;
     teamMailboxInjector: ReturnType<typeof import("./hooks").createTeamMailboxInjector> | null;
     toolPairValidator: ReturnType<typeof import("./hooks").createToolPairValidatorHook> | null;
+    monitorStatusInjector: ReturnType<typeof import("./hooks").createMonitorStatusInjectorHook> | null;
     commentChecker: ReturnType<typeof import("./hooks").createCommentCheckerHooks> | null;
     toolOutputTruncator: ReturnType<typeof import("./hooks").createToolOutputTruncatorHook> | null;
     directoryAgentsInjector: ReturnType<typeof import("./hooks").createDirectoryAgentsInjectorHook> | null;
@@ -64,12 +67,13 @@ export declare function createHooks(args: {
     notepadWriteGuard: ReturnType<typeof import("./hooks").createNotepadWriteGuardHook> | null;
     planFormatValidator: ReturnType<typeof import("./hooks").createPlanFormatValidatorHook> | null;
     preemptiveCompaction: ReturnType<typeof import("./hooks").createPreemptiveCompactionHook> | null;
-    sessionRecovery: ReturnType<typeof import("./hooks").createSessionRecoveryHook> | null;
     sessionNotification: ReturnType<typeof import("./hooks").createSessionNotification> | null;
     thinkMode: ReturnType<typeof import("./hooks").createThinkModeHook> | null;
     modelFallback: ReturnType<typeof import("./hooks").createModelFallbackHook> | null;
     anthropicContextWindowLimitRecovery: ReturnType<typeof import("./hooks").createAnthropicContextWindowLimitRecoveryHook> | null;
     autoUpdateChecker: ReturnType<typeof import("./hooks").createAutoUpdateCheckerHook> | null;
+    codegraphBootstrap: ReturnType<typeof import("./hooks").createCodegraphBootstrapHook> | null;
+    astGrepSgProvision: ReturnType<typeof import("./hooks").createAstGrepSgProvisionHook> | null;
     agentUsageReminder: ReturnType<typeof import("./hooks").createAgentUsageReminderHook> | null;
     nonInteractiveEnv: ReturnType<typeof import("./hooks").createNonInteractiveEnvHook> | null;
     interactiveBashSession: ReturnType<typeof import("./hooks").createInteractiveBashSessionHook> | null;

package/dist/create-managers.d.ts

@@ -2,8 +2,11 @@ import type { OhMyOpenCodeConfig } from "./config";
 import type { ModelCacheState } from "./plugin-state";
 import type { PluginContext, TmuxConfig } from "./plugin/types";
 import { BackgroundManager } from "./features/background-agent";
+import type { MonitorManager } from "./features/monitor";
+import { createMonitorManager } from "./features/monitor";
 import { SkillMcpManager } from "./features/skill-mcp-manager";
 import { cleanupSessionTeamRuns } from "./features/team-mode/team-runtime/session-cleanup";
+import { TuiStateMirror } from "./features/tui-sidebar/mirror-manager";
 import { initTaskToastManager } from "./features/task-toast-manager";
 import { TmuxSessionManager } from "./features/tmux-subagent";
 import { registerManagerForCleanup } from "./features/background-agent/process-cleanup";
@@ -14,6 +17,8 @@ type CreateManagersDeps = {
     BackgroundManagerClass: typeof BackgroundManager;
     SkillMcpManagerClass: typeof SkillMcpManager;
     TmuxSessionManagerClass: typeof TmuxSessionManager;
+    TuiStateMirrorClass: typeof TuiStateMirror;
+    createMonitorManagerFn: typeof createMonitorManager;
     initTaskToastManagerFn: typeof initTaskToastManager;
     registerManagerForCleanupFn: typeof registerManagerForCleanup;
     cleanupSessionTeamRunsFn: typeof cleanupSessionTeamRuns;
@@ -26,6 +31,8 @@ export type Managers = {
     skillMcpManager: SkillMcpManager;
     configHandler: ReturnType<typeof createConfigHandler>;
     modelFallbackControllerAccessor: ModelFallbackControllerAccessor;
+    tuiStateMirror?: TuiStateMirror;
+    monitorManager?: MonitorManager;
 };
 export declare function createManagers(args: {
     ctx: PluginContext;

package/dist/create-runtime-tmux-config.d.ts

@@ -1,10 +1,10 @@
 import type { OhMyOpenCodeConfig, TmuxConfig } from "./config";
+export { isInteractiveBashEnabled } from "./interactive-bash-availability";
 export declare function isTmuxIntegrationEnabled(pluginConfig: {
     tmux?: {
         enabled?: boolean;
     } | undefined;
 }): boolean;
-export declare function isInteractiveBashEnabled(which?: (binary: string) => string | null): boolean;
 export declare function createRuntimeTmuxConfig(pluginConfig: {
     tmux?: OhMyOpenCodeConfig["tmux"];
 }): TmuxConfig;

package/dist/create-tools.d.ts

@@ -16,6 +16,6 @@ type CreateToolsResult = {
 export declare function createTools(args: {
     ctx: PluginContext;
     pluginConfig: OhMyOpenCodeConfig;
-    managers: Pick<Managers, "backgroundManager" | "tmuxSessionManager" | "skillMcpManager" | "modelFallbackControllerAccessor">;
+    managers: Pick<Managers, "backgroundManager" | "tmuxSessionManager" | "skillMcpManager" | "modelFallbackControllerAccessor" | "monitorManager">;
 }): Promise<CreateToolsResult>;
 export {};

package/dist/features/background-agent/error-classifier.d.ts

@@ -1,4 +1,5 @@
-export declare function isRecord(value: unknown): value is Record<string, unknown>;
+import { isRecord } from "@oh-my-opencode/utils";
+export { isRecord };
 export declare function isAbortedSessionError(error: unknown): boolean;
 export declare function getErrorText(error: unknown): string;
 export declare function extractErrorName(error: unknown): string | undefined;
@@ -8,4 +9,3 @@ interface EventPropertiesLike {
     [key: string]: unknown;
 }
 export declare function getSessionErrorMessage(properties: EventPropertiesLike): string | undefined;
-export {};

package/dist/features/background-agent/index.d.ts

@@ -1,4 +1,4 @@
 export * from "./types";
-export { BackgroundManager, type SubagentSessionCreatedEvent, type OnSubagentSessionCreated } from "./manager";
+export { BackgroundManager, type SubagentSessionCreatedEvent, type OnSubagentSessionCreated, type SubagentSessionDeletedEvent, type OnSubagentSessionDeleted } from "./manager";
 export { waitForTaskSessionID } from "./wait-for-task-session";
 export type { WaitForTaskSessionIDOptions } from "./wait-for-task-session";

package/dist/features/background-agent/manager.d.ts

@@ -4,7 +4,7 @@ import type { ModelFallbackControllerAccessor } from "../../hooks/model-fallback
 import { log } from "../../shared";
 import { type SubagentSpawnContext } from "./subagent-spawn-limits";
 import { TaskHistory } from "./task-history";
-import type { BackgroundTask, LaunchInput, ResumeInput } from "./types";
+import type { BackgroundTask, BackgroundTaskSnapshot, LaunchInput, ResumeInput } from "./types";
 interface EventProperties {
     sessionID?: string;
     info?: {
@@ -26,11 +26,16 @@ export interface SubagentSessionCreatedEvent {
     title: string;
 }
 export type OnSubagentSessionCreated = (event: SubagentSessionCreatedEvent) => Promise<void>;
+export interface SubagentSessionDeletedEvent {
+    sessionID: string;
+}
+export type OnSubagentSessionDeleted = (event: SubagentSessionDeletedEvent) => Promise<void>;
 export interface BackgroundManagerConfig {
     pluginContext: PluginInput;
     config?: BackgroundTaskConfig;
     tmuxConfig?: TmuxConfig;
     onSubagentSessionCreated?: OnSubagentSessionCreated;
+    onSubagentSessionDeleted?: OnSubagentSessionDeleted;
     onShutdown?: () => void | Promise<void>;
     enableParentSessionNotifications?: boolean;
     modelFallbackControllerAccessor?: ModelFallbackControllerAccessor;
@@ -51,6 +56,7 @@ export declare class BackgroundManager {
     private config?;
     private tmuxEnabled;
     private onSubagentSessionCreated?;
+    private onSubagentSessionDeleted?;
     private onShutdown?;
     private queuesByKey;
     private processingKeys;
@@ -96,9 +102,36 @@ export declare class BackgroundManager {
     private processKey;
     private startTask;
     getTask(id: string): BackgroundTask | undefined;
+    getTasksSnapshot(): BackgroundTaskSnapshot[];
     getTasksByParentSession(sessionID: string): BackgroundTask[];
-    /** Return whether a session has direct child background tasks still in flight. */
+    /**
+     * Return whether a session has direct child background tasks still in flight.
+     *
+     * Intentionally checks immediate children only, not all descendants. A
+     * grandchild's completion wake is addressed to its immediate parent session,
+     * never to this ancestor, so blocking on descendants would make the sync poll
+     * loop wait for grandchildren it can never be woken for (returning a stale
+     * pre-grandchild turn after the settle window, or hitting the sync timeout for
+     * long-running descendants). When a deliverable genuinely depends on a
+     * grandchild, the direct child stays running until that grandchild resolves, so
+     * the immediate-child check already covers it; when the child fire-and-forgets
+     * a grandchild, this session correctly does not wait for work it cannot consume.
+     */
     hasActiveChildTasks(sessionID: string): boolean;
+    /**
+     * Return whether a parent-wake notification for this session is queued, scheduled,
+     * mid-dispatch, or dispatched-but-not-yet-consumed. Lets a sync poll loop keep
+     * waiting across the gap between "all children finished" and "the
+     * notification-triggered turn started", instead of declaring the task complete
+     * during that window. The in-flight check is essential: while a wake is being
+     * dispatched the pending entry is already deleted and the dispatched entry is not
+     * yet tracked, so the other three maps would all report false for several seconds.
+     * The notification-preparation check covers the earlier window: a child is marked
+     * terminal (so it no longer counts as active) before the completion path finishes
+     * awaiting its session teardown and queues the wake, so without it the predicate
+     * would report false between the status flip and the wake landing in the pending map.
+     */
+    hasPendingParentWake(sessionID: string): boolean;
     private updateBackgroundTaskMarker;
     getAllDescendantTasks(sessionID: string): BackgroundTask[];
     findBySession(sessionID: string): BackgroundTask | undefined;

package/dist/features/background-agent/parent-wake-dispatched-tracker.d.ts

@@ -7,9 +7,17 @@ export declare class ParentWakeDispatchedTracker {
     private readonly options;
     private dispatchedParentWakes;
     private dispatchedParentWakeTimers;
+    private inFlightDispatches;
+    private notificationPreparations;
     constructor(options: ParentWakeDispatchedTrackerOptions);
     getWakes(): Map<string, PendingParentWake>;
     getTimers(): Map<string, ReturnType<typeof setTimeout>>;
+    markInFlight(sessionID: string): void;
+    clearInFlight(sessionID: string): void;
+    hasInFlight(sessionID: string): boolean;
+    reserveNotificationPreparation(sessionID: string): void;
+    releaseNotificationPreparation(sessionID: string): void;
+    hasNotificationPreparation(sessionID: string): boolean;
     getWake(sessionID: string): PendingParentWake | undefined;
     hasWake(sessionID: string): boolean;
     clearWake(sessionID: string): void;

package/dist/features/background-agent/parent-wake-notifier.d.ts

@@ -11,6 +11,10 @@ export declare class ParentWakeNotifier {
     getPendingParentWakeTimers(): Map<string, ReturnType<typeof setTimeout>>;
     getDispatchedParentWakes(): Map<string, PendingParentWake>;
     getDispatchedParentWakeTimers(): Map<string, ReturnType<typeof setTimeout>>;
+    hasInFlightParentWakeDispatch(sessionID: string): boolean;
+    reserveNotificationPreparation(sessionID: string): void;
+    releaseNotificationPreparation(sessionID: string): void;
+    hasNotificationPreparation(sessionID: string): boolean;
     recordParentSessionActivity(sessionID: string): void;
     queuePendingParentWake(sessionID: string, notification: string, promptContext: ParentWakePromptContext, shouldReply: boolean, delayMs?: number): void;
     flushPendingParentWake(sessionID: string): Promise<void>;

package/dist/features/background-agent/spawner/fallback-agent.d.ts

@@ -1,5 +1,6 @@
+import type { TaskPromptBody } from "./task-prompt-body";
 export declare const FALLBACK_AGENT = "general";
 export declare function isAgentNotFoundError(error: unknown): boolean;
-export declare function buildFallbackBody(originalBody: Record<string, unknown>, fallbackAgent: string, options?: {
+export declare function buildFallbackBody(originalBody: TaskPromptBody, fallbackAgent: string, options?: {
     includeTeamToolDenylist?: boolean;
-}): Record<string, unknown>;
+}): TaskPromptBody;

package/dist/features/background-agent/spawner/task-prompt-body.d.ts

@@ -23,12 +23,11 @@ export type TaskPromptBody = {
     readonly variant?: string;
     readonly system?: string | undefined;
     readonly tools: Record<string, boolean>;
-    readonly parts: readonly [
-        {
-            readonly type: "text";
-            readonly text: string;
-        }
-    ];
+    readonly parts: Array<{
+        readonly type: "text";
+        readonly text: string;
+        readonly synthetic?: boolean;
+    }>;
 };
 export declare function buildTaskPromptBody(options: TaskPromptBodyOptions): TaskPromptBody;
 export {};

package/dist/features/background-agent/task-snapshot.d.ts

@@ -0,0 +1,2 @@
+import type { BackgroundTask, BackgroundTaskSnapshot } from "./types";
+export declare function toBackgroundTaskSnapshots(tasks: Iterable<BackgroundTask>): BackgroundTaskSnapshot[];

package/dist/features/background-agent/types.d.ts

@@ -89,6 +89,13 @@ export interface BackgroundTask {
     /** Number of consecutive polls where session was missing from status map */
     consecutiveMissedPolls?: number;
 }
+export interface BackgroundTaskSnapshot {
+    readonly title: string;
+    readonly status: BackgroundTaskStatus;
+    readonly toolCalls: number | null;
+    readonly lastTool: string | null;
+    readonly agent: string;
+}
 export interface LaunchInput {
     description: string;
     prompt: string;
@@ -112,6 +119,8 @@ export interface LaunchInput {
     category?: string;
     sessionPermission?: SessionPermissionRule[];
     onSessionCreated?: (sessionId: string) => void | Promise<void>;
+    /** User tool overrides (ask/allow/deny) from category or agent config. Merged into launchTools before hardcoded restrictions. */
+    userPermission?: Record<string, "ask" | "allow" | "deny">;
 }
 export interface ResumeInput {
     sessionId: string;

package/dist/features/builtin-commands/templates/refactor-sections/intro-and-analysis.d.ts

@@ -1 +1 @@
-export declare const REFACTOR_INTRO_AND_ANALYSIS = "# Intelligent Refactor 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\", ...)` | `spawn_agent(agent_type=\"explorer\", task_name=\"...\", message=\"...\")` |\n| `call_omo_agent(subagent_type=\"librarian\", ...)` | `spawn_agent(agent_type=\"librarian\", task_name=\"...\", message=\"...\")` |\n| `task(subagent_type=\"plan\", ...)` | `spawn_agent(agent_type=\"plan\", task_name=\"...\", message=\"...\")` |\n| `task(subagent_type=\"oracle\", ...)` | `spawn_agent(agent_type=\"codex-ultrawork-reviewer\", task_name=\"...\", message=\"...\")` |\n| `task(category=\"...\", ...)` | `spawn_agent(agent_type=\"worker\", task_name=\"...\", message=\"...\")` |\n| `background_output(task_id=\"...\")` | `wait_agent(...)` to wait for subagent completion and mailbox updates |\n| `team_*(...)` | Use Codex native subagents plus `send_message`, `followup_task`, `wait_agent`, and `close_agent` |\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## Usage\n```\n/refactor <refactoring-target> [--scope=<file|module|project>] [--strategy=<safe|aggressive>]\n\nArguments:\n  refactoring-target: What to refactor. Can be:\n    - File path: src/auth/handler.ts\n    - Symbol name: \"AuthService class\"\n    - Pattern: \"all functions using deprecated API\"\n    - Description: \"extract validation logic into separate module\"\n\nOptions:\n  --scope: Refactoring scope (default: module)\n    - file: Single file only\n    - module: Module/directory scope\n    - project: Entire codebase\n\n  --strategy: Risk tolerance (default: safe)\n    - safe: Conservative, maximum test coverage required\n    - aggressive: Allow broader changes with adequate coverage\n```\n\n## What This Command Does\n\nPerforms intelligent, deterministic refactoring with full codebase awareness. Unlike blind search-and-replace, this command:\n\n1. **Understands your intent** - Analyzes what you actually want to achieve\n2. **Maps the codebase** - Builds a definitive codemap before touching anything\n3. **Assesses risk** - Evaluates test coverage and determines verification strategy\n4. **Plans meticulously** - Creates a detailed plan with Plan agent\n5. **Executes precisely** - Step-by-step refactoring with LSP and AST-grep\n6. **Verifies constantly** - Runs tests after each change to ensure zero regression\n\n---\n\n# PHASE 0: INTENT GATE (MANDATORY FIRST STEP)\n\n**BEFORE ANY ACTION, classify and validate the request.**\n\n## Step 0.1: Parse Request Type\n\n| Signal | Classification | Action |\n|--------|----------------|--------|\n| Specific file/symbol | Explicit | Proceed to codebase analysis |\n| \"Refactor X to Y\" | Clear transformation | Proceed to codebase analysis |\n| \"Improve\", \"Clean up\" | Open-ended | **MUST ask**: \"What specific improvement?\" |\n| Ambiguous scope | Uncertain | **MUST ask**: \"Which modules/files?\" |\n| Missing context | Incomplete | **MUST ask**: \"What's the desired outcome?\" |\n\n## Step 0.2: Validate Understanding\n\nBefore proceeding, confirm:\n- [ ] Target is clearly identified\n- [ ] Desired outcome is understood\n- [ ] Scope is defined (file/module/project)\n- [ ] Success criteria can be articulated\n\n**If ANY of above is unclear, ASK CLARIFYING QUESTION:**\n\n```\nI want to make sure I understand the refactoring goal correctly.\n\n**What I understood**: [interpretation]\n**What I'm unsure about**: [specific ambiguity]\n\nOptions I see:\n1. [Option A] - [implications]\n2. [Option B] - [implications]\n\n**My recommendation**: [suggestion with reasoning]\n\nShould I proceed with [recommendation], or would you prefer differently?\n```\n\n## Step 0.3: Create Initial Todos\n\n**IMMEDIATELY after understanding the request, create todos:**\n\n```\nTodoWrite([\n  {\"id\": \"phase-1\", \"content\": \"PHASE 1: Codebase Analysis - launch parallel explore agents\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-2\", \"content\": \"PHASE 2: Build Codemap - map dependencies and impact zones\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-3\", \"content\": \"PHASE 3: Test Assessment - analyze test coverage and verification strategy\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-4\", \"content\": \"PHASE 4: Plan Generation - invoke Plan agent for detailed refactoring plan\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-5\", \"content\": \"PHASE 5: Execute Refactoring - step-by-step with continuous verification\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-6\", \"content\": \"PHASE 6: Final Verification - full test suite and regression check\", \"status\": \"pending\", \"priority\": \"high\"}\n])\n```\n\n---\n\n# PHASE 1: CODEBASE ANALYSIS (PARALLEL EXPLORATION)\n\n**Mark phase-1 as in_progress.**\n\n## 1.1: Launch Parallel Explore Agents (BACKGROUND)\n\nFire ALL of these simultaneously using `call_omo_agent`:\n\n```\n// Agent 1: Find the refactoring target\ncall_omo_agent(\n  subagent_type=\"explore\",\n  run_in_background=true,\n  prompt=\"Find all occurrences and definitions of [TARGET]. \n  Report: file paths, line numbers, usage patterns.\"\n)\n\n// Agent 2: Find related code\ncall_omo_agent(\n  subagent_type=\"explore\", \n  run_in_background=true,\n  prompt=\"Find all code that imports, uses, or depends on [TARGET].\n  Report: dependency chains, import graphs.\"\n)\n\n// Agent 3: Find similar patterns\ncall_omo_agent(\n  subagent_type=\"explore\",\n  run_in_background=true,\n  prompt=\"Find similar code patterns to [TARGET] in the codebase.\n  Report: analogous implementations, established conventions.\"\n)\n\n// Agent 4: Find tests\ncall_omo_agent(\n  subagent_type=\"explore\",\n  run_in_background=true,\n  prompt=\"Find all test files related to [TARGET].\n  Report: test file paths, test case names, coverage indicators.\"\n)\n\n// Agent 5: Architecture context\ncall_omo_agent(\n  subagent_type=\"explore\",\n  run_in_background=true,\n  prompt=\"Find architectural patterns and module organization around [TARGET].\n  Report: module boundaries, layer structure, design patterns in use.\"\n)\n```\n\n## 1.2: Direct Tool Exploration (WHILE AGENTS RUN)\n\nWhile background agents are running, use direct tools:\n\n### LSP Tools for Precise Analysis:\n\n```typescript\n// Find definition(s)\nLspGotoDefinition(filePath, line, character)  // Where is it defined?\n\n// Find ALL usages across workspace\nLspFindReferences(filePath, line, character, includeDeclaration=true)\n\n// Get file structure\nLspDocumentSymbols(filePath)  // Hierarchical outline\nLspWorkspaceSymbols(filePath, query=\"[target_symbol]\")  // Search by name\n\n// Get current diagnostics\nlsp_diagnostics(filePath)  // Errors, warnings before we start\n```\n\n### AST-Grep for Pattern Analysis:\n\n```typescript\n// Find structural patterns\nast_grep_search(\n  pattern=\"function $NAME($$$) { $$$ }\",  // or relevant pattern\n  lang=\"typescript\",  // or relevant language\n  paths=[\"src/\"]\n)\n\n// Preview refactoring (DRY RUN)\nast_grep_replace(\n  pattern=\"[old_pattern]\",\n  rewrite=\"[new_pattern]\",\n  lang=\"[language]\",\n  dryRun=true  // ALWAYS preview first\n)\n```\n\n### Grep for Text Patterns:\n\n```\ngrep(pattern=\"[search_term]\", path=\"src/\", include=\"*.ts\")\n```\n\n## 1.3: Collect Background Results\n\n```\nbackground_output(task_id=\"[agent_1_id]\")\nbackground_output(task_id=\"[agent_2_id]\")\n...\n```\n\n**Mark phase-1 as completed after all results collected.**\n\n---\n\n";
+export declare const REFACTOR_INTRO_AND_ANALYSIS = "# Intelligent Refactor 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\", ...)` | `spawn_agent(agent_type=\"explorer\", task_name=\"...\", message=\"...\")` |\n| `call_omo_agent(subagent_type=\"librarian\", ...)` | `spawn_agent(agent_type=\"librarian\", task_name=\"...\", message=\"...\")` |\n| `task(subagent_type=\"plan\", ...)` | `spawn_agent(agent_type=\"plan\", task_name=\"...\", message=\"...\")` |\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=\"...\", ...)` | `spawn_agent(agent_type=\"worker\", task_name=\"...\", message=\"...\")` |\n| `background_output(task_id=\"...\")` | `wait_agent(...)` to wait for subagent completion and mailbox updates |\n| `team_*(...)` | Use Codex native subagents plus `send_message`, `followup_task`, `wait_agent`, and `close_agent` |\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## Usage\n```\n/refactor <refactoring-target> [--scope=<file|module|project>] [--strategy=<safe|aggressive>]\n\nArguments:\n  refactoring-target: What to refactor. Can be:\n    - File path: src/auth/handler.ts\n    - Symbol name: \"AuthService class\"\n    - Pattern: \"all functions using deprecated API\"\n    - Description: \"extract validation logic into separate module\"\n\nOptions:\n  --scope: Refactoring scope (default: module)\n    - file: Single file only\n    - module: Module/directory scope\n    - project: Entire codebase\n\n  --strategy: Risk tolerance (default: safe)\n    - safe: Conservative, maximum test coverage required\n    - aggressive: Allow broader changes with adequate coverage\n```\n\n## What This Command Does\n\nPerforms intelligent, deterministic refactoring with full codebase awareness. Unlike blind search-and-replace, this command:\n\n1. **Understands your intent** - Analyzes what you actually want to achieve\n2. **Maps the codebase** - Builds a definitive codemap before touching anything\n3. **Assesses risk** - Evaluates test coverage and determines verification strategy\n4. **Plans meticulously** - Creates a detailed plan with Plan agent\n5. **Executes precisely** - Step-by-step refactoring with LSP and AST-grep\n6. **Verifies constantly** - Runs tests after each change to ensure zero regression\n\n---\n\n# PHASE 0: INTENT GATE (MANDATORY FIRST STEP)\n\n**BEFORE ANY ACTION, classify and validate the request.**\n\n## Step 0.1: Parse Request Type\n\n| Signal | Classification | Action |\n|--------|----------------|--------|\n| Specific file/symbol | Explicit | Proceed to codebase analysis |\n| \"Refactor X to Y\" | Clear transformation | Proceed to codebase analysis |\n| \"Improve\", \"Clean up\" | Open-ended | **MUST ask**: \"What specific improvement?\" |\n| Ambiguous scope | Uncertain | **MUST ask**: \"Which modules/files?\" |\n| Missing context | Incomplete | **MUST ask**: \"What's the desired outcome?\" |\n\n## Step 0.2: Validate Understanding\n\nBefore proceeding, confirm:\n- [ ] Target is clearly identified\n- [ ] Desired outcome is understood\n- [ ] Scope is defined (file/module/project)\n- [ ] Success criteria can be articulated\n\n**If ANY of above is unclear, ASK CLARIFYING QUESTION:**\n\n```\nI want to make sure I understand the refactoring goal correctly.\n\n**What I understood**: [interpretation]\n**What I'm unsure about**: [specific ambiguity]\n\nOptions I see:\n1. [Option A] - [implications]\n2. [Option B] - [implications]\n\n**My recommendation**: [suggestion with reasoning]\n\nShould I proceed with [recommendation], or would you prefer differently?\n```\n\n## Step 0.3: Create Initial Todos\n\n**IMMEDIATELY after understanding the request, create todos:**\n\n```\nTodoWrite([\n  {\"id\": \"phase-1\", \"content\": \"PHASE 1: Codebase Analysis - launch parallel explore agents\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-2\", \"content\": \"PHASE 2: Build Codemap - map dependencies and impact zones\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-3\", \"content\": \"PHASE 3: Test Assessment - analyze test coverage and verification strategy\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-4\", \"content\": \"PHASE 4: Plan Generation - invoke Plan agent for detailed refactoring plan\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-5\", \"content\": \"PHASE 5: Execute Refactoring - step-by-step with continuous verification\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"phase-6\", \"content\": \"PHASE 6: Final Verification - full test suite and regression check\", \"status\": \"pending\", \"priority\": \"high\"}\n])\n```\n\n---\n\n# PHASE 1: CODEBASE ANALYSIS (PARALLEL EXPLORATION)\n\n**Mark phase-1 as in_progress.**\n\n## 1.1: Launch Parallel Explore Agents (BACKGROUND)\n\nFire ALL of these simultaneously using `call_omo_agent`:\n\n```\n// Agent 1: Find the refactoring target\ncall_omo_agent(\n  subagent_type=\"explore\",\n  run_in_background=true,\n  prompt=\"Find all occurrences and definitions of [TARGET]. \n  Report: file paths, line numbers, usage patterns.\"\n)\n\n// Agent 2: Find related code\ncall_omo_agent(\n  subagent_type=\"explore\", \n  run_in_background=true,\n  prompt=\"Find all code that imports, uses, or depends on [TARGET].\n  Report: dependency chains, import graphs.\"\n)\n\n// Agent 3: Find similar patterns\ncall_omo_agent(\n  subagent_type=\"explore\",\n  run_in_background=true,\n  prompt=\"Find similar code patterns to [TARGET] in the codebase.\n  Report: analogous implementations, established conventions.\"\n)\n\n// Agent 4: Find tests\ncall_omo_agent(\n  subagent_type=\"explore\",\n  run_in_background=true,\n  prompt=\"Find all test files related to [TARGET].\n  Report: test file paths, test case names, coverage indicators.\"\n)\n\n// Agent 5: Architecture context\ncall_omo_agent(\n  subagent_type=\"explore\",\n  run_in_background=true,\n  prompt=\"Find architectural patterns and module organization around [TARGET].\n  Report: module boundaries, layer structure, design patterns in use.\"\n)\n```\n\n## 1.2: Direct Tool Exploration (WHILE AGENTS RUN)\n\nWhile background agents are running, use direct tools:\n\n### LSP Tools for Precise Analysis:\n\n```typescript\n// Find definition(s)\nLspGotoDefinition(filePath, line, character)  // Where is it defined?\n\n// Find ALL usages across workspace\nLspFindReferences(filePath, line, character, includeDeclaration=true)\n\n// Get file structure\nLspDocumentSymbols(filePath)  // Hierarchical outline\nLspWorkspaceSymbols(filePath, query=\"[target_symbol]\")  // Search by name\n\n// Get current diagnostics\nlsp_diagnostics(filePath)  // Errors, warnings before we start\n```\n\n### AST-Grep Skill for Pattern Analysis:\n\n```bash\n// Find structural patterns\npython3 scripts/ast_grep_helper.py search 'function $NAME($$$) { $$$ }' --lang ts src/\n\n# Preview refactoring first\nsg --pattern '[old_pattern]' --rewrite '[new_pattern]' --lang ts src/\n```\n\n### Grep for Text Patterns:\n\n```\ngrep(pattern=\"[search_term]\", path=\"src/\", include=\"*.ts\")\n```\n\n## 1.3: Collect Background Results\n\n```\nbackground_output(task_id=\"[agent_1_id]\")\nbackground_output(task_id=\"[agent_2_id]\")\n...\n```\n\n**Mark phase-1 as completed after all results collected.**\n\n---\n\n";

package/dist/features/builtin-commands/templates/refactor-sections/plan-and-execution.d.ts

@@ -1 +1 @@
-export declare const REFACTOR_PLAN_AND_EXECUTION = "# PHASE 4: PLAN GENERATION (PLAN AGENT)\n\n**Mark phase-4 as in_progress.**\n\n## 4.1: Invoke Plan Agent\n\n```\nTask(\n  subagent_type=\"plan\",\n  prompt=\"Create a detailed refactoring plan:\n\n  ## Refactoring Goal\n  [User's original request]\n\n  ## Codemap (from Phase 2)\n  [Insert codemap here]\n\n  ## Test Coverage (from Phase 3)\n  [Insert verification plan here]\n\n  ## Constraints\n  - MUST follow existing patterns: [list]\n  - MUST NOT break: [critical paths]\n  - MUST run tests after each step\n\n  ## Requirements\n  1. Break down into atomic refactoring steps\n  2. Each step must be independently verifiable\n  3. Order steps by dependency (what must happen first)\n  4. Specify exact files and line ranges for each step\n  5. Include rollback strategy for each step\n  6. Define commit checkpoints\"\n)\n```\n\n## 4.2: Review and Validate Plan\n\nAfter receiving plan from Plan agent:\n\n1. **Verify completeness**: All identified files addressed?\n2. **Verify safety**: Each step reversible?\n3. **Verify order**: Dependencies respected?\n4. **Verify verification**: Test commands specified?\n\n## 4.3: Register Detailed Todos\n\nConvert Plan agent output into granular todos:\n\n```\nTodoWrite([\n  // Each step from the plan becomes a todo\n  {\"id\": \"refactor-1\", \"content\": \"Step 1: [description]\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"verify-1\", \"content\": \"Verify Step 1: run tests\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"refactor-2\", \"content\": \"Step 2: [description]\", \"status\": \"pending\", \"priority\": \"medium\"},\n  {\"id\": \"verify-2\", \"content\": \"Verify Step 2: run tests\", \"status\": \"pending\", \"priority\": \"medium\"},\n  // ... continue for all steps\n])\n```\n\n**Mark phase-4 as completed.**\n\n---\n\n# PHASE 5: EXECUTE REFACTORING (DETERMINISTIC EXECUTION)\n\n**Mark phase-5 as in_progress.**\n\n## 5.1: Execution Protocol\n\nFor EACH refactoring step:\n\n### Pre-Step\n1. Mark step todo as `in_progress`\n2. Read current file state\n3. Verify lsp_diagnostics is baseline\n\n### Execute Step\nUse appropriate tool:\n\n**For Symbol Renames:**\n```typescript\nlsp_prepare_rename(filePath, line, character)  // Validate rename is possible\nlsp_rename(filePath, line, character, newName)  // Execute rename\n```\n\n**For Pattern Transformations:**\n```typescript\n// Preview first\nast_grep_replace(pattern, rewrite, lang, dryRun=true)\n\n// If preview looks good, execute\nast_grep_replace(pattern, rewrite, lang, dryRun=false)\n```\n\n**For Structural Changes:**\n```typescript\n// Use Edit tool for precise changes\nedit(filePath, oldString, newString)\n```\n\n### Post-Step Verification (MANDATORY)\n\n```typescript\n// 1. Check diagnostics\nlsp_diagnostics(filePath)  // Must be clean or same as baseline\n\n// 2. Run tests\nbash(\"bun test\")  // Or appropriate test command\n\n// 3. Type check\nbash(\"tsc --noEmit\")  // Or appropriate type check\n```\n\n### Step Completion\n1. If verification passes \u2192 Mark step todo as `completed`\n2. If verification fails \u2192 **STOP AND FIX**\n\n## 5.2: Failure Recovery Protocol\n\nIf ANY verification fails:\n\n1. **STOP** immediately\n2. **REVERT** the failed change\n3. **DIAGNOSE** what went wrong\n4. **OPTIONS**:\n   - Fix the issue and retry\n   - Skip this step (if optional)\n   - Consult oracle agent for help\n   - Ask user for guidance\n\n**NEVER proceed to next step with broken tests.**\n\n## 5.3: Commit Checkpoints\n\nAfter each logical group of changes:\n\n```bash\ngit add [changed-files]\ngit commit -m \"refactor(scope): description\n\n[details of what was changed and why]\"\n```\n\n**Mark phase-5 as completed when all refactoring steps done.**\n\n---\n\n";
+export declare const REFACTOR_PLAN_AND_EXECUTION = "# PHASE 4: PLAN GENERATION (PLAN AGENT)\n\n**Mark phase-4 as in_progress.**\n\n## 4.1: Invoke Plan Agent\n\n```\nTask(\n  subagent_type=\"plan\",\n  prompt=\"Create a detailed refactoring plan:\n\n  ## Refactoring Goal\n  [User's original request]\n\n  ## Codemap (from Phase 2)\n  [Insert codemap here]\n\n  ## Test Coverage (from Phase 3)\n  [Insert verification plan here]\n\n  ## Constraints\n  - MUST follow existing patterns: [list]\n  - MUST NOT break: [critical paths]\n  - MUST run tests after each step\n\n  ## Requirements\n  1. Break down into atomic refactoring steps\n  2. Each step must be independently verifiable\n  3. Order steps by dependency (what must happen first)\n  4. Specify exact files and line ranges for each step\n  5. Include rollback strategy for each step\n  6. Define commit checkpoints\"\n)\n```\n\n## 4.2: Review and Validate Plan\n\nAfter receiving plan from Plan agent:\n\n1. **Verify completeness**: All identified files addressed?\n2. **Verify safety**: Each step reversible?\n3. **Verify order**: Dependencies respected?\n4. **Verify verification**: Test commands specified?\n\n## 4.3: Register Detailed Todos\n\nConvert Plan agent output into granular todos:\n\n```\nTodoWrite([\n  // Each step from the plan becomes a todo\n  {\"id\": \"refactor-1\", \"content\": \"Step 1: [description]\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"verify-1\", \"content\": \"Verify Step 1: run tests\", \"status\": \"pending\", \"priority\": \"high\"},\n  {\"id\": \"refactor-2\", \"content\": \"Step 2: [description]\", \"status\": \"pending\", \"priority\": \"medium\"},\n  {\"id\": \"verify-2\", \"content\": \"Verify Step 2: run tests\", \"status\": \"pending\", \"priority\": \"medium\"},\n  // ... continue for all steps\n])\n```\n\n**Mark phase-4 as completed.**\n\n---\n\n# PHASE 5: EXECUTE REFACTORING (DETERMINISTIC EXECUTION)\n\n**Mark phase-5 as in_progress.**\n\n## 5.1: Execution Protocol\n\nFor EACH refactoring step:\n\n### Pre-Step\n1. Mark step todo as `in_progress`\n2. Read current file state\n3. Verify lsp_diagnostics is baseline\n\n### Execute Step\nUse appropriate tool:\n\n**For Symbol Renames:**\n```typescript\nlsp_prepare_rename(filePath, line, character)  // Validate rename is possible\nlsp_rename(filePath, line, character, newName)  // Execute rename\n```\n\n**For Pattern Transformations:**\n```bash\n// Preview first\nsg --pattern '[pattern]' --rewrite '[rewrite]' --lang ts path/to/file.ts\n\n// If preview looks good, execute\npython3 scripts/ast_grep_helper.py replace '[pattern]' '[rewrite]' --lang ts path/to/file.ts --apply\n```\n\n**For Structural Changes:**\n```typescript\n// Use Edit tool for precise changes\nedit(filePath, oldString, newString)\n```\n\n### Post-Step Verification (MANDATORY)\n\n```typescript\n// 1. Check diagnostics\nlsp_diagnostics(filePath)  // Must be clean or same as baseline\n\n// 2. Run tests\nbash(\"bun test\")  // Or appropriate test command\n\n// 3. Type check\nbash(\"tsc --noEmit\")  // Or appropriate type check\n```\n\n### Step Completion\n1. If verification passes \u2192 Mark step todo as `completed`\n2. If verification fails \u2192 **STOP AND FIX**\n\n## 5.2: Failure Recovery Protocol\n\nIf ANY verification fails:\n\n1. **STOP** immediately\n2. **REVERT** the failed change\n3. **DIAGNOSE** what went wrong\n4. **OPTIONS**:\n   - Fix the issue and retry\n   - Skip this step (if optional)\n   - Consult oracle agent for help\n   - Ask user for guidance\n\n**NEVER proceed to next step with broken tests.**\n\n## 5.3: Commit Checkpoints\n\nAfter each logical group of changes:\n\n```bash\ngit add [changed-files]\ngit commit -m \"refactor(scope): description\n\n[details of what was changed and why]\"\n```\n\n**Mark phase-5 as completed when all refactoring steps done.**\n\n---\n\n";

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 ast_grep_replace with dryRun=true 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` 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";

package/dist/features/builtin-commands/templates/refactor-sections/verification-and-tooling.d.ts

@@ -1 +1 @@
-export declare const REFACTOR_VERIFICATION_AND_TOOLING = "# PHASE 6: FINAL VERIFICATION (REGRESSION CHECK)\n\n**Mark phase-6 as in_progress.**\n\n## 6.1: Full Test Suite\n\n```bash\n# Run complete test suite\nbun test  # or npm test, pytest, go test, etc.\n```\n\n## 6.2: Type Check\n\n```bash\n# Full type check\ntsc --noEmit  # or equivalent\n```\n\n## 6.3: Lint Check\n\n```bash\n# Run linter\neslint .  # or equivalent\n```\n\n## 6.4: Build Verification (if applicable)\n\n```bash\n# Ensure build still works\nbun run build  # or npm run build, etc.\n```\n\n## 6.5: Final Diagnostics\n\n```typescript\n// Check all changed files\nfor (file of changedFiles) {\n  lsp_diagnostics(file)  // Must all be clean\n}\n```\n\n## 6.6: Generate Summary\n\n```markdown\n## Refactoring Complete\n\n### What Changed\n- [List of changes made]\n\n### Files Modified\n- `path/to/file.ts` - [what changed]\n- `path/to/file2.ts` - [what changed]\n\n### Verification Results\n- Tests: PASSED (X/Y passing)\n- Type Check: CLEAN\n- Lint: CLEAN\n- Build: SUCCESS\n\n### No Regressions Detected\nAll existing tests pass. No new errors introduced.\n```\n\n**Mark phase-6 as completed.**\n\n---\n\n# CRITICAL RULES\n\n## NEVER DO\n- Skip lsp_diagnostics check after changes\n- Proceed with failing tests\n- Make changes without understanding impact\n- Use `as any`, `@ts-ignore`, `@ts-expect-error`\n- Delete tests to make them pass\n- Commit broken code\n- Refactor without understanding existing patterns\n\n## ALWAYS DO\n- Understand before changing\n- Preview before applying (ast_grep dryRun=true)\n- Verify after every change\n- Follow existing codebase patterns\n- Keep todos updated in real-time\n- Commit at logical checkpoints\n- Report issues immediately\n\n## ABORT CONDITIONS\nIf any of these occur, **STOP and consult user**:\n- Test coverage is zero for target code\n- Changes would break public API\n- Refactoring scope is unclear\n- 3 consecutive verification failures\n- User-defined constraints violated\n\n---\n\n# Tool Usage Philosophy\n\nYou already know these tools. Use them intelligently:\n\n## LSP Tools\nLeverage LSP tools for precision analysis. Key patterns:\n- **Understand before changing**: `LspGotoDefinition` to grasp context\n- **Impact analysis**: `LspFindReferences` to map all usages before modification\n- **Safe refactoring**: `lsp_prepare_rename` \u2192 `lsp_rename` for symbol renames\n- **Continuous verification**: `lsp_diagnostics` after every change\n\n## AST-Grep\nUse `ast_grep_search` and `ast_grep_replace` for structural transformations.\n**Critical**: Always `dryRun=true` first, review, then execute.\n\n## Agents\n- `explore`: Parallel codebase pattern discovery\n- `plan`: Detailed refactoring plan generation\n- `oracle`: Read-only consultation for complex architectural decisions and debugging\n- `librarian`: **Use proactively** when encountering deprecated methods or library migration tasks. Query official docs and OSS examples for modern replacements.\n\n## Deprecated Code & Library Migration\nWhen you encounter deprecated methods/APIs during refactoring:\n1. Fire `librarian` to find the recommended modern alternative\n2. **DO NOT auto-upgrade to latest version** unless user explicitly requests migration\n3. If user requests library migration, use `librarian` to fetch latest API docs before making changes\n\n---\n\n**Remember: Refactoring without tests is reckless. Refactoring without understanding is destructive. This command ensures you do neither.**\n\n<user-request>\n$ARGUMENTS\n</user-request>\n";
+export declare const REFACTOR_VERIFICATION_AND_TOOLING = "# PHASE 6: FINAL VERIFICATION (REGRESSION CHECK)\n\n**Mark phase-6 as in_progress.**\n\n## 6.1: Full Test Suite\n\n```bash\n# Run complete test suite\nbun test  # or npm test, pytest, go test, etc.\n```\n\n## 6.2: Type Check\n\n```bash\n# Full type check\ntsc --noEmit  # or equivalent\n```\n\n## 6.3: Lint Check\n\n```bash\n# Run linter\neslint .  # or equivalent\n```\n\n## 6.4: Build Verification (if applicable)\n\n```bash\n# Ensure build still works\nbun run build  # or npm run build, etc.\n```\n\n## 6.5: Final Diagnostics\n\n```typescript\n// Check all changed files\nfor (file of changedFiles) {\n  lsp_diagnostics(file)  // Must all be clean\n}\n```\n\n## 6.6: Generate Summary\n\n```markdown\n## Refactoring Complete\n\n### What Changed\n- [List of changes made]\n\n### Files Modified\n- `path/to/file.ts` - [what changed]\n- `path/to/file2.ts` - [what changed]\n\n### Verification Results\n- Tests: PASSED (X/Y passing)\n- Type Check: CLEAN\n- Lint: CLEAN\n- Build: SUCCESS\n\n### No Regressions Detected\nAll existing tests pass. No new errors introduced.\n```\n\n**Mark phase-6 as completed.**\n\n---\n\n# CRITICAL RULES\n\n## NEVER DO\n- Skip lsp_diagnostics check after changes\n- Proceed with failing tests\n- Make changes without understanding impact\n- Use `as any`, `@ts-ignore`, `@ts-expect-error`\n- Delete tests to make them pass\n- Commit broken code\n- Refactor without understanding existing patterns\n\n## ALWAYS DO\n- Understand before changing\n- Preview structural rewrites before applying them\n- Verify after every change\n- Follow existing codebase patterns\n- Keep todos updated in real-time\n- Commit at logical checkpoints\n- Report issues immediately\n\n## ABORT CONDITIONS\nIf any of these occur, **STOP and consult user**:\n- Test coverage is zero for target code\n- Changes would break public API\n- Refactoring scope is unclear\n- 3 consecutive verification failures\n- User-defined constraints violated\n\n---\n\n# Tool Usage Philosophy\n\nYou already know these tools. Use them intelligently:\n\n## LSP Tools\nLeverage LSP tools for precision analysis. Key patterns:\n- **Understand before changing**: `LspGotoDefinition` to grasp context\n- **Impact analysis**: `LspFindReferences` to map all usages before modification\n- **Safe refactoring**: `lsp_prepare_rename` \u2192 `lsp_rename` for symbol renames\n- **Continuous verification**: `lsp_diagnostics` after every change\n\n## AST-Grep\nUse the `ast-grep` skill helper or `sg` CLI for structural transformations.\n**Critical**: Always preview first, review, then execute.\n\n## Agents\n- `explore`: Parallel codebase pattern discovery\n- `plan`: Detailed refactoring plan generation\n- `oracle`: Read-only consultation for complex architectural decisions and debugging\n- `librarian`: **Use proactively** when encountering deprecated methods or library migration tasks. Query official docs and OSS examples for modern replacements.\n\n## Deprecated Code & Library Migration\nWhen you encounter deprecated methods/APIs during refactoring:\n1. Fire `librarian` to find the recommended modern alternative\n2. **DO NOT auto-upgrade to latest version** unless user explicitly requests migration\n3. If user requests library migration, use `librarian` to fetch latest API docs before making changes\n\n---\n\n**Remember: Refactoring without tests is reckless. Refactoring without understanding is destructive. This command ensures you do neither.**\n\n<user-request>\n$ARGUMENTS\n</user-request>\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\", ...)` | `spawn_agent(agent_type=\"explorer\", task_name=\"...\", message=\"...\")` |\n| `call_omo_agent(subagent_type=\"librarian\", ...)` | `spawn_agent(agent_type=\"librarian\", task_name=\"...\", message=\"...\")` |\n| `task(subagent_type=\"plan\", ...)` | `spawn_agent(agent_type=\"plan\", task_name=\"...\", message=\"...\")` |\n| `task(subagent_type=\"oracle\", ...)` | `spawn_agent(agent_type=\"codex-ultrawork-reviewer\", task_name=\"...\", message=\"...\")` |\n| `task(category=\"...\", ...)` | `spawn_agent(agent_type=\"worker\", task_name=\"...\", message=\"...\")` |\n| `background_output(task_id=\"...\")` | `wait_agent(...)` to wait for subagent completion and mailbox updates |\n| `team_*(...)` | Use Codex native subagents plus `send_message`, `followup_task`, `wait_agent`, and `close_agent` |\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_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\", ...)` | `spawn_agent(agent_type=\"explorer\", task_name=\"...\", message=\"...\")` |\n| `call_omo_agent(subagent_type=\"librarian\", ...)` | `spawn_agent(agent_type=\"librarian\", task_name=\"...\", message=\"...\")` |\n| `task(subagent_type=\"plan\", ...)` | `spawn_agent(agent_type=\"plan\", task_name=\"...\", message=\"...\")` |\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=\"...\", ...)` | `spawn_agent(agent_type=\"worker\", task_name=\"...\", message=\"...\")` |\n| `background_output(task_id=\"...\")` | `wait_agent(...)` to wait for subagent completion and mailbox updates |\n| `team_*(...)` | Use Codex native subagents plus `send_message`, `followup_task`, `wait_agent`, and `close_agent` |\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";

package/dist/features/builtin-skills/index.d.ts

@@ -1,2 +1 @@
-export * from "./types";
-export { createBuiltinSkills, resolveActiveBuiltinSkills, type CreateBuiltinSkillsOptions, type ResolveActiveBuiltinSkillsOptions, } from "./skills";
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/index";

package/dist/features/builtin-skills/skill-file-loader.d.ts

@@ -1,4 +1 @@
-type SkillFileReader = (path: string, encoding: "utf8") => string;
-export declare function createSharedSkillTemplateLoader(readFile?: SkillFileReader, baseDir?: string): (skillName: string) => string;
-export declare function loadSharedSkillTemplate(skillName: string): string;
-export {};
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skill-file-loader";

package/dist/features/builtin-skills/skills/agent-browser-skill.d.ts

@@ -1,2 +1 @@
-import type { BuiltinSkill } from "../types";
-export declare const agentBrowserSkill: BuiltinSkill;
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/agent-browser-skill";

package/dist/features/builtin-skills/skills/agent-browser-template.d.ts

@@ -1,2 +1 @@
-export declare function createAgentBrowserTemplate(markdown: string): string;
-export declare const agentBrowserTemplate: string;
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/agent-browser-template";

package/dist/features/builtin-skills/skills/debugging.d.ts

@@ -1,2 +1 @@
-import type { BuiltinSkill } from "../types";
-export declare const debuggingSkill: BuiltinSkill;
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/debugging";

package/dist/features/builtin-skills/skills/dev-browser.d.ts

@@ -1,2 +1 @@
-import type { BuiltinSkill } from "../types";
-export declare const devBrowserSkill: BuiltinSkill;
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/dev-browser";

package/dist/features/builtin-skills/skills/frontend.d.ts

@@ -0,0 +1 @@
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/frontend";

package/dist/features/builtin-skills/skills/git-master-sections/commit-atomic-planning.d.ts

@@ -1 +1 @@
-export declare const GIT_MASTER_COMMIT_ATOMIC_PLANNING_SECTION = "## PHASE 3: Atomic Unit Planning (BLOCKING - MUST OUTPUT BEFORE PROCEEDING)\n\n<atomic_planning>\n**THIS PHASE HAS MANDATORY OUTPUT** - You MUST print the commit plan before moving to Phase 4.\n\n### 3.0 Calculate Minimum Commit Count FIRST\n\n```\nFORMULA: min_commits = ceil(file_count / 3)\n\n 3 files -> min 1 commit\n 5 files -> min 2 commits\n 9 files -> min 3 commits\n15 files -> min 5 commits\n```\n\n**If your planned commit count < min_commits -> WRONG. SPLIT MORE.**\n\n### 3.1 Split by Directory/Module FIRST (Primary Split)\n\n**RULE: Different directories = Different commits (almost always)**\n\n```\nExample: 8 changed files\n  - app/[locale]/page.tsx\n  - app/[locale]/layout.tsx\n  - components/demo/browser-frame.tsx\n  - components/demo/shopify-full-site.tsx\n  - components/pricing/pricing-table.tsx\n  - e2e/navbar.spec.ts\n  - messages/en.json\n  - messages/ko.json\n\nWRONG: 1 commit \"Update landing page\" (LAZY, WRONG)\nWRONG: 2 commits (still too few)\n\nCORRECT: Split by directory/concern:\n  - Commit 1: app/[locale]/page.tsx + layout.tsx (app layer)\n  - Commit 2: components/demo/* (demo components)\n  - Commit 3: components/pricing/* (pricing components)\n  - Commit 4: e2e/* (tests)\n  - Commit 5: messages/* (i18n)\n  = 5 commits from 8 files (CORRECT)\n```\n\n### 3.2 Split by Concern SECOND (Secondary Split)\n\n**Within same directory, split by logical concern:**\n\n```\nExample: components/demo/ has 4 files\n  - browser-frame.tsx (UI frame)\n  - shopify-full-site.tsx (specific demo)\n  - review-dashboard.tsx (NEW - specific demo)\n  - tone-settings.tsx (NEW - specific demo)\n\nOption A (acceptable): 1 commit if ALL tightly coupled\nOption B (preferred): 2 commits\n  - Commit: \"Update existing demo components\" (browser-frame, shopify)\n  - Commit: \"Add new demo components\" (review-dashboard, tone-settings)\n```\n\n### 3.3 NEVER Do This (Anti-Pattern Examples)\n\n```\nWRONG: \"Refactor entire landing page\" - 1 commit with 15 files\nWRONG: \"Update components and tests\" - 1 commit mixing concerns\nWRONG: \"Big update\" - Any commit touching 5+ unrelated files\n\nRIGHT: Multiple focused commits, each 1-4 files max\nRIGHT: Each commit message describes ONE specific change\nRIGHT: A reviewer can understand each commit in 30 seconds\n```\n\n### 3.4 Implementation + Test Pairing (MANDATORY)\n\n```\nRULE: Test files MUST be in same commit as implementation\n\nTest patterns to match:\n- test_*.py <-> *.py\n- *_test.py <-> *.py\n- *.test.ts <-> *.ts\n- *.spec.ts <-> *.ts\n- __tests__/*.ts <-> *.ts\n- tests/*.py <-> src/*.py\n```\n\n### 3.5 MANDATORY JUSTIFICATION (Before Creating Commit Plan)\n\n**NON-NEGOTIABLE: Before finalizing your commit plan, you MUST:**\n\n```\nFOR EACH planned commit with 3+ files:\n  1. List all files in this commit\n  2. Write ONE sentence explaining why they MUST be together\n  3. If you can't write that sentence -> SPLIT\n\nTEMPLATE:\n\"Commit N contains [files] because [specific reason they are inseparable].\"\n\nVALID reasons:\n  VALID: \"implementation file + its direct test file\"\n  VALID: \"type definition + the only file that uses it\"\n  VALID: \"migration + model change (would break without both)\"\n\nINVALID reasons (MUST SPLIT instead):\n  INVALID: \"all related to feature X\" (too vague)\n  INVALID: \"part of the same PR\" (not a reason)\n  INVALID: \"they were changed together\" (not a reason)\n  INVALID: \"makes sense to group\" (not a reason)\n```\n\n**OUTPUT THIS JUSTIFICATION in your analysis before executing commits.**\n\n### 3.7 Dependency Ordering\n\n```\nLevel 0: Utilities, constants, type definitions\nLevel 1: Models, schemas, interfaces\nLevel 2: Services, business logic\nLevel 3: API endpoints, controllers\nLevel 4: Configuration, infrastructure\n\nCOMMIT ORDER: Level 0 -> Level 1 -> Level 2 -> Level 3 -> Level 4\n```\n\n### 3.8 Create Commit Groups\n\nFor each logical feature/change:\n```yaml\n- group_id: 1\n  feature: \"Add Shopify discount deletion\"\n  files:\n    - errors/shopify_error.py\n    - types/delete_input.py\n    - mutations/update_contract.py\n    - tests/test_update_contract.py\n  dependency_level: 2\n  target_commit: null | <existing-hash>  # null = new, hash = fixup\n```\n\n### 3.9 MANDATORY OUTPUT (BLOCKING)\n\n**You MUST output this block before proceeding to Phase 4. NO EXCEPTIONS.**\n\n```\nCOMMIT PLAN\n===========\nFiles changed: N\nMinimum commits required: ceil(N/3) = M\nPlanned commits: K\nStatus: K >= M (PASS) | K < M (FAIL - must split more)\n\nCOMMIT 1: [message in detected style]\n  - path/to/file1.py\n  - path/to/file1_test.py\n  Justification: implementation + its test\n\nCOMMIT 2: [message in detected style]\n  - path/to/file2.py\n  Justification: independent utility function\n\nCOMMIT 3: [message in detected style]\n  - config/settings.py\n  - config/constants.py\n  Justification: tightly coupled config changes\n\nExecution order: Commit 1 -> Commit 2 -> Commit 3\n(follows dependency: Level 0 -> Level 1 -> Level 2 -> ...)\n```\n\n**VALIDATION BEFORE EXECUTION:**\n- Each commit has <=4 files (or justified)\n- Each commit message matches detected STYLE + LANGUAGE\n- Test files paired with implementation\n- Different directories = different commits (or justified)\n- Total commits >= min_commits\n\n**IF ANY CHECK FAILS, DO NOT PROCEED. REPLAN.**\n</atomic_planning>";
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/git-master-sections/commit-atomic-planning";

package/dist/features/builtin-skills/skills/git-master-sections/commit-context-analysis.d.ts

@@ -1 +1 @@
-export declare const GIT_MASTER_COMMIT_CONTEXT_ANALYSIS_SECTION = "## PHASE 0: Parallel Context Gathering (MANDATORY FIRST STEP)\n\n<parallel_analysis>\n**Execute ALL of the following commands IN PARALLEL to minimize latency:**\n\n```bash\n# Group 1: Current state\ngit status\ngit diff --staged --stat\ngit diff --stat\n\n# Group 2: History context\ngit log -30 --oneline\ngit log -30 --pretty=format:\"%s\"\n\n# Group 3: Branch context\ngit branch --show-current\ngit merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null\ngit rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo \"NO_UPSTREAM\"\ngit log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null)..HEAD 2>/dev/null\n```\n\n**Capture these data points simultaneously:**\n1. What files changed (staged vs unstaged)\n2. Recent 30 commit messages for style detection\n3. Branch position relative to main/master\n4. Whether branch has upstream tracking\n5. Commits that would go in PR (local only)\n</parallel_analysis>\n\n---\n\n## PHASE 1: Style Detection (BLOCKING - MUST OUTPUT BEFORE PROCEEDING)\n\n<style_detection>\n**THIS PHASE HAS MANDATORY OUTPUT** - You MUST print the analysis result before moving to Phase 2.\n\n### 1.1 Language Profile Detection\n\n```\nCount from git log -30:\n- Dominant language/script patterns: N commits\n- Secondary language/script patterns: M commits\n- Mixed/ambiguous: K commits\n\nDECISION:\n- Preserve the dominant repository language pattern in commit messages\n- If multiple languages are common, follow the nearest recent examples for the same module\n- Never restrict output to specific languages; support any language used by the repo (e.g., Japanese, Korean, English, etc.)\n```\n\n### 1.2 Commit Style Classification\n\n| Style | Pattern | Example | Detection Regex |\n|-------|---------|---------|-----------------|\n| `SEMANTIC` | `type: message` or `type(scope): message` | `feat: add login` | `/^(feat\\|fix\\|chore\\|refactor\\|docs\\|test\\|ci\\|style\\|perf\\|build)(\\(.+\\))?:/` |\n| `PLAIN` | Just description, no prefix | `Add login feature` | No conventional prefix, >3 words |\n| `SENTENCE` | Full sentence style | `Implemented the new login flow` | Complete grammatical sentence |\n| `SHORT` | Minimal keywords | `format`, `lint` | 1-3 words only |\n\n**Detection Algorithm:**\n```\nsemantic_count = commits matching semantic regex\nplain_count = non-semantic commits with >3 words\nshort_count = commits with <=3 words\n\nIF semantic_count >= 15 (50%): STYLE = SEMANTIC\nELSE IF plain_count >= 15: STYLE = PLAIN\nELSE IF short_count >= 10: STYLE = SHORT\nELSE: STYLE = PLAIN (safe default)\n```\n\n### 1.3 MANDATORY OUTPUT (BLOCKING)\n\n**You MUST output this block before proceeding to Phase 2. NO EXCEPTIONS.**\n\n```\nSTYLE DETECTION RESULT\n======================\nAnalyzed: 30 commits from git log\n\nLanguage profile: [DOMINANT_LANGUAGE_OR_SCRIPT]\n  - Dominant pattern: N (X%)\n  - Secondary pattern: M (Y%)\n\nStyle: [SEMANTIC | PLAIN | SENTENCE | SHORT]\n  - Semantic (feat:, fix:, etc): N (X%)\n  - Plain: M (Y%)\n  - Short: K (Z%)\n\nReference examples from repo:\n  1. \"actual commit message from log\"\n  2. \"actual commit message from log\"\n  3. \"actual commit message from log\"\n\nAll commits will follow: [DOMINANT_LANGUAGE_OR_SCRIPT] + [STYLE]\n```\n\n**IF YOU SKIP THIS OUTPUT, YOUR COMMITS WILL BE WRONG. STOP AND REDO.**\n</style_detection>\n\n---\n\n## PHASE 2: Branch Context Analysis\n\n<branch_analysis>\n### 2.1 Determine Branch State\n\n```\nBRANCH_STATE:\n  current_branch: <name>\n  has_upstream: true | false\n  commits_ahead: N  # Local-only commits\n  merge_base: <hash>\n\nREWRITE_SAFETY:\n  - If has_upstream AND commits_ahead > 0 AND already pushed:\n    -> WARN before force push\n  - If no upstream OR all commits local:\n    -> Safe for aggressive rewrite (fixup, reset, rebase)\n  - If on main/master:\n    -> NEVER rewrite, only new commits\n```\n\n### 2.2 History Rewrite Strategy Decision\n\n```\nIF current_branch == main OR current_branch == master:\n  -> STRATEGY = NEW_COMMITS_ONLY\n  -> Never fixup, never rebase\n\nELSE IF commits_ahead == 0:\n  -> STRATEGY = NEW_COMMITS_ONLY\n  -> No history to rewrite\n\nELSE IF all commits are local (not pushed):\n  -> STRATEGY = AGGRESSIVE_REWRITE\n  -> Fixup freely, reset if needed, rebase to clean\n\nELSE IF pushed but not merged:\n  -> STRATEGY = CAREFUL_REWRITE\n  -> Fixup OK but warn about force push\n```\n</branch_analysis>";
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/git-master-sections/commit-context-analysis";

package/dist/features/builtin-skills/skills/git-master-sections/commit-execution-verification.d.ts

@@ -1 +1 @@
-export declare const GIT_MASTER_COMMIT_EXECUTION_VERIFICATION_SECTION = "## PHASE 4: Commit Strategy Decision\n\n<strategy_decision>\n### 4.1 For Each Commit Group, Decide:\n\n```\nFIXUP if:\n  - Change complements existing commit's intent\n  - Same feature, fixing bugs or adding missing parts\n  - Review feedback incorporation\n  - Target commit exists in local history\n\nNEW COMMIT if:\n  - New feature or capability\n  - Independent logical unit\n  - Different issue/ticket\n  - No suitable target commit exists\n```\n\n### 4.2 History Rebuild Decision (Aggressive Option)\n\n```\nCONSIDER RESET & REBUILD when:\n  - History is messy (many small fixups already)\n  - Commits are not atomic (mixed concerns)\n  - Dependency order is wrong\n\nRESET WORKFLOW:\n  1. git reset --soft $(git merge-base HEAD main)\n  2. All changes now staged\n  3. Re-commit in proper atomic units\n  4. Clean history from scratch\n\nONLY IF:\n  - All commits are local (not pushed)\n  - User explicitly allows OR branch is clearly WIP\n```\n\n### 4.3 Final Plan Summary\n\n```yaml\nEXECUTION_PLAN:\n  strategy: FIXUP_THEN_NEW | NEW_ONLY | RESET_REBUILD\n  fixup_commits:\n    - files: [...]\n      target: <hash>\n  new_commits:\n    - files: [...]\n      message: \"...\"\n      level: N\n  requires_force_push: true | false\n```\n</strategy_decision>\n\n---\n\n## PHASE 5: Commit Execution\n\n<execution>\n### 5.1 Register TODO Items\n\nUse TodoWrite to register each commit as a trackable item:\n```\n- [ ] Fixup: <description> -> <target-hash>\n- [ ] New: <description>\n- [ ] Rebase autosquash\n- [ ] Final verification\n```\n\n### 5.2 Fixup Commits (If Any)\n\n```bash\n# Stage files for each fixup\ngit add <files>\ngit commit --fixup=<target-hash>\n\n# Repeat for all fixups...\n\n# Single autosquash rebase at the end\nMERGE_BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)\nGIT_SEQUENCE_EDITOR=: git rebase -i --autosquash $MERGE_BASE\n```\n\n### 5.3 New Commits (After Fixups)\n\nFor each new commit group, in dependency order:\n\n```bash\n# Stage files\ngit add <file1> <file2> ...\n\n# Verify staging\ngit diff --staged --stat\n\n# Commit with detected style\ngit commit -m \"<message-matching-COMMIT_CONFIG>\"\n\n# Verify\ngit log -1 --oneline\n```\n\n### 5.4 Commit Message Generation\n\n**Based on COMMIT_CONFIG from Phase 1:**\n\n```\nIF style == SEMANTIC:\n  -> Use a semantic prefix + repository language message\n  -> Examples:\n     - \"feat: add login feature\"\n     - \"feat: \u30ED\u30B0\u30A4\u30F3\u6A5F\u80FD\u3092\u8FFD\u52A0\"\n     - \"feat: \uB85C\uADF8\uC778 \uAE30\uB2A5 \uCD94\uAC00\"\n\nIF style == PLAIN:\n  -> Use plain repository language message without semantic prefix\n  -> Examples:\n     - \"Add login feature\"\n     - \"\u30ED\u30B0\u30A4\u30F3\u6A5F\u80FD\u3092\u8FFD\u52A0\"\n     - \"\uB85C\uADF8\uC778 \uAE30\uB2A5 \uCD94\uAC00\"\n\nIF style == SHORT:\n  -> \"format\" / \"type fix\" / \"lint\"\n```\n\n**VALIDATION before each commit:**\n1. Does message match detected style?\n2. Does message use the repository's dominant language/script profile (from Phase 1.1)?\n3. Is it similar to examples from git log?\n\nIf ANY check fails -> REWRITE message.\n```\n</execution>\n\n---\n\n## PHASE 6: Verification & Cleanup\n\n<verification>\n### 6.1 Post-Commit Verification\n\n```bash\n# Check working directory clean\ngit status\n\n# Review new history\ngit log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)..HEAD\n\n# Verify each commit is atomic\n# (mentally check: can each be reverted independently?)\n```\n\n### 6.2 Force Push Decision\n\n```\nIF fixup was used AND branch has upstream:\n  -> Requires: git push --force-with-lease\n  -> WARN user about force push implications\n\nIF only new commits:\n  -> Regular: git push\n```\n\n### 6.3 Final Report\n\n```\nCOMMIT SUMMARY:\n  Strategy: <what was done>\n  Commits created: N\n  Fixups merged: M\n\nHISTORY:\n  <hash1> <message1>\n  <hash2> <message2>\n  ...\n\nNEXT STEPS:\n  - git push [--force-with-lease]\n  - Create PR if ready\n```\n</verification>";
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/git-master-sections/commit-execution-verification";

package/dist/features/builtin-skills/skills/git-master-sections/commit-workflow.d.ts

@@ -1 +1 @@
-export declare const GIT_MASTER_COMMIT_WORKFLOW_SECTION: string;
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/git-master-sections/commit-workflow";

package/dist/features/builtin-skills/skills/git-master-sections/history-search-workflow.d.ts

@@ -1 +1 @@
-export declare const GIT_MASTER_HISTORY_SEARCH_WORKFLOW_SECTION = "## HISTORY SEARCH MODE (Phase H1-H3)\n\n## PHASE H1: Determine Search Type\n\n<history_search_type>\n### H1.1 Parse User Request\n\n| User Request | Search Type | Tool |\n|--------------|-------------|------|\n| \"when was X added\" in any language (e.g., \"X\uAC00 \uC5B8\uC81C \uCD94\uAC00\uB410\uC5B4\", \"X\u306F\u3044\u3064\u8FFD\u52A0\u3055\u308C\u305F\") | PICKAXE | `git log -S` |\n| \"find commits changing X pattern\" | REGEX | `git log -G` |\n| \"who wrote this line\" in any language (e.g., \"\uC774 \uC904 \uB204\uAC00 \uC37C\uC5B4\", \"\u3053\u306E\u884C\u3092\u66F8\u3044\u305F\u306E\u306F\u8AB0\") | BLAME | `git blame` |\n| \"when did bug start\" in any language (e.g., \"\uBC84\uADF8 \uC5B8\uC81C \uC0DD\uACBC\uC5B4\", \"\u30D0\u30B0\u306F\u3044\u3064\u5165\u3063\u305F\") | BISECT | `git bisect` |\n| \"history of file\" in any language (e.g., \"\uD30C\uC77C \uD788\uC2A4\uD1A0\uB9AC\", \"\u30D5\u30A1\u30A4\u30EB\u5C65\u6B74\") | FILE_LOG | `git log -- path` |\n| \"find deleted code\" in any language (e.g., \"\uC0AD\uC81C\uB41C \uCF54\uB4DC \uCC3E\uAE30\", \"\u524A\u9664\u3055\u308C\u305F\u30B3\u30FC\u30C9\u3092\u63A2\u3059\") | PICKAXE_ALL | `git log -S --all` |\n\n### H1.2 Extract Search Parameters\n\n```\nFrom user request, identify:\n- SEARCH_TERM: The string/pattern to find\n- FILE_SCOPE: Specific file(s) or entire repo\n- TIME_RANGE: All time or specific period\n- BRANCH_SCOPE: Current branch or --all branches\n```\n</history_search_type>\n\n---\n\n## PHASE H2: Execute Search\n\n<history_search_exec>\n### H2.1 Pickaxe Search (git log -S)\n\n**Purpose**: Find commits that ADD or REMOVE a specific string\n\n```bash\n# Basic: Find when string was added/removed\ngit log -S \"searchString\" --oneline\n\n# With context (see the actual changes):\ngit log -S \"searchString\" -p\n\n# In specific file:\ngit log -S \"searchString\" -- path/to/file.py\n\n# Across all branches (find deleted code):\ngit log -S \"searchString\" --all --oneline\n\n# With date range:\ngit log -S \"searchString\" --since=\"2024-01-01\" --oneline\n\n# Case insensitive:\ngit log -S \"searchstring\" -i --oneline\n```\n\n**Example Use Cases:**\n```bash\n# When was this function added?\ngit log -S \"def calculate_discount\" --oneline\n\n# When was this constant removed?\ngit log -S \"MAX_RETRY_COUNT\" --all --oneline\n\n# Find who introduced a bug pattern\ngit log -S \"== None\" -- \"*.py\" --oneline  # Should be \"is None\"\n```\n\n### H2.2 Regex Search (git log -G)\n\n**Purpose**: Find commits where diff MATCHES a regex pattern\n\n```bash\n# Find commits touching lines matching pattern\ngit log -G \"pattern.*regex\" --oneline\n\n# Find function definition changes\ngit log -G \"def\\s+my_function\" --oneline -p\n\n# Find import changes\ngit log -G \"^import\\s+requests\" -- \"*.py\" --oneline\n\n# Find TODO additions/removals\ngit log -G \"TODO|FIXME|HACK\" --oneline\n```\n\n**-S vs -G Difference:**\n```\n-S \"foo\": Finds commits where COUNT of \"foo\" changed\n-G \"foo\": Finds commits where DIFF contains \"foo\"\n\nUse -S for: \"when was X added/removed\"\nUse -G for: \"what commits touched lines containing X\"\n```\n\n### H2.3 Git Blame\n\n**Purpose**: Line-by-line attribution\n\n```bash\n# Basic blame\ngit blame path/to/file.py\n\n# Specific line range\ngit blame -L 10,20 path/to/file.py\n\n# Show original commit (ignoring moves/copies)\ngit blame -C path/to/file.py\n\n# Ignore whitespace changes\ngit blame -w path/to/file.py\n\n# Show email instead of name\ngit blame -e path/to/file.py\n\n# Output format for parsing\ngit blame --porcelain path/to/file.py\n```\n\n**Reading Blame Output:**\n```\n^abc1234 (Author Name 2024-01-15 10:30:00 +0900 42) code_line_here\n|         |            |                       |    +-- Line content\n|         |            |                       +-- Line number\n|         |            +-- Timestamp\n|         +-- Author\n+-- Commit hash (^ means initial commit)\n```\n\n### H2.4 Git Bisect (Binary Search for Bugs)\n\n**Purpose**: Find exact commit that introduced a bug\n\n```bash\n# Start bisect session\ngit bisect start\n\n# Mark current (bad) state\ngit bisect bad\n\n# Mark known good commit (e.g., last release)\ngit bisect good v1.0.0\n\n# Git checkouts middle commit. Test it, then:\ngit bisect good  # if this commit is OK\ngit bisect bad   # if this commit has the bug\n\n# Repeat until git finds the culprit commit\n# Git will output: \"abc1234 is the first bad commit\"\n\n# When done, return to original state\ngit bisect reset\n```\n\n**Automated Bisect (with test script):**\n```bash\n# If you have a test that fails on bug:\ngit bisect start\ngit bisect bad HEAD\ngit bisect good v1.0.0\ngit bisect run pytest tests/test_specific.py\n\n# Git runs test on each commit automatically\n# Exits 0 = good, exits 1-127 = bad, exits 125 = skip\n```\n\n### H2.5 File History Tracking\n\n```bash\n# Full history of a file\ngit log --oneline -- path/to/file.py\n\n# Follow file across renames\ngit log --follow --oneline -- path/to/file.py\n\n# Show actual changes\ngit log -p -- path/to/file.py\n\n# Files that no longer exist\ngit log --all --full-history -- \"**/deleted_file.py\"\n\n# Who changed file most\ngit shortlog -sn -- path/to/file.py\n```\n</history_search_exec>\n\n---\n\n## PHASE H3: Present Results\n\n<history_results>\n### H3.1 Format Search Results\n\n```\nSEARCH QUERY: \"<what user asked>\"\nSEARCH TYPE: <PICKAXE | REGEX | BLAME | BISECT | FILE_LOG>\nCOMMAND USED: git log -S \"...\" ...\n\nRESULTS:\n  Commit       Date           Message\n  ---------    ----------     --------------------------------\n  abc1234      2024-06-15     feat: add discount calculation\n  def5678      2024-05-20     refactor: extract pricing logic\n\nMOST RELEVANT COMMIT: abc1234\nDETAILS:\n  Author: John Doe <john@example.com>\n  Date: 2024-06-15\n  Files changed: 3\n  \nDIFF EXCERPT (if applicable):\n  + def calculate_discount(price, rate):\n  +     return price * (1 - rate)\n```\n\n### H3.2 Provide Actionable Context\n\nBased on search results, offer relevant follow-ups:\n\n```\nFOUND THAT commit abc1234 introduced the change.\n\nPOTENTIAL ACTIONS:\n- View full commit: git show abc1234\n- Revert this commit: git revert abc1234\n- See related commits: git log --ancestry-path abc1234..HEAD\n- Cherry-pick to another branch: git cherry-pick abc1234\n```\n</history_results>";
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/git-master-sections/history-search-workflow";

package/dist/features/builtin-skills/skills/git-master-sections/overview.d.ts

@@ -1 +1 @@
-export declare const GIT_MASTER_OVERVIEW_SECTION = "# Git Master Agent\n\nYou are a Git expert combining three specializations:\n1. **Commit Architect**: Atomic commits, dependency ordering, style detection\n2. **Rebase Surgeon**: History rewriting, conflict resolution, branch cleanup  \n3. **History Archaeologist**: Finding when/where specific changes were introduced\n\n---\n\n## MODE DETECTION (FIRST STEP)\n\nAnalyze the user's request to determine operation mode:\n\n| User Request Pattern | Mode | Jump To |\n|---------------------|------|---------|\n| Commit intent in any language (e.g., \"commit\", \"\uCEE4\uBC0B\", \"\u30B3\u30DF\u30C3\u30C8\") | `COMMIT` | Phase 0-6 (existing) |\n| Rebase/squash intent in any language (e.g., \"rebase\", \"\uB9AC\uBCA0\uC774\uC2A4\", \"\u30EA\u30D9\u30FC\u30B9\") | `REBASE` | Phase R1-R4 |\n| History lookup intent in any language (e.g., \"find when\", \"\uC5B8\uC81C \uBC14\uB00C\uC5C8\", \"\u3044\u3064\u8FFD\u52A0\") | `HISTORY_SEARCH` | Phase H1-H3 |\n| \"smart rebase\", \"rebase onto\" | `REBASE` | Phase R1-R4 |\n\n**CRITICAL**: Don't default to COMMIT mode. Parse the actual request.\n\n---\n\n## CORE PRINCIPLE: MULTIPLE COMMITS BY DEFAULT (NON-NEGOTIABLE)\n\n<critical_warning>\n**ONE COMMIT = AUTOMATIC FAILURE**\n\nYour DEFAULT behavior is to CREATE MULTIPLE COMMITS.\nSingle commit is a BUG in your logic, not a feature.\n\n**HARD RULE:**\n```\n3+ files changed -> MUST be 2+ commits (NO EXCEPTIONS)\n5+ files changed -> MUST be 3+ commits (NO EXCEPTIONS)\n10+ files changed -> MUST be 5+ commits (NO EXCEPTIONS)\n```\n\n**If you're about to make 1 commit from multiple files, YOU ARE WRONG. STOP AND SPLIT.**\n\n**SPLIT BY:**\n| Criterion | Action |\n|-----------|--------|\n| Different directories/modules | SPLIT |\n| Different component types (model/service/view) | SPLIT |\n| Can be reverted independently | SPLIT |\n| Different concerns (UI/logic/config/test) | SPLIT |\n| New file vs modification | SPLIT |\n\n**ONLY COMBINE when ALL of these are true:**\n- EXACT same atomic unit (e.g., function + its test)\n- Splitting would literally break compilation\n- You can justify WHY in one sentence\n\n**MANDATORY SELF-CHECK before committing:**\n```\n\"I am making N commits from M files.\"\nIF N == 1 AND M > 2:\n  -> WRONG. Go back and split.\n  -> Write down WHY each file must be together.\n  -> If you can't justify, SPLIT.\n```\n</critical_warning>";
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/git-master-sections/overview";

package/dist/features/builtin-skills/skills/git-master-sections/quick-reference.d.ts

@@ -1 +1 @@
-export declare const GIT_MASTER_QUICK_REFERENCE_SECTION = "## Quick Reference\n\n### Style Detection Cheat Sheet\n\n| If git log shows... | Use this style |\n|---------------------|----------------|\n| `feat: xxx`, `fix: yyy` | SEMANTIC |\n| `Add xxx`, `Fix yyy`, `xxx \uCD94\uAC00`, `xxx\u3092\u8FFD\u52A0` | PLAIN |\n| `format`, `lint`, `typo` | SHORT |\n| Full sentences | SENTENCE |\n| Mix of above | Use MAJORITY (not semantic by default) |\n\n### Decision Tree\n\n```\nIs this on main/master?\n  YES -> NEW_COMMITS_ONLY, never rewrite\n  NO -> Continue\n\nAre all commits local (not pushed)?\n  YES -> AGGRESSIVE_REWRITE allowed\n  NO -> CAREFUL_REWRITE (warn on force push)\n\nDoes change complement existing commit?\n  YES -> FIXUP to that commit\n  NO -> NEW COMMIT\n\nIs history messy?\n  YES + all local -> Consider RESET_REBUILD\n  NO -> Normal flow\n```\n\n### Anti-Patterns (AUTOMATIC FAILURE)\n\n1. **NEVER make one giant commit** - 3+ files MUST be 2+ commits\n2. **NEVER default to semantic style** - detect from git log first\n3. **NEVER separate test from implementation** - same commit always\n4. **NEVER group by file type** - group by feature/module\n5. **NEVER rewrite pushed history** without explicit permission\n6. **NEVER leave working directory dirty** - complete all changes\n7. **NEVER skip JUSTIFICATION** - explain why files are grouped\n8. **NEVER use vague grouping reasons** - \"related to X\" is NOT valid\n\n---\n\n## FINAL CHECK BEFORE EXECUTION (BLOCKING)\n\n```\nSTOP AND VERIFY - Do not proceed until ALL boxes checked:\n\n[] File count check: N files -> at least ceil(N/3) commits?\n  - 3 files -> min 1 commit\n  - 5 files -> min 2 commits\n  - 10 files -> min 4 commits\n  - 20 files -> min 7 commits\n\n[] Justification check: For each commit with 3+ files, did I write WHY?\n\n[] Directory split check: Different directories -> different commits?\n\n[] Test pairing check: Each test with its implementation?\n\n[] Dependency order check: Foundations before dependents?\n```\n\n**HARD STOP CONDITIONS:**\n- Making 1 commit from 3+ files -> **WRONG. SPLIT.**\n- Making 2 commits from 10+ files -> **WRONG. SPLIT MORE.**\n- Can't justify file grouping in one sentence -> **WRONG. SPLIT.**\n- Different directories in same commit (without justification) -> **WRONG. SPLIT.**\n\n---\n\n### Commit Mode\n- One commit for many files -> SPLIT\n- Default to semantic style -> DETECT first\n\n### Rebase Mode\n- Rebase main/master -> NEVER\n- `--force` instead of `--force-with-lease` -> DANGEROUS\n- Rebase without stashing dirty files -> WILL FAIL\n\n### History Search Mode\n- `-S` when `-G` is appropriate -> Wrong results\n- Blame without `-C` on moved code -> Wrong attribution\n- Bisect without proper good/bad boundaries -> Wasted time";
+export * from "@oh-my-opencode/skills-loader-core/builtin-skills/skills/git-master-sections/quick-reference";