[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CBPF8WZBM7F9X096WT8PJD":3,"skill-same:01M6CBPF8WZBM7F9X096WT8PJD":78},{"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":18,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6CBPF8WZBM7F9X096WT8PJD","scout-observe",null,"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).","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-observe\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"scout","scout observe","observe","never","when","meaning","resources","get","map","health-check","back","show","cub scout","hooks","only","bot","version","use","broken","Bash","show me","inventory","provenance","risk","logs","doctor","deployment","diagnose","kubernetes","2026-11-10 10:12:30",false,"---\nname: scout-observe\ndescription: '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).'\nphase: verify\nallowed-tools: Bash(.\u002Fcub-scout doctor) Bash(.\u002Fcub-scout doctor *) Bash(cub-scout doctor) Bash(cub-scout doctor *) Bash(cub scout doctor) Bash(cub scout doctor *) Bash(.\u002Fcub-scout map list *) Bash(.\u002Fcub-scout map workloads *) Bash(.\u002Fcub-scout map orphans *) Bash(.\u002Fcub-scout map activity *) Bash(.\u002Fcub-scout map hooks *) Bash(.\u002Fcub-scout map meaning *) Bash(cub-scout map list *) Bash(cub-scout map workloads *) Bash(cub-scout map orphans *) Bash(cub-scout map activity *) Bash(cub-scout map hooks *) Bash(cub-scout map meaning *) Bash(cub scout map list *) Bash(cub scout map workloads *) Bash(cub scout map orphans *) Bash(cub scout map activity *) Bash(cub scout map hooks *) Bash(cub scout map meaning *) Bash(.\u002Fcub-scout trace *) Bash(cub-scout trace *) Bash(cub scout trace *) Bash(.\u002Fcub-scout tree *) Bash(cub-scout tree *) Bash(cub scout tree *) Bash(.\u002Fcub-scout scan *) Bash(cub-scout scan *) Bash(cub scout scan *) Bash(.\u002Fcub-scout graph *) Bash(cub-scout graph *) Bash(cub scout graph *) Bash(.\u002Fcub-scout snapshot *) Bash(cub-scout snapshot *) Bash(cub scout snapshot *) Bash(.\u002Fcub-scout status) Bash(.\u002Fcub-scout status *) Bash(cub-scout status) Bash(cub-scout status *) Bash(cub scout status) Bash(cub scout status *) Bash(kubectl get *) Bash(kubectl describe *) Bash(kubectl logs *) Bash(kubectl version) Bash(kubectl config current-context) Bash(kubectl config get-contexts *)\n---\n\n# scout-observe\n\nThe Observe verb group of cub-scout. Ten commands that show what is running in a cluster and who owns it — without modifying anything.\n\n## When to use\n\nExplicit phrasings:\n\n- \"What is running in my cluster?\" \u002F \"show me the Deployments in namespace prod\"\n- \"Give me a map of ownership\" \u002F \"who manages this resource?\"\n- \"Trace deploy\u002Fapi back to its Git source\" \u002F \"what created this?\"\n- \"Show me the ownership tree\" \u002F \"render the resource hierarchy\"\n- \"Scan this cluster for risk\" \u002F \"scan this manifest file\"\n- \"Dump cluster state as JSON\" \u002F \"snapshot the namespace\"\n- \"Stream cluster events to a webhook\"\n- \"Run cub-scout as an in-cluster observer bot\"\n- \"What's my connection status?\" \u002F \"am I connected to ConfigHub?\"\n- \"Is this cluster healthy?\" \u002F \"give me a one-screen status\"\n\nImplicit intents the skill should catch:\n\n- The user wants a *picture* of the cluster, not a diagnosis or remediation\n- The user wants a stable JSON \u002F ASCII artifact (for an agent, an audit, or a pipeline)\n- The user is starting a triage and needs to know what they're looking at before going deeper\n\n## Do not load for\n\n- \"Why is this broken?\" — load [`scout-diagnose`](..\u002Fscout-diagnose\u002FSKILL.md) instead\n- \"Does the cluster match what Git says?\" — load [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md)\n- \"Where did this field's value come from?\" — load [`scout-attribute`](..\u002Fscout-attribute\u002FSKILL.md)\n- \"Fix this\" \u002F \"apply this\" \u002F \"delete this\" — cub-scout cannot mutate; route to `cub`, `kubectl` (user driven), or another tool\n\n## Standalone vs connected\n\n- **Standalone (cluster only):** all ten Observe verbs work. `doctor`, `map`, `trace`, `tree`, `scan`, `graph`, `snapshot`, `watch`, `bot`, `status` need only your current kubectl context or in-cluster service account.\n- **Connected (cluster + `cub auth login`):** `trace --with-confighub`, `explain --with-confighub`, and single-resource `receipt verify --with-confighub` can attach object-correlated ConfigHub delivery evidence; `map activity --with-confighub` adds bounded release, unit-event, live-status, and event-consumer timeline rows; `status` shows ConfigHub session detail; `scan` can correlate findings with units.\n- **Offline (file \u002F bundle only):** `scan --file \u003Cpath>` audits manifests without a cluster; `bundle inspect` reads recorded debug bundles.\n\n## Tool boundary\n\n- **Allowed (read-only):** the specific Observe verbs — `cub-scout doctor`, `cub-scout map list \u002F workloads \u002F orphans \u002F activity \u002F hooks \u002F meaning`, `cub-scout trace`, `cub-scout tree`, `cub-scout scan`, `cub-scout graph`, `cub-scout snapshot`, `cub-scout status` (in all three invocation forms: `cub-scout`, `.\u002Fcub-scout`, `cub scout`). Plus `kubectl get\u002Fdescribe\u002Flogs`, `kubectl version`, `kubectl config current-context \u002F get-contexts`. `cub-scout watch` and `cub-scout bot` are Observe verbs too, but are not auto-approved: its `--webhook` flag sends events to any URL, so the host asks each time; `kubectl config view` is left out because `--raw` prints credentials. **Never** the broad `cub-scout *` wildcard — that would grant `demo` (kubectl-applies), `import apply` (writes to ConfigHub), and `compare --suggest --apply` (writes to ConfigHub).\n- **Not allowed:** `kubectl apply\u002Fedit\u002Fpatch\u002Fdelete\u002Fscale\u002Frollout\u002Fexec`, `kubectl debug` (privileged debug pods), any `cub * create\u002Fupdate\u002Fdelete`.\n- **Boundary with [`scout-diagnose`](..\u002Fscout-diagnose\u002FSKILL.md):** Observe shows *what* is there; Diagnose interprets *why* it looks the way it does and recommends *next steps*. The two often chain: Observe to map, then Diagnose to interpret.\n\n## The verb menu\n\nPick by the question being asked:\n\n| Question | Verb | Notes |\n|---|---|---|\n| \"Is this cluster healthy at a glance?\" | `cub-scout doctor` | One-screen health summary, with `--presentation human\\|ai\\|paired` and `--hint-mode default\\|beginner\\|operator` |\n| \"What's in this cluster, grouped by ownership?\" | `cub-scout map` (interactive TUI) | Sub-commands: `map list`, `map hooks`, `map activity`, `map orphans`, `map meaning` |\n| \"What happened recently in delivery\u002Fstatus feedback?\" | `cub-scout map activity --with-confighub --confighub-space \u003Cspace>` | Timeline rows for controller activity, Kubernetes events, ConfigHub releases, unit events, live-status writeback, event-consumer health, and omissions |\n| \"Can I keep the exact delivery\u002Fstatus observation for review?\" | `cub-scout receipt verify \u003Ckind>\u002F\u003Cname> -n \u003Cns> --with-confighub --confighub-space \u003Cspace>` | Fingerprint-covered `predicate.evidence.deliveryEvidence` on a single-resource receipt |\n| \"Trace this workload back to its Git \u002F OCI source\" | `cub-scout trace \u003Ckind>\u002F\u003Cname> -n \u003Cns>` | Walks Deployment → Application → Git or Deployment → HelmRelease → GitRepository |\n| \"Show me the runtime + ownership + git hierarchy\" | `cub-scout tree` | Multi-axis composition view |\n| \"Scan for risk patterns\" | `cub-scout scan` | 46 built-in patterns. Variants: `--state`, `--kyverno`, `--lifecycle-hazards`, `--timing-bombs`, `--dangling`, `--file \u003Cyaml>` |\n| \"Export the resource graph\" | `cub-scout graph export` | DOT \u002F JSON for downstream tools |\n| \"Dump the cluster as GSF JSON\" | `cub-scout snapshot` | Stable snapshot for AI \u002F agent \u002F audit; includes top-level `observation` metadata |\n| \"Stream observation events\" | `cub-scout watch -n \u003Cns> [--webhook url]` | Webhook \u002F file sinks, namespace \u002F owner \u002F severity filters; events include `observation` metadata |\n| \"Run an in-cluster observer bot\" | `cub-scout bot --webhook \u003Curl>` | Same event shape as `watch`, with env-var configuration for Kubernetes manifests and per-event `observation` metadata |\n| \"What mode am I in? Connection \u002F cluster info\" | `cub-scout status` | Standalone vs connected, context, cluster details |\n\nSnapshot-style verbs that support `--format json` emit deterministic JSON for\nagents. `map list --format json`, `snapshot`, `watch`, and `bot` also expose\npoint-in-time `observation.source\u002Fmode\u002FobservedAt\u002Ffreshness` metadata so agents\ncan avoid confusing a stale artifact with a fresh read.\n\n## The loop\n\n1. **Identify intent.** Translate the user's question into one of the rows in the verb menu above. If multiple verbs could answer, prefer the most specific (`trace` over `map` if the question is about one resource's lineage).\n2. **Pick the format.** Humans: ASCII (the default). Agents \u002F CI \u002F MCP: `--format json`.\n3. **Invoke.** Use `.\u002Fcub-scout ...` in the local repo; `cub-scout ...` standalone; `cub scout ...` plugin-form. All three accept the same flags.\n4. **Interpret.** Read the structured output:\n   - `doctor` → top-level health, top issues, next-step hints\n   - `map` → resource list with owner + namespace + health columns\n   - `trace` → ownership chain (controller → source → repository → commit)\n   - `scan` → findings list with severity + pattern + resource\n   - `snapshot` \u002F `graph export` → bulk JSON for downstream tooling\n5. **Hand off.** If the user needs a *why* or a *fix*, route to [`scout-diagnose`](..\u002Fscout-diagnose\u002FSKILL.md). If they need to compare against intent, route to [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md). If they need to act, refuse and route to `cub` skills or `kubectl` with the user driving.\n\n## Worked example\n\nUser: *\"Map the boutique namespace and show me which Deployments are managed by Argo.\"*\n\n```bash\n$ cub-scout map list -n boutique --format ascii\nNAME              KIND          OWNER     SOURCE                                      HEALTH\nfrontend          Deployment    Argo CD   apps\u002Fprod\u002Fboutique\u002Ffrontend                Ready\ncatalog           Deployment    Argo CD   apps\u002Fprod\u002Fboutique\u002Fcatalog                 Ready\ncheckout          Deployment    Flux      flux-system\u002FKustomization\u002Fboutique-checkout Ready\nredis             StatefulSet   Native    -                                           Ready\n```\n\nRead off: 2 Argo-managed Deployments, 1 Flux-managed, 1 native (no GitOps controller). The output is enough for the user to drill into any single resource with `trace deploy\u002Ffrontend -n boutique` (which is still in scope for this skill) or jump to `scout-diagnose` if they want to know *why* a status is what it is.\n\nFor agents:\n\n```bash\n$ cub-scout map list -n boutique --format json | jq '[.[] | {name, owner, source}]'\n[\n  {\"name\": \"frontend\", \"owner\": \"Argo CD\", \"source\": \"apps\u002Fprod\u002Fboutique\u002Ffrontend\"},\n  {\"name\": \"catalog\", \"owner\": \"Argo CD\", \"source\": \"apps\u002Fprod\u002Fboutique\u002Fcatalog\"},\n  {\"name\": \"checkout\", \"owner\": \"Flux\", \"source\": \"flux-system\u002FKustomization\u002Fboutique-checkout\"},\n  {\"name\": \"redis\", \"owner\": \"Native\", \"source\": null}\n]\n```\n\n## Output evidence\n\n- **Primary artifact:** ASCII or JSON output from the chosen verb.\n- **MCP gateway:** the standalone Observe tools (`doctor`, `map`, `scan`, `trace`, `explain`, `gitops_status`, `gitops_settings`, `release_check`) are exposed as MCP tools via `cub-scout mcp serve`. See [`references\u002Fmcp-tool-catalog.md`](..\u002Freferences\u002Fmcp-tool-catalog.md) for the full per-tool catalog (8 standalone + 13 connected, verified against `cmd\u002Fcub-scout\u002Fmcp.go`). Note: not every CLI verb is an MCP tool — e.g., `tree`, `graph`, `snapshot`, `watch`, `bot`, `status` are CLI-only.\n- **`nextSteps[]`** structured hints (where supported): every entry has `actionType: read-only` — mutating actionType is rejected at every cub-scout emit point.\n\n## References\n\n- Capability map: [`README.md`](..\u002F..\u002FREADME.md#capability-map) § Observe\n- Command details: [`docs\u002Freference\u002Fcommands.md`](..\u002F..\u002Fdocs\u002Freference\u002Fcommands.md)\n- JSON contract: [`docs\u002Freference\u002Fjson-contracts.md`](..\u002F..\u002Fdocs\u002Freference\u002Fjson-contracts.md)\n- Read-only triad: planned at `references\u002Fread-only-triad.md` (batch 5)\n- Standalone vs connected: planned at `references\u002Fstandalone-vs-connected.md` (batch 5)\n\n## Constraints\n\n- All output is point-in-time. `map list --format json`, `snapshot`, `watch`,\n  and `bot` declare this with `observation` metadata. For a durable,\n  fingerprinted record of \"what cub-scout observed at time T\", use the Verify\n  verb group (`cub-scout receipt verify`) — see\n  [`scout-verify`](..\u002Fscout-verify\u002FSKILL.md).\n- If `managedFields` is missing or stripped from the live object, ownership detection still works (via labels + annotations) but per-field attribution falls back to resource-level. See [`references\u002Fkubernetes-managedfields.md`](..\u002Freferences\u002Fkubernetes-managedfields.md) for the data substrate notes.\n- The `watch` and `bot` verbs run indefinitely until interrupted; agents should pass `--once` or a time bound. Streaming receipts use `--emit-receipt-on`, with per-poll backpressure from `--emit-receipt-batch-cap`.\n- If a user asks the skill to act (apply \u002F edit \u002F sync \u002F patch \u002F delete), refuse and route to the appropriate `cub` skill in [`confighub\u002Fconfighub-skills`](https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fconfighub-skills) or to direct `kubectl` with the user's hands on the keyboard.\n","# scout-observe\n\nThe Observe verb group of cub-scout. Ten commands that show what is running in a cluster and who owns it — without modifying anything.\n\n## When to use\n\nExplicit phrasings:\n\n- \"What is running in my cluster?\" \u002F \"show me the Deployments in namespace prod\"\n- \"Give me a map of ownership\" \u002F \"who manages this resource?\"\n- \"Trace deploy\u002Fapi back to its Git source\" \u002F \"what created this?\"\n- \"Show me the ownership tree\" \u002F \"render the resource hierarchy\"\n- \"Scan this cluster for risk\" \u002F \"scan this manifest file\"\n- \"Dump cluster state as JSON\" \u002F \"snapshot the namespace\"\n- \"Stream cluster events to a webhook\"\n- \"Run cub-scout as an in-cluster observer bot\"\n- \"What's my connection status?\" \u002F \"am I connected to ConfigHub?\"\n- \"Is this cluster healthy?\" \u002F \"give me a one-screen status\"\n\nImplicit intents the skill should catch:\n\n- The user wants a *picture* of the cluster, not a diagnosis or remediation\n- The user wants a stable JSON \u002F ASCII artifact (for an agent, an audit, or a pipeline)\n- The user is starting a triage and needs to know what they're looking at before going deeper\n\n## Do not load for\n\n- \"Why is this broken?\" — load [`scout-diagnose`](..\u002Fscout-diagnose\u002FSKILL.md) instead\n- \"Does the cluster match what Git says?\" — load [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md)\n- \"Where did this field's value come from?\" — load [`scout-attribute`](..\u002Fscout-attribute\u002FSKILL.md)\n- \"Fix this\" \u002F \"apply this\" \u002F \"delete this\" — cub-scout cannot mutate; route to `cub`, `kubectl` (user driven), or another tool\n\n## Standalone vs connected\n\n- **Standalone (cluster only):** all ten Observe verbs work. `doctor`, `map`, `trace`, `tree`, `scan`, `graph`, `snapshot`, `watch`, `bot`, `status` need only your current kubectl context or in-cluster service account.\n- **Connected (cluster + `cub auth login`):** `trace --with-confighub`, `explain --with-confighub`, and single-resource `receipt verify --with-confighub` can attach object-correlated ConfigHub delivery evidence; `map activity --with-confighub` adds bounded release, unit-event, live-status, and event-consumer timeline rows; `status` shows ConfigHub session detail; `scan` can correlate findings with units.\n- **Offline (file \u002F bundle only):** `scan --file \u003Cpath>` audits manifests without a cluster; `bundle inspect` reads recorded debug bundles.\n\n## Tool boundary\n\n- **Allowed (read-only):** the specific Observe verbs — `cub-scout doctor`, `cub-scout map list \u002F workloads \u002F orphans \u002F activity \u002F hooks \u002F meaning`, `cub-scout trace`, `cub-scout tree`, `cub-scout scan`, `cub-scout graph`, `cub-scout snapshot`, `cub-scout status` (in all three invocation forms: `cub-scout`, `.\u002Fcub-scout`, `cub scout`). Plus `kubectl get\u002Fdescribe\u002Flogs`, `kubectl version`, `kubectl config current-context \u002F get-contexts`. `cub-scout watch` and `cub-scout bot` are Observe verbs too, but are not auto-approved: its `--webhook` flag sends events to any URL, so the host asks each time; `kubectl config view` is left out because `--raw` prints credentials. **Never** the broad `cub-scout *` wildcard — that would grant `demo` (kubectl-applies), `import apply` (writes to ConfigHub), and `compare --suggest --apply` (writes to ConfigHub).\n- **Not allowed:** `kubectl apply\u002Fedit\u002Fpatch\u002Fdelete\u002Fscale\u002Frollout\u002Fexec`, `kubectl debug` (privileged debug pods), any `cub * create\u002Fupdate\u002Fdelete`.\n- **Boundary with [`scout-diagnose`](..\u002Fscout-diagnose\u002FSKILL.md):** Observe shows *what* is there; Diagnose interprets *why* it looks the way it does and recommends *next steps*. The two often chain: Observe to map, then Diagnose to interpret.\n\n## The verb menu\n\nPick by the question being asked:\n\n| Question | Verb | Notes |\n|---|---|---|\n| \"Is this cluster healthy at a glance?\" | `cub-scout doctor` | One-screen health summary, with `--presentation human\\|ai\\|paired` and `--hint-mode default\\|beginner\\|operator` |\n| \"What's in this cluster, grouped by ownership?\" | `cub-scout map` (interactive TUI) | Sub-commands: `map list`, `map hooks`, `map activity`, `map orphans`, `map meaning` |\n| \"What happened recently in delivery\u002Fstatus feedback?\" | `cub-scout map activity --with-confighub --confighub-space \u003Cspace>` | Timeline rows for controller activity, Kubernetes events, ConfigHub releases, unit events, live-status writeback, event-consumer health, and omissions |\n| \"Can I keep the exact delivery\u002Fstatus observation for review?\" | `cub-scout receipt verify \u003Ckind>\u002F\u003Cname> -n \u003Cns> --with-confighub --confighub-space \u003Cspace>` | Fingerprint-covered `predicate.evidence.deliveryEvidence` on a single-resource receipt |\n| \"Trace this workload back to its Git \u002F OCI source\" | `cub-scout trace \u003Ckind>\u002F\u003Cname> -n \u003Cns>` | Walks Deployment → Application → Git or Deployment → HelmRelease → GitRepository |\n| \"Show me the runtime + ownership + git hierarchy\" | `cub-scout tree` | Multi-axis composition view |\n| \"Scan for risk patterns\" | `cub-scout scan` | 46 built-in patterns. Variants: `--state`, `--kyverno`, `--lifecycle-hazards`, `--timing-bombs`, `--dangling`, `--file \u003Cyaml>` |\n| \"Export the resource graph\" | `cub-scout graph export` | DOT \u002F JSON for downstream tools |\n| \"Dump the cluster as GSF JSON\" | `cub-scout snapshot` | Stable snapshot for AI \u002F agent \u002F audit; includes top-level `observation` metadata |\n| \"Stream observation events\" | `cub-scout watch -n \u003Cns> [--webhook url]` | Webhook \u002F file sinks, namespace \u002F owner \u002F severity filters; events include `observation` metadata |\n| \"Run an in-cluster observer bot\" | `cub-scout bot --webhook \u003Curl>` | Same event shape as `watch`, with env-var configuration for Kubernetes manifests and per-event `observation` metadata |\n| \"What mode am I in? Connection \u002F cluster info\" | `cub-scout status` | Standalone vs connected, context, cluster details |\n\nSnapshot-style verbs that support `--format json` emit deterministic JSON for\nagents. `map list --format json`, `snapshot`, `watch`, and `bot` also expose\npoint-in-time `observation.source\u002Fmode\u002FobservedAt\u002Ffreshness` metadata so agents\ncan avoid confusing a stale artifact with a fresh read.\n\n## The loop\n\n1. **Identify intent.** Translate the user's question into one of the rows in the verb menu above. If multiple verbs could answer, prefer the most specific (`trace` over `map` if the question is about one resource's lineage).\n2. **Pick the format.** Humans: ASCII (the default). Agents \u002F CI \u002F MCP: `--format json`.\n3. **Invoke.** Use `.\u002Fcub-scout ...` in the local repo; `cub-scout ...` standalone; `cub scout ...` plugin-form. All three accept the same flags.\n4. **Interpret.** Read the structured output:\n   - `doctor` → top-level health, top issues, next-step hints\n   - `map` → resource list with owner + namespace + health columns\n   - `trace` → ownership chain (controller → source → repository → commit)\n   - `scan` → findings list with severity + pattern + resource\n   - `snapshot` \u002F `graph export` → bulk JSON for downstream tooling\n5. **Hand off.** If the user needs a *why* or a *fix*, route to [`scout-diagnose`](..\u002Fscout-diagnose\u002FSKILL.md). If they need to compare against intent, route to [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md). If they need to act, refuse and route to `cub` skills or `kubectl` with the user driving.\n\n## Worked example\n\nUser: *\"Map the boutique namespace and show me which Deployments are managed by Argo.\"*\n\n```bash\n$ cub-scout map list -n boutique --format ascii\nNAME              KIND          OWNER     SOURCE                                      HEALTH\nfrontend          Deployment    Argo CD   apps\u002Fprod\u002Fboutique\u002Ffrontend                Ready\ncatalog           Deployment    Argo CD   apps\u002Fprod\u002Fboutique\u002Fcatalog                 Ready\ncheckout          Deployment    Flux      flux-system\u002FKustomization\u002Fboutique-checkout Ready\nredis             StatefulSet   Native    -                                           Ready\n```\n\nRead off: 2 Argo-managed Deployments, 1 Flux-managed, 1 native (no GitOps controller). The output is enough for the user to drill into any single resource with `trace deploy\u002Ffrontend -n boutique` (which is still in scope for this skill) or jump to `scout-diagnose` if they want to know *why* a status is what it is.\n\nFor agents:\n\n```bash\n$ cub-scout map list -n boutique --format json | jq '[.[] | {name, owner, source}]'\n[\n  {\"name\": \"frontend\", \"owner\": \"Argo CD\", \"source\": \"apps\u002Fprod\u002Fboutique\u002Ffrontend\"},\n  {\"name\": \"catalog\", \"owner\": \"Argo CD\", \"source\": \"apps\u002Fprod\u002Fboutique\u002Fcatalog\"},\n  {\"name\": \"checkout\", \"owner\": \"Flux\", \"source\": \"flux-system\u002FKustomization\u002Fboutique-checkout\"},\n  {\"name\": \"redis\", \"owner\": \"Native\", \"source\": null}\n]\n```\n\n## Output evidence\n\n- **Primary artifact:** ASCII or JSON output from the chosen verb.\n- **MCP gateway:** the standalone Observe tools (`doctor`, `map`, `scan`, `trace`, `explain`, `gitops_status`, `gitops_settings`, `release_check`) are exposed as MCP tools via `cub-scout mcp serve`. See [`references\u002Fmcp-tool-catalog.md`](..\u002Freferences\u002Fmcp-tool-catalog.md) for the full per-tool catalog (8 standalone + 13 connected, verified against `cmd\u002Fcub-scout\u002Fmcp.go`). Note: not every CLI verb is an MCP tool — e.g., `tree`, `graph`, `snapshot`, `watch`, `bot`, `status` are CLI-only.\n- **`nextSteps[]`** structured hints (where supported): every entry has `actionType: read-only` — mutating actionType is rejected at every cub-scout emit point.\n\n## References\n\n- Capability map: [`README.md`](..\u002F..\u002FREADME.md#capability-map) § Observe\n- Command details: [`docs\u002Freference\u002Fcommands.md`](..\u002F..\u002Fdocs\u002Freference\u002Fcommands.md)\n- JSON contract: [`docs\u002Freference\u002Fjson-contracts.md`](..\u002F..\u002Fdocs\u002Freference\u002Fjson-contracts.md)\n- Read-only triad: planned at `references\u002Fread-only-triad.md` (batch 5)\n- Standalone vs connected: planned at `references\u002Fstandalone-vs-connected.md` (batch 5)\n\n## Constraints\n\n- All output is point-in-time. `map list --format json`, `snapshot`, `watch`,\n  and `bot` declare this with `observation` metadata. For a durable,\n  fingerprinted record of \"what cub-scout observed at time T\", use the Verify\n  verb group (`cub-scout receipt verify`) — see\n  [`scout-verify`](..\u002Fscout-verify\u002FSKILL.md).\n- If `managedFields` is missing or stripped from the live object, ownership detection still works (via labels + annotations) but per-field attribution falls back to resource-level. See [`references\u002Fkubernetes-managedfields.md`](..\u002Freferences\u002Fkubernetes-managedfields.md) for the data substrate notes.\n- The `watch` and `bot` verbs run indefinitely until interrupted; agents should pass `--once` or a time bound. Streaming receipts use `--emit-receipt-on`, with per-poll backpressure from `--emit-receipt-batch-cap`.\n- If a user asks the skill to act (apply \u002F edit \u002F sync \u002F patch \u002F delete), refuse and route to the appropriate `cub` skill in [`confighub\u002Fconfighub-skills`](https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fconfighub-skills) or to direct `kubectl` with the user's hands on the keyboard.\n",{"name":5,"phase":53,"description":7,"allowed-tools":54},"verify","Bash(.\u002Fcub-scout doctor) Bash(.\u002Fcub-scout doctor *) Bash(cub-scout doctor) Bash(cub-scout doctor *) Bash(cub scout doctor) Bash(cub scout doctor *) Bash(.\u002Fcub-scout map list *) Bash(.\u002Fcub-scout map workloads *) Bash(.\u002Fcub-scout map orphans *) Bash(.\u002Fcub-scout map activity *) Bash(.\u002Fcub-scout map hooks *) Bash(.\u002Fcub-scout map meaning *) Bash(cub-scout map list *) Bash(cub-scout map workloads *) Bash(cub-scout map orphans *) Bash(cub-scout map activity *) Bash(cub-scout map hooks *) Bash(cub-scout map meaning *) Bash(cub scout map list *) Bash(cub scout map workloads *) Bash(cub scout map orphans *) Bash(cub scout map activity *) Bash(cub scout map hooks *) Bash(cub scout map meaning *) Bash(.\u002Fcub-scout trace *) Bash(cub-scout trace *) Bash(cub scout trace *) Bash(.\u002Fcub-scout tree *) Bash(cub-scout tree *) Bash(cub scout tree *) Bash(.\u002Fcub-scout scan *) Bash(cub-scout scan *) Bash(cub scout scan *) Bash(.\u002Fcub-scout graph *) Bash(cub-scout graph *) Bash(cub scout graph *) Bash(.\u002Fcub-scout snapshot *) Bash(cub-scout snapshot *) Bash(cub scout snapshot *) Bash(.\u002Fcub-scout status) Bash(.\u002Fcub-scout status *) Bash(cub-scout status) Bash(cub-scout status *) Bash(cub scout status) Bash(cub scout status *) Bash(kubectl get *) Bash(kubectl describe *) Bash(kubectl logs *) Bash(kubectl version) Bash(kubectl config current-context) Bash(kubectl config get-contexts *)","main","261862e7ec5e5c93ce377ccfd6b583f5ac03c95c","skills\u002Fscout-observe",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":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add confighub\u002Fcub-scout --skill scout-observe",{"tool":70,"command":71},"bunx","bunx skills add confighub\u002Fcub-scout --skill scout-observe",{"tool":73,"command":74},"pnpm","pnpm dlx skills add confighub\u002Fcub-scout --skill scout-observe","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-observe\u002FSKILL.md",true,[],[79,106,128,154,176,200],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":90,"publishedAt":48},"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",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[91,92,93,47,46,44,43,94,95,96,38,97,98,99,37,100,36,101,22,31,102,103,27,104,26,105,23],"triage","workload","triage unhealthy workload","ci","payments","api","loop","explain","check","question","rollout","route","drift","time","now",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":48},"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",[112],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},[53,114,19,47,115,116,94,117,41,96,39,38,118,119,120,121,122,36,22,123,31,30,102,124,26,125,126,127,23],"scout verify","acceptance","produce","attestation","postmortem","changeset","argocd","view","fix","evidence","me","app","unit","managed",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":137,"publishedAt":48},"01M6CBPBM5J9PX4H8CE628AY5X","scout-mcp","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).","https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-mcp\u002FSKILL.md",[134],{"categoryNo":135,"categoryName":136,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000023","Skill与智能体开发",[138,139,19,34,140,141,142,143,144,145,146,147,38,148,119,149,150,33,151,152,21,26,126,153,23],"MCP","scout mcp","mcp server","ai agent","auth","config","run","release","server","SET","model","read","snapshot","ready","up","agent-context",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":48},"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",[],[161,162,19,47,46,145,163,116,164,147,40,165,39,38,119,166,100,149,167,121,36,33,21,31,30,168,169,170,171,125,126,172,173,174,175],"ingest","scout ingest","state","adoption","discovery","repo","write","structure","aggregator","adopt","argo","reading","exported","invoke","parse",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":48},"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",[],[183,19,184,142,185,186,187,40,53,39,38,188,119,121,189,36,190,191,192,21,31,30,193,26,194,195,126,196,197,198,199,23],"scout govern","change","governance","blast radius","audit","history","catalog","diff","say","snapshots","project","mutation","impact","render","blast-radius","which","inspect",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":48},"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",[],[46,207,19,47,208,45,163,43,209,41,40,38,98,120,210,37,122,36,22,21,31,102,103,124,211,26,125,212,213,23],"scout diagnose","debug","pipeline","just","next","error","what-should-i-do"]