oh-my-customcodex 0.1.0

package/templates/.claude/skills/deep-plan/SKILL.md

@@ -0,0 +1,344 @@
+---
+name: deep-plan
+description: Research-validated planning — research → plan → verify cycle for high-confidence implementation plans
+scope: core
+context: fork
+version: 1.0.0
+user-invocable: true
+argument-hint: "<topic-or-issue>"
+teams-compatible: true
+---
+
+# Deep Plan Skill
+
+Research-validated planning that eliminates the gap between research assumptions and actual code. Orchestrates a 3-phase cycle: Discovery Research → Reality-Check Planning → Plan Verification.
+
+**Teams-compatible** — works both from the main conversation (R010) and inside Agent Teams members. When used in Teams, the member directly executes the 3-phase workflow without Skill tool invocation.
+
+## Usage
+
+```
+/deep-plan <topic-or-issue>
+/deep-plan "implement caching layer for API responses"
+/deep-plan #325 new authentication system
+/deep-plan Rust async runtime migration
+```
+
+## Problem Solved
+
+Research-only analysis (like `/research`) produces findings based on assumptions about the codebase. These assumptions often diverge from reality:
+
+| Assumption | Reality | Impact |
+|------------|---------|--------|
+| "Feature X is missing" | Already implemented | Wasted effort on duplicate work |
+| "Pattern Y is needed" | Partially exists | Over-engineering existing code |
+| "Library Z is required" | Already a dependency | Unnecessary integration effort |
+
+`/deep-plan` solves this by cross-referencing research findings against actual code before committing to a plan.
+
+## Architecture — 3 Phases
+
+### Phase 1: Discovery Research
+
+Invoke the `/research` skill internally for comprehensive topic analysis.
+
+```
+Phase 1: Discovery Research
+├── Skill(research, args="<topic>")
+├── 10-team parallel analysis (3 batches × 4/4/2)
+├── Cross-verification loop (opus + codex)
+├── ADOPT / ADAPT / AVOID taxonomy
+└── Output: research report (artifact)
+```
+
+**Execution**:
+- **Orchestrator mode**: Delegates to `/research` skill via `Skill(research, args="<topic>")`.
+- **Teams mode**: Executes the research workflow inline (see Teams Mode section). The member spawns research teams directly as sub-agents.
+
+The executor waits for completion before proceeding to Phase 2.
+
+**Output**: Full research report with ADOPT/ADAPT/AVOID taxonomy.
+
+### Phase 2: Reality-Check Planning
+
+Ground-truth the research findings against the actual codebase.
+
+```
+Phase 2: Reality-Check Planning
+├── EnterPlanMode
+├── Explore agents (up to 3 parallel)
+│   ├── Explore 1: Verify ADOPT items exist/don't exist
+│   ├── Explore 2: Check ADAPT items for current state
+│   └── Explore 3: Validate AVOID alternatives
+├── Gap analysis table
+├── Refined plan (real gaps only)
+└── ExitPlanMode → user approval
+```
+
+**Steps**:
+
+1. **Enter Plan Mode**: `EnterPlanMode` to activate planning context
+2. **Codebase Exploration**: Spawn up to 3 Explore agents in parallel to verify research assumptions:
+   - Each ADOPT item: Does it already exist? Partially implemented?
+   - Each ADAPT item: What is the current state to adapt from?
+   - Each AVOID item: Are the alternatives already available?
+3. **Gap Analysis**: Build a reconciliation table:
+
+   ```
+   | Research Finding | Actual Code State | Gap Type | Action |
+   |-----------------|-------------------|----------|--------|
+   | "No caching"    | Redis client exists | Overestimate | Remove from plan |
+   | "Need auth middleware" | No auth layer | Real gap | Keep in plan |
+   | "Migrate to v3" | Already on v3.1 | Overestimate | Remove from plan |
+   | "Add rate limiting" | Basic limiter exists | Partial gap | Adapt existing |
+   ```
+
+4. **Refined Plan**: Write implementation plan containing ONLY real gaps:
+   - Remove overestimates (already implemented)
+   - Adjust partial gaps (adapt, don't rebuild)
+   - Prioritize real gaps by impact
+5. **User Approval**: `ExitPlanMode` presents the refined plan for user review
+
+### Phase 3: Plan Verification Research
+
+Validate the refined plan with focused research before implementation begins.
+
+```
+Phase 3: Plan Verification Research
+├── 3-team focused verification
+│   ├── T1: Technical feasibility
+│   ├── T2: Conflict/duplication check
+│   └── T3: Test strategy & risk
+├── Verdict: PASS or REVISE
+├── PASS → implementation advisory
+└── REVISE → return to Phase 2
+```
+
+**Teams** (3 parallel, NOT full 10-team):
+
+| Team | Focus | Verifies |
+|------|-------|----------|
+| T1 | Technical feasibility | Can the plan be implemented with current stack/deps? |
+| T2 | Conflict & duplication | Does the plan conflict with in-flight work or duplicate existing code? |
+| T3 | Test strategy & risk | Is the plan testable? What are the failure modes? |
+
+**Invocation**: Phase 3 teams are spawned directly as parallel agents (NOT via `Skill(research)`). The orchestrator creates 3 focused agents, each with a specific verification mandate derived from the Phase 2 plan.
+
+**Model selection**: sonnet for teams, opus for synthesis.
+
+**Verdict**:
+- **PASS**: Plan is verified. Display implementation advisory.
+- **REVISE**: Issues found. Return to Phase 2 with feedback for plan refinement.
+- **REVISE limit**: After 2 REVISE cycles, escalate to user for manual judgment.
+
+## Workflow Diagram
+
+```
+User: /deep-plan "topic"
+  │
+  ├─ Phase 1: Discovery Research
+  │   ├─ Skill(research, args="topic")
+  │   ├─ 10-team analysis → ADOPT/ADAPT/AVOID
+  │   └─ Output: research artifact
+  │
+  ├─ Phase 2: Reality-Check Planning
+  │   ├─ EnterPlanMode
+  │   ├─ Explore agents (up to 3 parallel)
+  │   ├─ Gap analysis: research vs actual code
+  │   ├─ Refined plan (real gaps only)
+  │   └─ ExitPlanMode → user approval
+  │
+  └─ Phase 3: Plan Verification
+      ├─ 3-team focused research
+      ├─ Verdict: PASS or REVISE
+      ├─ PASS → implementation advisory
+      └─ REVISE → loop back to Phase 2 (max 2 cycles)
+```
+
+## Differentiation
+
+| Skill | Scope | Code Verification | Phases |
+|-------|-------|-------------------|--------|
+| `/research` | Analysis only | None — assumption-based | 1 |
+| Plan mode | Planning only | Yes — code exploration | 1 |
+| `/structured-dev-cycle` | Full implementation | Yes — stage-by-stage | 6 |
+| **`/deep-plan`** | **Analysis + Planning + Verification** | **3-pass cross-verification** | **3** |
+
+`/deep-plan` fills the gap between research (which lacks code grounding) and implementation (which lacks upfront analysis). It produces a **verified plan** ready for execution.
+
+## Display Format
+
+Before execution:
+```
+[Deep Plan] {topic}
+├── Phase 1: Discovery Research (10 teams, 3 batches)
+├── Phase 2: Reality-Check Planning (up to 3 Explore agents)
+└── Phase 3: Plan Verification (3 focused teams)
+
+Estimated phases: 3 | Models: sonnet → opus
+Execute? [Y/n]
+```
+
+Phase transitions:
+```
+[Deep Plan] Phase 1/3 — Discovery Research
+├── Research skill active...
+└── Awaiting 10-team results
+
+[Deep Plan] Phase 2/3 — Reality-Check Planning
+├── Gap analysis: 6 ADOPT items → 2 real gaps, 4 overestimates
+└── Refined plan: 5 action items (down from 12)
+
+[Deep Plan] Phase 3/3 — Plan Verification
+├── T1 (feasibility): ✓ PASS
+├── T2 (conflicts): ✓ PASS
+├── T3 (test/risk): ✓ PASS
+└── Verdict: PASS — ready for implementation
+```
+
+## Post-Completion Advisory
+
+After PASS verdict:
+```
+[Advisory] Verified plan ready for implementation.
+├── For complex implementations (10+ files): /structured-dev-cycle
+├── For parallel task execution: superpowers:subagent-driven-development
+└── For simple tasks (< 3 files): proceed directly
+```
+
+## Execution Rules
+
+| Rule | Detail |
+|------|--------|
+| Phase 1 | Full `/research` skill invocation (10 teams) |
+| Phase 2 | Max 3 parallel Explore agents (R009) |
+| Phase 3 | Max 3 parallel verification teams (R009) |
+| Orchestrator only | Main conversation manages all phases (R010) |
+| Intent display | Show phase plan before execution (R015) |
+| Ecomode | Auto-activate for team result aggregation (R013) |
+| REVISE limit | Max 2 cycles before user escalation |
+
+## Agent Teams (R018)
+
+When Agent Teams is enabled, Phase 1 and Phase 3 parallel teams SHOULD use Agent Teams instead of individual Agent tool calls:
+
+| Phase | Without Agent Teams | With Agent Teams |
+|-------|--------------------|--------------------|
+| Phase 1 | Delegates to `/research` (handles internally) | Delegates to `/research` (handles internally) |
+| Phase 2 | Up to 3 Explore agents via Agent tool | Up to 3 Explore agents via Agent tool (below threshold) |
+| Phase 3 | 3 agents via Agent tool | 3 agents — at threshold, prefer Agent Teams for coordination |
+
+Phase 1 delegation to `/research` means Agent Teams decisions are handled by the research skill itself. Phase 3's 3-team verification is at the Agent Teams threshold (3+ agents) and benefits from peer messaging for cross-verification.
+
+## Model Selection
+
+| Phase | Component | Model | Rationale |
+|-------|-----------|-------|-----------|
+| Phase 1 | Research teams | sonnet | Delegated to /research skill |
+| Phase 1 | Verification | opus | Delegated to /research skill |
+| Phase 2 | Explore agents | haiku | Fast codebase search |
+| Phase 2 | Gap analysis | opus | Complex reconciliation reasoning |
+| Phase 3 | Verification teams | sonnet | Balanced analysis |
+| Phase 3 | Synthesis/verdict | opus | Final judgment |
+
+## Cost Estimate
+
+| Phase | Approximate Cost | Driver |
+|-------|-----------------|--------|
+| Phase 1 | High | Full 10-team `/research` invocation |
+| Phase 2 | Low-Medium | Up to 3 Explore agents (haiku) + 1 opus synthesis |
+| Phase 3 | Medium | 3 sonnet verification teams + 1 opus synthesis |
+| **Total** | **High** | Dominated by Phase 1 research cost |
+
+`/deep-plan` is designed for high-stakes decisions where plan quality justifies the cost. For quick planning, use `EnterPlanMode` directly.
+
+## Integration
+
+| Component | Integration |
+|-----------|-------------|
+| `/research` | Phase 1 full invocation (via Skill tool or inline in Teams mode) + Phase 3 reduced invocation pattern |
+| EnterPlanMode/ExitPlanMode | Phase 2 plan creation and user approval |
+| Explore agents | Phase 2 codebase verification (up to 3 parallel) |
+| R009 | Phase 1 (10 teams batched), Phase 2 (3 Explore), Phase 3 (3 teams) |
+| R010 | Orchestrator manages all 3 phases; teams are subagents |
+| R013 | Ecomode for team result aggregation |
+| R015 | Phase transition intent display |
+| result-aggregation | Phase 1 and 3 result formatting |
+| superpowers:subagent-driven-development | Post-PASS implementation advisory (external plugin) |
+
+## Fallback Behavior
+
+| Scenario | Fallback |
+|----------|----------|
+| Phase 1 `/research` fails | Manual analysis, then proceed to Phase 2 |
+| Phase 2 EnterPlanMode unavailable | Perform analysis without plan mode context |
+| Phase 3 REVISE ≥ 2 times | Escalate to user for manual judgment |
+| Explore agent failure | Reduce parallel count, retry with remaining |
+| Partial team failure | Synthesize from available results, note gaps |
+
+## Teams Mode
+
+When running inside an Agent Teams member (not via Skill tool), the deep-plan workflow operates identically but with these adaptations:
+
+### How It Works
+
+The orchestrator reads this SKILL.md and includes the deep-plan instructions directly in the Teams member's prompt. The member then:
+
+1. Phase 1: Executes research workflow inline (not via `Skill(research)`) — spawns 10 research teams as sub-agents
+2. Phase 2: Uses EnterPlanMode/ExitPlanMode and Explore agents normally
+3. Phase 3: Spawns 3 verification teams as sub-agents
+4. Delivers final verified plan via `SendMessage` to team lead
+
+### Prompt Embedding Pattern
+
+```
+# When spawning a Teams member for deep-plan:
+Agent(
+  name: "planner-1",
+  team_name: "my-team",
+  prompt: """
+  You are a deep-plan agent. Follow the deep-plan skill workflow below:
+  {contents of deep-plan/SKILL.md}
+
+  Also follow this research workflow for Phase 1:
+  {contents of research/SKILL.md}
+
+  Topic: {user's planning topic}
+  Deliver verified plan via SendMessage to team lead when complete.
+  """
+)
+```
+
+### Differences from Orchestrator Mode
+
+| Aspect | Orchestrator Mode | Teams Mode |
+|--------|------------------|------------|
+| Invocation | `Skill(deep-plan)` | Prompt embedding |
+| Phase 1 research | `Skill(research)` | Inline execution |
+| Result delivery | Return to main conversation | `SendMessage` to team lead |
+| Plan approval | User via ExitPlanMode | Team lead via SendMessage |
+| Context isolation | Previously used `context: fork` | Standard context (no fork) |
+
+### Why No context: fork
+
+`context: fork` was removed to enable Teams compatibility. Fork blocks sub-agent spawning, which is essential for Phase 1 (10 research teams) and Phase 3 (3 verification teams). Without fork, deep-plan operates in the standard context, which is required for both orchestrator and Teams usage.
+
+## Artifact Persistence
+
+Phase 1 research artifact is persisted by the `/research` skill.
+
+Phase 3 verification report is persisted by the final synthesis agent:
+```
+.codex/outputs/sessions/{YYYY-MM-DD}/deep-plan-{HHmmss}.md
+```
+
+With metadata header:
+```markdown
+---
+skill: deep-plan
+date: {ISO-8601 with timezone}
+query: "{original user query}"
+phases_completed: 3
+verdict: PASS|REVISE
+---
+```

package/templates/.claude/skills/deep-verify/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: deep-verify
+description: Multi-angle release quality verification using parallel expert review teams
+scope: core
+version: 1.1.0
+user-invocable: true
+effort: high
+---
+
+# /deep-verify — Multi-Angle Release Quality Verification
+
+## Purpose
+
+Performs deep cross-iterative verification of code changes before release, using multiple independent review perspectives to catch issues that single-pass review misses.
+
+## Usage
+
+```
+/deep-verify [branch|PR]
+```
+
+If no argument, verifies current branch against its base (usually `develop`).
+
+## Workflow
+
+### Round 1: Baseline Assessment
+- Gather the full diff (`git diff develop...HEAD`)
+- Run test suite, lint, and type check
+- Collect results as baseline
+
+### Round 2: Parallel Expert Review (6 agents)
+Spawn 6 parallel review agents, each with a different focus:
+
+1. **Correctness Reviewer** — Logic errors, edge cases, off-by-one, null handling
+2. **Security Reviewer** — Injection, auth bypass, data exposure, OWASP top 10
+3. **Performance Reviewer** — O(n^2) loops, unbounded queries, memory leaks, missing indexes
+4. **Integration Reviewer** — API contract breaks, migration safety, cross-module side effects
+5. **Philosophy Reviewer** — Project concept/metaphor alignment, separation of concerns (R006), orchestrator rules (R010), advisory-first enforcement (R021), compilation metaphor integrity
+6. **Regression & Performance Reviewer** — Feature regression risk, API contract preservation, query performance impact, index effectiveness, algorithm complexity at realistic scale
+
+Each agent receives the full diff and returns findings as structured JSON:
+```json
+{
+  "severity": "HIGH|MEDIUM|LOW",
+  "file": "path/to/file",
+  "line": 42,
+  "finding": "description",
+  "suggestion": "fix suggestion"
+}
+```
+
+### Round 3: Cross-Verification
+- Merge all findings from Round 2
+- Deduplicate (same file+line+similar finding = 1 entry)
+- For each HIGH finding: spawn a verification agent to confirm or dismiss as FALSE POSITIVE
+- Evidence-based: each confirmation must include proof (e.g., `toQuery()` output, test result)
+
+### Round 4: FALSE POSITIVE Filter
+- Remove confirmed false positives with evidence
+- Remaining findings are CONFIRMED issues
+
+### Round 5: Fix Application
+- For each CONFIRMED HIGH/MEDIUM finding: spawn fix agent
+- Run tests after fixes
+- If tests fail: revert fix, report as "needs manual review"
+
+### Round 6: Final Verification
+- Re-run full test suite
+- Re-run lint and type check
+- Generate summary report
+
+### Round 7: Philosophy & Regression Gate
+- Verify all changes align with project's compilation metaphor (Skills=source, Agents=artifacts, Rules=spec)
+- Check separation of concerns: no agents containing skill logic, no skills with agent definitions
+- Verify orchestrator rules: no new file writes from orchestrator context
+- Check advisory-first: no new hard-blocking hooks introduced
+- Confirm no feature regressions: existing APIs preserved, test coverage maintained
+- Performance sanity: no O(n^2) on large datasets, no missing indexes for new queries
+- If any CONCERN or VIOLATION found: report for manual review before release
+
+## Output Format
+
+```
+╔══════════════════════════════════════════════════════╗
+║  Deep Verification Report                            ║
+╠══════════════════════════════════════════════════════╣
+║  Branch: {branch}                                    ║
+║  Commits: {count}                                    ║
+║  Files changed: {count}                              ║
+╠══════════════════════════════════════════════════════╣
+║  Findings:                                           ║
+║    HIGH:   {n} ({confirmed} confirmed, {fp} FP)      ║
+║    MEDIUM: {n} ({confirmed} confirmed, {fp} FP)      ║
+║    LOW:    {n}                                       ║
+╠══════════════════════════════════════════════════════╣
+║  Fixes Applied: {n}                                  ║
+║  Tests: {pass}/{total} passing                       ║
+║  Verdict: READY / NEEDS REVIEW / BLOCKED             ║
+║  Philosophy: ALIGNED / {n} CONCERNS                  ║
+║  Regression: CLEAN / {n} RISKS                       ║
+╚══════════════════════════════════════════════════════╝
+```
+
+## Notes
+
+- Round 2 agents use `model: sonnet` for cost efficiency
+- Round 3 verification agents use `model: opus` for reasoning depth
+- FALSE POSITIVE filtering is critical — previous releases showed 80%+ FP rate on automated review
+- This skill replaces ad-hoc cross-verification with a repeatable process
+- Round 7 philosophy check references AGENTS.md architecture section and R006/R010/R021 rules
+- Regression check compares function signatures, export lists, and test counts against develop baseline

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

@@ -0,0 +1,161 @@
+---
+name: dev-lead-routing
+description: Routes development tasks to the correct language or framework expert agent. Use when user requests code review, implementation, refactoring, or debugging.
+scope: core
+user-invocable: false
+context: fork
+---
+
+# Dev Lead Routing
+
+## Engineers
+
+| Type | Agents |
+|------|--------|
+| Language | lang-golang-expert, lang-python-expert, lang-rust-expert, lang-kotlin-expert, lang-typescript-expert, lang-java21-expert |
+| Frontend | fe-vercel-agent, fe-vuejs-agent, fe-svelte-agent, fe-flutter-agent, fe-design-expert |
+| Backend | be-fastapi-expert, be-springboot-expert, be-go-backend-expert, be-nestjs-expert, be-express-expert, be-django-expert |
+| Tooling | tool-npm-expert, tool-optimizer, tool-bun-expert |
+| Database | db-supabase-expert, db-postgres-expert, db-redis-expert, db-alembic-expert |
+| Architect | arch-documenter, arch-speckit-agent |
+| Security | sec-codeql-expert |
+| Infra | infra-docker-expert, infra-aws-expert |
+
+## File Extension Mapping
+
+| Extension | Agent |
+|-----------|-------|
+| `.go` | lang-golang-expert |
+| `.py` | lang-python-expert |
+| `.rs` | lang-rust-expert |
+| `.kt`, `.kts` | lang-kotlin-expert |
+| `.ts`, `.tsx` | lang-typescript-expert |
+| `.java` | lang-java21-expert |
+| `.js/.jsx` (React) | fe-vercel-agent |
+| `.vue` | fe-vuejs-agent |
+| `.svelte` | fe-svelte-agent |
+| `.dart`, `pubspec.yaml` | fe-flutter-agent |
+| `.sql` (PG) | db-postgres-expert |
+| `.sql` (Supabase) | db-supabase-expert |
+| `alembic.ini`, `alembic/versions/*.py` | db-alembic-expert |
+| `Dockerfile`, `*.dockerfile` | infra-docker-expert |
+| `*.tf`, `*.tfvars` | infra-aws-expert |
+| `*.yaml`, `*.yml` (CloudFormation) | infra-aws-expert |
+
+## Keyword Mapping
+
+| Keywords | Agent |
+|----------|-------|
+| go, golang | lang-golang-expert |
+| python, py | lang-python-expert |
+| rust | lang-rust-expert |
+| kotlin | lang-kotlin-expert |
+| typescript, ts | lang-typescript-expert |
+| java | lang-java21-expert |
+| react, next.js, vercel | fe-vercel-agent |
+| vue | fe-vuejs-agent |
+| svelte | fe-svelte-agent |
+| flutter, dart, riverpod, bloc, widget | fe-flutter-agent |
+| design, typography, color, motion, ux writing, ui design, "design system", "design review", impeccable | fe-design-expert |
+| fastapi | be-fastapi-expert |
+| django | be-django-expert |
+| spring, springboot | be-springboot-expert |
+| nestjs | be-nestjs-expert |
+| express | be-express-expert |
+| npm | tool-npm-expert |
+| optimize, bundle | tool-optimizer |
+| bun | tool-bun-expert |
+| postgres, postgresql, psql, pg_stat | db-postgres-expert |
+| redis, cache, pub/sub, sorted set | db-redis-expert |
+| supabase, rls, edge function | db-supabase-expert |
+| alembic, migration, db revision, db upgrade, db downgrade | db-alembic-expert |
+| docker, dockerfile, container, compose | infra-docker-expert |
+| aws, cloudformation, vpc, iam, s3, lambda, cdk, terraform | infra-aws-expert |
+| security, codeql, cve, vulnerability, sarif, sast, security audit | sec-codeql-expert |
+| architecture, adr, openapi, swagger, diagram | arch-documenter |
+| spec, specification, tdd, requirements | arch-speckit-agent |
+
+## Model Selection
+
+| Task | Model |
+|------|-------|
+| Architecture analysis | opus |
+| Code review/implementation | sonnet |
+| Quick validation/search | haiku |
+
+## Routing Decision (Priority Order)
+
+Before selecting an expert agent, evaluate in this order:
+
+### Step 1: Agent Teams Eligibility (R018)
+Check if Agent Teams is available (`OMCODEX_AGENT_TEAMS=1` or TeamCreate/SendMessage tools present).
+
+| Scenario | Preferred |
+|----------|-----------|
+| Single-language review | Task Tool |
+| Multi-language code review (3+) | Agent Teams |
+| Code review + fix cycle | Agent Teams |
+| Cross-layer debugging (FE + BE + DB) | Agent Teams |
+| Simple file search/validation | Task Tool |
+
+### Step 2: Codex-Exec Hybrid (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%:
+   - 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
+
+**Suitable**: New file creation, boilerplate, scaffolding, test code
+**Unsuitable**: Existing code modification, architecture decisions, bug fixes
+
+### Step 3: Expert Agent Selection
+Route to appropriate language/framework expert based on file extension and keyword mapping.
+
+> **Permission Mode**: When spawning agents, pass `mode: "bypassPermissions"` in the Agent tool call if the session uses bypassPermissions. Without explicit mode, CC defaults to `acceptEdits`.
+
+### Step 4: Ontology-RAG Enrichment (R019)
+
+If `get_agent_for_task` MCP tool is available, call it with the original query and inject `suggested_skills` into the agent prompt. Skip silently on failure.
+
+### Step 5: Soul Injection (R006)
+
+If the selected agent has `soul: true` in frontmatter, read and prepend `.codex/agents/souls/{agent-name}.soul.md` content to the prompt. Skip silently if file doesn't exist.
+
+## Routing Rules
+
+Multi-language: detect all languages, route to parallel experts (max 4). Single-language: route to matching expert. Cross-layer (frontend + backend): multiple experts in parallel.
+
+## No Match Fallback
+
+When file extension or keyword doesn't match any existing agent:
+
+```
+User Input → No matching development agent
+  ↓
+Detect: File extension (.rb, .swift, .php, etc.) or language keyword
+  ↓
+Delegate to mgr-creator with context:
+  domain: detected language/framework
+  type: sw-engineer
+  keywords: extracted from user input
+  file_patterns: detected extensions
+  skills: auto-discover from .codex/skills/
+  guides: auto-discover from templates/guides/
+```
+
+**Examples of dynamic creation triggers:**
+- Unrecognized file extension (e.g., `.rb` → Ruby expert, `.swift` → Swift expert)
+- New framework keyword (e.g., "Flutter 앱 리뷰해줘", "Rails API 만들어줘")
+- Language detected but no specialist exists
+
+Not user-invocable. Auto-triggered on development intent.