claudecode-omc 4.5.7 → 4.7.4

package/skills/ralph/SKILL.md

@@ -8,14 +8,14 @@ description: Self-referential loop until task completion with architect verifica
 Your previous attempt did not output the completion promise. Continue working on the task.
 
 <Purpose>
-Ralph is a persistence loop that keeps working on a task until it is fully complete and architect-verified. It wraps ultrawork's parallel execution with session persistence, automatic retry on failure, and mandatory verification before completion.
+Ralph is a PRD-driven persistence loop that keeps working on a task until ALL user stories in prd.json have passes: true and are architect-verified. It wraps ultrawork's parallel execution with session persistence, automatic retry on failure, structured story tracking, and mandatory verification before completion.
 </Purpose>
 
 <Use_When>
 - Task requires guaranteed completion with verification (not just "do your best")
 - User says "ralph", "don't stop", "must complete", "finish this", or "keep going until done"
 - Work may span multiple iterations and needs persistence across retries
-- Task benefits from parallel execution with architect sign-off at the end
+- Task benefits from structured PRD-driven execution with architect sign-off
 </Use_When>
 
 <Do_Not_Use_When>
@@ -26,9 +26,19 @@ Ralph is a persistence loop that keeps working on a task until it is fully compl
 </Do_Not_Use_When>
 
 <Why_This_Exists>
-Complex tasks often fail silently: partial implementations get declared "done", tests get skipped, edge cases get forgotten. Ralph prevents this by looping until work is genuinely complete, requiring fresh verification evidence before allowing completion, and using tiered architect review to confirm quality.
+Complex tasks often fail silently: partial implementations get declared "done", tests get skipped, edge cases get forgotten. Ralph prevents this by:
+1. Structuring work into discrete user stories with testable acceptance criteria (prd.json)
+2. Iterating story-by-story until each one passes
+3. Tracking progress and learnings across iterations (progress.txt)
+4. Requiring fresh architect verification against specific acceptance criteria before completion
 </Why_This_Exists>
 
+<PRD_Mode>
+By default, ralph operates in PRD mode. A scaffold `prd.json` is auto-generated when ralph starts if none exists.
+
+**Opt-out:** If `{{PROMPT}}` contains `--no-prd`, skip PRD generation and work in legacy mode (no story tracking, generic verification). Use this for trivial quick fixes.
+</PRD_Mode>
+
 <Execution_Policy>
 - Fire independent agent calls simultaneously -- never wait sequentially for independent work
 - Use `run_in_background: true` for long operations (installs, builds, test suites)
@@ -38,25 +48,52 @@ Complex tasks often fail silently: partial implementations get declared "done",
 </Execution_Policy>
 
 <Steps>
-1. **Review progress**: Check TODO list and any prior iteration state
-2. **Continue from where you left off**: Pick up incomplete tasks
-3. **Delegate in parallel**: Route tasks to specialist agents at appropriate tiers
-   - Simple lookups: LOW tier (Haiku) -- "What does this function return?"
-   - Standard work: MEDIUM tier (Sonnet) -- "Add error handling to this module"
-   - Complex analysis: HIGH tier (Opus) -- "Debug this race condition"
-4. **Run long operations in background**: Builds, installs, test suites use `run_in_background: true`
-5. **Verify completion with fresh evidence**:
-   a. Identify what command proves the task is complete
-   b. Run verification (test, build, lint)
-   c. Read the output -- confirm it actually passed
-   d. Check: zero pending/in_progress TODO items
-6. **Architect verification** (tiered):
+1. **PRD Setup** (first iteration only):
+   a. Check if `prd.json` exists (in project root or `.omc/`). If it already exists, read it and proceed to Step 2.
+   b. If no `prd.json` exists, the system has auto-generated a scaffold. Read `.omc/prd.json`.
+   c. **CRITICAL: Refine the scaffold.** The auto-generated PRD has generic acceptance criteria ("Implementation is complete", etc.). You MUST replace these with task-specific criteria:
+      - Analyze the original task and break it into right-sized user stories (each completable in one iteration)
+      - Write concrete, verifiable acceptance criteria for each story (e.g., "Function X returns Y when given Z", "Test file exists at path P and passes")
+      - If acceptance criteria are generic (e.g., "Implementation is complete"), REPLACE them with task-specific criteria before proceeding
+      - Order stories by priority (foundational work first, dependent work later)
+      - Write the refined `prd.json` back to disk
+   d. Initialize `progress.txt` if it doesn't exist
+
+2. **Pick next story**: Read `prd.json` and select the highest-priority story with `passes: false`. This is your current focus.
+
+3. **Implement the current story**:
+   - Delegate to specialist agents at appropriate tiers:
+     - Simple lookups: LOW tier (Haiku) -- "What does this function return?"
+     - Standard work: MEDIUM tier (Sonnet) -- "Add error handling to this module"
+     - Complex analysis: HIGH tier (Opus) -- "Debug this race condition"
+   - If during implementation you discover sub-tasks, add them as new stories to `prd.json`
+   - Run long operations in background: Builds, installs, test suites use `run_in_background: true`
+
+4. **Verify the current story's acceptance criteria**:
+   a. For EACH acceptance criterion in the story, verify it is met with fresh evidence
+   b. Run relevant checks (test, build, lint, typecheck) and read the output
+   c. If any criterion is NOT met, continue working -- do NOT mark the story as complete
+
+5. **Mark story complete**:
+   a. When ALL acceptance criteria are verified, set `passes: true` for this story in `prd.json`
+   b. Record progress in `progress.txt`: what was implemented, files changed, learnings for future iterations
+   c. Add any discovered codebase patterns to `progress.txt`
+
+6. **Check PRD completion**:
+   a. Read `prd.json` -- are ALL stories marked `passes: true`?
+   b. If NOT all complete, loop back to Step 2 (pick next story)
+   c. If ALL complete, proceed to Step 7 (architect verification)
+
+7. **Architect verification** (tiered, against acceptance criteria):
    - <5 files, <100 lines with full tests: STANDARD tier minimum (architect-medium / Sonnet)
    - Standard changes: STANDARD tier (architect-medium / Sonnet)
    - >20 files or security/architectural changes: THOROUGH tier (architect / Opus)
    - Ralph floor: always at least STANDARD, even for small changes
-7. **On approval**: Run `/oh-my-claudecode:cancel` to cleanly exit and clean up all state files
-8. **On rejection**: Fix the issues raised, then re-verify at the same tier
+   - The architect verifies against the SPECIFIC acceptance criteria from prd.json, not vague "is it done?"
+
+8. **On approval**: Run `/oh-my-claudecode:cancel` to cleanly exit and clean up all state files
+
+9. **On rejection**: Fix the issues raised, re-verify at the same tier, then loop back to check if the story needs to be marked incomplete
 </Steps>
 
 <Tool_Usage>
@@ -67,43 +104,67 @@ Complex tasks often fail silently: partial implementations get declared "done",
 </Tool_Usage>
 
 <Examples>
+<Good>
+PRD refinement in Step 1:
+```
+Auto-generated scaffold has:
+  acceptanceCriteria: ["Implementation is complete", "Code compiles without errors"]
+
+After refinement:
+  acceptanceCriteria: [
+    "detectNoPrdFlag('ralph --no-prd fix') returns true",
+    "detectNoPrdFlag('ralph fix this') returns false",
+    "stripNoPrdFlag removes --no-prd and trims whitespace",
+    "TypeScript compiles with no errors (npm run build)"
+  ]
+```
+Why good: Generic criteria replaced with specific, testable criteria.
+</Good>
+
 <Good>
 Correct parallel delegation:
 ```
-Task(subagent_type="oh-my-claudecode:executor-low", model="haiku", prompt="Add type export for UserConfig")
+Task(subagent_type="oh-my-claudecode:executor", model="haiku", prompt="Add type export for UserConfig")
 Task(subagent_type="oh-my-claudecode:executor", model="sonnet", prompt="Implement the caching layer for API responses")
-Task(subagent_type="oh-my-claudecode:executor-high", model="opus", prompt="Refactor auth module to support OAuth2 flow")
+Task(subagent_type="oh-my-claudecode:executor", model="opus", prompt="Refactor auth module to support OAuth2 flow")
 ```
 Why good: Three independent tasks fired simultaneously at appropriate tiers.
 </Good>
 
 <Good>
-Correct verification before completion:
+Story-by-story verification:
 ```
-1. Run: npm test           → Output: "42 passed, 0 failed"
-2. Run: npm run build      → Output: "Build succeeded"
-3. Run: lsp_diagnostics    → Output: 0 errors
-4. Spawn architect-medium  → Verdict: "APPROVED"
-5. Run /oh-my-claudecode:cancel
+1. Story US-001: "Add flag detection helpers"
+   - Criterion: "detectNoPrdFlag returns true for --no-prd" → Run test → PASS
+   - Criterion: "TypeScript compiles" → Run build → PASS
+   - Mark US-001 passes: true
+2. Story US-002: "Wire PRD into bridge.ts"
+   - Continue to next story...
 ```
-Why good: Fresh evidence at each step, architect verification, then clean exit.
+Why good: Each story verified against its own acceptance criteria before marking complete.
 </Good>
 
 <Bad>
-Claiming completion without verification:
+Claiming completion without PRD verification:
 "All the changes look good, the implementation should work correctly. Task complete."
-Why bad: Uses "should" and "look good" -- no fresh test/build output, no architect verification.
+Why bad: Uses "should" and "look good" -- no fresh evidence, no story-by-story verification, no architect review.
 </Bad>
 
 <Bad>
 Sequential execution of independent tasks:
 ```
-Task(executor-low, "Add type export") → wait →
+Task(executor, "Add type export") → wait →
 Task(executor, "Implement caching") → wait →
-Task(executor-high, "Refactor auth")
+Task(executor, "Refactor auth")
 ```
 Why bad: These are independent tasks that should run in parallel, not sequentially.
 </Bad>
+
+<Bad>
+Keeping generic acceptance criteria:
+"prd.json created with criteria: Implementation is complete, Code compiles. Moving on to coding."
+Why bad: Did not refine scaffold criteria into task-specific ones. This is PRD theater.
+</Bad>
 </Examples>
 
 <Escalation_And_Stop_Conditions>
@@ -115,54 +176,19 @@ Why bad: These are independent tasks that should run in parallel, not sequential
 </Escalation_And_Stop_Conditions>
 
 <Final_Checklist>
+- [ ] All prd.json stories have `passes: true` (no incomplete stories)
+- [ ] prd.json acceptance criteria are task-specific (not generic boilerplate)
 - [ ] All requirements from the original task are met (no scope reduction)
 - [ ] Zero pending or in_progress TODO items
 - [ ] Fresh test run output shows all tests pass
 - [ ] Fresh build output shows success
 - [ ] lsp_diagnostics shows 0 errors on affected files
-- [ ] Architect verification passed (STANDARD tier minimum)
+- [ ] progress.txt records implementation details and learnings
+- [ ] Architect verification passed (STANDARD tier minimum) against specific acceptance criteria
 - [ ] `/oh-my-claudecode:cancel` run for clean state cleanup
 </Final_Checklist>
 
 <Advanced>
-## PRD Mode (Optional)
-
-When the user provides the `--prd` flag, initialize a Product Requirements Document before starting the ralph loop.
-
-### Detecting PRD Mode
-Check if `{{PROMPT}}` contains `--prd` or `--PRD`.
-
-### PRD Workflow
-1. Create `.omc/prd.json` and `.omc/progress.txt`
-2. Parse the task (everything after `--prd` flag)
-3. Break down into user stories:
-
-```json
-{
-  "project": "[Project Name]",
-  "branchName": "ralph/[feature-name]",
-  "description": "[Feature description]",
-  "userStories": [
-    {
-      "id": "US-001",
-      "title": "[Short title]",
-      "description": "As a [user], I want to [action] so that [benefit].",
-      "acceptanceCriteria": ["Criterion 1", "Typecheck passes"],
-      "priority": 1,
-      "passes": false
-    }
-  ]
-}
-```
-
-4. Create `progress.txt` with timestamp and empty patterns section
-5. Guidelines: right-sized stories (one session each), verifiable criteria, independent stories, priority order (foundational work first)
-6. Proceed to normal ralph loop using user stories as the task list
-
-### Example
-User input: `--prd build a todo app with React and TypeScript`
-Workflow: Detect flag, extract task, create `.omc/prd.json`, create `.omc/progress.txt`, begin ralph loop.
-
 ## Background Execution Rules
 
 **Run in background** (`run_in_background: true`):

package/skills/ralplan/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: ralplan
-description: Alias for /plan --consensus
+description: Alias for /omc-plan --consensus
 ---
 
 # Ralplan (Consensus Planning Alias)
 
-Ralplan is a shorthand alias for `/oh-my-claudecode:plan --consensus`. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).
+Ralplan is a shorthand alias for `/oh-my-claudecode:omc-plan --consensus`. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).
 
 ## Usage
 
@@ -29,7 +29,7 @@ Ralplan is a shorthand alias for `/oh-my-claudecode:plan --consensus`. It trigge
 This skill invokes the Plan skill in consensus mode:
 
 ```
-/oh-my-claudecode:plan --consensus <arguments>
+/oh-my-claudecode:omc-plan --consensus <arguments>
 ```
 
 The consensus workflow:
@@ -49,9 +49,9 @@ The consensus workflow:
    d. Return to Critic evaluation
    e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached
    f. If 5 iterations are reached without `APPROVE`, present the best version to the user
-6. On Critic approval *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options (Approve and execute via ralph / Approve and implement via team / Clear context and implement / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop.
-7. *(--interactive only)* User chooses: Approve (ralph or team), Request changes, or Reject
-8. *(--interactive only)* On approval: invoke `Skill("oh-my-claudecode:ralph")` for sequential execution or `Skill("oh-my-claudecode:team")` for parallel team execution -- never implement directly
+6. On Critic approval *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options (Approve and implement via team (Recommended) / Approve and execute via ralph / Clear context and implement / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop.
+7. *(--interactive only)* User chooses: Approve (team or ralph), Request changes, or Reject
+8. *(--interactive only)* On approval: invoke `Skill("oh-my-claudecode:team")` for parallel team execution (recommended) or `Skill("oh-my-claudecode:ralph")` for sequential execution -- never implement directly
 
 > **Important:** Steps 3 and 4 MUST run sequentially. Do NOT issue both agent Task calls in the same parallel batch. Always await the Architect result before issuing the Critic Task.
 
@@ -117,8 +117,8 @@ The gate auto-passes when it detects **any** concrete signal. You do not need al
    - **Architect** reviews for soundness
    - **Critic** validates quality and testability
 5. On consensus approval, user chooses execution path:
+   - **team**: parallel coordinated agents (recommended)
    - **ralph**: sequential execution with verification
-   - **team**: parallel coordinated agents
 6. Execution begins with a clear, bounded plan
 
 ### Troubleshooting

package/skills/security-review/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: security-review
+name: omc-security-review
 description: Run a comprehensive security review on code
 ---
 
@@ -258,7 +258,7 @@ The security-reviewer agent verifies:
 ```
 /pipeline security "review authentication module"
 ```
-Uses: explore → security-reviewer → executor → security-reviewer-low (re-verify)
+Uses: explore → security-reviewer → executor → security-reviewer (re-verify)
 
 **With Swarm:**
 ```

package/skills/team/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: team
 description: N coordinated agents on shared task list using Claude Code native teams
-aliases: [swarm]
+aliases: []
 ---
 
 # Team Skill
 
 Spawn N coordinated agents working on a shared task list using Claude Code's native team tools. Replaces the legacy `/swarm` skill (SQLite-based) with built-in team management, inter-agent messaging, and task dependencies -- no external dependencies required.
 
-`swarm` is the compatibility alias for this canonical skill entrypoint.
+The `swarm` compatibility alias was removed in #1131.
 
 ## Usage
 
@@ -439,6 +439,7 @@ When spawning teammates, include this preamble in the prompt to establish the wo
 ```
 You are a TEAM WORKER in team "{team_name}". Your name is "{worker_name}".
 You report to the team lead ("team-lead").
+You are not the leader and must not perform leader orchestration actions.
 
 == WORK PROTOCOL ==
 
@@ -474,11 +475,23 @@ Do NOT mark the task as completed. Leave it in_progress so the lead can reassign
 
 == RULES ==
 - NEVER spawn sub-agents or use the Task tool
+- NEVER run tmux pane/session orchestration commands (for example `tmux split-window`, `tmux new-session`)
+- NEVER run team spawning/orchestration skills or commands (for example `$team`, `$ultrawork`, `$autopilot`, `$ralph`, `omc team ...`, `omx team ...`)
 - ALWAYS use absolute file paths
 - ALWAYS report progress via SendMessage to "team-lead"
 - Use SendMessage with type "message" only -- never "broadcast"
 ```
 
+### Agent-Type Prompt Injection (Worker-Specific Addendum)
+
+When composing teammate prompts, append a short addendum based on worker type:
+
+- `claude_worker`: Emphasize strict TaskList/TaskUpdate/SendMessage loop and no orchestration commands.
+- `codex_worker`: Emphasize CLI API lifecycle (`omc team api ... --json`) and explicit failure ACKs with stderr.
+- `gemini_worker`: Emphasize bounded file ownership and milestone ACKs after each completed sub-step.
+
+This addendum must preserve the core rule: **worker = executor only, never leader/orchestrator**.
+
 ## Communication Patterns
 
 ### Teammate to Lead (task completion report)
@@ -834,6 +847,27 @@ When team is linked to ralph, cancellation follows dependency order:
 
 If teammates are unresponsive, `TeamDelete` may fail. In that case, the cancel skill should wait briefly and retry, or inform the user to manually clean up `~/.claude/teams/{team_name}/` and `~/.claude/tasks/{team_name}/`.
 
+## Runtime V2 (Event-Driven)
+
+When `OMC_RUNTIME_V2=1` is set, the team runtime uses an event-driven architecture instead of the legacy done.json polling watchdog:
+
+- **No done.json**: Task completion is detected via CLI API lifecycle transitions (claim-task, transition-task-status)
+- **Snapshot-based monitoring**: Each poll cycle takes a point-in-time snapshot of tasks and workers, computes deltas, and emits events
+- **Event log**: All team events are appended to `.omc/state/team/{teamName}/events.jsonl`
+- **Worker status files**: Workers write status to `.omc/state/team/{teamName}/workers/{name}/status.json`
+- **Preserved**: Sentinel gate (blocks premature completion), circuit breaker (dead worker detection), failure sidecars
+
+The v2 runtime is feature-flagged and can be enabled per-session. The legacy v1 runtime remains the default.
+
+## Dynamic Scaling
+
+When `OMC_TEAM_SCALING_ENABLED=1` is set, the team supports mid-session scaling:
+
+- **scale_up**: Add workers to a running team (respects max_workers limit)
+- **scale_down**: Remove idle workers with graceful drain (workers finish current task before removal)
+- File-based scaling lock prevents concurrent scale operations
+- Monotonic worker index counter ensures unique worker names across scale events
+
 ## Configuration
 
 Optional settings via `.omc-config.json`:

package/skills/ultrawork/SKILL.md

@@ -50,9 +50,9 @@ Sequential task execution wastes time when tasks are independent. Ultrawork enab
 </Steps>
 
 <Tool_Usage>
-- Use `Task(subagent_type="oh-my-claudecode:executor-low", model="haiku", ...)` for simple changes
+- Use `Task(subagent_type="oh-my-claudecode:executor", model="haiku", ...)` for simple changes
 - Use `Task(subagent_type="oh-my-claudecode:executor", model="sonnet", ...)` for standard work
-- Use `Task(subagent_type="oh-my-claudecode:executor-high", model="opus", ...)` for complex work
+- Use `Task(subagent_type="oh-my-claudecode:executor", model="opus", ...)` for complex work
 - Use `run_in_background: true` for package installs, builds, and test suites
 - Use foreground execution for quick status checks and file operations
 </Tool_Usage>
@@ -61,7 +61,7 @@ Sequential task execution wastes time when tasks are independent. Ultrawork enab
 <Good>
 Three independent tasks fired simultaneously:
 ```
-Task(subagent_type="oh-my-claudecode:executor-low", model="haiku", prompt="Add missing type export for Config interface")
+Task(subagent_type="oh-my-claudecode:executor", model="haiku", prompt="Add missing type export for Config interface")
 Task(subagent_type="oh-my-claudecode:executor", model="sonnet", prompt="Implement the /api/users endpoint with validation")
 Task(subagent_type="oh-my-claudecode:executor", model="sonnet", prompt="Add integration tests for the auth middleware")
 ```
@@ -72,7 +72,7 @@ Why good: Independent tasks at appropriate tiers, all fired at once.
 Correct use of background execution:
 ```
 Task(subagent_type="oh-my-claudecode:executor", model="sonnet", prompt="npm install && npm run build", run_in_background=true)
-Task(subagent_type="oh-my-claudecode:executor-low", model="haiku", prompt="Update the README with new API endpoints")
+Task(subagent_type="oh-my-claudecode:executor", model="haiku", prompt="Update the README with new API endpoints")
 ```
 Why good: Long build runs in background while short task runs in foreground.
 </Good>
@@ -80,7 +80,7 @@ Why good: Long build runs in background while short task runs in foreground.
 <Bad>
 Sequential execution of independent work:
 ```
-result1 = Task(executor-low, "Add type export")  # wait...
+result1 = Task(executor, "Add type export")  # wait...
 result2 = Task(executor, "Implement endpoint")     # wait...
 result3 = Task(executor, "Add tests")              # wait...
 ```
@@ -90,9 +90,9 @@ Why bad: These tasks are independent. Running them sequentially wastes time.
 <Bad>
 Wrong tier selection:
 ```
-Task(subagent_type="oh-my-claudecode:executor-high", model="opus", prompt="Add a missing semicolon")
+Task(subagent_type="oh-my-claudecode:executor", model="opus", prompt="Add a missing semicolon")
 ```
-Why bad: Opus is expensive overkill for a trivial fix. Use executor-low with Haiku instead.
+Why bad: Opus is expensive overkill for a trivial fix. Use executor with Haiku instead.
 </Bad>
 </Examples>
 

package/templates/hooks/keyword-detector.mjs

@@ -226,21 +226,10 @@ function resolveConflicts(matches) {
 
   let resolved = [...matches];
 
-  // Team beats autopilot (legacy ultrapilot semantics)
-  if (names.includes('team') && names.includes('autopilot')) {
-    resolved = resolved.filter(m => m.name !== 'autopilot');
-  }
-
-  // Team beats ultrapilot (team is the canonical implementation)
-  if (names.includes('team') && names.includes('ultrapilot')) {
-    resolved = resolved.filter(m => m.name !== 'ultrapilot');
-  }
-
-  // Ralph + Team coexist (team-ralph linked mode)
-  // Both keywords are preserved so the skill can detect the composition.
+  // Team keyword detection removed — team is now explicit-only via /team skill.
 
   // Sort by priority order
-const priorityOrder = ['cancel','ralph','autopilot','team','ultrawork',
+const priorityOrder = ['cancel','ralph','autopilot','ultrawork',
     'pipeline','ccg','ralplan','plan','tdd','research','ultrathink','deepsearch','analyze'];
   resolved.sort((a, b) => priorityOrder.indexOf(a.name) - priorityOrder.indexOf(b.name));
 
@@ -289,6 +278,20 @@ function isTeamEnabled() {
 
 // Main
 async function main() {
+  // Skip guard: check OMC_SKIP_HOOKS env var (see issue #838)
+  const _skipHooks = (process.env.OMC_SKIP_HOOKS || '').split(',').map(s => s.trim());
+  if (process.env.DISABLE_OMC === '1' || _skipHooks.includes('keyword-detector')) {
+    console.log(JSON.stringify({ continue: true }));
+    return;
+  }
+
+  // Team worker guard: prevent keyword detection inside team workers to avoid
+  // infinite spawning loops (worker detects "team" -> invokes team skill -> spawns more workers)
+  if (process.env.OMC_TEAM_WORKER) {
+    console.log(JSON.stringify({ continue: true, suppressOutput: true }));
+    return;
+  }
+
   try {
     const input = await readStdin();
     if (!input.trim()) {
@@ -326,13 +329,8 @@ async function main() {
       matches.push({ name: 'autopilot', args: '' });
     }
 
-    // Team keywords (intent-gated to prevent false positives on bare "team")
-    // Uses negative lookbehind to exclude possessive/article contexts like "my team", "the team"
-    const hasTeamKeyword = /(?<!\b(?:my|the|our|a|his|her|their|its)\s)\bteam\b/i.test(cleanPrompt) ||
-      /\bcoordinated\s+team\b/i.test(cleanPrompt);
-    if (hasTeamKeyword && isTeamEnabled()) {
-      matches.push({ name: 'team', args: '' });
-    }
+    // Team keyword detection removed — team mode is now explicit-only via /team skill.
+    // This prevents infinite spawning when Claude workers receive prompts containing "team".
 
     // Ultrawork keywords
     if (/\b(ultrawork|ulw)\b/i.test(cleanPrompt)) {
@@ -398,14 +396,14 @@ async function main() {
 
     // Handle cancel specially - clear states and emit
     if (resolved.length > 0 && resolved[0].name === 'cancel') {
-      clearStateFiles(directory, ['ralph', 'autopilot', 'team', 'ultrawork', 'pipeline']);
+      clearStateFiles(directory, ['ralph', 'autopilot', 'ultrawork', 'pipeline']);
       console.log(JSON.stringify(createHookOutput(createSkillInvocation('cancel', prompt))));
       return;
     }
 
     // Activate states for modes that need them
     const sessionId = data.sessionId || data.session_id || data.sessionid || '';
-    const stateModes = resolved.filter(m => ['ralph', 'autopilot', 'team', 'ultrawork'].includes(m.name));
+    const stateModes = resolved.filter(m => ['ralph', 'autopilot', 'ultrawork'].includes(m.name));
     for (const mode of stateModes) {
       activateState(directory, prompt, mode.name, sessionId);
     }
@@ -413,16 +411,10 @@ async function main() {
     // Special: Ralph with ultrawork (ralph always includes ultrawork)
     const hasRalph = resolved.some(m => m.name === 'ralph');
     const hasUltrawork = resolved.some(m => m.name === 'ultrawork');
-    const hasTeam = resolved.some(m => m.name === 'team');
     if (hasRalph && !hasUltrawork) {
       activateState(directory, prompt, 'ultrawork', sessionId);
     }
 
-    // Link ralph + team if both detected (team-ralph composition)
-    if (hasRalph && hasTeam) {
-      linkRalphTeam(directory, sessionId);
-    }
-
     // Handle ultrathink specially - prepend message instead of skill invocation
     const ultrathinkIndex = resolved.findIndex(m => m.name === 'ultrathink');
     if (ultrathinkIndex !== -1) {