[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CBPBM5J9PX4H8CE628AY5X":3,"skill-same:01M6CBPBM5J9PX4H8CE628AY5X":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6CBPBM5J9PX4H8CE628AY5X","scout-mcp",null,"Use when the user wants to expose cub-scout to an AI agent over MCP, wants a deterministic AI-ready snapshot of cluster context, or wants cub-scout running as a read-only event bot — the Integrate verb group. Natural phrasing: \"start the MCP server\", \"expose cub-scout to Claude \u002F Codex \u002F my agent\", \"give me an AI-ready context pack of this cluster\", \"set up the MCP gateway\", \"what MCP tools does cub-scout expose?\", \"run cub-scout as a bot\", \"produce JSON context for an LLM to reason about this cluster\". Load whenever intent is mcp \u002F mcp-gateway \u002F mcp-serve \u002F context-pack \u002F bot \u002F agent-context \u002F ai-snapshot \u002F llm-context \u002F model-context-protocol. Do NOT load for: actually running a non-integrate verb (those are scout-observe \u002F scout-diagnose \u002F scout-compare \u002F scout-attribute \u002F scout-ingest \u002F scout-govern \u002F scout-verify), or `cub` MCP integration (that's a separate tool surface).","confighub\u002Fcub-scout","confighub","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F206140369?v=4","01M6CBJBWD33AFNG4VXMJHSRXD","ConfigHub Inc","01M6CBJC0K0F8CJVFWGRSR0KYC",14,"MIT","https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-mcp\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"scout","scout mcp","MCP","changeset","when","agent-context","unit","get","observe","up","ready","only","snapshot","read","model","Bash","SET","server","release","run","config","auth","ai agent","mcp server","bot","2026-11-10 10:12:30",false,"---\nname: scout-mcp\ndescription: 'Use when the user wants to expose cub-scout to an AI agent over MCP, wants a deterministic AI-ready snapshot of cluster context, or wants cub-scout running as a read-only event bot — the Integrate verb group. Natural phrasing: \"start the MCP server\", \"expose cub-scout to Claude \u002F Codex \u002F my agent\", \"give me an AI-ready context pack of this cluster\", \"set up the MCP gateway\", \"what MCP tools does cub-scout expose?\", \"run cub-scout as a bot\", \"produce JSON context for an LLM to reason about this cluster\". Load whenever intent is mcp \u002F mcp-gateway \u002F mcp-serve \u002F context-pack \u002F bot \u002F agent-context \u002F ai-snapshot \u002F llm-context \u002F model-context-protocol. Do NOT load for: actually running a non-integrate verb (those are scout-observe \u002F scout-diagnose \u002F scout-compare \u002F scout-attribute \u002F scout-ingest \u002F scout-govern \u002F scout-verify), or `cub` MCP integration (that''s a separate tool surface).'\nphase: cross-cutting\nallowed-tools: Bash(.\u002Fcub-scout mcp *) Bash(cub-scout mcp *) Bash(cub scout mcp *) Bash(.\u002Fcub-scout context-pack *) Bash(cub-scout context-pack *) Bash(cub scout context-pack *) Bash(.\u002Fcub-scout version) Bash(cub-scout version) Bash(cub scout version) Bash(.\u002Fcub-scout status) Bash(cub-scout status) Bash(cub scout status) Bash(kubectl get *) Bash(kubectl describe *) Bash(kubectl config current-context) Bash(cub auth status) Bash(cub space list *) Bash(cub unit get *) Bash(cub unit list *) Bash(cub link get *) Bash(cub link list *) Bash(cub view get *) Bash(cub view list *) Bash(cub unit-event list *) Bash(cub resource list *) Bash(cub release list *) Bash(cub changeset list *)\n---\n\n# scout-mcp\n\nThe Integrate verb group of cub-scout. Three ways to plug cub-scout into AI workflows:\n\n- **`mcp serve`** — long-running Model Context Protocol gateway exposing cub-scout's verbs as MCP tools for Claude \u002F Codex \u002F any MCP-aware agent\n- **`context-pack`** — one-shot deterministic JSON context bundle an agent can consume directly\n- **`bot`** — in-cluster event producer using the same read-only watch stream as `cub-scout watch`\n\nPlus the version\u002Fstatus meta-commands the harness uses for cold-start checks.\n\n## When to use\n\nExplicit phrasings:\n\n- \"Start the MCP server\" \u002F \"expose cub-scout to my agent over MCP\"\n- \"Set up cub-scout as an MCP tool for Claude \u002F Codex\"\n- \"Give me an AI-ready context pack of this cluster\"\n- \"What MCP tools does cub-scout expose?\"\n- \"Produce JSON context an LLM can reason about\" \u002F \"deterministic context snapshot\"\n- \"Run cub-scout as an in-cluster bot\"\n- \"Bootstrap the MCP gateway\"\n- \"Plug cub-scout into the agent\"\n\nImplicit intents:\n\n- The user is integrating cub-scout with an LLM \u002F agent framework\n- The user wants a *deterministic* (no AI, no inference) snapshot for an LLM to reason over\n- The user is debugging MCP tool registration \u002F tool listing \u002F tool calls\n- The user is composing cub-scout with `cub`-side MCP tools\n\n## Do not load for\n\n- Running a single cub-scout verb directly from the CLI — load the verb's own skill (`scout-observe`, etc.)\n- `cub` MCP integration (the ConfigHub-side MCP surface) — that's a separate skill set\n- Generating receipts — [`scout-verify`](..\u002Fscout-verify\u002FSKILL.md)\n- Comparing live state — [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md)\n\n## Standalone vs connected\n\n- **Standalone (cluster only):** `mcp serve` exposes the read-only standalone tool set (doctor, explain, map, scan, trace, compare drift, etc.). `context-pack` produces a cluster snapshot with attribution evidence but no ConfigHub linkage. `bot` streams watch events using kubeconfig or in-cluster service-account credentials.\n- **Connected (cluster + `cub auth login`):** `mcp serve` additionally registers the connected-mode tools (`compare_three_way`, `compare_source_truth`, `confighub_changesets`, `confighub_k8s_resources`, `confighub_k8s_types`, `confighub_live_status`, `confighub_releases`, `confighub_resources`, `confighub_unit_events`, `confighub_units`, `confighub_unit_get`). Connected `context-pack` includes ConfigHub unit linkage and connected attribution (`bindingSource`).\n- **Offline (no cluster):** `mcp serve` refuses to start without a reachable cluster. `context-pack` works against debug bundles via `--bundle \u003Cpath>`.\n\n## Tool boundary\n\n- **Allowed (read-only):** `mcp serve` (long-running but no mutation), `context-pack` (deterministic snapshot), `version`, `status`; `kubectl get\u002Fdescribe`, `kubectl config current-context`; `cub \u003Centity> get \u002F list` for the entities named in allowed-tools, `cub auth status`. `bot` changes nothing in the cluster but is not auto-approved: its `--webhook` flag sends events to any URL, so the host asks each time.\n- **Not allowed:** `mcp serve` exposes ONLY the read-only cub-scout verbs as tools. The MCP tool catalog explicitly excludes any mutating verb (`demo`, `import apply`, `compare --suggest --apply`) — see `cmd\u002Fcub-scout\u002Fmcp.go` `RegisterTools` for the closed list. `context-pack` never writes; it reads + emits.\n- **MCP and the read-only triad:** the MCP gateway is the third party in the architectural triad. cub-scout (evidence) ↔ MCP (transport) ↔ Pilot or agent (judge \u002F actor). The MCP layer NEVER decides; it just streams cub-scout's structured output.\n\n## The verb menu\n\n| Question | Verb | Notes |\n|---|---|---|\n| \"Start the MCP gateway\" | `cub-scout mcp serve` | Long-running stdio transport. |\n| \"What MCP tools are registered?\" | MCP `tools\u002Flist` request | Dumps the tool catalog through the standard MCP discovery request. Useful for agent registration debugging. |\n| \"Produce deterministic AI context\" | `cub-scout context-pack --format json` | One-shot. Cluster snapshot + ownership classifications + attribution evidence in a single JSON. |\n| \"Pack a bundle as AI context\" | `cub-scout context-pack --bundle \u003Cpath>` | Same shape, sourced from a debug bundle instead of the live cluster. Offline-friendly. |\n| \"Run cub-scout as an event bot\" | `cub-scout bot --webhook \u003Curl>` | In-cluster-friendly watch stream with env-var config for manifests. |\n| \"Check cub-scout version\" | `cub-scout version` | Build tag. Agents that registered cub-scout tools use this to detect breaking-change ranges. |\n| \"Confirm mode\" | `cub-scout status --json` | Agents call this first to know which connected tools are available. Read `confighub_reads` (and `confighub_reads_reason`), not the `mode` line — see [standalone vs connected](..\u002Freferences\u002Fstandalone-vs-connected.md). |\n\n## The loop\n\n1. **Decide MCP vs context-pack vs bot.** Long-running agent tool gateway → `mcp serve`. Single-shot reasoning over a snapshot → `context-pack`. In-cluster event producer → `bot`.\n2. **Check the mode.** `cub-scout status --json` confirms it: `confighub_reads: true` means the connected tools will run, and when it is `false` `confighub_reads_reason` says why. The `mode` line describes `hub.confighub.com` and can disagree in either direction, so do not use it as the pre-flight. Tell the agent which tool subset is live.\n3. **Start the surface.** For MCP, `mcp serve` registers tools with the agent. For context-pack, `--format json` and pipe to the agent. For bot mode, set destination env vars or flags and deploy\u002Frun the process.\n4. **Compose with sibling skills.** The MCP gateway is plumbing — once it's running, every other verb-group skill (`scout-observe`, `scout-diagnose`, etc.) is reachable via MCP tools and uses the same loops described in those skills.\n5. **Hand off mutations.** No matter what an agent asks the MCP gateway to do, the gateway refuses to call a mutating verb. Mutations route through `cub` skills (in [`confighub\u002Fconfighub-skills`](https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fconfighub-skills)) or direct `kubectl` with the user driving.\n\n## Worked examples\n\n### A: MCP STDIO for Claude Code\n\n```jsonc\n\u002F\u002F .claude\u002Fmcp_servers.json (or equivalent for your agent host)\n{\n  \"mcpServers\": {\n    \"cub-scout\": {\n      \"command\": \"cub-scout\",\n      \"args\": [\"mcp\", \"serve\"],\n      \"env\": {\n        \"KUBECONFIG\": \"${env:HOME}\u002F.kube\u002Fconfig\"\n      }\n    }\n  }\n}\n```\n\nThe agent now sees cub-scout's read-only tools (`doctor`, `explain`, `trace`, `compare_three_way`, `confighub_live_status`, etc.) and can call them like any other MCP tool.\n\n### B: list the tool catalog\n\nUse the standard MCP `tools\u002Flist` request from the agent host. The standalone\ncatalog contains `doctor`, `explain`, `gitops_settings`, `gitops_status`, `map`,\n`release_check`, `scan`, and `trace`; connected mode adds the ConfigHub tools\nlisted below.\n\nEvery tool is a thin wrapper over the underlying CLI verb with `--format json` — see `docs\u002Freference\u002Fjson-contracts.md` for the response shape.\n\n### C: deterministic context pack for an LLM\n\n```bash\n$ cub-scout context-pack --format json > cluster-ctx.json\n$ jq '.ownership | group_by(.type) | map({type: .[0].type, count: length})' cluster-ctx.json\n[\n  {\"type\": \"argo\",     \"count\": 47},\n  {\"type\": \"flux\",     \"count\": 12},\n  {\"type\": \"helm\",     \"count\": 8},\n  {\"type\": \"native\",   \"count\": 23},\n  {\"type\": \"unknown\",  \"count\": 3}\n]\n```\n\nThe pack is **deterministic** — same cluster state + same cub-scout version → same JSON bytes. Safe to feed to an LLM with prompt caching, and safe to diff in CI.\n\n### D: connected MCP for promotion workflows\n\nWhen the ConfigHub session check passes (`confighub_reads: true` in `cub-scout status --json`), `mcp serve` additionally registers the tools below. Since v2.14.0 the check is made through the ConfigHub SDK and needs no `cub` binary; `cub auth status` checks the same session.\n\n- `compare_three_way` — DRY\u002FWET\u002FLIVE comparison\n- `compare_source_truth` — strategy-typed verdict (requires `target` + `namespace` + `strategy`)\n- `confighub_attestations` — attestations recorded directly against one exact revision\n- `confighub_changeorder_get` — one ChangeOrder's reported Stage\u002FState and declarations\n- `confighub_changesets` — governed ChangeSet history from ConfigHub\n- `confighub_k8s_types` — Resource-backed intended Kubernetes type survey\n- `confighub_k8s_resources` — Resource-backed intended Kubernetes resource reader\n- `confighub_live_status` — Space live-status writeback with freshness\n- `confighub_releases` — bounded ConfigHub Release history\n- `confighub_resources` — generic ConfigHub Resource entity query\n- `confighub_unit_events` — bounded ConfigHub UnitEvent history\n- `confighub_units` — ConfigHub unit + fleet inventory\n- `confighub_unit_get` — exact ConfigHub unit details + applied\u002Flive revision\n\nThese are the typical acceptance-kernel inputs. The agent composes them;\ncub-scout produces evidence; the downstream judge decides.\n\n## Output evidence\n\n### `mcp serve` (the gateway)\n\n- Long-running. STDIO transport.\n- Lists tools via the standard MCP `tools\u002Flist` request.\n- Each tool call returns `content[0].text` containing the wrapped CLI verb's `--format json` output verbatim.\n- Optional `structuredContent` field on selected connected-mode tools adds parsed evidence + read-only trust guidance for Pilot-shaped consumers.\n\n### `context-pack` (the snapshot)\n\nThe fields below are `contextPackV2` in `cmd\u002Fcub-scout\u002Fcontext_pack.go`.\n\n| Field | Meaning |\n|---|---|\n| `version` | cub-scout build tag + context-pack schema version |\n| `generatedAt` | RFC 3339 timestamp |\n| `cluster` | kubeconfig context |\n| `namespace` | Scope of the snapshot, or `all` |\n| `provenance` | `source` \u002F `deterministic` \u002F `confidence` for the snapshot itself |\n| `ownershipSummary` | Per-owner counts |\n| `topRisks[]` | Bounded issue list, most severe first |\n| `traceSeeds[]` | Workloads worth tracing, each with the exact `trace` command |\n| `commandEvidence[]` | Commands whose output backs the above |\n| `truncated`, `sizeBytes` | Whether the payload was cut to fit, and its size |\n\nThere is no `mode` field: `context-pack` is a standalone snapshot. Whether\nConfigHub reads work is `confighub_reads` in `cub-scout status --json`.\n\nThe snapshot is the *evidence base* a downstream LLM reasons over. It is NOT a recommendation; the LLM forms recommendations.\n\n## MCP tool catalog (current)\n\nThe closed list of MCP tools cub-scout registers. The set is verified by `cmd\u002Fcub-scout\u002Fmcp_test.go` against the connected\u002Fstandalone modes.\n\n| Tool name | Mode | Wraps |\n|---|---|---|\n| `doctor` | standalone | `cub-scout doctor --format json` plus optional `--with-confighub` delivery evidence flags |\n| `map` | standalone | `cub-scout map list --json` |\n| `scan` | standalone | `cub-scout scan --json` |\n| `trace` | standalone | `cub-scout trace \u003Cresource> --format json` |\n| `explain` | standalone | `cub-scout explain \u003Cresource> --format json` |\n| `gitops_status` | standalone | `cub-scout gitops status --format json` |\n| `gitops_settings` | standalone | `cub-scout gitops settings --format json` (preview: shapes may still change) |\n| `release_check` | standalone | `cub-scout release check --format json` |\n| `compare_three_way` | connected | `cub-scout compare three-way --format json` |\n| `compare_source_truth` | connected | `cub-scout compare source-truth \u003Ctarget> -n \u003Cns> --strategy \u003Cs> --format json` |\n| `confighub_attestations` | connected | One revision and its space's attestation list, as `cub revision get` and `cub attestation list` print them (SDK) |\n| `confighub_changeorder_get` | connected | `cub changeorder get \u003Corder> -o json --space \u003Cspace>` (SDK; an order named by ID runs `cub`) |\n| `confighub_changesets` | connected | `cub changeset list -o json --space \u003Cspace>` (SDK) |\n| `confighub_k8s_resources` | connected | `cub k8s get \u003Ctype> [\u003Cname> ...] -o json` (runs `cub`) |\n| `confighub_k8s_types` | connected | `cub k8s types [\u003Ctype>] -o json` (runs `cub`) |\n| `confighub_live_status` | connected | `cub space list -o json --select Slug,SpaceID,Annotations,Labels [--where \"Slug = '\u003Cspace>'\"]` (runs `cub`) |\n| `confighub_releases` | connected | `cub release list --space \u003Cspace> -o json` (SDK; `space: \"*\"` runs `cub`) |\n| `confighub_resources` | connected | `cub resource list --space \u003Cspace> -o json` (SDK; with `select`, `filter`, `view` or `raw_data` it runs `cub`) |\n| `confighub_unit_events` | connected | `cub unit-event list [unit] --space \u003Cspace> -o json` (SDK; a Unit named by ID or as `\u003Cspace>\u002F\u003Cslug>` runs `cub`) |\n| `confighub_units` | connected | `cub unit list -o json --space \u003Cspace>` (SDK) |\n| `confighub_unit_get` | connected | `cub unit get -o json \u003Cunit> --space \u003Cspace>` (SDK; a Unit named by ID, or as `\u003Cspace>\u002F\u003Cslug>` together with `space`, runs `cub`) |\n\n8 standalone + 13 connected = **21 tools total**. The catalog is intentionally narrow and every tool is read-only.\n\n**(SDK)** marks a read cub-scout makes through the ConfigHub SDK by default since v2.14.0: no `cub` process runs, and the JSON is what the named `cub` command prints. **(runs `cub`)** marks a read that still starts the `cub` CLI and fails, saying so, on a machine without it. `CUB_SCOUT_CONFIGHUB_READER=cub` sends every read through `cub`.\n\nFor the full reference (per-tool parameters, return shape, when-to-load semantics, deferred verbs not in the catalog), see [`references\u002Fmcp-tool-catalog.md`](..\u002Freferences\u002Fmcp-tool-catalog.md).\n\n## References\n\n- Command reference: [`docs\u002Freference\u002Fcommands.md`](..\u002F..\u002Fdocs\u002Freference\u002Fcommands.md) § mcp, § context-pack\n- MCP tool descriptions audit: `cub-scout\u002F#377`\n- Connected MCP trust surface: [`docs\u002Freference\u002Fjson-contracts.md`](..\u002F..\u002Fdocs\u002Freference\u002Fjson-contracts.md) § \"MCP connected trust guidance\"\n- Context-pack format: [`docs\u002Fhowto\u002Fcontext-pack-v2.md`](..\u002F..\u002Fdocs\u002Fhowto\u002Fcontext-pack-v2.md)\n- AI integration walkthrough: [`examples\u002Fai-integration\u002F`](..\u002F..\u002Fexamples\u002Fai-integration\u002F)\n- MCP gateway example: [`examples\u002Fmcp-gateway\u002F`](..\u002F..\u002Fexamples\u002Fmcp-gateway\u002F)\n- Bot deployment example: [`examples\u002Fbot\u002F`](..\u002F..\u002Fexamples\u002Fbot\u002F)\n\n## Constraints\n\n- The MCP server never starts a mutating tool. The tool catalog is closed and read-only by construction; adding a tool requires a code change + a passing test.\n- `context-pack` is **deterministic** — same input, same bytes. Do not introduce non-determinism (random IDs, timestamps in non-`capturedAt` fields, map iteration order).\n- For long-running agent sessions, use MCP STDIO; `bot` is the separate in-cluster event-stream entrypoint.\n- `cub-scout mcp serve` is the cub-scout-side MCP. `cub` may also expose an MCP surface; the two are separate, and an agent can register both.\n","# scout-mcp\n\nThe Integrate verb group of cub-scout. Three ways to plug cub-scout into AI workflows:\n\n- **`mcp serve`** — long-running Model Context Protocol gateway exposing cub-scout's verbs as MCP tools for Claude \u002F Codex \u002F any MCP-aware agent\n- **`context-pack`** — one-shot deterministic JSON context bundle an agent can consume directly\n- **`bot`** — in-cluster event producer using the same read-only watch stream as `cub-scout watch`\n\nPlus the version\u002Fstatus meta-commands the harness uses for cold-start checks.\n\n## When to use\n\nExplicit phrasings:\n\n- \"Start the MCP server\" \u002F \"expose cub-scout to my agent over MCP\"\n- \"Set up cub-scout as an MCP tool for Claude \u002F Codex\"\n- \"Give me an AI-ready context pack of this cluster\"\n- \"What MCP tools does cub-scout expose?\"\n- \"Produce JSON context an LLM can reason about\" \u002F \"deterministic context snapshot\"\n- \"Run cub-scout as an in-cluster bot\"\n- \"Bootstrap the MCP gateway\"\n- \"Plug cub-scout into the agent\"\n\nImplicit intents:\n\n- The user is integrating cub-scout with an LLM \u002F agent framework\n- The user wants a *deterministic* (no AI, no inference) snapshot for an LLM to reason over\n- The user is debugging MCP tool registration \u002F tool listing \u002F tool calls\n- The user is composing cub-scout with `cub`-side MCP tools\n\n## Do not load for\n\n- Running a single cub-scout verb directly from the CLI — load the verb's own skill (`scout-observe`, etc.)\n- `cub` MCP integration (the ConfigHub-side MCP surface) — that's a separate skill set\n- Generating receipts — [`scout-verify`](..\u002Fscout-verify\u002FSKILL.md)\n- Comparing live state — [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md)\n\n## Standalone vs connected\n\n- **Standalone (cluster only):** `mcp serve` exposes the read-only standalone tool set (doctor, explain, map, scan, trace, compare drift, etc.). `context-pack` produces a cluster snapshot with attribution evidence but no ConfigHub linkage. `bot` streams watch events using kubeconfig or in-cluster service-account credentials.\n- **Connected (cluster + `cub auth login`):** `mcp serve` additionally registers the connected-mode tools (`compare_three_way`, `compare_source_truth`, `confighub_changesets`, `confighub_k8s_resources`, `confighub_k8s_types`, `confighub_live_status`, `confighub_releases`, `confighub_resources`, `confighub_unit_events`, `confighub_units`, `confighub_unit_get`). Connected `context-pack` includes ConfigHub unit linkage and connected attribution (`bindingSource`).\n- **Offline (no cluster):** `mcp serve` refuses to start without a reachable cluster. `context-pack` works against debug bundles via `--bundle \u003Cpath>`.\n\n## Tool boundary\n\n- **Allowed (read-only):** `mcp serve` (long-running but no mutation), `context-pack` (deterministic snapshot), `version`, `status`; `kubectl get\u002Fdescribe`, `kubectl config current-context`; `cub \u003Centity> get \u002F list` for the entities named in allowed-tools, `cub auth status`. `bot` changes nothing in the cluster but is not auto-approved: its `--webhook` flag sends events to any URL, so the host asks each time.\n- **Not allowed:** `mcp serve` exposes ONLY the read-only cub-scout verbs as tools. The MCP tool catalog explicitly excludes any mutating verb (`demo`, `import apply`, `compare --suggest --apply`) — see `cmd\u002Fcub-scout\u002Fmcp.go` `RegisterTools` for the closed list. `context-pack` never writes; it reads + emits.\n- **MCP and the read-only triad:** the MCP gateway is the third party in the architectural triad. cub-scout (evidence) ↔ MCP (transport) ↔ Pilot or agent (judge \u002F actor). The MCP layer NEVER decides; it just streams cub-scout's structured output.\n\n## The verb menu\n\n| Question | Verb | Notes |\n|---|---|---|\n| \"Start the MCP gateway\" | `cub-scout mcp serve` | Long-running stdio transport. |\n| \"What MCP tools are registered?\" | MCP `tools\u002Flist` request | Dumps the tool catalog through the standard MCP discovery request. Useful for agent registration debugging. |\n| \"Produce deterministic AI context\" | `cub-scout context-pack --format json` | One-shot. Cluster snapshot + ownership classifications + attribution evidence in a single JSON. |\n| \"Pack a bundle as AI context\" | `cub-scout context-pack --bundle \u003Cpath>` | Same shape, sourced from a debug bundle instead of the live cluster. Offline-friendly. |\n| \"Run cub-scout as an event bot\" | `cub-scout bot --webhook \u003Curl>` | In-cluster-friendly watch stream with env-var config for manifests. |\n| \"Check cub-scout version\" | `cub-scout version` | Build tag. Agents that registered cub-scout tools use this to detect breaking-change ranges. |\n| \"Confirm mode\" | `cub-scout status --json` | Agents call this first to know which connected tools are available. Read `confighub_reads` (and `confighub_reads_reason`), not the `mode` line — see [standalone vs connected](..\u002Freferences\u002Fstandalone-vs-connected.md). |\n\n## The loop\n\n1. **Decide MCP vs context-pack vs bot.** Long-running agent tool gateway → `mcp serve`. Single-shot reasoning over a snapshot → `context-pack`. In-cluster event producer → `bot`.\n2. **Check the mode.** `cub-scout status --json` confirms it: `confighub_reads: true` means the connected tools will run, and when it is `false` `confighub_reads_reason` says why. The `mode` line describes `hub.confighub.com` and can disagree in either direction, so do not use it as the pre-flight. Tell the agent which tool subset is live.\n3. **Start the surface.** For MCP, `mcp serve` registers tools with the agent. For context-pack, `--format json` and pipe to the agent. For bot mode, set destination env vars or flags and deploy\u002Frun the process.\n4. **Compose with sibling skills.** The MCP gateway is plumbing — once it's running, every other verb-group skill (`scout-observe`, `scout-diagnose`, etc.) is reachable via MCP tools and uses the same loops described in those skills.\n5. **Hand off mutations.** No matter what an agent asks the MCP gateway to do, the gateway refuses to call a mutating verb. Mutations route through `cub` skills (in [`confighub\u002Fconfighub-skills`](https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fconfighub-skills)) or direct `kubectl` with the user driving.\n\n## Worked examples\n\n### A: MCP STDIO for Claude Code\n\n```jsonc\n\u002F\u002F .claude\u002Fmcp_servers.json (or equivalent for your agent host)\n{\n  \"mcpServers\": {\n    \"cub-scout\": {\n      \"command\": \"cub-scout\",\n      \"args\": [\"mcp\", \"serve\"],\n      \"env\": {\n        \"KUBECONFIG\": \"${env:HOME}\u002F.kube\u002Fconfig\"\n      }\n    }\n  }\n}\n```\n\nThe agent now sees cub-scout's read-only tools (`doctor`, `explain`, `trace`, `compare_three_way`, `confighub_live_status`, etc.) and can call them like any other MCP tool.\n\n### B: list the tool catalog\n\nUse the standard MCP `tools\u002Flist` request from the agent host. The standalone\ncatalog contains `doctor`, `explain`, `gitops_settings`, `gitops_status`, `map`,\n`release_check`, `scan`, and `trace`; connected mode adds the ConfigHub tools\nlisted below.\n\nEvery tool is a thin wrapper over the underlying CLI verb with `--format json` — see `docs\u002Freference\u002Fjson-contracts.md` for the response shape.\n\n### C: deterministic context pack for an LLM\n\n```bash\n$ cub-scout context-pack --format json > cluster-ctx.json\n$ jq '.ownership | group_by(.type) | map({type: .[0].type, count: length})' cluster-ctx.json\n[\n  {\"type\": \"argo\",     \"count\": 47},\n  {\"type\": \"flux\",     \"count\": 12},\n  {\"type\": \"helm\",     \"count\": 8},\n  {\"type\": \"native\",   \"count\": 23},\n  {\"type\": \"unknown\",  \"count\": 3}\n]\n```\n\nThe pack is **deterministic** — same cluster state + same cub-scout version → same JSON bytes. Safe to feed to an LLM with prompt caching, and safe to diff in CI.\n\n### D: connected MCP for promotion workflows\n\nWhen the ConfigHub session check passes (`confighub_reads: true` in `cub-scout status --json`), `mcp serve` additionally registers the tools below. Since v2.14.0 the check is made through the ConfigHub SDK and needs no `cub` binary; `cub auth status` checks the same session.\n\n- `compare_three_way` — DRY\u002FWET\u002FLIVE comparison\n- `compare_source_truth` — strategy-typed verdict (requires `target` + `namespace` + `strategy`)\n- `confighub_attestations` — attestations recorded directly against one exact revision\n- `confighub_changeorder_get` — one ChangeOrder's reported Stage\u002FState and declarations\n- `confighub_changesets` — governed ChangeSet history from ConfigHub\n- `confighub_k8s_types` — Resource-backed intended Kubernetes type survey\n- `confighub_k8s_resources` — Resource-backed intended Kubernetes resource reader\n- `confighub_live_status` — Space live-status writeback with freshness\n- `confighub_releases` — bounded ConfigHub Release history\n- `confighub_resources` — generic ConfigHub Resource entity query\n- `confighub_unit_events` — bounded ConfigHub UnitEvent history\n- `confighub_units` — ConfigHub unit + fleet inventory\n- `confighub_unit_get` — exact ConfigHub unit details + applied\u002Flive revision\n\nThese are the typical acceptance-kernel inputs. The agent composes them;\ncub-scout produces evidence; the downstream judge decides.\n\n## Output evidence\n\n### `mcp serve` (the gateway)\n\n- Long-running. STDIO transport.\n- Lists tools via the standard MCP `tools\u002Flist` request.\n- Each tool call returns `content[0].text` containing the wrapped CLI verb's `--format json` output verbatim.\n- Optional `structuredContent` field on selected connected-mode tools adds parsed evidence + read-only trust guidance for Pilot-shaped consumers.\n\n### `context-pack` (the snapshot)\n\nThe fields below are `contextPackV2` in `cmd\u002Fcub-scout\u002Fcontext_pack.go`.\n\n| Field | Meaning |\n|---|---|\n| `version` | cub-scout build tag + context-pack schema version |\n| `generatedAt` | RFC 3339 timestamp |\n| `cluster` | kubeconfig context |\n| `namespace` | Scope of the snapshot, or `all` |\n| `provenance` | `source` \u002F `deterministic` \u002F `confidence` for the snapshot itself |\n| `ownershipSummary` | Per-owner counts |\n| `topRisks[]` | Bounded issue list, most severe first |\n| `traceSeeds[]` | Workloads worth tracing, each with the exact `trace` command |\n| `commandEvidence[]` | Commands whose output backs the above |\n| `truncated`, `sizeBytes` | Whether the payload was cut to fit, and its size |\n\nThere is no `mode` field: `context-pack` is a standalone snapshot. Whether\nConfigHub reads work is `confighub_reads` in `cub-scout status --json`.\n\nThe snapshot is the *evidence base* a downstream LLM reasons over. It is NOT a recommendation; the LLM forms recommendations.\n\n## MCP tool catalog (current)\n\nThe closed list of MCP tools cub-scout registers. The set is verified by `cmd\u002Fcub-scout\u002Fmcp_test.go` against the connected\u002Fstandalone modes.\n\n| Tool name | Mode | Wraps |\n|---|---|---|\n| `doctor` | standalone | `cub-scout doctor --format json` plus optional `--with-confighub` delivery evidence flags |\n| `map` | standalone | `cub-scout map list --json` |\n| `scan` | standalone | `cub-scout scan --json` |\n| `trace` | standalone | `cub-scout trace \u003Cresource> --format json` |\n| `explain` | standalone | `cub-scout explain \u003Cresource> --format json` |\n| `gitops_status` | standalone | `cub-scout gitops status --format json` |\n| `gitops_settings` | standalone | `cub-scout gitops settings --format json` (preview: shapes may still change) |\n| `release_check` | standalone | `cub-scout release check --format json` |\n| `compare_three_way` | connected | `cub-scout compare three-way --format json` |\n| `compare_source_truth` | connected | `cub-scout compare source-truth \u003Ctarget> -n \u003Cns> --strategy \u003Cs> --format json` |\n| `confighub_attestations` | connected | One revision and its space's attestation list, as `cub revision get` and `cub attestation list` print them (SDK) |\n| `confighub_changeorder_get` | connected | `cub changeorder get \u003Corder> -o json --space \u003Cspace>` (SDK; an order named by ID runs `cub`) |\n| `confighub_changesets` | connected | `cub changeset list -o json --space \u003Cspace>` (SDK) |\n| `confighub_k8s_resources` | connected | `cub k8s get \u003Ctype> [\u003Cname> ...] -o json` (runs `cub`) |\n| `confighub_k8s_types` | connected | `cub k8s types [\u003Ctype>] -o json` (runs `cub`) |\n| `confighub_live_status` | connected | `cub space list -o json --select Slug,SpaceID,Annotations,Labels [--where \"Slug = '\u003Cspace>'\"]` (runs `cub`) |\n| `confighub_releases` | connected | `cub release list --space \u003Cspace> -o json` (SDK; `space: \"*\"` runs `cub`) |\n| `confighub_resources` | connected | `cub resource list --space \u003Cspace> -o json` (SDK; with `select`, `filter`, `view` or `raw_data` it runs `cub`) |\n| `confighub_unit_events` | connected | `cub unit-event list [unit] --space \u003Cspace> -o json` (SDK; a Unit named by ID or as `\u003Cspace>\u002F\u003Cslug>` runs `cub`) |\n| `confighub_units` | connected | `cub unit list -o json --space \u003Cspace>` (SDK) |\n| `confighub_unit_get` | connected | `cub unit get -o json \u003Cunit> --space \u003Cspace>` (SDK; a Unit named by ID, or as `\u003Cspace>\u002F\u003Cslug>` together with `space`, runs `cub`) |\n\n8 standalone + 13 connected = **21 tools total**. The catalog is intentionally narrow and every tool is read-only.\n\n**(SDK)** marks a read cub-scout makes through the ConfigHub SDK by default since v2.14.0: no `cub` process runs, and the JSON is what the named `cub` command prints. **(runs `cub`)** marks a read that still starts the `cub` CLI and fails, saying so, on a machine without it. `CUB_SCOUT_CONFIGHUB_READER=cub` sends every read through `cub`.\n\nFor the full reference (per-tool parameters, return shape, when-to-load semantics, deferred verbs not in the catalog), see [`references\u002Fmcp-tool-catalog.md`](..\u002Freferences\u002Fmcp-tool-catalog.md).\n\n## References\n\n- Command reference: [`docs\u002Freference\u002Fcommands.md`](..\u002F..\u002Fdocs\u002Freference\u002Fcommands.md) § mcp, § context-pack\n- MCP tool descriptions audit: `cub-scout\u002F#377`\n- Connected MCP trust surface: [`docs\u002Freference\u002Fjson-contracts.md`](..\u002F..\u002Fdocs\u002Freference\u002Fjson-contracts.md) § \"MCP connected trust guidance\"\n- Context-pack format: [`docs\u002Fhowto\u002Fcontext-pack-v2.md`](..\u002F..\u002Fdocs\u002Fhowto\u002Fcontext-pack-v2.md)\n- AI integration walkthrough: [`examples\u002Fai-integration\u002F`](..\u002F..\u002Fexamples\u002Fai-integration\u002F)\n- MCP gateway example: [`examples\u002Fmcp-gateway\u002F`](..\u002F..\u002Fexamples\u002Fmcp-gateway\u002F)\n- Bot deployment example: [`examples\u002Fbot\u002F`](..\u002F..\u002Fexamples\u002Fbot\u002F)\n\n## Constraints\n\n- The MCP server never starts a mutating tool. The tool catalog is closed and read-only by construction; adding a tool requires a code change + a passing test.\n- `context-pack` is **deterministic** — same input, same bytes. Do not introduce non-determinism (random IDs, timestamps in non-`capturedAt` fields, map iteration order).\n- For long-running agent sessions, use MCP STDIO; `bot` is the separate in-cluster event-stream entrypoint.\n- `cub-scout mcp serve` is the cub-scout-side MCP. `cub` may also expose an MCP surface; the two are separate, and an agent can register both.\n",{"name":5,"phase":54,"description":7,"allowed-tools":55},"cross-cutting","Bash(.\u002Fcub-scout mcp *) Bash(cub-scout mcp *) Bash(cub scout mcp *) Bash(.\u002Fcub-scout context-pack *) Bash(cub-scout context-pack *) Bash(cub scout context-pack *) Bash(.\u002Fcub-scout version) Bash(cub-scout version) Bash(cub scout version) Bash(.\u002Fcub-scout status) Bash(cub-scout status) Bash(cub scout status) Bash(kubectl get *) Bash(kubectl describe *) Bash(kubectl config current-context) Bash(cub auth status) Bash(cub space list *) Bash(cub unit get *) Bash(cub unit list *) Bash(cub link get *) Bash(cub link list *) Bash(cub view get *) Bash(cub view list *) Bash(cub unit-event list *) Bash(cub resource list *) Bash(cub release list *) Bash(cub changeset list *)","main","261862e7ec5e5c93ce377ccfd6b583f5ac03c95c","skills\u002Fscout-mcp",1,"https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout","https:\u002F\u002Fgithub.com\u002Fconfighub","http:\u002F\u002Fwww.confighub.com","Public repo for ConfigHub","2026-11-11 04:47:05",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add confighub\u002Fcub-scout --skill scout-mcp",{"tool":71,"command":72},"bunx","bunx skills add confighub\u002Fcub-scout --skill scout-mcp",{"tool":74,"command":75},"pnpm","pnpm dlx skills add confighub\u002Fcub-scout --skill scout-mcp","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-mcp\u002FSKILL.md",true,[],[80,114,138,155,177,201],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":89,"publishedAt":49},"01M6CBPQHTK7YGVZD3MMH1328H","triage-unhealthy-workload","Use when the user is responding to a broken Kubernetes workload UNDER TIME PRESSURE — pager-going-off, CI-red, \"prod is down\" framing. Natural phrasing: \"deploy\u002Fapi is CrashLoopBackOff, what now?\", \"the rollout is stuck, help\", \"this pod won't start\", \"pager fired on payments\", \"everything is red in argocd\", \"what should I check first?\", \"give me a triage plan for this workload\". Composes doctor → explain → trace into a tight ~30-second loop the operator can run in a pager-acknowledged context. Do NOT load for: a planned investigation without urgency (use scout-diagnose directly), a drift question (use investigate-drift), or anything mutating (cub-scout never mutates — route to kubectl with the user driving).","https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Ftriage-unhealthy-workload\u002FSKILL.md",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[90,91,92,93,94,95,96,97,98,99,39,100,101,102,103,104,105,106,107,108,109,110,111,112,31,113,28],"triage","workload","triage unhealthy workload","kubernetes","diagnose","doctor","logs","ci","payments","api","loop","explain","check","broken","question","use","rollout","never","cub scout","route","drift","map","time","now",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":121,"publishedAt":49},"01M6CBPKYVREY83CQYNFW6BVD0","scout-verify","Use when the user wants a TYPED, FINGERPRINTED, IMMUTABLE evidence artifact about a Kubernetes resource — the Verify verb group of cub-scout (the receipt capability shipped in #446). Natural phrasing: \"produce a receipt that this is in compliance\", \"give me an attestation that the cluster matches Git\", \"I need a verifiable record for the audit trail\", \"build a receipt verifying no manual edits since deploy\", \"verify deploy\u002Fapi against source-truth and save the artifact\", \"validate this receipt has not been tampered with\", \"show me what receipts we have\", \"is this receipt tampered with?\", \"attach evidence to my CI gate\". Load whenever intent is receipt \u002F attestation \u002F evidence-artifact \u002F tamper-evident-record \u002F verified-record \u002F audit-trail \u002F postmortem-evidence \u002F acceptance-judge-input. Do NOT load for: a live comparison without a persisted artifact (use scout-compare), interpreting a single field's provenance (use scout-attribute), or actually applying a fix (cub-scout never mutates — route to cub \u002F argocd \u002F kubectl with the user driving).","https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-verify\u002FSKILL.md",[120],{"categoryNo":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},[122,123,24,93,124,125,97,126,127,99,128,39,129,27,130,131,132,105,107,133,108,134,109,135,31,136,30,137,28],"verify","scout verify","acceptance","produce","attestation","provenance","show me","postmortem","argocd","view","fix","evidence","show","me","app","managed",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":49},"01M6CBPF8WZBM7F9X096WT8PJD","scout-observe","Use when the user wants to SEE what is running in a Kubernetes cluster, who owns it, and how it is structured — the read-only Observe verb group of cub-scout. Natural phrasing: \"what is running in my cluster?\", \"give me a map of resources\", \"who owns this Deployment?\", \"trace this back to its source\", \"show me the ownership tree\", \"scan this cluster for risk\", \"dump the cluster as JSON\", \"stream cluster events\", \"run cub-scout as a bot\", \"what is the connection status?\", \"is this cluster healthy?\". Load when intent is observe \u002F inventory \u002F map \u002F show \u002F list \u002F trace \u002F scan \u002F dump \u002F stream \u002F bot \u002F health-check over a Kubernetes cluster. Do NOT load for: explaining WHY something is broken (use scout-diagnose), comparing cluster state to intended state (use scout-compare), provenance of individual field values (use scout-attribute), or any action that mutates the cluster (cub-scout never mutates — route to cub or kubectl with the user driving).","https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-observe\u002FSKILL.md",[],[32,145,24,48,93,94,146,95,96,147,127,148,128,39,103,105,149,107,35,150,108,134,151,152,111,31,153,154,28],"scout observe","deployment","risk","inventory","version","hooks","back","health-check","resources","meaning",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":49},"01M6CBP7D72G704FWGRXNB6F9T","scout-ingest","Use when the user wants to ADOPT existing Kubernetes \u002F GitOps workload structure into ConfigHub after observing the live cluster — the adoption\u002Fimport verb group of cub-scout. Natural phrasing: \"discover workloads in this cluster and propose ConfigHub units\", \"show me the import proposal before I apply\", \"import this Argo Application set\", \"bring my Flux Kustomizations into ConfigHub\", \"preview what would land in ConfigHub if I imported this repo\", \"parse my git repo as a ConfigHub import bundle\", \"import a cluster aggregator\", \"what would --git-path produce for this repo?\". Load whenever intent is adopt \u002F import \u002F ingest \u002F preview \u002F propose \u002F parse-repo \u002F discovery \u002F aggregator \u002F bring-into-confighub \u002F what-would-confighub-see. Do NOT load for: questions about who changed a resource, whether it was edited by hand or drifted (use scout-attribute or investigate-drift); reading an exported `kubectl get -o yaml` dump to answer a question about the cluster (that is not an import); basic live-cluster inventory (use scout-observe), troubleshooting (use scout-diagnose), comparing live state to ConfigHub (use scout-compare), or the actual write to ConfigHub via `cub variant upload` (that is `cub`, not cub-scout — route to cub skills). Important: `cub-scout import apply` IS the mutating write into ConfigHub — this skill teaches the read-only preview path and explicitly refuses to invoke `import apply` itself.","https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-ingest\u002FSKILL.md",[],[162,163,24,93,94,42,164,125,165,40,148,166,128,39,27,167,104,37,168,131,105,35,32,108,134,169,170,171,172,136,30,173,174,175,176],"ingest","scout ingest","state","adoption","discovery","repo","write","structure","aggregator","adopt","argo","reading","exported","invoke","parse",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":49},"01M6CBP32CYJT8DJSGNCRWXQTM","scout-govern","Use when the user wants to consume CONNECTED ConfigHub governance signals from cub-scout — the Govern verb group. Natural phrasing: \"show me the ChangeSet history for this unit\", \"what is the blast radius if I change this unit?\", \"which clusters in my fleet are outliers?\", \"show me yesterday's connected summary\", \"render this view across the fleet\", \"audit who changed this\", \"where did the last apply come from?\", \"list ConfigHub bundles I have\", \"show me the catalog of past snapshots\". Load whenever intent is history \u002F impact \u002F blast-radius \u002F fleet-outliers \u002F summary \u002F view \u002F audit \u002F bundle \u002F catalog \u002F connected-context. Do NOT load for: live cluster comparison (use scout-compare), receipts (use scout-verify), inventory of running pods (use scout-observe), or any mutation via cub. Most of this skill requires `cub auth login` — say so upfront.","https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-govern\u002FSKILL.md",[],[184,24,185,45,186,187,188,148,122,128,39,189,27,131,190,105,191,192,193,32,108,134,194,31,195,196,30,197,198,199,200,28],"scout govern","change","governance","blast radius","audit","history","catalog","diff","say","snapshots","project","mutation","impact","render","blast-radius","which","inspect",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":207,"publishedAt":49},"01M6CBNZ2JCB0050H8NYYGQMDN","scout-diagnose","Use when the user wants cub-scout to INTERPRET what it sees and suggest a next step — the Diagnose verb group. Natural phrasing: \"explain this Deployment\", \"why is this broken?\", \"what should I do about this?\", \"is this drift or just slow sync?\", \"what does this error mean?\", \"is there a known pattern for this?\", \"is my GitOps pipeline healthy?\", \"what events are firing on this Pod?\", \"give me a suggested remedy for this finding\". Load whenever intent is explain \u002F why \u002F what-does-it-mean \u002F what-should-I-do \u002F interpret \u002F diagnose \u002F recommend \u002F suggest-fix over a Kubernetes cluster or a scan finding. Do NOT load for: pure cluster inventory (use scout-observe), comparing intended vs running state at the field level (use scout-compare), field-level provenance (use scout-attribute), or actually applying a fix (cub-scout never mutates — route to cub or kubectl with the user driving).","https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-diagnose\u002FSKILL.md",[],[94,208,24,93,209,146,164,96,210,127,148,39,101,130,211,103,132,105,107,32,108,109,110,135,212,31,136,213,214,28],"scout diagnose","debug","pipeline","just","next","error","what-should-i-do"]