AGENT SKILL

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 / impact / blast-radius / fleet-outliers / summary / view / audit / bundle / catalog / 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.

License 许可
MIT
最近更新
2026-11-11
Stars
★ 14
Forks
1

01 前言 Front Matter

name
scout-govern
phase
verify
description
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 / impact / blast-radius / fleet-outliers / summary / view / audit / bundle / catalog / 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.
allowed-tools
Bash(./cub-scout history *) Bash(cub-scout history *) Bash(cub scout history *) Bash(./cub-scout impact *) Bash(cub-scout impact *) Bash(cub scout impact *) Bash(./cub-scout fleet *) Bash(cub-scout fleet *) Bash(cub scout fleet *) Bash(./cub-scout summary list *) Bash(cub-scout summary list *) Bash(cub scout summary list *) Bash(./cub-scout views resolve *) Bash(./cub-scout views project *) Bash(cub-scout views resolve *) Bash(cub-scout views project *) Bash(cub scout views resolve *) Bash(cub scout views project *) Bash(./cub-scout audit *) Bash(cub-scout audit *) Bash(cub scout audit *) Bash(./cub-scout bundle diff *) Bash(./cub-scout bundle inspect *) Bash(./cub-scout bundle summarize *) Bash(./cub-scout bundle timeline *) Bash(cub-scout bundle diff *) Bash(cub-scout bundle inspect *) Bash(cub-scout bundle summarize *) Bash(cub-scout bundle timeline *) Bash(cub scout bundle diff *) Bash(cub scout bundle inspect *) Bash(cub scout bundle summarize *) Bash(cub scout bundle timeline *) Bash(./cub-scout catalog list *) Bash(./cub-scout catalog validate *) Bash(cub-scout catalog list *) Bash(cub-scout catalog validate *) Bash(cub scout catalog list *) Bash(cub scout catalog validate *) Bash(./cub-scout status) Bash(cub-scout status) Bash(cub scout status) Bash(kubectl get *) Bash(kubectl describe *) 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 *) Bash(cub auth status)

03 SKILL.md 正文

scout-govern

The Govern verb group of cub-scout. Read-only consumption of connected ConfigHub governance signals — ChangeSet history, blast-radius impact analysis, fleet conformance, connected summaries, Views, audit trails, and bundle / catalog state.

Most of this skill requires connected mode (a logged-in cub CLI: cub auth login). Standalone-mode users get bundle / catalog / audit against local artifacts only.

When to use

Explicit phrasings:

  • "Show me the ChangeSet history for unit payments-api"
  • "What's the blast radius if I change this unit?" / "what depends on this?"
  • "Which clusters in my fleet are outliers?" / "show fleet conformance"
  • "Show me yesterday's connected summary for cluster X"
  • "Render Hub View monthly-spend-by-team across the fleet"
  • "Audit who changed deploy/api recently"
  • "Where did the last apply come from?"
  • "List the ConfigHub bundles I have locally"
  • "Show me the catalog of past snapshots"
  • "What ConfigHub units / spaces does this resource belong to?"

Implicit intents:

  • The user is investigating a change retroactively (history / audit / postmortem framing)
  • The user is gating a change prospectively (impact / blast-radius / promotion-safety framing)
  • The user is reasoning across the fleet (multi-cluster outliers, conformance)
  • The user wants a structured connected-mode snapshot rather than ad-hoc reads

Do not load for

Standalone vs connected

  • Connected (cluster + cub auth login): history, impact, fleet outliers, summary list/slack, views resolve, audit list — all require ConfigHub auth.
  • Standalone (cluster only): audit list against local audit logs; bundle inspect/replay/diff/summarize/timeline and catalog list against on-disk artifacts. No ConfigHub needed.
  • Offline (artifact only): bundle inspect, bundle replay, bundle diff, bundle timeline, catalog list work against .bundle.tar / .catalog.json files with no cluster and no ConfigHub.

cub-scout status is the entry point that says which mode you're in.

Tool boundary

  • Allowed (read-only): all eight Govern verbs; kubectl get/describe for cross-reference; cub <entity> get / list for the entities named in allowed-tools (connected); cub auth status to confirm mode.
  • Not allowed: cub * create/update/delete, cub variant upload (mutating), kubectl apply/edit/patch/delete, argocd app sync, flux reconcile --with-source. Governance verbs read the connected surface; they never write to it.
  • fleet and summary: read across multiple clusters via ConfigHub's connected snapshots. They do NOT shell out to each cluster's kubeconfig directly — the connected surface is the source of truth.

The verb menu

Question Verb Notes
"Who changed this unit, when?" cub-scout history <kind>/<name> -n <ns> ChangeSet timeline for the unit tied to this resource. Requires connected.
"What depends on this unit?" cub-scout impact <unit-slug> Blast-radius preview: which downstream units / clusters / Apps would be affected. Requires connected.
"Which clusters are outliers?" cub-scout fleet outliers --view <view> Fleet-wide conformance against a View. Requires connected.
"Show me the connected summary" cub-scout summary list --cluster <name> --format json List stored connected summaries with observation metadata. summary slack formats for Slack output.
"Render a Hub View" cub-scout views resolve <url-or-uuid> Resolve a ConfigHub Hub View URL to its structured columns. --scope cluster for fleet-wide.
"Audit who changed what" cub-scout audit list Audit log entries. Read-only access to ConfigHub's audit trail.
"Inspect a debug bundle" cub-scout bundle inspect <path> bundle replay / diff / summarize / timeline for richer per-bundle reads.
"List my bundle catalogs" cub-scout catalog list Multi-bundle catalog view — useful for time-series / per-environment archives.

The loop

  1. Check the mode. Run cub-scout status to confirm whether you're connected. If not and the user needs connected data, say so explicitly — don't half-answer with stale local data.
  2. Pick the verb. Most user prompts map cleanly to one of the eight verbs above.
  3. Invoke. Use --format json for agent / CI consumption; the default ASCII output is human-friendly.
  4. Read the evidence. Each verb has a structured shape (ChangeSet timeline, impact graph, fleet outlier list, View column matrix). They feed Pilot's acceptance kernel and similar tooling directly.
  5. Hand off. If the user wants to act on a governance finding ("revert this change", "promote to staging", "apply the missing unit"), route to a cub skill. cub-scout never mutates ConfigHub.

Worked examples

A: ChangeSet history (connected)

$ cub-scout history deploy/api -n prod
ChangeSet timeline for unit payments-api:
  2026-05-22T10:30Z  Apply by ci-bot     rev=42  "promote v2.3.0"
  2026-05-21T14:00Z  Apply by alice      rev=41  "config tuning"
  2026-05-20T09:15Z  Create by alice     rev=40  "initial unit"

ConfigHub URL: https://hub.confighub.com/p/payments/u/payments-api

B: blast-radius impact (connected)

$ cub-scout impact payments-api --format json
{
  "unit": "payments-api",
  "downstream": [
    {"kind": "App", "name": "checkout", "via": "link:env-shared"},
    {"kind": "Unit", "name": "payments-worker", "via": "link:image-shared"}
  ],
  "clusters": ["prod-use2", "prod-euw1", "staging-use2"]
}

C: fleet outliers against a View (connected)

$ cub-scout fleet outliers --view monthly-spend-by-team
View: monthly-spend-by-team
Clusters: 12

  payments  EXPECTED 3 deploys / cluster   prod-euw1: 2 (outlier: missing payments-worker)
  checkout  EXPECTED 5 deploys / cluster   ALL match
  search    EXPECTED 4 deploys / cluster   staging-use2: 3 (outlier: missing search-replica)

D: bundle inspect (offline, no cluster needed)

$ cub-scout bundle inspect ./prod-snapshot.bundle.tar
Bundle: prod-snapshot.bundle.tar
  capturedAt: 2026-05-22T10:30:00Z
  cluster: prod-use2
  resources: 247
  topNamespaces: payments(48), checkout(32), platform(20)

bundle diff / bundle timeline work the same way for multi-bundle comparisons.

Output evidence

Verb Returns
history ChangeSet timeline + ConfigHub deep-link
impact Downstream unit / cluster / App graph
fleet outliers Per-View matrix with outlier rows highlighted
summary Stored connected summaries indexed by cluster / timestamp, with summary-store observation metadata in JSON output
views resolve Structured columns from a Hub View URL
audit Audit log entries (read-only ConfigHub audit trail)
bundle inspect/diff/summarize/timeline Per-bundle structured reads
catalog list Multi-bundle catalog metadata

Connected-mode trust surface

Where history / impact / fleet outliers return guidance about whether to act, those hints are trust signals for Pilot and similar acceptance kernels. They are NEVER action recommendations from cub-scout itself. Per the read-only triad (#410 / #428):

  • cub-scout = evidence (this skill)
  • ConfigHub = authority (where the state lives)
  • Pilot = judge (decides accept / wait / block)

If a user is reading impact output and asks "should I promote?", route them to Pilot or to a human acceptance step — never let cub-scout produce an "approved" answer.

References

Constraints

  • Connected verbs (history / impact / fleet / summary / views / audit) refuse to run without cub auth login. The error message points at auth, not at the verb.
  • bundle / catalog work in standalone mode but cannot resolve ConfigHub-specific identifiers (unit slugs, space names) without connected context. They surface the unresolved references explicitly.
  • This skill does not generate receipts — receipts are scout-verify's job. Govern returns governance evidence; Verify returns fingerprinted artifacts.

04 同仓库更多 Skills

confighub
confighub/cub-scout

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/api 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).

运维与部署
★ 14
confighub
confighub/cub-scout

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/api 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 / attestation / evidence-artifact / tamper-evident-record / verified-record / audit-trail / postmortem-evidence / 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 / argocd / kubectl with the user driving).

运维与部署
★ 14
confighub
confighub/cub-scout

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 / inventory / map / show / list / trace / scan / dump / stream / bot / 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).

★ 14
confighub
confighub/cub-scout

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 / Codex / 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 / mcp-gateway / mcp-serve / context-pack / bot / agent-context / ai-snapshot / llm-context / model-context-protocol. Do NOT load for: actually running a non-integrate verb (those are scout-observe / scout-diagnose / scout-compare / scout-attribute / scout-ingest / scout-govern / scout-verify), or `cub` MCP integration (that's a separate tool surface).

Skill与智能体开发
★ 14
confighub
confighub/cub-scout

scout-ingest

Use when the user wants to ADOPT existing Kubernetes / GitOps workload structure into ConfigHub after observing the live cluster — the adoption/import 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 / import / ingest / preview / propose / parse-repo / discovery / aggregator / bring-into-confighub / 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.

★ 14
confighub
confighub/cub-scout

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 / why / what-does-it-mean / what-should-I-do / interpret / diagnose / recommend / 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).

★ 14