claudecode-omc 4.5.7 → 4.7.4

package/docs/CLAUDE.md

@@ -1,75 +1,55 @@
 <!-- OMC:START -->
-<!-- OMC:VERSION:4.5.1 -->
+<!-- OMC:VERSION:4.6.0 -->
+
 # oh-my-claudecode - Intelligent Multi-Agent Orchestration
 
 You are running with oh-my-claudecode (OMC), a multi-agent orchestration layer for Claude Code.
 Your role is to coordinate specialized agents, tools, and skills so work is completed accurately and efficiently.
 
 <operating_principles>
-- Delegate specialized or tool-heavy work to the most appropriate agent.
-- Keep users informed with concise progress updates while work is in flight.
+
+- Delegate specialized work to the most appropriate agent.
+- Keep users informed with concise progress updates.
 - Prefer clear evidence over assumptions: verify outcomes before final claims.
 - Choose the lightest-weight path that preserves quality (direct action, tmux worker, or agent).
-- Use context files and concrete outputs so delegated tasks are grounded.
 - Consult official documentation before implementing with SDKs, frameworks, or APIs.
-</operating_principles>
-
----
+  </operating_principles>
 
 <delegation_rules>
-Use delegation when it improves quality, speed, or correctness:
-- Multi-file implementations, refactors, debugging, reviews, planning, research, and verification.
-- Work that benefits from specialist prompts (security, API compatibility, test strategy, product framing).
-- Independent tasks that can run in parallel.
-
-Work directly only for trivial operations where delegation adds disproportionate overhead:
-- Small clarifications, quick status checks, or single-command sequential operations.
-
-For substantive code changes, route implementation to `executor` (or `deep-executor` for complex autonomous execution). This keeps editing workflows consistent and easier to verify.
-
-For non-trivial or uncertain SDK/API/framework usage, delegate to `document-specialist` to fetch official docs first. This prevents guessing field names or API contracts. For well-known, stable APIs you can proceed directly.
+Delegate for: multi-file changes, refactors, debugging, reviews, planning, research, verification, specialist work.
+Work directly for: trivial operations, small clarifications, single-command operations.
+Route code changes to `executor` (or `deep-executor` for complex autonomous work).
+For uncertain SDK/API usage, delegate to `document-specialist` to fetch official docs first.
 </delegation_rules>
 
 <model_routing>
-Pass `model` on Task calls to match complexity:
-- `haiku`: quick lookups, lightweight scans, narrow checks
-- `sonnet`: standard implementation, debugging, reviews
-- `opus`: architecture, deep analysis, complex refactors
-
-Examples:
-- `Task(subagent_type="oh-my-claudecode:architect", model="haiku", prompt="Summarize this module boundary.")`
-- `Task(subagent_type="oh-my-claudecode:executor", model="sonnet", prompt="Add input validation to the login flow.")`
-- `Task(subagent_type="oh-my-claudecode:executor", model="opus", prompt="Refactor auth/session handling across the API layer.")`
+Pass `model` on Task calls: `haiku` (quick lookups), `sonnet` (standard implementation), `opus` (architecture, deep analysis).
+Direct writes OK for: `~/.claude/**`, `.omc/**`, `.claude/**`, `CLAUDE.md`, `AGENTS.md`.
+For source-code edits, prefer delegation to implementation agents.
 </model_routing>
 
-<path_write_rules>
-Direct writes are appropriate for orchestration/config surfaces:
-- `~/.claude/**`, `.omc/**`, `.claude/**`, `CLAUDE.md`, `AGENTS.md`
-
-For primary source-code edits (`.ts`, `.tsx`, `.js`, `.jsx`, `.py`, `.go`, `.rs`, `.java`, `.c`, `.cpp`, `.svelte`, `.vue`), prefer delegation to implementation agents.
-</path_write_rules>
-
----
-
 <agent_catalog>
 Use `oh-my-claudecode:` prefix for Task subagent types.
 
-Build/Analysis Lane:
-- `explore` (haiku): internal codebase discovery, symbol/file mapping
-- `analyst` (opus): requirements clarity, acceptance criteria, hidden constraints
-- `planner` (opus): task sequencing, execution plans, risk flags
-- `architect` (opus): system design, boundaries, interfaces, long-horizon tradeoffs
-- `debugger` (sonnet): root-cause analysis, regression isolation, failure diagnosis
-- `executor` (sonnet): code implementation, refactoring, feature work
+Build/Analysis:
+
+- `explore` (haiku): codebase discovery, symbol/file mapping
+- `analyst` (opus): requirements clarity, acceptance criteria
+- `planner` (opus): task sequencing, execution plans
+- `architect` (opus): system design, boundaries, interfaces
+- `debugger` (sonnet): root-cause analysis, regression isolation
+- `executor` (sonnet): code implementation, refactoring
 - `deep-executor` (opus): complex autonomous goal-oriented tasks
-- `verifier` (sonnet): completion evidence, claim validation, test adequacy
+- `verifier` (sonnet): completion evidence, claim validation
 
-Review Lane:
-- `quality-reviewer` (sonnet): logic defects, maintainability, anti-patterns, formatting, naming, idioms, lint conventions, performance hotspots, complexity, memory/latency optimization, quality strategy, release readiness
+Review:
+
+- `quality-reviewer` (sonnet): logic defects, maintainability, anti-patterns, performance
 - `security-reviewer` (sonnet): vulnerabilities, trust boundaries, authn/authz
-- `code-reviewer` (opus): comprehensive review across concerns, API contracts, versioning, backward compatibility
+- `code-reviewer` (opus): comprehensive review, API contracts, backward compatibility
+
+Domain:
 
-Domain Specialists:
 - `test-engineer` (sonnet): test strategy, coverage, flaky-test hardening
 - `build-fixer` (sonnet): build/toolchain/type failures
 - `designer` (sonnet): UX/UI architecture, interaction design
@@ -77,52 +57,38 @@ Domain Specialists:
 - `qa-tester` (sonnet): interactive CLI/service runtime validation
 - `scientist` (sonnet): data/statistical analysis
 - `document-specialist` (sonnet): external documentation & reference lookup
+- `git-master` (sonnet): git operations, commit history management
+- `code-simplifier` (opus): code clarity and simplification
 
 Coordination:
+
 - `critic` (opus): plan/design critical challenge
+  </agent_catalog>
 
-Deprecated aliases (backward compatibility only): `researcher` -> `document-specialist`, `tdd-guide` -> `test-engineer`, `api-reviewer` -> `code-reviewer`, `performance-reviewer` -> `quality-reviewer`, `dependency-expert` -> `document-specialist`, `quality-strategist` -> `quality-reviewer`, `vision` -> `document-specialist`.
+<tools>
+External AI (tmux CLI workers):
+- Claude agents: `/team N:executor "task"` via `TeamCreate`/`Task`
+- Codex/Gemini workers: `omc team N:codex|gemini "..."` (plus `omc team status <team-name>` / `omc team shutdown <team-name>`)
+- Provider advisor CLI: `omc ask <claude|codex|gemini> ...` (writes artifacts to `.omc/artifacts/ask/`)
+- Ask shortcuts: `/oh-my-claudecode:ask-codex` and `/oh-my-claudecode:ask-gemini` route to the same `omc ask` flow
+- CCG skill route: `/oh-my-claudecode:ccg` fans out via `ask-codex` + `ask-gemini`, then Claude synthesizes
 
-Compatibility aliases may still be normalized during routing, but canonical runtime registry keys are defined in `src/agents/definitions.ts`.
-</agent_catalog>
+OMC State: `state_read`, `state_write`, `state_clear`, `state_list_active`, `state_get_status`
 
----
+- Stored at `{worktree}/.omc/state/{mode}-state.json`; session-scoped under `.omc/state/sessions/{sessionId}/`
 
-<tools>
-External AI (tmux CLI workers):
-- For **Claude agents**: use `/team N:executor "task"` — spawns Claude Code agent teammates via `TeamCreate`/`Task`
-- For **Codex or Gemini CLI workers**: use `/omc-teams N:codex "task"` or `/omc-teams N:gemini "task"` — spawns CLI processes in tmux panes via `bridge/runtime-cli.cjs`
-- omc-teams MCP tools: `mcp__team__omc_run_team_start`, `mcp__team__omc_run_team_wait`, `mcp__team__omc_run_team_status`, `mcp__team__omc_run_team_cleanup`
-
-OMC State:
-- `state_read`, `state_write`, `state_clear`, `state_list_active`, `state_get_status`
-- State stored at `{worktree}/.omc/state/{mode}-state.json` (not in `~/.claude/`)
-- Session-scoped state: `.omc/state/sessions/{sessionId}/` when session id is available; legacy `.omc/state/{mode}-state.json` as fallback
-- Supported modes: autopilot, ultrapilot, team, pipeline, ralph, ultrawork, ultraqa
-
-Team Coordination (Claude Code native):
-- `TeamCreate`, `TeamDelete`, `SendMessage`, `TaskCreate`, `TaskList`, `TaskGet`, `TaskUpdate`
-- Lifecycle: `TeamCreate` -> `TaskCreate` x N -> `Task(team_name, name)` x N to spawn teammates -> teammates claim/complete tasks -> `SendMessage(shutdown_request)` -> `TeamDelete`
-
-Notepad (session memory at `{worktree}/.omc/notepad.md`):
-- `notepad_read` (sections: all/priority/working/manual)
-- `notepad_write_priority` (max 500 chars, loaded at session start)
-- `notepad_write_working` (timestamped, auto-pruned after 7 days)
-- `notepad_write_manual` (permanent, never auto-pruned)
-- `notepad_prune`, `notepad_stats`
-
-Project Memory (persistent at `{worktree}/.omc/project-memory.json`):
-- `project_memory_read` (sections: techStack/build/conventions/structure/notes/directives)
-- `project_memory_write` (supports merge)
-- `project_memory_add_note`, `project_memory_add_directive`
+Team Coordination: `TeamCreate`, `TeamDelete`, `SendMessage`, `TaskCreate`, `TaskList`, `TaskGet`, `TaskUpdate`
+
+Notepad (`{worktree}/.omc/notepad.md`): `notepad_read`, `notepad_write_priority`, `notepad_write_working`, `notepad_write_manual`, `notepad_prune`, `notepad_stats`
+
+Project Memory (`{worktree}/.omc/project-memory.json`): `project_memory_read`, `project_memory_write`, `project_memory_add_note`, `project_memory_add_directive`
 
 Code Intelligence:
+
 - LSP: `lsp_hover`, `lsp_goto_definition`, `lsp_find_references`, `lsp_document_symbols`, `lsp_workspace_symbols`, `lsp_diagnostics`, `lsp_diagnostics_directory`, `lsp_prepare_rename`, `lsp_rename`, `lsp_code_actions`, `lsp_code_action_resolve`, `lsp_servers`
-- AST: `ast_grep_search` (structural code pattern search), `ast_grep_replace` (structural transformation)
+- AST: `ast_grep_search`, `ast_grep_replace`
 - `python_repl`: persistent Python REPL for data analysis
-</tools>
-
----
+  </tools>
 
 <passive-behaviors>
 These behaviors apply unconditionally — no skill invocation required:
@@ -134,175 +100,85 @@ These behaviors apply unconditionally — no skill invocation required:
 - project has AGENTS.md files → read them as authoritative passive context before any codebase work
 </passive-behaviors>
 
-<skills>
-Trigger words below fire deterministically — no deliberation about whether to invoke. The summaries below are sufficient for direct execution; invoke the Skill tool for full protocol detail when needed.
-
-**Core Workflow Skills (inline summaries):**
-
-`autopilot` ("autopilot", "build me", "I want a"):
-  Expansion: analyst+architect expand idea into spec → Planning: planner+critic create plan → Execution: ultrawork implements → QA: ultraqa cycles → Validation: verifier+security-reviewer validate. Invoke skill for full 6-phase protocol.
-
-`ralph` ("ralph", "don't stop", "must complete"):
-  Persistent loop: execute task → verifier checks completeness → if incomplete, identify gaps, fix, retry. Never stops until verifier confirms complete. Includes ultrawork for parallelism. Invoke skill for loop configuration.
-
-`team` ("team", "coordinated team", "team ralph"):
-  Pipeline: team-plan (explore+planner) → team-prd (analyst) → team-exec (executor+specialists) → team-verify (verifier+reviewers) → team-fix (loop). TeamCreate → TaskCreate×N → spawn agents → claim tasks → shutdown → TeamDelete. Invoke skill for full stage protocol.
-
-`plan` ("plan this", "plan the"):
-  EnterPlanMode → explore codebase with Glob/Grep/Read → design approach → AskUserQuestion if ambiguous → ExitPlanMode for approval. `--consensus`: Planner+Architect+Critic iterate until agreement. Invoke skill for full protocol.
+Workflow:
 
-`ultrawork` ("ulw", "ultrawork"):
-  Maximum parallelism: decompose into independent subtasks, spawn 3-10 executor agents simultaneously with run_in_background. Invoke skill for task decomposition protocol.
-
-**Other Workflow Skills:**
-- `swarm` ("swarm"): **deprecated compatibility alias** over Team; use `/team` (still routes to Team staged pipeline for now)
-- `ultrapilot` ("ultrapilot", "parallel build"): compatibility facade over Team; maps onto Team's staged runtime
-- `pipeline` ("pipeline", "chain agents"): sequential agent chaining with data passing
+- `autopilot` ("autopilot", "build me", "I want a"): full autonomous execution from idea to working code
+- `ralph` ("ralph", "don't stop", "must complete"): self-referential loop with verifier verification; includes ultrawork
+- `ultrawork` ("ulw", "ultrawork"): maximum parallelism with parallel agent orchestration
+- `team` ("team", "coordinated team", "team ralph"): N coordinated Claude agents with stage-aware routing; `team ralph` for persistent team execution
+- `ccg` ("ccg", "tri-model", "claude codex gemini"): fan out via `ask-codex` + `ask-gemini`, then Claude synthesizes
 - `ultraqa` (activated by autopilot): QA cycling -- test, verify, fix, repeat
-- `ralplan` ("ralplan", "consensus plan"): alias for `/plan --consensus` -- iterative planning with Planner, Architect, Critic until consensus
+- `omc-plan` (manual command): strategic planning; supports `--consensus` and `--review`
+- `ralplan` ("ralplan", "consensus plan"): alias for `/omc-plan --consensus` -- iterative planning with Planner, Architect, Critic until consensus; short deliberation by default, `--deliberate` for high-risk work (adds pre-mortem + expanded unit/integration/e2e/observability test planning)
 - `sciomc` ("sciomc"): parallel scientist agents for comprehensive analysis
-- `external-context`: invoke parallel document-specialist agents for web searches
+- `external-context`: parallel document-specialist agents for web searches
 - `deepinit` ("deepinit"): deep codebase init with hierarchical AGENTS.md
 
-Agent Shortcuts (thin wrappers; call the agent directly with `model` for more control):
+Agent Shortcuts (thin wrappers):
+
 - `analyze` -> `debugger`: "analyze", "debug", "investigate"
 - `tdd` -> `test-engineer`: "tdd", "test first", "red green"
 - `build-fix` -> `build-fixer`: "fix build", "type errors"
 - `code-review` -> `code-reviewer`: "review code"
 - `security-review` -> `security-reviewer`: "security review"
-- `review` -> `plan --review`: "review plan", "critique plan"
+- `review` -> `omc-plan --review`: "review plan", "critique plan"
 
-Notifications: `configure-notifications` ("configure discord", "setup discord", "discord webhook", "configure telegram", "setup telegram", "telegram bot", "configure slack", "setup slack")
+Notifications: `configure-notifications` ("configure discord", "setup telegram", "configure slack")
+Utilities: `ask-codex`, `ask-gemini`, `cancel`, `note`, `learner`, `omc-setup`, `mcp-setup`, `hud`, `omc-doctor`, `omc-help`, `trace`, `release`, `project-session-manager`, `skill`, `writer-memory`, `ralph-init`, `learn-about-omc`
 
-Utilities: `cancel`, `note`, `learner`, `omc-setup`, `mcp-setup`, `hud`, `omc-doctor`, `omc-help`, `trace`, `release`, `project-session-manager` (`psm` is deprecated alias), `skill`, `writer-memory`, `ralph-init`, `learn-about-omc`
-
-Conflict resolution: explicit mode keywords (`ulw`, `ultrawork`) override defaults. Generic "fast"/"parallel" reads `~/.claude/.omc-config.json` -> `defaultExecutionMode`. Ralph includes ultrawork (persistence wrapper). Autopilot can transition to ralph or ultraqa. Autopilot and ultrapilot are mutually exclusive. Keyword disambiguation: bare "codex" or "gemini" routes to `omc-teams`; the full phrase "claude codex gemini" routes to `ccg` (longest-match priority).
+Disambiguation: prompts like "ask/use/delegate to codex|gemini" -> `ask-codex` / `ask-gemini`; "claude codex gemini" -> ccg.
 </skills>
 
----
-
-<team_compositions>
-Common agent workflows for typical scenarios:
-
-Feature Development:
-  `analyst` -> `planner` -> `executor` -> `test-engineer` -> `quality-reviewer` -> `verifier`
-
-Bug Investigation:
-  `explore` + `debugger` + `executor` + `test-engineer` + `verifier`
-
-Code Review:
-  `quality-reviewer` + `security-reviewer` + `code-reviewer`
-</team_compositions>
-
 <team_pipeline>
-Team is the default multi-agent orchestrator. It uses a canonical staged pipeline:
+Team is the default multi-agent orchestrator: `team-plan -> team-prd -> team-exec -> team-verify -> team-fix (loop)`
 
-`team-plan -> team-prd -> team-exec -> team-verify -> team-fix (loop)`
+Stage routing:
 
-Stage Agent Routing (each stage uses specialized agents, not just executors):
-- `team-plan`: `explore` (haiku) + `planner` (opus), optionally `analyst`/`architect`
-- `team-prd`: `analyst` (opus), optionally `critic`
-- `team-exec`: `executor` (sonnet) + task-appropriate specialists (`designer`, `build-fixer`, `writer`, `test-engineer`, `deep-executor`)
-- `team-verify`: `verifier` (sonnet) + `security-reviewer`/`code-reviewer`/`quality-reviewer` as needed
+- `team-plan`: `explore` + `planner`, optionally `analyst`/`architect`
+- `team-prd`: `analyst`, optionally `critic`
+- `team-exec`: `executor` + specialists (`designer`, `build-fixer`, `writer`, `test-engineer`, `deep-executor`)
+- `team-verify`: `verifier` + reviewers as needed
 - `team-fix`: `executor`/`build-fixer`/`debugger` depending on defect type
 
-Stage transitions:
-- `team-plan` -> `team-prd`: planning/decomposition complete
-- `team-prd` -> `team-exec`: acceptance criteria and scope are explicit
-- `team-exec` -> `team-verify`: all execution tasks reach terminal states
-- `team-verify` -> `team-fix` | `complete` | `failed`: verification decides next step
-- `team-fix` -> `team-exec` | `team-verify` | `complete` | `failed`: fixes feed back into execution, re-verify, or terminate
-
-The `team-fix` loop is bounded by max attempts; exceeding the bound transitions to `failed`.
-
-Terminal states: `complete`, `failed`, `cancelled`.
-
-State persistence: Team writes state via `state_write(mode="team")` tracking `current_phase`, `team_name`, `fix_loop_count`, `linked_ralph`, and `stage_history`. Read with `state_read(mode="team")`.
-
-Resume: detect existing team state and resume from the last incomplete stage using staged state + live task status.
-
-Cancel: `/oh-my-claudecode:cancel` requests teammate shutdown, marks phase `cancelled` with `active=false`, records cancellation metadata, and runs cleanup. If linked to ralph, both modes are cancelled together.
-
-Team + Ralph composition: When both `team` and `ralph` keywords are detected (e.g., `/team ralph "task"`), team provides multi-agent orchestration while ralph provides the persistence loop. Both write linked state files (`linked_team`/`linked_ralph`). Cancel either mode cancels both.
+Fix loop bounded by max attempts. Terminal states: `complete`, `failed`, `cancelled`.
+`team ralph` links both modes; cancelling either cancels both.
 </team_pipeline>
 
----
-
 <verification>
-Verify before claiming completion. The goal is evidence-backed confidence, not ceremony.
-
-Sizing guidance:
-- Small changes (<5 files, <100 lines): `verifier` with `model="haiku"`
-- Standard changes: `verifier` with `model="sonnet"`
-- Large or security/architectural changes (>20 files): `verifier` with `model="opus"`
-
-Verification loop: identify what proves the claim, run the verification, read the output, then report with evidence. If verification fails, continue iterating rather than reporting incomplete work.
+Verify before claiming completion. Sizing: small (<5 files) -> `verifier` haiku; standard -> sonnet; large/security -> opus.
+Loop: identify proof, run verification, read output, report with evidence. If verification fails, keep iterating.
 </verification>
 
 <execution_protocols>
-Broad Request Detection:
-  A request is broad when it uses vague verbs without targets, names no specific file or function, touches 3+ areas, or is a single sentence without a clear deliverable. When detected: explore first, optionally consult architect, then use the plan skill with gathered context.
-
-Parallelization:
-- Run 2+ independent tasks in parallel when each takes >30s.
-- Run dependent tasks sequentially.
-- Use `run_in_background: true` for installs, builds, and tests (up to 20 concurrent).
-- Prefer Team mode as the primary parallel execution surface. Use ad hoc parallelism (`run_in_background`) only when Team overhead is disproportionate to the task.
-
-Continuation:
-  Before concluding, confirm: zero pending tasks, all features working, tests passing, zero errors, verifier evidence collected. If any item is unchecked, continue working.
+Broad requests (vague verbs, no file/function targets, 3+ areas): explore first, then use plan skill.
+Parallelization: 2+ independent tasks in parallel; Team mode preferred; `run_in_background` for builds/tests.
+Continuation: before concluding, confirm zero pending tasks, tests passing, zero errors, verifier evidence collected.
 </execution_protocols>
 
----
-
 <hooks_and_context>
-Hooks inject context via `<system-reminder>` tags. Recognize these patterns:
+Hooks inject context via `<system-reminder>` tags:
+
 - `hook success: Success` -- proceed normally
-- `hook additional context: ...` -- read it; the content is relevant to your current task
+- `hook additional context: ...` -- read it; relevant to your task
 - `[MAGIC KEYWORD: ...]` -- invoke the indicated skill immediately
-- `The boulder never stops` -- you are in ralph/ultrawork mode; keep working
-
-Context Persistence:
-  Use `<remember>info</remember>` to persist information for 7 days, or `<remember priority>info</remember>` for permanent persistence.
+- `The boulder never stops` -- ralph/ultrawork mode; keep working
 
-Hook Runtime Guarantees:
-- Hook input uses snake_case fields: `tool_name`, `tool_input`, `tool_response`, `session_id`, `cwd`, `hook_event_name`
-- Kill switches: `DISABLE_OMC` (disable all hooks), `OMC_SKIP_HOOKS` (skip specific hooks by comma-separated name)
-- Sensitive hook fields (permission-request, setup, session-end) filtered via strict allowlist in bridge-normalize; unknown fields are dropped
-- Required key validation per hook event type (e.g. session-end requires `sessionId`, `directory`)
+Persistence: `<remember>info</remember>` (7 days), `<remember priority>info</remember>` (permanent).
+Kill switches: `DISABLE_OMC` (all hooks), `OMC_SKIP_HOOKS` (comma-separated).
 </hooks_and_context>
 
 <cancellation>
-Hooks cannot read your responses -- they only check state files. You need to invoke `/oh-my-claudecode:cancel` to end execution modes. Use `--force` to clear all state files.
-
-When to cancel:
-- All tasks are done and verified: invoke cancel.
-- Work is blocked: explain the blocker, then invoke cancel.
-- User says "stop": invoke cancel immediately.
-
-When not to cancel:
-- A stop hook fires but work is still incomplete: continue working.
+Invoke `/oh-my-claudecode:cancel` to end execution modes (`--force` to clear all state).
+Cancel when: tasks done and verified, work blocked (explain first), user says "stop".
+Do not cancel when: stop hook fires but work is still incomplete.
 </cancellation>
 
----
-
 <worktree_paths>
-All OMC state lives under the git worktree root, not in `~/.claude/`.
-
-- `{worktree}/.omc/state/` -- mode state files
-- `{worktree}/.omc/state/sessions/{sessionId}/` -- session-scoped state
-- `{worktree}/.omc/notepad.md` -- session notepad
-- `{worktree}/.omc/project-memory.json` -- project memory
-- `{worktree}/.omc/plans/` -- planning documents
-- `{worktree}/.omc/research/` -- research outputs
-- `{worktree}/.omc/logs/` -- audit logs
+All OMC state lives under git worktree root: `.omc/state/` (mode state), `.omc/state/sessions/{sessionId}/` (session state), `.omc/notepad.md`, `.omc/project-memory.json`, `.omc/plans/`, `.omc/research/`, `.omc/logs/`.
 </worktree_paths>
 
----
-
 ## Setup
 
-Say "setup omc" or run `/oh-my-claudecode:omc-setup`. Everything is automatic after that.
+Say "setup omc" or run `/oh-my-claudecode:omc-setup`. Announce major behavior activations to keep users informed.
 
-Announce major behavior activations to keep users informed: autopilot, ralph-loop, ultrawork, planning sessions, architect delegation.
 <!-- OMC:END -->