Update to Capability Orchestrator

{
  "description": "Use at the start of non-trivial user requests when the task may benefit from installed skills, plugins, connected apps, connectors, MCP tools, or native specialist capabilities. Determine the user's intent, select the smallest effective set of relevant capabilities, and delegate each subtask to the most specialized available capability before attempting the work generically.",
  "included_files": [
    {
      "relative_path": "references/delegation-contract.md",
      "size_in_bytes": 1221
    },
    {
      "relative_path": "references/discovery-policy.md",
      "size_in_bytes": 1311
    },
    {
      "relative_path": "references/routing-policy.md",
      "size_in_bytes": 2284
    },
    {
      "relative_path": "references/surface-adaptation.md",
      "size_in_bytes": 1275
    }
  ],
  "name": "capability-orchestrator",
  "skill_md_contents": "---\nname: capability-orchestrator\ndescription: Use at the start of non-trivial user requests when the task may benefit from installed skills, plugins, connected apps, connectors, MCP tools, or native specialist capabilities. Determine the user's intent, select the smallest effective set of relevant capabilities, and delegate each subtask to the most specialized available capability before attempting the work generically.\n---\n\n# Capability Orchestrator\n\nUse this skill as a control plane. Do not replace specialist capabilities\nwith generic reasoning when a suitable specialist is available.\n\nFor trivial social conversation, acknowledgements, or simple questions\nthat clearly need no specialist capability, do not run the full routing workflow.\n\n## Hard invariants\n\n- Prefer a direct specialist over a generic router.\n- Use the smallest effective set of capabilities.\n- Never delegate to capability-orchestrator.\n- Maximum routing depth: 4.\n- Do not load unrelated capability context.\n- Do not claim a capability ran unless it was actually invoked.\n- Respect user overrides unless they conflict with safety or platform rules.\n- Installation, connection, authentication, and permission grants remain\n  explicit user actions when the host requires them.\n\n## Understand intent\n\nIdentify the requested outcome, inputs, constraints, domain, freshness\nneeds, account access needs, file operations, and expected artifact.\n\n## Decide whether to decompose\n\nKeep the request direct when one specialist can complete it.\nDecompose only when independent or sequential subtasks require different\ncapabilities.\n\nUse one of these shapes:\n- Direct\n- Complementary\n- Sequential\n- Discovery\n- Native fallback\n\n## Inspect available capabilities\n\nInspect capabilities already available in the current environment first.\nConsider specialist skills, plugins, connected apps, connectors, MCP tools,\nnative tools, generic routers, and direct model reasoning.\n\nIf no suitable capability is available and capability discovery exists,\nfollow `references/discovery-policy.md`.\n\n## Select the route\n\nApply `references/routing-policy.md`.\n\nUser overrides:\n- \"do not use plugins\" disables plugin delegation.\n- \"use only X\" restricts delegation to X when X can safely perform the task.\n- An explicitly requested valid capability has priority over automatic\n  selection unless a higher-priority platform or safety rule prevents it.\n\n## Delegate with minimal context\n\nFor every delegated subtask, follow `references/delegation-contract.md`.\nSend only the objective, relevant context, constraints, expected output,\nand dependencies required by that specialist.\n\n## Synthesize and report\n\nCombine complementary results only as much as needed to satisfy the user.\nDo not rewrite specialist output merely to make the orchestrator appear\nactive.\n\nAt the end, report only capabilities actually invoked. If none were\ninvoked, report that none were used.\n\nFor host-specific behavior, follow `references/surface-adaptation.md`.\n"
}