oh-my-customcodex 0.5.8 → 0.5.9

package/README.md

@@ -13,7 +13,7 @@
 
 **[한국어 문서 (Korean)](./README_ko.md)**
 
-50 agents. 123 skills. 22 rules. One command.
+50 agents. 120 skills. 22 rules. One command.
 
 ```bash
 npm install -g oh-my-customcodex && cd your-project && omcustomcodex init
@@ -135,7 +135,7 @@ Each agent declares its tools, model, memory scope, and limitations in YAML fron
 
 ---
 
-### Skills (123)
+### Skills (120)
 
 | Category | Count | Includes |
 |----------|-------|----------|
@@ -148,7 +148,7 @@ Each agent declares its tools, model, memory scope, and limitations in YAML fron
 | Package | 3 | npm-publish, npm-version, npm-audit |
 | Optimization | 3 | optimize-analyze, optimize-bundle, optimize-report |
 | Security | 3 | adversarial-review, cve-triage, jinja2-prompts |
-| Other | 13 | codex-exec, claude-native, gitlab, visual-ralph, visual-verdict, vercel-deploy, skills-sh-search, result-aggregation, writing-clearly-and-concisely, and more |
+| Other | 10 | claude-native, gitlab, visual-ralph, visual-verdict, vercel-deploy, skills-sh-search, result-aggregation, writing-clearly-and-concisely, and more |
 
 Skills use a 3-tier scope system: `core` (universal), `harness` (agent/skill maintenance), `package` (project-specific).
 
@@ -288,7 +288,7 @@ your-project/
 │   ├── contexts/               # 4 shared context files
 │   └── ontology/               # Knowledge graph for RAG
 ├── .agents/
-│   └── skills/                 # 123 installed skill modules
+│   └── skills/                 # 120 installed skill modules
 └── guides/                     # 51 reference documents
 ```
 

package/dist/cli/index.js

@@ -3091,7 +3091,7 @@ var init_package = __esm(() => {
     workspaces: [
       "packages/*"
     ],
-    version: "0.5.8",
+    version: "0.5.9",
     requiresCC: ">=2.1.121",
     claudeCode: {
       minimumVersion: "2.1.121",

package/dist/index.js

@@ -2316,7 +2316,7 @@ var package_default = {
   workspaces: [
     "packages/*"
   ],
-  version: "0.5.8",
+  version: "0.5.9",
   requiresCC: ">=2.1.121",
   claudeCode: {
     minimumVersion: "2.1.121",

package/package.json

@@ -3,7 +3,7 @@
   "workspaces": [
     "packages/*"
   ],
-  "version": "0.5.8",
+  "version": "0.5.9",
   "requiresCC": ">=2.1.121",
   "claudeCode": {
     "minimumVersion": "2.1.121",

package/templates/.claude/hooks/scripts/agent-teams-advisor.sh

@@ -57,7 +57,8 @@ echo "$COUNT" > "$COUNTER_FILE"
 if [ "$BATCH_ISSUES" -ge 3 ] && [ "$COUNT" -eq 1 ]; then
   echo "" >&2
   echo "--- [R018 Advisor] Batch context detected (${BATCH_ISSUES} issues) ---" >&2
-  echo "  RECOMMENDATION: Use Agent Teams (TeamCreate) for this batch." >&2
+  echo "  RECOMMENDATION: Use Agent Teams (TeamCreate) for this batch unless work is a mechanical disjoint-file refactor with explicit write scopes." >&2
+  echo "  VERIFY DONE WITH: git diff/status, rg/grep, scripts/tests; team task status is advisory only." >&2
   echo "  Current: Agent(${agent_type}) -- ${prompt_preview}" >&2
   echo "-----------------------------------------------------------" >&2
 elif [ "$COUNT" -ge 2 ]; then
@@ -67,6 +68,8 @@ elif [ "$COUNT" -ge 2 ]; then
   echo "    * 3+ agents needed for this work" >&2
   echo "    * Review -> fix -> re-review cycle exists" >&2
   echo "    * Agents need shared state or coordination" >&2
+  echo "  NOTE: For mechanical disjoint-file refactors, bounded standalone agents may avoid Team runtime overhead." >&2
+  echo "  VERIFY DONE WITH: git diff/status, rg/grep, scripts/tests; task status alone is not proof." >&2
   echo "  Current: Agent(${agent_type}) -- ${prompt_preview}" >&2
   echo "-----------------------------------------------------------" >&2
 fi

package/templates/.claude/rules/MUST-agent-teams.md

@@ -6,296 +6,135 @@
 
 ## Detection
 
-Available when `OMCODEX_AGENT_TEAMS=1` or TeamCreate/SendMessage tools present.
+Available when `OMCODEX_AGENT_TEAMS=1` or `TeamCreate` / `SendMessage` exists.
 
 ## Decision Matrix
 
 | Scenario | Preferred | Reason |
 |----------|-----------|--------|
 | Simple independent subtasks | Agent Tool | Lower cost, no coordination overhead |
-| Sequential-dependency init/scaffolding | Agent Tool | Blocked agents waste tokens polling; single agent faster |
+| Mechanical disjoint-file refactors/deletions | Agent Tool | Explicit write scopes can avoid Team runtime overhead/stalls |
+| Sequential-dependency init/scaffolding | Agent Tool | Avoid blocked agents polling |
 | Multi-step with shared state | **Agent Teams** | Shared task list, peer messaging |
-| Research requiring discussion | **Agent Teams** | Iterative discovery, synthesis |
-| Cost-sensitive batch ops | Agent Tool | Minimal token overhead |
+| Research requiring discussion | **Agent Teams** | Iterative discovery and synthesis |
 | Complex debugging across modules | **Agent Teams** | Cross-module state sharing |
 | Code review + fix cycle | **Agent Teams** | Review → fix → re-review loop |
-| Single file operations | Agent Tool | Overkill for simple tasks |
 | Dynamic agent creation + usage | **Agent Teams** | Create → test → iterate cycle |
-| Multi-issue release batch | **Agent Teams** | Shared task tracking, coordinated release |
-
-**When Agent Teams is enabled and criteria are met, usage is required.**
-
-### Scope: Intra-Session vs Cross-Session
-
-| Scope | Tool | Protocol | Use Case |
-|-------|------|----------|----------|
-| Intra-session | `SendMessage` (Agent Teams) | Peer-to-peer within team | Multi-agent collaboration in one session |
-| Cross-session | `send_message` (claude-peers-mcp) | Broker-mediated | Multi-terminal/project coordination |
-
-These are distinct mechanisms. Agent Teams `SendMessage` requires `TeamCreate` and operates within a single Claude Code session. claude-peers-mcp `send_message` operates across separate Claude Code processes via a localhost broker.
-
-## Self-Check (Before Agent Tool)
-
-Before using Agent tool for 2+ agent tasks, complete this check:
-Quick rule: User explicitly preferred plain subagents this session? → use Agent Tool (R000 user instructions > R018). Otherwise: 3+ agents OR review cycle → use Agent Teams. Sequential deps / scaffolding → Agent Tool. 2+ issues in same batch → prefer Agent Teams.
-
-<!-- DETAIL: Self-Check (Before Agent Tool)
-╔══════════════════════════════════════════════════════════════════╗
-║  BEFORE USING Agent TOOL FOR 2+ AGENTS:                          ║
-║                                                                   ║
-║  0. Has user explicitly preferred plain subagents this session?  ║
-║     YES → Use Agent tool (R000 user instructions > R018)         ║
-║     NO  → Continue to #1                                          ║
-║                                                                   ║
-║  1. Is Agent Teams available?                                    ║
-║     YES → check criteria #2-#5                                  ║
-║     NO  → Proceed with Agent tool                               ║
-║                                                                   ║
-║  2. Will 3+ agents be involved?                                  ║
-║     YES → use Agent Teams                                        ║
-║     NO  → Check #3                                               ║
-║                                                                   ║
-║  3. Is there a review → fix → re-review cycle?                  ║
-║     YES → use Agent Teams                                        ║
-║     NO  → Check #4                                               ║
-║                                                                   ║
-║  4. Are 2+ issues being fixed in the same release batch?        ║
-║     YES → prefer Agent Teams (coordination benefit)              ║
-║     NO  → Check #5                                               ║
-║                                                                   ║
-║  5. Are tasks sequentially dependent (init/scaffold)?            ║
-║     YES → prefer Agent Tool (single agent, no coordination)     ║
-║     NO  → Continue with Agent Teams                              ║
-║                                                                   ║
-║  Simple rule: 3+ agents OR review cycle → use Agent Teams        ║
-║  Sequential deps / scaffolding → Agent Tool (single agent)       ║
-║  2+ issues in same batch → prefer Agent Teams                    ║
-║  Everything else → Agent tool                                    ║
-╚══════════════════════════════════════════════════════════════════╝
+| Multi-issue release batch | **Agent Teams** | Shared task tracking and coordinated release |
+
+When enabled and criteria match, Agent Teams is required.
+
+## Scope: Intra-Session vs Cross-Session
+
+| Scope | Tool | Use Case |
+|-------|------|----------|
+| Intra-session | `SendMessage` (Agent Teams) | Multi-agent collaboration in one session |
+| Cross-session | `send_message` (claude-peers-mcp) | Multi-terminal/project coordination |
+
+Do not confuse these mechanisms.
+
+## Self-Check Before Agent Tool
+
+Quick rule: explicit user preference for plain subagents wins. Otherwise use Teams for 3+ agents, review cycles, shared state, complex debugging, dynamic creation, or multi-issue batches; use Agent Tool for 1-2 simple tasks, sequential scaffolding, or mechanical disjoint-file batches with explicit scopes.
+
+<!-- DETAIL: Self-Check Before Agent Tool
+0. Did the user explicitly prefer plain subagents this session? YES → Agent Tool.
+1. Is Agent Teams unavailable? YES → Agent Tool with R009/R010.
+2. Will 3+ agents be involved? YES → Agent Teams.
+3. Is there a review → fix → re-review cycle? YES → Agent Teams.
+4. Are 2+ issues fixed in the same release batch? YES → prefer Agent Teams.
+5. Are tasks sequentially dependent init/scaffold work? YES → Agent Tool.
+6. Is this a mechanical disjoint-file refactor/deletion batch with explicit write scopes where Team runtime overhead or stall risk exceeds coordination value? YES → Agent Tool allowed.
+7. Otherwise, use Agent Teams when collaboration or shared state has material value.
 -->
 
-### Spawn Completeness Check
-
-All members must be spawned in a single message. Partial spawning needs correction per R018 and R009.
-
-<!-- DETAIL: Self-Check (Spawn Completeness)
-╔══════════════════════════════════════════════════════════════════╗
-║  BEFORE SPAWNING TEAM MEMBERS:                                   ║
-║                                                                   ║
-║  1. How many members does this team need?  N = ___               ║
-║  2. Am I spawning ALL N members in THIS message?                 ║
-║     YES → Good. Continue.                                        ║
-║     NO  → Spawn all N members in this message before proceeding. ║
-║                                                                   ║
-║  Partial spawn (e.g., 1/3) = needs correction                    ║
-║  Sequential spawn (one per message) = needs correction           ║
-║  All at once in single message = correct                         ║
-╚══════════════════════════════════════════════════════════════════╝
+## Spawn Completeness
+
+Spawn all members for a parallel team slice in one message; partial/sequential spawning needs correction.
+
+<!-- DETAIL: Spawn Completeness
+Before spawning, count required members (N) and spawn all N in one message. Partial spawn (1/N) and one-member-per-message sequencing break the team contract because early workers begin without the intended peer set and shared coordination context.
 -->
 
-<!-- DETAIL: External Skill Conflict Resolution
-When an external skill instructs using Agent tool but R018 criteria are met:
+## External Skill Conflict Resolution
 
-| Skill says | R018 requires | Resolution |
-|------------|--------------|------------|
-| "Use Agent tool for N tasks" | 3+ agents → Teams | Use Agent Teams, follow skill logic |
-| "Sequential agent spawning" | Independent tasks → parallel | Parallelize per R009 |
-| "Skip coordination" | Shared state → Teams | Use Teams for coordination |
+External skills define workflow; R018 defines execution method. Keep skill logic but use Teams when R018 criteria match.
 
-Rule: External skills define the WORKFLOW. R018 defines the EXECUTION METHOD.
-The skill's steps are followed, but agent spawning uses Teams when criteria are met.
+<!-- DETAIL: External Skill Conflict Resolution
+Examples:
+- Skill says “Use Agent tool for N tasks”; R018 says 3+ agents → use Agent Teams.
+- Skill suggests sequential spawning; R009 says independent tasks → spawn in parallel.
+- Skill says “skip coordination”; shared state/review cycles → use Team coordination.
+-->
+
+## Retrospective Hardening
+
+- Mechanical disjoint-file refactors/deletions may use standalone parallel agents when prompts have explicit write scopes and Team runtime overhead or stall risk outweighs coordination value.
+- Agent Teams task status is advisory only; verify completion with deterministic evidence such as `git diff`, `git status`, search, scripts, tests, or build output.
+- Split giant delegated prompts by domain, file group, and write scope so assignees can finish without touching another agent's files.
+- Do not misuse `AskUserQuestion` or other user-facing prompts for internal coordination; use peer channels, runtime state, or repository evidence.
+- In zsh snippets, avoid the reserved `status` variable; use names like `exit_status` or `cmd_status`.
+
+<!-- DETAIL: Retrospective Hardening
+#1430/#1431 hardening intent:
+- Mechanical disjoint-file batches are not inherently collaborative. Standalone agents may be safer when each owns a non-overlapping file set and Team runtime coordination would add token cost, idle polling, or stall risk.
+- Team task status, TaskList state, member status, and peer claims are coordination signals, not proof. The orchestrator must confirm outcomes through repository state and repeatable commands before declaring completion.
+- Giant prompts create cross-scope edits and confused ownership. Split by domain/file group/write scope, include explicit boundaries, and require agents to report rather than self-assign extra work.
+- AskUserQuestion is for human decisions, not internal agent coordination. Internal coordination belongs in Agent Teams peer messages, cross-session peer messaging, runtime state, or direct repo evidence.
+- zsh reserves `status`; shell snippets that assign to it can fail. Use `exit_status`, `cmd_status`, or another non-reserved name.
 -->
 
 ## Common Violations
 
-```
-❌ WRONG: 3+ tasks using Agent tool instead of Agent Teams
-   Agent(Explore):haiku → Analysis 1
-   Agent(Explore):haiku → Analysis 2
-   Agent(Explore):haiku → Analysis 3
-
-✓ CORRECT: TeamCreate → spawn researchers → coordinate via shared task list
-   TeamCreate("research-team") + Agent(researcher-1/2/3) + SendMessage(coordinate)
-```
-
-<!-- DETAIL: Common Violations (full examples)
-❌ WRONG: Agent Teams enabled, 3+ research tasks using Agent tool
-   Agent(Explore):haiku → Analysis 1
-   Agent(Explore):haiku → Analysis 2
-   Agent(Explore):haiku → Analysis 3
-
-✓ CORRECT: TeamCreate → spawn researchers → coordinate via shared task list
-   TeamCreate("research-team")
-   Agent(researcher-1) → Analysis 1  ┐
-   Agent(researcher-2) → Analysis 2  ├─ Spawned as team members
-   Agent(researcher-3) → Analysis 3  ┘
-   SendMessage(coordinate)
-
-❌ WRONG: Code review + fix as independent Agents
-   Agent(reviewer) → "Review code"
-   (receive result)
-   Agent(implementer) → "Fix issues"
-   (receive result)
-   Agent(reviewer) → "Re-review"
-
-✓ CORRECT: Agent Teams for review-fix cycle
-   TeamCreate("review-fix")
-   Agent(reviewer) + Agent(implementer) → team members
-   reviewer → SendMessage(implementer, "issues found")
-   implementer → fixes → SendMessage(reviewer, "fixed")
-   reviewer → re-reviews → done
-
-❌ WRONG: Spawning team members one at a time
-   TeamCreate("research-team")
-   Message 1: Agent(researcher-1) → Analysis 1   (only 1/3 spawned)
-   Message 2: Agent(researcher-2) → Analysis 2   (late spawn)
-   Message 3: Agent(researcher-3) → Analysis 3   (late spawn)
-
-✓ CORRECT: All members in a single message
-   TeamCreate("research-team")
-   Single message:
-     Agent(researcher-1) → Analysis 1  ┐
-     Agent(researcher-2) → Analysis 2  ├─ ALL spawned together
-     Agent(researcher-3) → Analysis 3  ┘
-
-❌ WRONG: Completed member modifies other member's files
-   svelte-projects completes task → browses TaskList → edits agent-teams-advisor.sh (hook-fixer's scope)
-
-✓ CORRECT: Completed member reports and waits
-   svelte-projects completes task → SendMessage("Task complete") → waits silently
+Wrong: 3+ collaborative standalone agents, uncoordinated review/fix loops, or one-at-a-time team spawns. Correct: create team, spawn together, coordinate via `SendMessage`, verify deterministically.
+
+<!-- DETAIL: Common Violations
+Wrong: three researchers launched as unrelated Agent calls while Agent Teams is available.
+Correct: TeamCreate("research-team") + researcher-1/2/3 spawned together + SendMessage coordination.
+
+Wrong: reviewer → implementer → reviewer as disconnected calls.
+Correct: reviewer and implementer are team members; reviewer sends findings, implementer fixes, reviewer re-checks.
+
+Wrong: completed member browses TaskList and edits another member's files.
+Correct: completed member reports completion and waits silently unless reassigned by the lead.
 -->
 
 ## Cost Guidelines
 
-| Criteria | Agent Tool | Agent Teams |
-|----------|-----------|-------------|
-| Agent count | 1-2 | 3+ |
-| Inter-task dependency | None | Present |
-| Iteration cycles | None | Present (review→fix→re-review) |
-| Estimated duration | < 3 min | > 3 min |
-| Shared state needed | No | Yes |
+Agent Tool: 1-2 simple independent agents. Agent Teams: 3+ agents, shared state, review cycles, complex work, multi-issue batches, or dynamic creation.
 
 ## Team Patterns
 
-Standard: Research (researcher-1 + researcher-2 + synthesizer), Development (implementer + reviewer + tester), Debug (investigator-1 + investigator-2 + fixer).
-Hybrid: Review+Fix, Create+Validate, Multi-Expert, Dynamic Creation, Codex Hybrid.
+Common patterns: Research, Development, Debug, Dynamic Creation, and Codex Hybrid.
 
 <!-- DETAIL: Team Patterns
-### Standard Patterns
-- Research: researcher-1 + researcher-2 + synthesizer
-- Development: implementer + reviewer + tester
-- Debug: investigator-1 + investigator-2 + fixer
-
-### Hybrid Patterns
-- Review+Fix: reviewer + implementer (reviewer finds issues → implementer fixes → reviewer re-checks)
-- Create+Validate: mgr-creator + qa-engineer (create agent → validate → iterate)
-- Multi-Expert: expert-1 + expert-2 + coordinator (cross-domain tasks requiring multiple specialties)
-
-### Dynamic Patterns
-- Dynamic Creation: mgr-creator + domain-expert (create new agent → immediately use for pending task)
-- Codex Hybrid: codex-exec-agent + claude-reviewer (Codex generates → Claude reviews/refines)
-
-### Codex-Exec Integration
-When both Agent Teams and codex-exec are available:
-  1. Claude agent analyzes requirements
-  2. codex-exec generates implementation (Codex strength: code generation)
-  3. Claude agent reviews and refines (Claude strength: reasoning, quality)
-  4. Iterate via team messaging until quality meets standards
-
-| Step | Agent | Model |
-|------|-------|-------|
-| Analysis | Claude team member | sonnet/opus |
-| Generation | codex-exec | (Codex default) |
-| Review | Claude team member | sonnet |
-| Refinement | Appropriate expert | sonnet |
-
-### Dynamic Agent Creation in Teams
-When Agent Teams creates a new agent via mgr-creator:
-1. Team lead identifies missing expertise
-2. Spawns mgr-creator as team member
-3. mgr-creator creates agent with auto-discovered skills
-4. New agent joins team immediately
-5. Team continues with expanded capabilities
+Research: parallel researchers gather evidence; synthesizer merges and checks conflicts.
+Development: implementer changes code, reviewer challenges, tester verifies.
+Debug: investigators isolate causes across modules; fixer implements after evidence converges.
+Dynamic Creation: mgr-creator creates missing expertise, validator checks immediate usability.
+Codex Hybrid: codex-exec generates implementation, Claude team member reviews/refines, then verification closes the loop.
 -->
 
 ## Blocked Agent Behavior
 
-When a team member is blocked: prefer Deferred spawn (no wasted tokens) > Silent wait (short waits) > Reassign (blocked >2 min).
-Post-completion: report via SendMessage, wait silently. Do NOT browse TaskList or modify files outside scope.
+Prefer deferred spawn over idle polling. Blocked/completed members wait silently, check infrequently, and never edit outside scope.
 
 <!-- DETAIL: Blocked Agent Behavior
-| Strategy | When | Benefit |
-|----------|------|---------|
-| Deferred spawn | Dependency chain is clear | No wasted tokens; spawn after blocker completes |
-| Silent wait | Agent already spawned, short wait expected | Minimal overhead |
-| Reassign | Agent blocked >2 min with no progress | Reuse agent for unblocked work |
-
-### Prompt Guidelines for Team Members
-When spawning agents that may be blocked:
-1. Include explicit instruction: "If your task is blocked, wait silently. Do NOT send periodic status messages."
-2. Set check interval: "Check TaskList once per minute, not continuously."
-3. Prefer deferred spawn when the dependency resolution time is unpredictable.
-4. Post-completion instruction: "After completing your task, report via SendMessage and wait. Do NOT explore or modify files outside your scope."
-5. Explicit scope boundary: "Your scope is limited to: {file list or directory}. Do NOT modify files outside this scope."
-
-### Anti-Pattern: Idle Polling
-❌ WRONG: Blocked agent sends repeated status messages
-   docker-dev: "Task #1 still pending..."  (×5 messages, wasting tokens)
-
-✓ CORRECT: Deferred spawn after dependency resolves
-   (Task #1 completes) → then spawn docker-dev for Task #3
-
-✓ ALSO CORRECT: Silent wait with infrequent checks
-   docker-dev spawned with: "Wait silently if blocked. Check TaskList once per minute."
-
-### Post-Completion Scope Constraint
-| Behavior | Correct | Wrong |
-|----------|---------|-------|
-| Task completed | Report completion via SendMessage, wait silently | Browse TaskList for other work |
-| No more tasks | Exit or wait for team shutdown | Explore/modify files outside original scope |
-| See unfinished work | Report to team lead, do NOT self-assign | Edit files that belong to other members |
-
-### Self-Check (After Task Completion)
-╔══════════════════════════════════════════════════════════════════╗
-║  AFTER COMPLETING YOUR ASSIGNED TASK:                            ║
-║                                                                   ║
-║  1. Did I complete ONLY my assigned task?                        ║
-║     YES → Report completion                                      ║
-║     NO  → Revert scope-violation changes                         ║
-║                                                                   ║
-║  2. Are there files modified outside my task scope?              ║
-║     YES → This is a violation — revert                           ║
-║     NO  → Good                                                    ║
-║                                                                   ║
-║  3. Am I about to explore/modify files for "other tasks"?        ║
-║     YES → STOP. Report to team lead instead                      ║
-║     NO  → Good. Wait silently or exit                            ║
-╚══════════════════════════════════════════════════════════════════╝
+Strategies: defer spawn when dependency chain is clear; silent wait for short blocks; reassign after sustained blocking. Prompts should say: “If blocked, wait silently. Check TaskList at most once per minute. After completing, report via SendMessage and do not browse or edit outside your scope.”
 -->
 
 ## Lifecycle
 
-`TeamCreate → TaskCreate → Agent(spawn members) → SendMessage → TaskUpdate → ... → TeamDelete`. See full lifecycle via Read tool.
+`TeamCreate → TaskCreate → Agent(spawn members) → SendMessage → TaskUpdate → ... → TeamDelete`.
 
 <!-- DETAIL: Lifecycle diagram
-```
-TeamCreate → TaskCreate → Agent(spawn members) → SendMessage(coordinate)
-  → TaskUpdate(progress) → ... → shutdown members → TeamDelete
-```
+TeamCreate → TaskCreate → Agent(spawn members) → SendMessage(coordinate) → TaskUpdate(progress) → verify → shutdown members → TeamDelete.
 -->
 
 ## Fallback
 
-When Agent Teams unavailable: use Agent tool with R009/R010 rules.
-When Agent Teams available: actively prefer it for qualifying tasks.
-
-## Cost Awareness
-
-Agent Teams actively preferred for qualifying collaborative tasks. Use Agent tool only when:
-- 1-2 agents with no inter-dependency
-- No review → fix cycles
-- Simple independent subtasks
+If Teams unavailable, use Agent tool with R009/R010. If available, prefer Teams for qualifying collaboration.
 
-Do NOT avoid Agent Teams solely for cost reasons when criteria are met.
+## Active Preference Rule
 
-**Active preference rule**: When Agent Teams is available, default to using it for any multi-step or multi-issue work. Only fall back to Agent tool for truly simple, single-issue tasks with no verification needs.
+Default to Teams for multi-step/multi-issue collaboration. Fall back only for simple single-issue work, explicit user preference, sequential scaffolding, or low-coordination mechanical disjoint-file batches.

package/templates/.claude/skills/de-lead-routing/SKILL.md

@@ -61,24 +61,17 @@ Check if Agent Teams is available (`OMCODEX_AGENT_TEAMS=1` or TeamCreate/SendMes
 | Cross-tool data quality analysis | Agent Teams |
 | Quick DAG/model validation | Agent Tool |
 
-### Step 2: Codex-Exec Hybrid (Code Generation)
+### Step 2: External Interop Guidance (Code Generation)
 For **new pipeline code**, **DAG scaffolding**, or **SQL model generation**:
 
-1. Check `/tmp/.codex-env-status-*` for codex, gemini, and rtk availability
-2. If codex available AND task involves new file creation → automatically delegate to `/codex-exec` for scaffolding:
-   - Display: `[Codex Hybrid] Delegating to codex-exec...`
-   - codex-exec generates initial code (strength: fast generation)
-   - Selected DE expert reviews and refines codex output (strength: reasoning, quality)
-3. If codex unavailable but gemini available → delegate to `/gemini-exec` for scaffolding:
-   - Display: `[Gemini Hybrid] Delegating to gemini-exec...`
-   - gemini-exec generates initial code
-   - Selected DE expert reviews and refines output
-4. If RTK available (`RTK=available` in env status) → optionally wrap DE expert output through RTK to reduce token consumption by 60-90%:
+1. Use the selected DE expert as the default implementation path.
+2. If the native Claude Code plugin `openai/codex-plugin-cc` is explicitly installed and requested, it may provide Codex interop for scaffolding before expert review.
+3. If RTK is available (`RTK=available` in env status), optionally wrap DE expert output through `rtk-exec` to reduce token consumption by 60-90%:
    - Display: `[RTK Proxy] Token optimization active via rtk-exec`
    - RTK acts as a transparent proxy — no change to expert selection
-5. If none available → display `[External CLI] Unavailable — proceeding with {expert} directly` and use DE expert directly
+4. Otherwise display `[External CLI] Not requested — proceeding with {expert} directly` and use the expert directly.
 
-**Suitable**: New DAG files, dbt model scaffolding, SQL template generation
+**Suitable for optional plugin interop**: New DAG files, dbt model scaffolding, SQL template generation
 **Unsuitable**: Existing pipeline modification, architecture decisions, data quality analysis
 
 ### Step 3: Expert Selection

package/templates/.claude/skills/dev-lead-routing/SKILL.md

@@ -104,24 +104,17 @@ Check if Agent Teams is available (`OMCODEX_AGENT_TEAMS=1` or TeamCreate/SendMes
 | Cross-layer debugging (FE + BE + DB) | Agent Teams |
 | Simple file search/validation | Task Tool |
 
-### Step 2: Codex-Exec Hybrid (Implementation Tasks)
+### Step 2: External Interop Guidance (Implementation Tasks)
 For **new file creation**, **boilerplate**, or **test code generation**:
 
-1. Check `/tmp/.codex-env-status-*` for codex, gemini, and rtk availability
-2. If codex available AND task involves new file creation → automatically delegate to `/codex-exec` for scaffolding:
-   - Display: `[Codex Hybrid] Delegating to codex-exec...`
-   - codex-exec generates initial code (strength: fast generation)
-   - Selected Claude expert reviews and refines codex output (strength: reasoning, quality)
-3. If codex unavailable but gemini available → delegate to `/gemini-exec` for scaffolding:
-   - Display: `[Gemini Hybrid] Delegating to gemini-exec...`
-   - gemini-exec generates initial code
-   - Selected Claude expert reviews and refines output
-4. If RTK available (`RTK=available` in env status) → optionally wrap Claude expert output through RTK to reduce token consumption by 60-90%:
+1. Use the selected expert agent as the default implementation path.
+2. If the native Claude Code plugin `openai/codex-plugin-cc` is explicitly installed and requested, it may provide Codex interop for scaffolding before expert review.
+3. If RTK is available (`RTK=available` in env status), optionally wrap expert output through `rtk-exec` to reduce token consumption by 60-90%:
    - Display: `[RTK Proxy] Token optimization active via rtk-exec`
    - RTK acts as a transparent proxy — no change to expert selection
-5. If none available → display `[External CLI] Unavailable — proceeding with {expert} directly` and use Claude expert directly
+4. Otherwise display `[External CLI] Not requested — proceeding with {expert} directly` and use the expert directly.
 
-**Suitable**: New file creation, boilerplate, scaffolding, test code
+**Suitable for optional plugin interop**: New file creation, boilerplate, scaffolding, test code
 **Unsuitable**: Existing code modification, architecture decisions, bug fixes
 
 ### Step 3: Expert Agent Selection

package/templates/.claude/skills/intent-detection/SKILL.md

@@ -262,14 +262,12 @@ english:
 ```
 Research intent detected (confidence >= 70%)
     ↓
-Check Codex CLI availability
-    ├─ Available (codex binary + OPENAI_API_KEY)
-    │   → Use codex-exec skill with --effort xhigh
-    │   → Prompt: "Research and analyze: {user_request}"
-    │   → Returns: structured findings for orchestrator
-    └─ Unavailable
-        → Fall back to Claude's WebFetch/WebSearch
-        → Orchestrator handles directly or via general-purpose agent
+Use the research workflow or researcher/expert agents
+    ├─ Native Claude Code plugin `openai/codex-plugin-cc` explicitly installed/requested
+    │   → Optional Codex interop may assist analysis
+    └─ Otherwise
+        → Use existing expert agents, researcher, WebFetch/WebSearch, or RTK paths
+        → Orchestrator handles directly or via specialist agent
 ```
 
 ### Confidence Scoring
@@ -288,6 +286,6 @@ Check Codex CLI availability
 ├── Input: "{user input}"
 ├── Workflow: research-workflow
 ├── Confidence: {percentage}%
-├── Method: codex-exec (xhigh) | WebFetch fallback
+├── Method: research workflow | researcher/expert agent | optional Codex plugin when requested
 └── Reason: {explanation}
 ```

package/templates/.claude/skills/research/SKILL.md

@@ -167,17 +167,8 @@ Batch 3: T9, T10            (Innovation)
 
 Before starting verification rounds, check codex availability:
 
-```bash
-# Run this check once before Phase 2 begins
-which codex &>/dev/null && [ -n "$OPENAI_API_KEY" ]
-# Exit 0 → codex available: enable dual-model verification (opus + codex)
-# Exit 1 → codex unavailable: display notice and proceed with opus-only
-```
-
-If unavailable, display: `[Phase 2] Codex unavailable — opus-only verification`
-
 ```
-Team findings ──→ opus 4.6 verification ──→ codex-exec xhigh verification (if available)
+Team findings ──→ opus 4.6 verification ──→ optional plugin-assisted verification
        │                                              │
        └── Contradiction detected? ── YES ──→ Round N+1
                                       NO  ──→ Consensus reached → Phase 3
@@ -185,8 +176,7 @@ Team findings ──→ opus 4.6 verification ──→ codex-exec xhigh verific
 
 Each round:
 1. **opus 4.6**: Deep reasoning verification — checks logical consistency, identifies gaps, challenges assumptions
-2. **codex-exec xhigh** (when available): Independent code-level verification — validates technical claims, tests feasibility
-   - If unavailable: display `[Phase 2] Round {N}: Codex unavailable, proceeding with opus verification only`
+2. **Optional Codex interop**: Use native Claude Code plugin `openai/codex-plugin-cc` only when explicitly installed/requested; otherwise use researcher or RTK-backed local evidence gathering.
 3. **Contradiction resolution**: Reconcile divergent findings between teams and verifiers
 4. **Convergence check**: All major claims verified with no outstanding contradictions → proceed
 
@@ -319,16 +309,11 @@ Round N:
           - Internal consistency (breadth ↔ depth alignment)
           - Cross-domain consistency (security ↔ architecture)
           - Evidence quality (claims without backing)
-  Step 2: codex-exec validates technical claims (when available):
-          a. Invoke: /codex-exec with findings from all teams
-          b. Prompt:  "Validate technical claims: {findings}.
-                       Check code patterns, benchmark reproducibility,
-                       dependency resolution."
-          c. Effort:  --effort xhigh
-          d. Parse:   contradictions → merge with opus findings
-          e. On timeout/error: log "[Phase 2] Round {N}: codex-exec error — {reason},
-                                continuing with opus results only"
-     If unavailable: log "[Phase 2] Round {N}: Codex unavailable, proceeding with opus verification only"
+  Step 2: Optional plugin-assisted validation (only if `openai/codex-plugin-cc` is explicitly installed/requested):
+          a. Validate technical claims against code patterns, benchmark reproducibility,
+             and dependency resolution.
+          b. Parse contradictions → merge with opus findings.
+          c. On unavailable plugin or error: log "[Phase 2] Round {N}: optional Codex interop unavailable — continuing with opus/researcher results".
   Step 3: Compile contradiction list
           - 0 contradictions → CONVERGED
           - >0 contradictions → feedback to relevant teams → Round N+1
@@ -410,7 +395,7 @@ This advisory is informational only and does not block execution.
 
 | Scenario | Fallback |
 |----------|----------|
-| codex-exec unavailable | opus-only verification (still min 2 rounds) |
+| Optional Codex plugin unavailable | opus/researcher verification (still min 2 rounds) |
 | Agent Teams unavailable | Standard Agent tool with R009 batching |
 | Partial team failure | Synthesize from available results, note gaps in report |
 | GitHub issue creation fails | Output report to conversation only |