oh-my-customcodex 0.5.7 → 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.7",
+    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.7",
+  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.7",
+  "version": "0.5.9",
   "requiresCC": ">=2.1.121",
   "claudeCode": {
     "minimumVersion": "2.1.121",

package/templates/.claude/agents/arch-speckit-agent.md

@@ -60,7 +60,7 @@ When writing acceptance criteria, use the EARS (Easy Approach to Requirements Sy
 | Ubiquitous | The `<system>` shall `<action>` | The validator shall reject invalid frontmatter |
 | Event-driven | When `<event>`, the `<system>` shall `<action>` | When a new agent is created, the routing skill shall update its pattern table |
 | State-driven | While `<state>`, the `<system>` shall `<action>` | While ecomode is active, agents shall use concise output format |
-| Optional | Where `<condition>`, the `<system>` shall `<action>` | Where the user has MCP configured, the orchestrator shall attempt claude-mem save |
+| Optional | Where `<condition>`, the `<system>` shall `<action>` | Where the user has an approved memory MCP configured, the orchestrator shall attempt searchable memory save |
 | Complex | When `<event>` while `<state>` where `<condition>`, the `<system>` shall `<action>`, resulting in `<result>` | When session ends while Agent Teams is active where tasks remain incomplete, the orchestrator shall log incomplete tasks, resulting in a task summary |
 
 **Usage**: Apply EARS format in spec output's `invariants` and `acceptance_criteria` sections. This ensures testable, unambiguous requirements.

package/templates/.claude/agents/sys-memory-keeper.md

@@ -27,26 +27,26 @@ permissionMode: bypassPermissions
 
 When a task targets `.claude/**`, `templates/.claude/**`, or other Claude-compatibility mirrors, treat the old `/tmp` wrapper as legacy fallback only. Codex-native `.codex/**` edits stay direct, and Claude Code `bypassPermissions` can write `.claude/skills/`, `.claude/agents/`, and `.claude/commands/` directly on v2.1.121+, with broader protected-path coverage on v2.1.126+.
 
-You are a session memory management specialist ensuring context survives across session compactions using claude-mem.
+You are a session memory management specialist ensuring context survives across session compactions using native auto-memory first and optional omx-memory/AgentMemory-compatible searchable backends.
 
 ## Capabilities
 
 - Save session context before compaction
 - Restore context on session start
-- Query memories by project and semantic search
-- Tag memories with project, session, and task info
+- Query native and configured searchable memory by project and semantic search
+- Tag memory summaries with project, session, and task info
 
 ## Save Operation
 
-Collect tasks, decisions, open items, code changes. Format with metadata (project, session, tags, timestamp). Store via chroma_add_documents.
+Collect tasks, decisions, open items, and code changes. Format with metadata (project, session, tags, timestamp). Return the summary to the orchestrator for optional `memory_add` or `observation_add` persistence.
 
 ## Recall Operation
 
-Build semantic query with project prefix + keywords + optional date. Search via chroma_query_documents. Filter by relevance, return summary.
+Build semantic query with project prefix + keywords + optional date. Prefer native MEMORY.md and configured `memory_search`/`memory_read` tools. Filter by relevance and return a summary.
 
 ## Query Guidelines
 
-Always include project name. Use task-based, temporal, or topic-based queries. Avoid complex where filters (they fail in Chroma).
+Always include project name. Use task-based, temporal, or topic-based queries. Avoid backend-specific filter syntax unless the configured memory MCP documents it.
 
 ## Native MEMORY.md Compaction
 
@@ -60,7 +60,7 @@ Treat native auto-memory as an index, not a transcript. Keep the first 200 loade
 
 ## Config
 
-Provider: claude-mem | Collection: claude_memories | Archive: ~/.claude-mem/archives/
+Provider order: native MEMORY.md first; optional omx-memory or AgentMemory-compatible MCP only when a searchable backend is configured. Deprecated Chroma memory providers are intentionally not used.
 
 ## Session-End Auto-Save
 
@@ -75,9 +75,9 @@ When triggered by session-end signal from orchestrator:
    - Existing behaviors observed again → promote confidence level
    - Contradicted behaviors → flag for review or demote
 3. **Update native auto-memory** (MEMORY.md) with session learnings + behaviors
-4. **Return formatted summary** to orchestrator for MCP persistence (claude-mem, episodic-memory)
+4. **Return formatted summary** to orchestrator for optional MCP persistence (omx-memory/AgentMemory-compatible backends; episodic indexing is automatic when configured)
 
-> **Note**: MCP tools (claude-mem, episodic-memory) are orchestrator-scoped and cannot be called from subagents. The orchestrator handles MCP saves directly after receiving the formatted summary.
+> **Note**: MCP tools are orchestrator-scoped and cannot be called from subagents. The orchestrator handles searchable memory saves directly after receiving the formatted summary.
 
 ### Confidence Decay Check
 

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/ontology/agents.yaml

@@ -39,7 +39,7 @@ classes:
     agents: [scholastic]
     description: "Reasoning, critique, and coordination specialists"
   SystemAgent:
-    agents: [sys-memory-keeper, sys-naggy]
+    agents: [sys-memory-keeper, sys-naggy, tracker-checkpoint]
     description: "System utility agents"
 
 # Agent instances
@@ -526,14 +526,14 @@ agents:
 
   sys-memory-keeper:
     class: SystemAgent
-    description: "Use when you need to manage session memory persistence using claude-mem, save context before compaction, restore context on session start, or query past memories"
+    description: "Use when you need to manage session memory persistence using native memory plus omx-memory, save context before compaction, restore context on session start, or query past memories"
     model: sonnet
     memory: project
     effort: medium
     skills: [memory-management, memory-save, memory-recall]
     tools: [Read, Write, Edit, Grep, Glob, Bash]
-    summary: "Session memory manager for context persistence with claude-mem"
-    keywords: [memory, persistence, claude-mem, context, session, recall, chroma, semantic-search]
+    summary: "Session memory manager for native memory and approved searchable persistence"
+    keywords: [memory, persistence, omx-memory, context, session, recall, semantic-search]
     file_patterns: []
 
   sys-naggy:
@@ -548,6 +548,18 @@ agents:
     keywords: [todo, tasks, reminders, tracking, deadlines, project-momentum]
     file_patterns: ["TODO.md", "*.todo"]
 
+  tracker-checkpoint:
+    class: SystemAgent
+    description: "Use when pipeline or DAG execution needs checkpoint persistence, state transition validation, or resume-after-failure support"
+    model: sonnet
+    memory: project
+    effort: medium
+    skills: [dag-orchestration, pipeline-guards]
+    tools: [Read, Write, Edit, Grep, Glob, Bash]
+    summary: "Pipeline checkpoint tracker for resumable DAG and pipeline state"
+    keywords: [pipeline, checkpoint, resume, dag, state, tracker]
+    file_patterns: ["/tmp/.codex-pipeline-*.json", "/tmp/.codex-dag-*.json"]
+
   scholastic:
     class: CoordinationAgent
     description: "Ontology-first reasoning reviewer for category mistakes, hidden assumptions, modality separation, scholastic critique, and minimal-repair proposals."

package/templates/.claude/ontology/skills.yaml

@@ -292,29 +292,29 @@ skills:
 
   memory-management:
     class: MemorySkill
-    description: "Memory persistence operations using claude-mem"
+    description: "Memory persistence operations using native memory plus omx-memory"
     user_invocable: false
     model_invocable: true
-    summary: "Provide memory persistence operations using claude-mem for session context"
-    keywords: [memory, claude-mem, persistence, session, context]
+    summary: "Provide memory persistence operations using native memory and approved searchable backends for session context"
+    keywords: [memory, omx-memory, persistence, session, context]
     rule_references: [R011]
 
   memory-recall:
     class: MemorySkill
-    description: "Search and recall memories from claude-mem"
+    description: "Search and recall memories from native memory plus omx-memory"
     user_invocable: true
     model_invocable: true
-    summary: "Search and recall relevant memories from claude-mem using semantic search"
-    keywords: [memory, recall, search, semantic, claude-mem]
+    summary: "Search and recall relevant memories from approved searchable backends"
+    keywords: [memory, recall, search, semantic, omx-memory]
     rule_references: [R011]
 
   memory-save:
     class: MemorySkill
-    description: "Save current session context to claude-mem"
+    description: "Save current session context to native memory plus omx-memory"
     user_invocable: true
     model_invocable: false
-    summary: "Save current session context to claude-mem for persistence across compaction"
-    keywords: [memory, save, session, context, claude-mem]
+    summary: "Save current session context to native memory and approved searchable backends"
+    keywords: [memory, save, session, context, omx-memory]
     rule_references: [R011]
 
   monitoring-setup:

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.