@lvlup-sw/exarchos 2.7.1 → 2.8.0

package/skills/cursor/shepherd/references/fix-strategies.md

@@ -8,7 +8,7 @@ How to address common issues found during shepherd assessment.
 |-----------|----------|
 | Single file, < 20 lines changed | Fix directly in the stack branch |
 | Multiple files, contained concern | Fix directly if < 5 files |
-| Cross-cutting or architectural | Delegate via `/exarchos:delegate --pr-fixes [PR_URL]` |
+| Cross-cutting or architectural | Route to `/exarchos:delegate --fixes` for subagent dispatch |
 | Test changes needed | Fix directly (keep TDD cycle tight) |
 
 **Default to fixing directly** — delegation adds overhead. Only delegate when the fix scope warrants it.
@@ -105,7 +105,7 @@ These events feed `selfCorrectionRate` and `avgRemediationAttempts` metrics in C
 
 If a test passes locally but fails in CI:
 1. Check if it's a known flaky test
-2. Re-run CI: `gh pr checks <number> --watch` (or push an empty commit to retrigger)
+2. Re-run CI: `exarchos_orchestrate({ action: "check_ci", prId: "<number>" })` (or push an empty commit to retrigger)
 3. If consistently flaky, fix the test or mark it with a skip annotation and create a follow-up issue
 
 ## Addressing Inline Review Comments
@@ -268,7 +268,7 @@ When making fixes to stack branches:
    git push --force-with-lease
    ```
 
-**IMPORTANT:** After pushing, verify auto-merge is still enabled: `gh pr view <number> --json autoMergeRequest`.
+**IMPORTANT:** After pushing, verify auto-merge is still enabled: `gh pr view <number> --json autoMergeRequest` (no MCP equivalent yet — use VCS CLI directly).
 
 ## Responding on PRs
 
@@ -286,4 +286,4 @@ mcp__plugin_github_github__add_issue_comment({
   body: "Addressed review feedback:\n- Fixed Sentry bug: ...\n- Replied to DI concern...\n\nAll inline review threads have replies."
 })
 ```
-Fallback (if MCP token lacks write scope): `gh pr comment <number> --body "..."`
+Fallback (if MCP token lacks write scope): `exarchos_orchestrate({ action: "add_pr_comment", prId: "<number>", body: "..." })`

package/skills/cursor/synthesis/SKILL.md

@@ -11,6 +11,12 @@ metadata:
 
 # Synthesis Skill
 
+## VCS Provider
+
+This skill uses VCS operations through Exarchos MCP actions (`create_pr`, `merge_pr`, `list_prs`, `check_ci`, etc.).
+These actions automatically detect and route to the correct VCS provider (GitHub, GitLab, Azure DevOps).
+No `gh`/`glab`/`az` commands needed — the MCP server handles provider dispatch.
+
 ## Overview
 
 Submit stacked PRs after review phase completes. The `prepare_synthesis` composite action consolidates readiness checks, stack verification, test validation, and quality signal analysis into a single call -- eliminating the multi-script coordination that historically caused synthesis failures.
@@ -105,20 +111,33 @@ mcp__exarchos__exarchos_orchestrate({
 })
 ```
 
-**Do NOT call `gh pr create` until validation passes.** If validation fails, fix the body and re-validate.
+**Do NOT call `create_pr` until validation passes.** If validation fails, fix the body and re-validate.
 
 ### Step 3: Submit and Merge
 
-Create PRs using the validated body and enable auto-merge:
-```bash
-# For each branch in the stack (bottom-up):
-gh pr create --base <parent-branch> --head <branch> --title "<type>: <what>" --body-file /tmp/pr-body.md
-gh pr merge <number> --auto --squash
+Create PRs using the validated body and enable auto-merge. For each branch in the stack (bottom-up):
+
+```typescript
+// Create PR via VCS MCP action
+exarchos_orchestrate({
+  action: "create_pr",
+  base: "<parent-branch>",
+  head: "<branch>",
+  title: "<type>: <what>",
+  body: "<pr-body>"
+})
+
+// Enable auto-merge
+exarchos_orchestrate({
+  action: "merge_pr",
+  prId: "<number>",
+  strategy: "squash"
+})
 ```
 
 After submission:
 1. **Apply benchmark label** -- If `verification.hasBenchmarks` is true, apply label: `gh pr edit <number> --add-label has-benchmarks`
-2. **Record PR URLs** -- Capture URLs from `gh pr list --json number,url,headRefName`
+2. **Record PR URLs** -- Capture URLs via `exarchos_orchestrate({ action: "list_prs", state: "open" })`
 3. **Update state:**
 
 ```typescript
@@ -135,7 +154,7 @@ For merge ordering strategy, see `references/merge-ordering.md`.
 **Human checkpoint:** Output "Stacked PRs enqueued: [URLs]. Waiting for CI/merge queue." then **PAUSE for user input**: "Merge stack? (yes/no/feedback)"
 
 - **'yes'** -- PRs merge; transition to completed via `cleanup`
-- **'feedback'** -- Route to `delegate --pr-fixes [PR_URL]` to address comments, then return here
+- **'feedback'** -- Route to `shepherd [PR_URL]` to address comments, then return here
 - **'no'** -- Pause workflow; resume later with `rehydrate`
 
 ### Event Emissions (REQUIRED)

package/skills/cursor/synthesis/references/github-native-stacking.md

@@ -8,15 +8,15 @@ PR stacking creates a chain of dependent pull requests that merge bottom-up into
 
 ## 1. PR Chain Creation
 
-Create PRs that chain together by setting each PR's `--base` to the previous branch:
+Create PRs that chain together by setting each PR's base to the previous branch:
 
-```bash
-# First PR in chain targets main
-gh pr create --base main --head feat/step-1 --title "feat: step 1" --body "..."
+```typescript
+// First PR in chain targets main
+exarchos_orchestrate({ action: "create_pr", base: "main", head: "feat/step-1", title: "feat: step 1", body: "..." })
 
-# Subsequent PRs target the previous PR's branch
-gh pr create --base feat/step-1 --head feat/step-2 --title "feat: step 2" --body "..."
-gh pr create --base feat/step-2 --head feat/step-3 --title "feat: step 3" --body "..."
+// Subsequent PRs target the previous PR's branch
+exarchos_orchestrate({ action: "create_pr", base: "feat/step-1", head: "feat/step-2", title: "feat: step 2", body: "..." })
+exarchos_orchestrate({ action: "create_pr", base: "feat/step-2", head: "feat/step-3", title: "feat: step 3", body: "..." })
 ```
 
 The resulting chain looks like:
@@ -72,15 +72,14 @@ After rebasing a mid-stack branch, all downstream branches in the stack must als
 
 View the current PR chain and its state:
 
-```bash
-# List all open PRs with base/head branch relationships
-gh pr list --json number,baseRefName,headRefName,title,state \
-  --jq '.[] | "\(.number): \(.baseRefName) <- \(.headRefName) [\(.state)]"'
-
-# Example output:
-# 101: main <- feat/step-1 [OPEN]
-# 102: feat/step-1 <- feat/step-2 [OPEN]
-# 103: feat/step-2 <- feat/step-3 [OPEN]
+```typescript
+// List all open PRs with base/head branch relationships
+exarchos_orchestrate({ action: "list_prs", state: "open" })
+
+// Example output shows PR numbers, base/head branches, titles, and state:
+// 101: main <- feat/step-1 [OPEN]
+// 102: feat/step-1 <- feat/step-2 [OPEN]
+// 103: feat/step-2 <- feat/step-3 [OPEN]
 ```
 
 To validate stack integrity, use the `validate_pr_stack` action via orchestrate:
@@ -97,32 +96,29 @@ exarchos_orchestrate({
 GitHub's native merge queue ensures PRs pass CI before merging:
 
 - **Enable:** Repository Settings > Rules > Branch protection > Require merge queue
-- **Auto-merge:** `gh pr merge --auto --squash` enables auto-merge once checks pass
+- **Auto-merge:** `exarchos_orchestrate({ action: "merge_pr", prId: "<number>", strategy: "squash" })` enables auto-merge once checks pass
 - **For stacks:** Enable auto-merge on each PR, then merge bottom-up
 
-```bash
-# Enable auto-merge on all PRs in the stack
-gh pr merge 101 --auto --squash
-gh pr merge 102 --auto --squash
-gh pr merge 103 --auto --squash
-
-# Merge the first PR to start the cascade
-gh pr merge 101 --squash
+```typescript
+// Enable auto-merge on all PRs in the stack
+exarchos_orchestrate({ action: "merge_pr", prId: "101", strategy: "squash" })
+exarchos_orchestrate({ action: "merge_pr", prId: "102", strategy: "squash" })
+exarchos_orchestrate({ action: "merge_pr", prId: "103", strategy: "squash" })
 ```
 
 After PR 101 merges and its branch is deleted, GitHub retargets PR 102 to `main`. If auto-merge is enabled on PR 102, it merges automatically once CI passes.
 
-## 7. Graphite to GitHub-Native Equivalents
+## 7. Graphite to Exarchos MCP Equivalents
 
-| Graphite Command | GitHub-Native Equivalent |
+| Graphite Command | Exarchos MCP Equivalent |
 |---|---|
 | `gt create <branch> -m "feat: ..."` | `git checkout -b <branch> && git commit -m "feat: ..." && git push -u origin <branch>` |
-| `gt submit --no-interactive --publish --stack` | `gh pr create --base <base> --title "..." --body "..."` (per PR) |
-| `gt log` | `gh pr list --json number,baseRefName,headRefName` |
+| `gt submit --no-interactive --publish --stack` | `exarchos_orchestrate({ action: "create_pr", base: "<base>", title: "...", body: "..." })` (per PR) |
+| `gt log` | `exarchos_orchestrate({ action: "list_prs", state: "open" })` |
 | `gt modify -m "..."` | `git commit --amend -m "..." && git push --force-with-lease` |
 | `gt sync` | `git fetch --prune && git rebase origin/main` |
 | `gt restack` | `git rebase origin/<base-branch>` per branch in stack |
-| `mcp__graphite__run_gt_cmd` | `gh` CLI directly via Bash tool |
+| `mcp__graphite__run_gt_cmd` | `exarchos_orchestrate` VCS actions |
 
 ## 8. Error Handling
 

package/skills/cursor/synthesis/references/merge-ordering.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-GitHub-native stacked PRs merge bottom-up: the base branch merges first, then each dependent branch in sequence. This ordering is enforced by creating PRs with correct base branches and enabling auto-merge (`gh pr merge --auto --squash`).
+GitHub-native stacked PRs merge bottom-up: the base branch merges first, then each dependent branch in sequence. This ordering is enforced by creating PRs with correct base branches and enabling auto-merge via `exarchos_orchestrate({ action: "merge_pr", prId: "<number>", strategy: "squash" })`.
 
 ## Stack Ordering Rules
 

package/skills/cursor/synthesis/references/synthesis-steps.md

@@ -74,7 +74,7 @@ The script queries GitHub's PR reviews API for each PR, filters for CodeRabbit r
 **On `passed: true`:** All PRs are APPROVED or have no CodeRabbit review -- proceed to Step 5.
 **On `passed: false`:** At least one PR has CHANGES_REQUESTED or PENDING. The output identifies which PRs need attention. Route to fix cycle:
 ```typescript
-Skill({ skill: "exarchos:delegate", args: "--pr-fixes [PR_URL]" })
+Skill({ skill: "exarchos:shepherd", args: "[PR_URL]" })
 ```
 After fixes are applied, return to Step 4 to re-check.
 
@@ -121,13 +121,13 @@ mcp__plugin_exarchos_exarchos__exarchos_orchestrate({
 
 Create PRs for each branch in the stack (bottom-up) and enable auto-merge:
 
-```bash
-# For each branch in the stack (bottom-up):
-gh pr create --base <parent-branch> --head <branch> --title "<type>: <what>" --body "<pr-body>"
-gh pr merge <number> --auto --squash
+```typescript
+// For each branch in the stack (bottom-up):
+exarchos_orchestrate({ action: "create_pr", base: "<parent-branch>", head: "<branch>", title: "<type>: <what>", body: "<pr-body>" })
+exarchos_orchestrate({ action: "merge_pr", prId: "<number>", strategy: "squash" })
 ```
 
-After creation, use `gh pr list --json number,url,headRefName` to get the PR URLs for each stack entry.
+After creation, use `exarchos_orchestrate({ action: "list_prs", state: "open" })` to get the PR URLs for each stack entry.
 
 ## Step 7: Cleanup After Merge
 

package/skills/cursor/synthesis/references/troubleshooting.md

@@ -21,7 +21,7 @@ If tests fail during synthesis (they passed in review):
 ### Merge Queue Rejection
 
 If the merge queue rejects a PR:
-1. Check CI status via `gh pr checks <number>` (or GitHub MCP `pull_request_read` with method `get_status` if available)
+1. Check CI status via `exarchos_orchestrate({ action: "check_ci", prId: "<number>" })`
 2. Fix failing checks
 3. Push fixes and re-enqueue
 
@@ -29,20 +29,13 @@ If the merge queue rejects a PR:
 
 If the user receives PR review comments:
 
-1. Offer to address feedback:
+1. Route to the shepherd skill:
    ```typescript
-   Skill({ skill: "exarchos:delegate", args: "--pr-fixes [PR_URL]" })
+   Skill({ skill: "exarchos:shepherd", args: "[PR_URL]" })
    ```
 
-2. Delegate reads PR comments via gh CLI:
-   ```bash
-   gh pr view <number> --json reviews,comments
-   ```
-   > Or use GitHub MCP `pull_request_read` if available.
-
-3. Creates fix tasks from review comments
-4. After fixes, amend the commit with `git commit --amend -m "fix: <description>"` and push with `git push --force-with-lease`
-5. Return to merge confirmation
+2. Shepherd reads PR comments, assesses CI, and applies fixes directly
+3. After fixes, return to merge confirmation
 
 ## Final Report Template
 
@@ -50,7 +43,7 @@ If the user receives PR review comments:
 ## Synthesis Complete
 
 ### Pull Requests
-[PR URLs from gh pr list]
+[PR URLs from list_prs action]
 
 ### Stack Branches
 - task/001-types
@@ -88,11 +81,11 @@ If workflow state doesn't match git reality:
 3. Update state via `mcp__plugin_exarchos_exarchos__exarchos_workflow` with `action: "set"` to match git truth
 
 ## PR Creation Failed
-If `gh pr create` fails:
+If `create_pr` fails:
 1. Check the error output for specific guidance
-2. Run `gh pr list --json number,baseRefName,headRefName` to verify the branch state
+2. Run `exarchos_orchestrate({ action: "list_prs", state: "open" })` to verify the branch state
 3. If rebase conflict: run `git rebase origin/<base>` to resolve
-4. If authentication issue: check GitHub token permissions
+4. If authentication issue: check VCS provider token permissions
 
 ## Stack Rebase Conflict
 If `git rebase` encounters conflicts:
@@ -104,8 +97,8 @@ If `git rebase` encounters conflicts:
 
 When Exarchos MCP tools are available:
 
-1. **After stack submission:** Call `mcp__plugin_exarchos_exarchos__exarchos_event` with `action: "append"` with event type `stack.enqueued` including PR numbers from `gh pr list --json number`
-2. **Monitor merge status:** Use `gh pr list --json number,state,mergedAt` to check stack/PR status
+1. **After stack submission:** Call `mcp__plugin_exarchos_exarchos__exarchos_event` with `action: "append"` with event type `stack.enqueued` including PR numbers from `exarchos_orchestrate({ action: "list_prs", state: "open" })`
+2. **Monitor merge status:** Use `exarchos_orchestrate({ action: "list_prs", state: "all" })` to check stack/PR status
 3. **On successful merge:** Call `mcp__plugin_exarchos_exarchos__exarchos_event` with `action: "append"` with event type `phase.transitioned` to mark workflow complete
 
 ## Performance Notes

package/skills/generic/cleanup/SKILL.md

@@ -11,6 +11,12 @@ metadata:
 
 # Cleanup Skill
 
+## VCS Provider
+
+This skill uses VCS operations through Exarchos MCP actions (`list_prs`, `get_pr_comments`, etc.).
+These actions automatically detect and route to the correct VCS provider (GitHub, GitLab, Azure DevOps).
+No `gh`/`glab`/`az` commands needed — the MCP server handles provider dispatch.
+
 ## Overview
 
 Resolve merged workflows to `completed` state in a single operation. Replaces the manual multi-step process of navigating HSM guards after PR stacks merge.
@@ -52,12 +58,12 @@ mcp__exarchos__exarchos_view({ action: "pipeline" })
 
 For each PR associated with the workflow, verify it is merged.
 
-**Primary method** — gh CLI:
-```bash
-gh pr view <number> --json state,mergedAt,headRefName
+**Primary method** — VCS MCP action:
+```typescript
+exarchos_orchestrate({ action: "list_prs", state: "merged" })
 ```
 
-> Or use GitHub MCP `pull_request_read` if available.
+For individual PR details, use `exarchos_orchestrate({ action: "get_pr_comments", prId: "<number>" })` or the VCS provider's native API.
 
 Collect from merged PRs:
 - `prUrl`: The PR URL (or array of URLs for stacked PRs)

package/skills/generic/cleanup/references/merge-verification.md

@@ -10,22 +10,21 @@ The cleanup action trusts the `mergeVerified` flag — it does not query GitHub
 
 ## Verification Methods
 
-### gh CLI (Primary)
+### VCS MCP Action (Primary)
 
-```bash
-gh pr view 123 --json state,mergedAt,headRefName
-# Check: .state == "MERGED" and .mergedAt is not null
+```typescript
+// List PRs to check merge state
+exarchos_orchestrate({ action: "list_prs", state: "merged" })
+// Check: each PR's state is "MERGED" and mergedAt is not null
 ```
 
-> Or use GitHub MCP `pull_request_read` if available for structured data.
-
 ### For Stacked PRs
 
 When verifying a stacked PR set, check ALL PRs in the stack:
 
-```bash
-# List PRs for the branch stack
-gh pr list --head "feature/*" --json number,state,headRefName
+```typescript
+// List PRs for the branch stack
+exarchos_orchestrate({ action: "list_prs", head: "feature/*", state: "all" })
 ```
 
 Collect from each merged PR:

package/skills/generic/debug/references/thorough-track.md

@@ -121,8 +121,11 @@ git commit -m "fix: <issue summary>"
 git push -u origin <branch-name>
 
 # Create PR and enable auto-merge
-gh pr create --base main --title "fix: <issue summary>" --body "<pr-body>"
-gh pr merge <number> --auto --squash
+```
+
+```typescript
+exarchos_orchestrate({ action: "create_pr", base: "main", head: "<branch-name>", title: "fix: <issue summary>", body: "<pr-body>" })
+exarchos_orchestrate({ action: "merge_pr", prId: "<number>", strategy: "squash" })
 ```
 
 Then update the PR description:

package/skills/generic/debug/references/troubleshooting.md

@@ -36,7 +36,7 @@ When Exarchos MCP tools are available, emit events throughout the debug workflow
 1. **At workflow start (triage):** `mcp__plugin_exarchos_exarchos__exarchos_event` with `action: "append"` -> `workflow.started` with workflowType "debug", urgency
 2. **On track selection:** `mcp__plugin_exarchos_exarchos__exarchos_event` with `action: "append"` -> `phase.transitioned` with selected track (hotfix/thorough)
 3. **On each phase transition:** `mcp__plugin_exarchos_exarchos__exarchos_event` with `action: "append"` -> `phase.transitioned` from->to
-4. **Thorough track stacking:** Handled by `/exarchos:synthesize` (PR creation via `gh pr create`)
+4. **Thorough track stacking:** Handled by `/exarchos:synthesize` (PR creation via `exarchos_orchestrate({ action: "create_pr" })`)
 5. **Hotfix track commit:** Single `git commit -m "fix: <description>"` + `git push` -- no multi-branch stacking needed
 6. **On complete:** `mcp__plugin_exarchos_exarchos__exarchos_event` with `action: "append"` -> `phase.transitioned` to "completed"
 

package/skills/generic/delegation/SKILL.md

@@ -43,7 +43,7 @@ Rationalization patterns that violate this principle are catalogued in `referenc
 
 **Auto-detection:** tmux + `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` present means `agent-team`. Otherwise `subagent`. Override with `delegate --mode subagent|agent-team`.
 
-**CRITICAL:** Always specify `model: "opus"` for coding tasks (when not using native agent definitions).
+Use the `recommendedModel` from `prepare_delegation` task classifications when available. If no classification exists (e.g., fixer dispatch), omit `model` to inherit the session default.
 
 ### Pre-Dispatch Schema Discovery
 
@@ -250,7 +250,9 @@ Handles review failures instead of initial implementation. Uses `references/fixe
 
 **Arguments:** `--fixes <state-file-path>` — state JSON containing review results in `.reviews.<taskId>.specReview` or `.reviews.<taskId>.qualityReview`.
 
-For detailed fix-mode process, see `references/fix-mode.md`. For PR feedback workflows (`--pr-fixes`), see `references/pr-fixes-mode.md`.
+For detailed fix-mode process, see `references/fix-mode.md`.
+
+> **Deprecated:** `--pr-fixes` has been superseded by `/exarchos:shepherd`. Use the shepherd skill for PR feedback workflows.
 
 ---
 
@@ -337,7 +339,6 @@ This is NOT a human checkpoint — the workflow continues autonomously.
 | `references/testing-patterns.md` | Arrange/Act/Assert, naming, mocking conventions |
 | `references/pbt-patterns.md` | Property-based testing patterns |
 | `references/fix-mode.md` | Detailed fix-mode process |
-| `references/pr-fixes-mode.md` | PR feedback fix workflows |
 | `references/state-management.md` | State patterns and benchmark labeling |
 | `references/troubleshooting.md` | Common failure modes and resolutions |
 | `references/adaptive-orchestration.md` | Adaptive team composition |

package/skills/generic/delegation/references/agent-teams-saga.md

@@ -103,7 +103,6 @@ exarchos_event append:
     teammateName: {name}
     worktreePath: {path}
     assignedTaskIds: [{taskIds}]
-    model: "opus"
 
 # Execute side effect
 # Note: teammates inherit the lead's permission mode (per Claude Code docs).
@@ -112,7 +111,6 @@ Task:
   subagent_type: "general-purpose"
   team_name: {featureId}
   name: {teammateName}
-  model: "opus"
   prompt: {spawnPrompt}  # See implementer-prompt.md template
 ```
 
@@ -199,7 +197,7 @@ If a compensating action itself fails after 3 retries, mark the workflow with `_
 | **Permissions inherit from lead** | Do NOT set `mode` at spawn -- not respected. All teammates inherit the lead's permission mode. |
 | **Teammates load MCP automatically** | Exarchos MCP tools are available without explicit instruction. The spawn prompt guides WHICH tools to use, not HOW to access them. |
 
-**CRITICAL:** Ensure your session is using the opus model for coding tasks. All teammates inherit the session model -- use Task tool dispatch if you need per-task model selection.
+**Model selection:** Teammates inherit the session model. Model is configured via `.exarchos.yml` and resolved by `prepare_delegation`. Use Task tool dispatch if you need per-task model override.
 
 ## Event Payload Conventions
 

package/skills/generic/delegation/references/fixer-prompt.md

@@ -109,7 +109,6 @@ When done, report:
 ```typescript
 Task({
   subagent_type: "general-purpose",
-  model: "opus",
   description: "Fix: SQL injection vulnerability",
   prompt: `
 # Fix Task: SQL Injection in User Query

package/skills/generic/delegation/references/implementer-prompt.md

@@ -280,7 +280,6 @@ When done, report:
 ```typescript
 Task({
   subagent_type: "general-purpose",
-  model: "opus",
   description: "Implement user validation",
   prompt: `
 # Task: Implement User Email Validation

package/skills/generic/delegation/references/parallel-strategy.md

@@ -21,8 +21,8 @@ Group B (depends on Group A):
 
 ```typescript
 // CORRECT: Single message, parallel execution
-Task({ model: "opus", description: "Task 001", prompt: "..." })
-Task({ model: "opus", description: "Task 002", prompt: "..." })
+Task({ description: "Task 001", prompt: "..." })
+Task({ description: "Task 002", prompt: "..." })
 
 // WRONG: Separate messages = sequential
 ```
@@ -59,7 +59,7 @@ Agent Teams supports one team per session. If you need more parallel groups than
 | Parallel dispatch | Multiple `Task()` in one message | Named teammates in agent team |
 | Waiting | `TaskOutput({ block: true })` | `TeammateIdle` hook (fires when teammate idle) |
 | Visibility | None (background) | tmux split panes |
-| Model control | `model: "opus"` per task | Session model for all |
+| Model control | `recommendedModel` from config | Session model for all |
 | Max parallelism | Unlimited | One team, N teammates |
 | Resume on crash | Task results preserved | Teammates lost (worktrees survive) |
 
@@ -73,14 +73,9 @@ TaskOutput({ task_id: "task-002-id" })
 
 ## Model Selection Guide
 
-| Task Type | Model | Reason |
-|-----------|-------|--------|
-| Code implementation | `opus` | Best quality for coding |
-| Code review | `opus` | Thorough analysis |
-| File search/exploration | (default) | Speed over quality |
-| Simple queries | `haiku` | Fast, low cost |
+Model selection is config-driven via `.exarchos.yml`. The `prepare_delegation` action returns a `recommendedModel` in each task classification based on the config cascade: per-agent override, then default-model, then fallback. Override per-task via the Task tool's `model` parameter when needed.
 
-**Note:** When using Agent Teams, all teammates inherit the session's model. Use Task tool dispatch if you need per-task model selection (e.g., `haiku` for simple queries, `opus` for implementation).
+**Note:** When using Agent Teams, all teammates inherit the session's model. Model is resolved from `.exarchos.yml` config via `prepare_delegation`. Use Task tool dispatch if you need per-task model override.
 
 ## Agent Teams Dispatch Pattern
 
@@ -106,7 +101,7 @@ Each teammate receives the full implementer prompt including TDD requirements, f
 | Cross-task deps | Orchestrator manages phases | Shared task list + unblocked task detection |
 | Monitoring | `TaskOutput` polling | tmux panes + `TeammateIdle` hook |
 | State updates | Orchestrator updates state | Hook auto-updates via state bridge |
-| Model per task | Yes (`model: "opus"` per Task) | No (session model for all) |
+| Model per task | Yes (`recommendedModel` per Task) | No (session model for all) |
 | Quality gates | Manual via `post_delegation_check` action | Automatic via `TeammateIdle` hook |
 | Recovery | Task results preserved | Worktrees survive, teammates lost |
 

package/skills/generic/delegation/references/worked-example.md

@@ -41,13 +41,13 @@ Build two self-contained prompts from `implementer-prompt.md` and dispatch in a
 
 ```typescript
 Task({
-  subagent_type: "general-purpose", model: "opus", run_in_background: true,
+  subagent_type: "general-purpose", run_in_background: true,
   description: "Implement task-001: Email format validator",
   prompt: `# Task: Email Format Validator\n\n## Working Directory\n/project/.worktrees/task-001\n\n[Full implementer prompt with TDD, file paths, acceptance criteria...]`
 })
 
 Task({
-  subagent_type: "general-purpose", model: "opus", run_in_background: true,
+  subagent_type: "general-purpose", run_in_background: true,
   description: "Implement task-002: Domain MX check",
   prompt: `# Task: Domain MX Check\n\n## Working Directory\n/project/.worktrees/task-002\n\n[Full implementer prompt with TDD, file paths, acceptance criteria...]`
 })
@@ -86,7 +86,7 @@ Re-dispatch with fixer prompt in the same worktree:
 
 ```typescript
 Task({
-  subagent_type: "general-purpose", model: "opus",
+  subagent_type: "general-purpose",
   description: "Fix task-002: DNS mock missing",
   prompt: `# Fix Task: DNS Mock Missing\n\n## Adversarial Verification Posture\nIndependently verify the failure...\n\n## Working Directory\n/project/.worktrees/task-002\n\n## Issue to Fix\n**File:** src/validators/domain.test.ts\n**Problem:** Missing vi.mock('dns') — test makes real network calls\n**Fix:** Add vi.mock('dns') with MX record stub\n\n## Verification\nRun: npm run test:run\nAll tests must pass without network access.`
 })

package/skills/generic/delegation/references/workflow-steps.md

@@ -40,7 +40,6 @@ TodoWrite({
 // Launch multiple in single message for parallel execution
 Task({
   subagent_type: "general-purpose",
-  model: "opus",
   run_in_background: true,
   description: "Implement task 001",
   prompt: "[Full implementer prompt]"
@@ -48,7 +47,6 @@ Task({
 
 Task({
   subagent_type: "general-purpose",
-  model: "opus",
   run_in_background: true,
   description: "Implement task 002",
   prompt: "[Full implementer prompt]"

package/skills/generic/delegation/references/worktree-enforcement.md

@@ -64,7 +64,7 @@ When using native isolation:
 | Don't | Do Instead |
 |-------|------------|
 | Make subagents read plan files | Provide full task text in prompt |
-| Use default model for coding | Specify `model: "opus"` |
+| Use default model for coding | Use configured model from `prepare_delegation` |
 | Send sequential Task calls | Batch parallel tasks in one message |
 | Skip worktree for parallel work | Create isolated worktrees |
 | Forget to track in TodoWrite | Update status for every task |