oh-my-customcode 0.37.2 → 0.38.0

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

@@ -5,14 +5,14 @@ scope: core
 version: 1.0.0
 user-invocable: true
 argument-hint: "<topic-or-issue>"
-context: fork
+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.
 
-**Orchestrator-only** — only the main conversation uses this skill (R010). All phases execute as subagents.
+**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
 
@@ -50,7 +50,11 @@ Phase 1: Discovery Research
 └── Output: research report (artifact)
 ```
 
-**Execution**: Delegates to `/research` skill via `Skill(research, args="<topic>")`. The orchestrator waits for completion before proceeding to Phase 2.
+**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.
 
@@ -251,7 +255,7 @@ Phase 1 delegation to `/research` means Agent Teams decisions are handled by the
 
 | Component | Integration |
 |-----------|-------------|
-| `/research` | Phase 1 full invocation + Phase 3 reduced invocation pattern |
+| `/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) |
@@ -271,6 +275,53 @@ Phase 1 delegation to `/research` means Agent Teams decisions are handled by the
 | 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.

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

@@ -18,6 +18,7 @@ context: fork
 | Tooling | tool-npm-expert, tool-optimizer, tool-bun-expert |
 | Database | db-supabase-expert, db-postgres-expert, db-redis-expert |
 | Architect | arch-documenter, arch-speckit-agent |
+| Security | sec-codeql-expert |
 | Infra | infra-docker-expert, infra-aws-expert |
 
 ## File Extension Mapping
@@ -67,6 +68,7 @@ context: fork
 | supabase, rls, edge function | db-supabase-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 |
 
@@ -97,10 +99,11 @@ Check if Agent Teams is available (`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` or T
 For **new file creation**, **boilerplate**, or **test code generation**:
 
 1. Check `/tmp/.claude-env-status-*` for codex availability
-2. If codex available → suggest hybrid workflow:
+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)
-   - Claude expert reviews and refines (strength: reasoning, quality)
-3. If codex unavailable → use Claude expert directly
+   - Selected Claude expert reviews and refines codex output (strength: reasoning, quality)
+3. If codex unavailable → display `[Codex] 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
@@ -110,26 +113,11 @@ Route to appropriate language/framework expert based on file extension and keywo
 
 ### Step 4: Ontology-RAG Enrichment (R019)
 
-After agent selection, enrich the spawned agent's prompt with ontology context:
+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.
 
-1. Call `get_agent_for_task(original_query)` via MCP
-2. Extract `suggested_skills` from response
-3. If `suggested_skills` non-empty, prepend to spawned agent prompt:
-   `"Ontology context suggests these skills may be relevant: {suggested_skills}"`
-4. On MCP failure: skip silently, proceed with unmodified prompt
+### Step 5: Soul Injection (R006)
 
-**This step is advisory only — it never changes which agent is selected.**
-
-### Step 5: Soul Injection
-
-If the selected agent has `soul: true` in its frontmatter:
-
-1. Read `.claude/agents/souls/{agent-name}.soul.md`
-2. If file exists, prepend soul content to the agent's prompt:
-   `"Identity context:\n{soul content}\n\n---\n\n"`
-3. If file doesn't exist → skip silently (no error, no injection)
-
-**This step runs after ontology-RAG enrichment. Soul content is identity context, not capability instructions.**
+If the selected agent has `soul: true` in frontmatter, read and prepend `.claude/agents/souls/{agent-name}.soul.md` content to the prompt. Skip silently if file doesn't exist.
 
 ## Routing Rules
 

package/templates/.claude/skills/dev-refactor/SKILL.md

@@ -2,7 +2,7 @@
 name: dev-refactor
 description: Refactor code for better structure and patterns
 scope: core
-argument-hint: "<file-or-directory> [--lang <language>]"
+argument-hint: "<file-or-directory> [--lang <language>] [--spec]"
 ---
 
 # Code Refactoring Skill
@@ -198,3 +198,36 @@ Summary:
 
 Recommendation: Run tests to verify changes.
 ```
+
+## Spec Mode (`--spec`)
+
+When the `--spec` flag is present, refactoring is guided by the target's canonical specification:
+
+### Workflow
+
+1. **Load spec**: Read `.claude/specs/<agent-name>.spec.md` (generated by `/omcustom:takeover`)
+   - If spec doesn't exist, run takeover first: `/omcustom:takeover <name>`
+2. **Extract invariants**: Parse the spec's `## Invariants` section as pre-flight guard constraints
+3. **Refactor**: Perform normal refactoring (per existing workflow)
+4. **Verify invariants**: After refactoring, check each invariant still holds:
+   ```
+   [Spec Verification]
+   ├── ✓ Invariant 1: {description} — PASS
+   ├── ✓ Invariant 2: {description} — PASS
+   └── ✗ Invariant 3: {description} — FAIL (reason)
+   ```
+5. **Regenerate spec**: If refactoring changed the contract, run `/omcustom:takeover <name>` to update
+
+### When to Use
+
+| Scenario | Use `--spec`? |
+|----------|--------------|
+| Refactoring agent internals | Yes — preserves declared invariants |
+| Renaming/restructuring skill | Yes — ensures contract stability |
+| Simple code cleanup | No — overhead not justified |
+| Adding new capability | No — spec will change anyway |
+
+### Prerequisites
+
+- `.claude/specs/<name>.spec.md` must exist (or will be auto-generated via takeover)
+- Target must be an agent or skill (not arbitrary code)

package/templates/.claude/skills/evaluator-optimizer/SKILL.md

@@ -46,6 +46,14 @@ evaluator-optimizer:
 | `quality_gate.threshold` | No | `0.8` | Score threshold (for `score_threshold` type) |
 | `max_iterations` | No | `3` | Max refinement loops (hard cap: 5) |
 
+### Model Selection Guidance
+
+For model selection within the evaluator-optimizer loop, follow the [reasoning-sandwich](/skills/reasoning-sandwich) pattern:
+
+- **Generator**: Use `sonnet` (default) — optimized for content generation
+- **Evaluator**: Use `opus` (default) — benefits from stronger reasoning for quality assessment
+- **Override**: For simpler domains, `sonnet`/`sonnet` is acceptable; for critical domains, consider `opus`/`opus`
+
 ## Quality Gate Types
 
 | Type | Behavior |
@@ -148,6 +156,7 @@ The evaluator MUST return a structured verdict in this format:
 | Documentation | `arch-documenter` | opus reviewer | Completeness, clarity, accuracy |
 | Architecture | Plan agent | opus reviewer | No SPOFs, no circular deps |
 | Test plans | `qa-planner` | `qa-engineer` | Coverage, edge cases, feasibility |
+| Test coverage | `qa-writer` | `qa-engineer` + coverage tool | `coverage >= target%` |
 | Agent creation | `mgr-creator` | opus reviewer | Frontmatter validity, R006 compliance |
 | Security audit | `sec-codeql-expert` | opus reviewer | Vulnerability coverage, false positive rate |
 
@@ -208,6 +217,50 @@ evaluator-optimizer:
   max_iterations: 3
 ```
 
+### Domain: Test Coverage Optimization
+
+```yaml
+evaluator-optimizer:
+  generator:
+    agent: qa-writer
+    model: sonnet
+  evaluator:
+    agent: qa-engineer
+    model: sonnet
+  rubric:
+    - criterion: line_coverage
+      weight: 0.4
+      description: "Percentage of code lines exercised by tests"
+    - criterion: branch_coverage
+      weight: 0.3
+      description: "Percentage of conditional branches tested"
+    - criterion: edge_cases
+      weight: 0.2
+      description: "Critical edge cases explicitly tested"
+    - criterion: test_quality
+      weight: 0.1
+      description: "Tests are meaningful, not just hitting lines"
+  quality_gate:
+    type: score_threshold
+    threshold: 0.8
+  max_iterations: 5
+  parameters:
+    target_coverage: 80        # Minimum coverage percentage
+    max_iterations: 5          # Hard cap (matches skill-level cap)
+```
+
+**Workflow**:
+1. qa-writer generates test cases targeting uncovered code
+2. qa-engineer runs tests and measures coverage
+3. If coverage < target: qa-writer generates additional tests for uncovered paths
+4. Repeat until target reached or max_iterations exhausted
+
+**Parameters**:
+| Parameter | Default | Description |
+|-----------|---------|-------------|
+| `target_coverage` | 80% | Minimum acceptable coverage |
+| `max_iterations` | 5 | Hard cap on refinement loops |
+
 ## Integration
 
 | Rule | Integration |

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

@@ -47,261 +47,26 @@ full_qa_cycle      → all agents (sequential)
 
 ### Ontology-RAG Enrichment (R019)
 
-After agent selection, enrich the spawned agent's prompt with ontology context:
+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.
 
-1. Call `get_agent_for_task(original_query)` via MCP
-2. Extract `suggested_skills` from response
-3. If `suggested_skills` non-empty, prepend to spawned agent prompt:
-   `"Ontology context suggests these skills may be relevant: {suggested_skills}"`
-4. On MCP failure: skip silently, proceed with unmodified prompt
+### Step 5: Soul Injection (R006)
 
-**This step is advisory only — it never changes which agent is selected.**
+If the selected agent has `soul: true` in frontmatter, read and prepend `.claude/agents/souls/{agent-name}.soul.md` content to the prompt. Skip silently if file doesn't exist.
 
-### Step 5: Soul Injection
+## Sequential Workflow Ordering
 
-If the selected agent has `soul: true` in its frontmatter:
-
-1. Read `.claude/agents/souls/{agent-name}.soul.md`
-2. If file exists, prepend soul content to the agent's prompt:
-   `"Identity context:\n{soul content}\n\n---\n\n"`
-3. If file doesn't exist → skip silently (no error, no injection)
-
-**This step runs after ontology-RAG enrichment. Soul content is identity context, not capability instructions.**
-
-## Routing Rules
-
-### 1. Test Planning
-
-```
-User: "Create test plan for feature X"
-
-Route:
-  Agent(qa-planner role → create test plan, model: "sonnet")
-
-Output:
-  - Test scenarios
-  - Coverage targets
-  - Acceptance criteria
-  - Risk assessment
-```
-
-### 2. Test Documentation
-
-```
-User: "Document test cases for API"
-
-Route:
-  Agent(qa-writer role → document test cases, model: "sonnet")
-
-Output:
-  - Test case specifications
-  - Test data requirements
-  - Expected results
-  - Test templates
-```
-
-### 3. Test Execution
-
-```
-User: "Execute tests for module Y"
-
-Route:
-  Agent(qa-engineer role → execute tests, model: "sonnet")
-
-Output:
-  - Test execution results
-  - Pass/fail metrics
-  - Defect reports
-  - Coverage reports
-```
-
-### 4. Quality Analysis
-
-When analysis is needed (parallel execution):
-
-```
-User: "Analyze quality metrics"
-
-Route (parallel):
-  Agent(qa-planner role → analyze strategy, model: "sonnet")
-  Agent(qa-engineer role → analyze results, model: "sonnet")
-
-Aggregate:
-  Strategy insights + execution data
-```
-
-### 5. Full QA Cycle (Sequential)
-
-For complete quality assurance workflow:
-
-```
-User: "Run full QA cycle for feature Z"
-
-Route (sequential):
-  1. Agent(qa-planner role → create test plan, model: "sonnet")
-  2. Agent(qa-writer role → document test cases, model: "sonnet")
-  3. Agent(qa-engineer role → execute tests, model: "sonnet")
-  4. Agent(qa-writer role → generate report, model: "sonnet")
-
-Aggregate and present final report
-```
-
-## Full QA Cycle Workflow
-
-```
-1. Planning Phase (qa-planner)
-   - Analyze requirements
-   - Define test scenarios
-   - Set acceptance criteria
-   - Identify risks
-
-2. Documentation Phase (qa-writer)
-   - Write test cases
-   - Define test data
-   - Document expected results
-   - Create templates
-
-3. Execution Phase (qa-engineer)
-   - Execute test cases
-   - Record results
-   - Report defects
-   - Calculate coverage
-
-4. Reporting Phase (qa-writer)
-   - Aggregate results
-   - Generate reports
-   - Document findings
-   - Provide recommendations
-
-5. Aggregation (qa-lead routing)
-   - Combine all phases
-   - Present unified status
-   - Highlight critical issues
-```
-
-## Sequential vs Parallel Execution
-
-### Sequential (typical for QA workflow)
-
-QA workflow is typically sequential because each phase depends on the previous:
-- Planning must complete before documentation
-- Documentation must complete before execution
-- Execution must complete before reporting
+Full QA cycle follows sequential phases (each depends on the previous):
 
 ```
 qa-planner → qa-writer → qa-engineer → qa-writer
    (plan)    (document)    (execute)     (report)
 ```
 
-### Parallel (rare, for independent analyses)
-
-Only when tasks are truly independent:
-- Quality analysis (strategy + results)
-- Multi-module testing (independent modules)
-
-```
-Example:
-  Agent(qa-engineer role → test module A, model: "sonnet")
-  Agent(qa-engineer role → test module B, model: "sonnet")
-  Agent(qa-engineer role → test module C, model: "sonnet")
-```
+Parallel execution only for independent analyses (e.g., multi-module testing). See R009.
 
 ## Sub-agent Model Selection
 
-### Model Mapping
-
-| Agent | Recommended Model | Reason |
-|-------|-------------------|--------|
-| qa-planner | `sonnet` | Strategy requires balanced reasoning |
-| qa-writer | `sonnet` | Documentation quality matters |
-| qa-engineer | `sonnet` | Test execution needs accuracy |
-
-All QA agents typically use `sonnet` for balanced quality output.
-
-### Agent Call Examples
-
-```
-# Test planning
-Agent(
-  subagent_type: "general-purpose",
-  prompt: "Create comprehensive test plan for authentication feature following qa-planner guidelines",
-  model: "sonnet"
-)
-
-# Test documentation
-Agent(
-  subagent_type: "general-purpose",
-  prompt: "Document test cases for API endpoints following qa-writer guidelines",
-  model: "sonnet"
-)
-
-# Test execution
-Agent(
-  subagent_type: "general-purpose",
-  prompt: "Execute integration tests and report results following qa-engineer guidelines",
-  model: "sonnet"
-)
-```
-
-## Display Format
-
-### Full QA Cycle
-
-```
-[Planning] Delegating to qa-planner...
-  → Test plan created (15 scenarios)
-
-[Documentation] Delegating to qa-writer...
-  → 15 test cases documented
-
-[Execution] Delegating to qa-engineer...
-  → 13 passed, 2 failed
-
-[Report] Generating summary...
-  Coverage: 85%
-  Pass Rate: 87%
-  Defects: 2 (1 High, 1 Medium)
-
-[Done] QA cycle completed
-```
-
-### Parallel Quality Analysis
-
-```
-[Analyzing] Spawning parallel analysis...
-
-[Instance 1] strategy-analysis:sonnet → qa-planner
-[Instance 2] results-analysis:sonnet → qa-engineer
-
-[Progress] ████████████ 2/2
-
-[Summary]
-  Strategy: Coverage targets met, add edge cases
-  Results: 85% pass rate, 2 critical defects
-
-Analysis completed.
-```
-
-## Integration with Other Agents
-
-- **Receives requirements from**: arch-speckit-agent (sw-architect)
-- **Reports quality status to**: dev-lead
-- **Coordinates with**: Language experts for automated tests
-- **Provides feedback to**: Development team via dev-lead
-
-## Metrics Tracking
-
-QA lead routing should aggregate these metrics:
-
-```yaml
-metrics:
-  test_coverage: percentage
-  pass_rate: percentage
-  defect_count: number
-  defect_severity: [critical, high, medium, low]
-  execution_time: duration
-  test_case_count: number
-```
+All QA agents use `sonnet` by default for balanced quality output.
 
 ## No Match Fallback
 

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

@@ -3,13 +3,14 @@ name: research
 description: 10-team parallel deep analysis with cross-verification for any topic, repository, or technology. Use when user invokes /research or asks for comprehensive research.
 scope: core
 user-invocable: true
+teams-compatible: true
 ---
 
 # Research Skill
 
 Orchestrates 10 parallel research teams for comprehensive deep analysis of any topic, GitHub repository, or technology. Produces a structured report with ADOPT/ADAPT/AVOID taxonomy.
 
-**Orchestrator-only** — only the main conversation uses this skill (R010). Teams execute as subagents.
+**Teams-compatible** — works both from the main conversation (R010) and inside Agent Teams members. When used in Teams, the member directly executes the research workflow without Skill tool invocation.
 
 ## Usage
 
@@ -162,8 +163,21 @@ Batch 3: T9, T10            (Innovation)
 
 ### Phase 2: Cross-Verification Loop (min 2, max 30 rounds)
 
+#### Codex Availability Check
+
+Before starting verification rounds, check codex availability:
+
+```bash
+# Run this check once before Phase 2 begins
+which codex &>/dev/null && [ -n "$OPENAI_API_KEY" ]
+# Exit 0 → codex available: enable dual-model verification (opus + codex)
+# Exit 1 → codex unavailable: display notice and proceed with opus-only
+```
+
+If unavailable, display: `[Phase 2] Codex unavailable — opus-only verification`
+
 ```
-Team findings ──→ opus 4.6 verification ──→ codex-exec xhigh verification
+Team findings ──→ opus 4.6 verification ──→ codex-exec xhigh verification (if available)
        │                                              │
        └── Contradiction detected? ── YES ──→ Round N+1
                                       NO  ──→ Consensus reached → Phase 3
@@ -171,7 +185,8 @@ Team findings ──→ opus 4.6 verification ──→ codex-exec xhigh verific
 
 Each round:
 1. **opus 4.6**: Deep reasoning verification — checks logical consistency, identifies gaps, challenges assumptions
-2. **codex-exec xhigh** (if available): Independent code-level verification — validates technical claims, tests feasibility
+2. **codex-exec xhigh** (when available): Independent code-level verification — validates technical claims, tests feasibility
+   - If unavailable: display `[Phase 2] Round {N}: Codex unavailable, proceeding with opus verification only`
 3. **Contradiction resolution**: Reconcile divergent findings between teams and verifiers
 4. **Convergence check**: All major claims verified with no outstanding contradictions → proceed
 
@@ -271,10 +286,16 @@ Round N:
           - Internal consistency (breadth ↔ depth alignment)
           - Cross-domain consistency (security ↔ architecture)
           - Evidence quality (claims without backing)
-  Step 2: codex-exec validates technical claims:
-          - Code patterns actually exist
-          - Benchmarks are reproducible
-          - Dependencies resolve correctly
+  Step 2: codex-exec validates technical claims (when available):
+          a. Invoke: /codex-exec with findings from all teams
+          b. Prompt:  "Validate technical claims: {findings}.
+                       Check code patterns, benchmark reproducibility,
+                       dependency resolution."
+          c. Effort:  --effort xhigh
+          d. Parse:   contradictions → merge with opus findings
+          e. On timeout/error: log "[Phase 2] Round {N}: codex-exec error — {reason},
+                                continuing with opus results only"
+     If unavailable: log "[Phase 2] Round {N}: Codex unavailable, proceeding with opus verification only"
   Step 3: Compile contradiction list
           - 0 contradictions → CONVERGED
           - >0 contradictions → feedback to relevant teams → Round N+1
@@ -385,6 +406,52 @@ Progress:
 └── T9-T10: ○ Pending
 ```
 
+## Teams Mode
+
+When running inside an Agent Teams member (not via Skill tool), the research workflow operates identically but with these adaptations:
+
+### How It Works
+
+The orchestrator reads this SKILL.md and includes the research instructions directly in the Teams member's prompt. The member then:
+
+1. Executes Phase 1-4 autonomously using its own Agent tool access
+2. Spawns research teams as sub-agents (Teams members CAN spawn sub-agents)
+3. Delivers results via `SendMessage` to the team lead instead of returning to orchestrator
+
+### Prompt Embedding Pattern
+
+```
+# When spawning a Teams member for research:
+Agent(
+  name: "researcher-1",
+  team_name: "my-team",
+  prompt: """
+  You are a research agent. Follow the research skill workflow below:
+  {contents of research/SKILL.md}
+
+  Topic: {user's research topic}
+  Deliver results via SendMessage to team lead when complete.
+  """
+)
+```
+
+### Differences from Orchestrator Mode
+
+| Aspect | Orchestrator Mode | Teams Mode |
+|--------|------------------|------------|
+| Invocation | `Skill(research)` | Prompt embedding |
+| Result delivery | Return to main conversation | `SendMessage` to team lead |
+| Artifact persistence | Teams member writes artifact | Same |
+| GitHub issue creation | Orchestrator handles | Teams member handles directly |
+| Phase management | Orchestrator manages phases | Member manages phases autonomously |
+
+### Constraints
+
+- Each Teams member running research still respects R009 (max 4 concurrent sub-agents)
+- Batching order remains: T1-T4 → T5-T8 → T9-T10
+- Cost is identical to orchestrator mode (~$8-15 per research invocation)
+- Multiple Teams members running research simultaneously will multiply costs proportionally
+
 ## Integration
 
 | Rule | Integration |