oh-my-customcodex 0.5.8 → 0.5.10

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.10",
     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.10",
   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.10",
   "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/rules/MUST-completion-verification.md

@@ -22,6 +22,18 @@ Before declaring any task `[Done]`, verify completion against task-type-specific
 
 Before [Done]: (1) Verify ACTUAL outcome not just attempt — "ran command" ≠ "succeeded". (2) Check task-type criteria above. (3) No unchecked items. (4) Would bet $100 it's complete.
 
+## Workflow Prompt and Verifier Ground Truth
+
+When a workflow delegates to `agent()` or equivalent subagent calls, complete the full prompt string before the call. Do not append guardrails, fact sheets, or critical constraints to the returned value after the agent has already run.
+
+Verifier lanes must receive the ground-truth sources needed to check cross-cutting claims, especially external URLs, cluster DNS/service names, credentials metadata, release facts, and infrastructure identifiers. A verifier cannot validate a fact that was never provided and is not present in the inspected source.
+
+## Read-Before-Characterize Diagnostics
+
+Do not characterize logs, traces, or diagnostics as an "error loop", "root cause", "flaky test", or similar conclusion before reading the relevant evidence. First capture the observed symptom, then inspect the authoritative log/output/source, then label the failure mode.
+
+For large or noisy logs, read a representative targeted slice before making permanent workflow, rule, template, or release-process changes. If the initial characterization changes after reading, report the correction explicitly.
+
 ## Diagnostic Hypothesis Verification
 
 When a failure diagnosis would cause a permanent workflow, rule, template, or release-process change, the diagnosis must be treated as a hypothesis until it is directly verified.

package/templates/.claude/rules/MUST-orchestrator-coordination.md

@@ -116,6 +116,26 @@ Main Conversation (orchestrator)
 ```
 -->
 
+## Subagent Scope-Creep STOP Protocol
+
+Before delegating broad work, decompose it into narrow domains with explicit write/command boundaries. For example, do not hand one agent an open-ended "migrate + backfill + fix infra" prompt when the work can split into data migration, credential handling, tunnel/networking, dashboard verification, and release notes.
+
+The orchestrator must stop and redesign a delegated lane when any of these occur:
+
+1. The same subagent trips the security classifier twice on one assignment.
+2. The subagent requests or attempts privileged actions outside the delegated scope.
+3. The subagent chains from an approved action into a different credential, tunnel, namespace, pod, cluster, account, or shared service.
+4. The user corrects the agent for acting beyond the requested scope.
+
+Required STOP response:
+
+1. Stop that subagent lane; do not retry the same broad prompt.
+2. Preserve evidence and summarize the exact scope breach.
+3. Redesign the task into smaller bounded lanes with explicit allowed and forbidden actions.
+4. Reconfirm authorization before any irreversible shared-infrastructure or credential action.
+
+Thirteen repeated security trips or repeated privileged retries are an anti-pattern: after the second trip, continuing without redesign is a coordination failure.
+
 ## Common Violations
 
 Key violations to avoid (file writes, git commands, bundled operations — all must be delegated):

package/templates/.claude/rules/MUST-permissions.md

@@ -13,6 +13,12 @@
 | 5: Conditional | TeamCreate, TeamDelete, SendMessage, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskStop, TaskOutput | Available when Agent Teams enabled |
 | 6: MCP | ListMcpResourcesTool, ReadMcpResourceTool, CronCreate, CronDelete, CronList, RemoteTrigger | MCP/extension tools, available when servers configured |
 
+## Privileged Scope Boundaries
+
+- Approval for one privileged action does not authorize follow-on privileged chaining. A request to remove one tunnel, secret, pod, namespace object, or credential does not authorize creating a replacement, rotating credentials, deleting adjacent resources, or executing inside production workloads.
+- Treat credential-store reads as sensitive even when the tool is otherwise available. Never paste raw secret values or full credential-store transcripts into chat; use redacted names, fingerprints, or boolean verification results.
+- Reconfirm scope before irreversible shared infrastructure or credential actions, including production pod exec/write, Kubernetes secret mutation, public tunnel creation, credential rotation, and shared namespace deletion.
+
 ## File Access
 
 | Operation | Allowed | Prohibited |

package/templates/.claude/rules/MUST-safety.md

@@ -11,6 +11,13 @@
 | Commands | `rm -rf /` or broad deletes, shutdown/restart, sudo/su, network config changes |
 | External | Access URLs without approval, send user data externally, download/execute unknown scripts |
 
+## Credential and Shared-Infrastructure Guardrails
+
+- Do not dump credential-store contents, `.env` files, OAuth material, kube secrets, or secret-manager values into transcripts, logs, issue bodies, or summaries. Report only the minimum redacted key names or verification status required for the task.
+- Do not rotate, delete, recreate, or replace credentials unless the user explicitly requested that exact credential action.
+- Before irreversible action on shared infrastructure or credentials, reconfirm the target, namespace/account/project, requested scope, rollback path, and user authorization.
+- Stop instead of chaining privileged actions when the next step would affect a different credential, tunnel, namespace, pod, cluster, account, or shared service than the user requested.
+
 ## Required Before Destructive Operations
 
 Verify target, assess impact scope, check recoverability, get user approval.

package/templates/.claude/rules/SHOULD-interaction.md

@@ -27,6 +27,17 @@
 | Ambiguous | `[Confirm] Understood "{request}" as {interpretation}. Proceed?` |
 | Risky | `[Warning] This action has {risk}. Continue? Yes: {action} / No: Cancel` |
 
+## External Product UI Claims
+
+Avoid presenting unverified external product UI field names, button labels, or step-by-step paths as fact. Product consoles change frequently and screenshots/docs may be stale.
+
+When UI evidence is not directly verified:
+
+- State that the UI path is an inference or may vary by account/version.
+- Prefer stable facts already observed in the environment: URLs, config keys, resource IDs, CLI output, or API results.
+- Ask the user to map those verified values into the current UI instead of inventing missing fields.
+- If exact UI steps are required, verify against current official docs or a live screenshot before giving precise labels.
+
 ## Multiple Tasks
 
 - Dependent: Sequential

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