feat: model capability routing for workflow phases

Workflow phases can declare a 'required_capability' to guide the LLM in
choosing an appropriate subagent and/or model for that phase. The user
wires up the capability→model/agent mapping in .vibe/config.yaml
(manually or via the new 'setup capabilities' CLI wizard). The feature
is fully opt-in: absent required_capability and absent capability_models
yields no behavioral change.

When a phase declares required_capability, the InstructionGenerator
embeds a hint into the phase instructions, e.g.:

  Capability hint: This phase requires thinking capability (deep
  reasoning, complex planning). When launching subagents, use agent:
  thinking (model: anthropic/claude-opus-4-7).

'thinking' and 'research' ship with a built-in description; 'coding' is
deliberately self-evident; any other term is echoed verbatim.

Configuration

.vibe/config.yaml accepts an optional capability_models map of
{ model?, agent? } per capability. Both fields are optional; either,
neither, or both may be set. ConfigManager validates the structure and
accepts the existing config shape unchanged.

CLI wizard

npx @codemcp/workflows setup capabilities <target> \
  [--model-thinking X --model-coding Y --model-research Z] [--force]

For each --model-<capability> provided, writes a per-target agent file
(e.g. .opencode/agents/<capability>.md for OpenCode, mode: subagent
with the chosen model) and merges the matching capability_models entry
into .vibe/config.yaml. Per-target agent files are produced from
templates shipped under resources/templates/opencode-agents/. Existing
per-target files are skipped by default; --force overwrites.

Only 'opencode' is currently implemented. Other registered targets
(kiro, claude, gemini, vscode, github-copilot) are stubs that throw
'not yet supported' and exit non-zero, but they are listed in
'setup capabilities --help' with a ⏳ status so users can see the wizard
is extensible. The architecture mirrors the per-target registry used
by ConfigGenerator and SkillGenerator — adding a new target is a single
class.

Workflow annotations

7 built-in workflows (qrspi, epcc, greenfield, waterfall, bugfix, tdd,
pr-review) annotate 23 phases with required_capability. Out of the
box, annotated phases still emit label-only hints; capability_models
config is only required for the LLM to know which model/agent to use.

Documentation

New user-facing page at packages/docs/user/capability-routing.md,
linked from the VitePress sidebar under 'User Guide'. Covers what you
get, declaring required_capability in a workflow YAML, configuring
capability_models in .vibe/config.yaml, the 'setup capabilities' CLI
command (flags, targets, examples), and which built-in workflows ship
with annotations.

Tests

936 tests across 4 packages (core 467, server 286, opencode 64, cli
119). The capability routing surface has dedicated unit tests for
formatCapabilityHint, the ProjectConfig validation rules, the
InstructionGenerator integration, the built-in workflow annotations
spot-check, and the per-target capability generator (registry,
concrete opencode impl, stubs, config merge).

Author: mrsimpson

.vibe/development-plan-feat-model-capability-routing.md

@@ -14,10 +14,13 @@
     "format:check": "prettier --check .",
     "format": "prettier --write ."
   },
-  "dependencies": {},
+  "dependencies": {
+    "js-yaml": "4.1.1"
+  },
   "devDependencies": {
     "@codemcp/workflows-core": "workspace:*",
     "@codemcp/workflows-server": "workspace:*",
+    "@types/js-yaml": "4.0.9",
     "@types/node": "^22.0.0",
     "rimraf": "^5.0.10",
     "tsup": "^8.0.0",