- Skills
- 36
- 仓库
- 1
- 职业覆盖
- 1
- 场景覆盖
- 3
- Stars
- ★ 14
ConfigHub Inc 的 Skills 36
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).
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).
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).
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).
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.
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.
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).
scout-compare
Use when the user wants to compare INTENDED vs ACTUAL Kubernetes state — the Compare verb group of cub-scout. Natural phrasing: "did this release land?", "does the cluster match Git?", "is there drift?", "compare DRY / WET / LIVE for this unit", "what does ConfigHub say should be running here?", "give me a source-truth verdict for this resource", "did Argo apply what was in the commit?", "compare this manifest to live state". Load whenever intent is compare / drift / sync-status / verify-matching / DRY-WET-LIVE / source-truth / has-this-landed. Do NOT load for: a list of what is running (use scout-observe), interpreting why something is wrong (use scout-diagnose), per-field provenance (use scout-attribute), or actually applying / syncing (cub-scout never mutates — route to cub, argocd, flux, or kubectl with the user driving).
scout-attribute
Use when the user wants manager evidence for a field value on a running Kubernetes resource — which recognized controller or interactive manager is recorded for a path, which git file or ConfigHub Link supplies desired state, or whether resource-level managedFields contains an interactive manager. Natural phrasing: "why is replicas: 1 in prod?", "does this resource show a kubectl manager?", "is Argo still reconciling or is an interactive manager recorded?", "what git commit set this image tag?", "which upstream unit feeds this field?", "where does this value come from?", "show me the provenance of this Deployment", "is this controller-drift or manual-edit?", "has an interactive manager changed this Deployment?", "which manager is recorded for this field?". Load whenever attribution / provenance / lineage / git-blame-for-runtime intent appears, especially on `compare` and `explain` output. For a known resource and exact canonical field path, `explain --field-path` can return only that path’s manager evidence; `explain` without the selector has a resource-level summary. Do NOT promise the latest writer or a human identity from manager evidence: exact-path and compare results do not order managers by time. Do NOT load for: pure ownership classification at the resource level (use scout-observe — that gives Owner=Argo/Flux/etc., not per-field), source-truth strategy verdicts (use scout-compare), or live-cluster mutation (cub-scout cannot mutate — that is `cub` or `kubectl` with user driving).
prepare-for-confighub
Use when the user is ADOPTING ConfigHub — they have existing live K8s + GitOps state (an existing cluster, live Argo ApplicationSets, Flux Kustomizations, or secondarily a git repo of manifests) and want to PREVIEW what a ConfigHub import would look like before committing. Natural phrasing: "show me the proposed units before I apply", "I want to adopt ConfigHub for this app", "what would ConfigHub see in our cluster?", "what would ConfigHub see in our argocd setup?", "preview what would land in ConfigHub if I imported this repo". Composes `cub-scout import --dry-run` + `import --git-path` + `import argocd` + `import cluster-aggregator` + `import parse-repo` + `app` for the **preview-only** flow. Do NOT load for: actually applying the proposal (that's `cub-scout import apply`, user-driven), live conformance audits (use audit-fleet-conformance), or comparing live to ConfigHub once units exist (use scout-compare). The whole skill is read-only and refuses to invoke `import apply`.
pilot-watch-alert-response
Use when Pilot is RESPONDING TO REAL-TIME CLUSTER EVENTS surfaced by `cub-scout watch` or `cub-scout bot`. Natural phrasings: "Pilot subscribes to the watch stream", "render verdicts on each drift event as they fire", "real-time acceptance kernel for cluster changes", "Pilot, decide on this drift.detected event", "what does Pilot say about the ownership.changed alert", "stream PASS/WATCH/ASK/BLOCK per event from cub-scout watch". Pilot consumes the `cub-scout watch` / `cub-scout bot` event stream (webhook or file sink, optionally with inline receipts via `--emit-receipt-on`) and renders a verdict per event, calling back into cub-scout (`explain`, `compare three-way`, `trace`) for context when needed. This is the ONLY event-driven skill in the pilot-* batch — others are query-driven. Do NOT load for: a single-resource pre-deploy gate (use pilot-cd-gate), a periodic fleet roll-up (use pilot-fleet-conformance), a drift-classification deep-dive (use pilot-patch-and-drift), a postmortem evidence pack (use pilot-incident-evidence), or any mutating action.
pilot-rollback-decision
Use when Pilot is DECIDING WHEN AND WHICH REVISION TO ROLL BACK TO after an incident or a broken release. Natural phrasings: "Pilot, should we roll back?", "what revision should Pilot pick for the rollback?", "is the previous SHA safe to roll back to?", "render the rollback verdict + target", "Pilot, choose the rollback revision and explain why". Pilot consumes cub-scout's `history` (ConfigHub ChangeSet timeline) + `impact` (blast-radius preview) + `compare source-truth --strategy <s>` (per-candidate-revision evidence) + `receipt verify --predicate applied-matches-spec --at-commit <sha>` (pin to a specific revision for fingerprinted evaluation). Pilot picks the rollback target and renders a safety verdict; the actual rollback is Pilot's mutation path (controller sync to the chosen revision), not cub-scout's. Do NOT load for: pre-deploy gate (use pilot-cd-gate), real-time event response (use pilot-watch-alert-response), drift-classification on the current state (use pilot-patch-and-drift), or incident close-out evidence assembly (use pilot-incident-evidence — which captures what happened; this skill picks where to go next).
pilot-release-verification
Use when Pilot is RUNNING POST-DEPLOY VALIDATION after a release has shipped — confirming the release actually landed per declared intent. Natural phrasings: "Pilot, verify the release", "did `payments-api@v1.4.3` land cleanly?", "post-deploy verification gate", "Pilot, render the release-quality verdict", "confirm the deploy matches Git", "did everything reconcile after the apply?". Pilot consumes cub-scout's `compare three-way` (DRY/WET/LIVE per resource in the release scope) + `bindingSource` graph (did Links propagate correctly?) + `history` since the deploy timestamp (what changed in the last N minutes?) + `gitSource` anchor (does the live state match the release SHA?). Pilot renders a release-quality verdict per resource and a release-level rollup. Distinct from `pilot-cd-gate` which fires BEFORE the deploy; this skill fires AFTER. Do NOT load for: pre-deploy gate (use pilot-cd-gate), real-time event response (use pilot-watch-alert-response), rollback decision when verification fails (use pilot-rollback-decision), or incident close-out evidence (use pilot-incident-evidence).
pilot-promotion-gate
Use when Pilot is GATING A VARIANT-TO-VARIANT PROMOTION between two intentional configurations (e.g., staging → prod; canary 5%% → 50%%; blue → green; cell-A → cell-B). Natural phrasings: "Pilot, gate the promotion from staging to prod", "is variant B safe to promote from variant A?", "render the cross-variant safety verdict", "what would change between cells if we promote?", "promotion gate for the canary rollout". Pilot consumes cub-scout's `compare three-way` per variant + the per-variant `bindingSource` graph + `compare source-truth --strategy <s>` per variant to render a CROSS-VARIANT verdict — not a pre-deploy gate against a single resource (that's pilot-cd-gate). Pilot picks promotion safety + the field-level diff reasons; the actual promotion execution lives in Pilot's mutation path. Do NOT load for: a single-resource pre-deploy gate (use pilot-cd-gate), a rollback decision (use pilot-rollback-decision), a real-time event response (use pilot-watch-alert-response), or a post-deploy validation (use pilot-release-verification).
pilot-patch-and-drift
Use when Pilot is CLASSIFYING DRIFT and DECIDING WHAT TO DO ABOUT IT after a divergence between intended state and live state is detected. Natural phrasings: "Pilot, classify this drift", "is this manual edit or controller drift?", "should Pilot revert this patch?", "quarantine or accept-as-canonical?", "what does cub-scout say about who touched this field?", "render a drift verdict for the audit". Pilot consumes cub-scout's attribution evidence (`cause: manual-edit` / `controller-drift` / `unknown` + `managerHint` + `gitSource` + `bindingSource`) and decides revert / quarantine / accept-as-canonical / ASK-human. The decision shape matches the attribution layer's evidence shape — cub-scout produces deterministic classification; Pilot picks the policy action. Do NOT load for: a single-resource pre-deploy gate (use pilot-cd-gate), a real-time event response (use pilot-watch-alert-response), a fleet roll-up (use pilot-fleet-conformance), or any mutating action. Pilot mutates via `cub` / Argo / kubectl — never via cub-scout.
pilot-incident-evidence
Use when Pilot is ASSEMBLING THE INCIDENT EVIDENCE PACK during incident close-out — Pilot renders a structured, fingerprinted evidence package the postmortem and the audit ticket both consume. Natural phrasings: "Pilot, build the evidence pack for last night's outage", "render the incident verdict + evidence for the SEV-2", "Pilot, what does cub-scout have on this incident?", "freeze the evidence before the cluster moves on", "assemble the postmortem inputs from cub-scout". Pilot composes `trace` + `explain` + attribution + recent K8s events + `bundle` + `history` + (crucially) per-affected-resource `receipt verify --save` with chained `--input-attestation` for multi-stage incidents. Differs from `operator-incident-evidence` which is OPERATOR-DRIVEN (the SRE assembling for their own postmortem); this skill is JUDGE-DRIVEN (Pilot rendering an evidence pack + verdict for downstream consumption). Do NOT load for: pager-active triage (use triage-unhealthy-workload), a real-time event-driven response (use pilot-watch-alert-response), a periodic fleet audit (use pilot-fleet-conformance), or any mutating remediation. cub-scout never mutates; Pilot's mutation path is `cub` / Argo / Flux.
pilot-fleet-conformance
Use when Pilot (or another acceptance-judge tool) is rendering a FLEET-WIDE CONFORMANCE VERDICT across multiple clusters / namespaces / a ConfigHub View. Natural phrasings: "Pilot, give me the fleet verdict for prod", "is the payments fleet conformant against `git-argo`?", "render the conformance report Pilot can attach to the compliance ticket", "what does Pilot say across all 12 clusters?", "per-cluster PASS/WATCH/ASK/BLOCK rolled up to a fleet verdict". Pilot consumes cub-scout's `compare three-way --view` + per-resource `compare source-truth --strategy` + `fleet outliers --view`, optionally persisting per-resource receipts via `receipt verify --save`, then synthesizes a fleet-level verdict. Differs from `audit-fleet-conformance` which is the OPERATOR-DRIVEN audit loop; this skill is the JUDGE-DRIVEN companion (Pilot reading the same surfaces but framing the output as a verdict, not a checklist). Do NOT load for: a single-resource pre-deploy gate (use pilot-cd-gate), real-time event-driven response (use pilot-watch-alert-response), or any mutating action.
pilot-compliance-audit
Use when Pilot is RENDERING A PERIODIC POLICY-CONFORMANCE REPORT for a compliance audit. Natural phrasings: "Pilot, run the quarterly compliance audit", "render the conformance report against policy", "audit our prod fleet against the security baseline", "produce the compliance evidence pack for the auditor", "Pilot, what are this quarter's policy violations + their evidence?". Pilot consumes cub-scout's scope-wide `compare source-truth` (per-resource verdicts under the declared strategy) + `scan` findings (risk-pattern matches) + (optional) per-resource receipts persisted to the local store, then synthesizes a compliance-shaped report with violations table + fingerprinted evidence inventory. Differs from `pilot-fleet-conformance` which is the SAME-VERBS-SAME-DAY operational verdict; this skill is the LONGER-CYCLE compliance shape — the output is a quarterly/monthly report with attached evidence inventory, not a real-time gate. Do NOT load for: a single-resource pre-deploy gate (use pilot-cd-gate), real-time event response (use pilot-watch-alert-response), incident close-out evidence (use pilot-incident-evidence), or a rollback decision (use pilot-rollback-decision).