- Skills
- 36
- 仓库
- 1
- 职业覆盖
- 1
- 场景覆盖
- 3
- Stars
- ★ 14
ConfigHub Inc 的 Skills 36
pilot-cd-gate
Use when Pilot (or another acceptance-judge tool) is making a PRE-DEPLOY GATE DECISION in a CD pipeline using cub-scout's structured evidence. Natural phrasings the operator brings to Pilot: "should this deploy go?", "is this release safe to promote?", "what does cub-scout say about this strategy?", "Pilot, gate the apply", "block the deploy if source-truth disagrees", "PASS/WATCH/ASK/BLOCK on payments-api release". Pilot consumes cub-scout's `compare source-truth --strategy <s>` (with optional `receipt verify --strategy <s> --fail-on any-non-pass` for typed evidence + exit-2 CI gate) and renders a verdict. cub-scout NEVER decides PASS/BLOCK — it produces evidence; Pilot makes the call. Do NOT load for: a Pilot post-deploy verification (use pilot-release-verification — coming in batch B), a real-time event-driven response (use pilot-watch-alert-response), a multi-cluster periodic audit (use pilot-fleet-conformance), or any cub-scout authoring command. Pilot mutates via `cub` / Argo / Flux — never via cub-scout.
operator-incident-evidence
Use when the user is GATHERING EVIDENCE FOR A POSTMORTEM / INCIDENT REPORT after the incident is past peak. Natural phrasing: "build the evidence package for last night's incident", "I need to write the postmortem — what does cub-scout have?", "gather all the data we have about the prod outage", "what changed on payments-api between 14:00 and 16:00?", "produce an audit trail for the rollback decision", "save the evidence before the cluster state moves on". Composes `trace` + `compare three-way` + `bundle` + `history` + `audit` + `receipt verify --save` for a STRUCTURED, IMMUTABLE evidence package. Read-only by design — postmortems should NOT mutate state. Do NOT load for: pager-active triage (use triage-unhealthy-workload), single-resource drift question (use investigate-drift), or any mutating action (rollback / fix is a separate decision; this skill captures evidence, not actions).
observe-sveltos
Use when the user wants to observe Sveltos-managed resources specifically. Natural phrasing: "is this from Sveltos?", "which ClusterProfile deployed this?", "what ConfigMap or Secret supplied this Sveltos policy?", "show me Sveltos Profile ownership", "what does projectsveltos.io/owner-kind mean?". Do NOT load for: generic ownership (use scout-observe), Sveltos authoring/mutation, or Sveltos notifications unless the task is read-only observation.
observe-native
Use when the user wants to observe NATIVE Kubernetes resources — anything cub-scout's ownership detector couldn't classify as Argo / Flux / Sveltos / Modelplane / Helm / Crossplane / kro / ConfigHub / Terraform / Custom. Natural phrasing: "why is this resource unowned?", "show me orphan workloads", "this isn't managed by anything — what does that mean?", "what is OwnerReferences-only ownership?", "is this a kubectl-applied resource without a controller?", "show me native K8s resources in this cluster". Load whenever intent is unowned / native / orphan / no-controller / OwnerReferences-only / direct-apply. Do NOT load for: any specific controller (use the matching observe-* skill), generic ownership when the controller IS known (use scout-observe), or apply/edit/delete operations (cub-scout never mutates).
observe-modelplane
Use when the user wants to observe Modelplane-managed resources specifically. Natural phrasing: "is this from Modelplane?", "which ModelDeployment produced this replica?", "show me Modelplane endpoints", "what does modelplane.ai/deployment mean?", "is this Modelplane or generic Crossplane?". Do NOT load for: generic ownership (use scout-observe), Crossplane-only resources (use observe-crossplane), or authoring Modelplane APIs.
observe-kro
Use when the user wants to observe KRO-managed resources specifically — the controller-specific observer skill for kro (the Kubernetes Resource Orchestrator). Natural phrasing: "is this a kro instance?", "which ResourceGraphDefinition produced this?", "show me kro applyset writes", "what does `kro.run/applyset` mean?", "trace this resource back to the kro instance". kro is a Kubernetes-native resource orchestrator using applysets. Do NOT load for: generic ownership (use scout-observe), Crossplane (similar composition pattern but different — use observe-crossplane), authoring kro CRDs themselves.
observe-helm
Use when the user wants to observe HELM-managed resources specifically — the controller-specific observer skill for Helm. The key complication: there are three ways a resource can "be Helm" — direct `helm install/upgrade`, Flux helm-controller delivering a HelmRelease, and Argo CD rendering Helm charts as an Application source. This skill teaches the disambiguation matrix. Natural phrasing: "is this a Helm release?", "which Helm chart produced this deployment?", "is this Helm-via-Flux or direct Helm or Argo-as-Helm-renderer?", "what does `app.kubernetes.io/managed-by: Helm` mean here?", "trace this Helm release back to source". Do NOT load for: Flux-specifically (use observe-flux for the Kustomization side), Argo-specifically (use observe-argocd), generic ownership (use scout-observe), authoring Helm charts.
observe-flux
Use when the user wants to observe FLUX-managed resources specifically — the controller-specific observer skill for Flux. Natural phrasing: "is this resource managed by Flux?", "which Kustomization owns this?", "show me the HelmRelease for this deployment", "what GitRepository / OCIRepository / Bucket is the source?", "did Flux reconcile the latest revision?", "show me Flux source-controller writes". Load whenever intent involves Flux specifically — Kustomizations, HelmReleases, source-controller, kustomize-controller, helm-controller, or source artifacts (GitRepository / HelmRepository / OCIRepository / Bucket). Do NOT load for: Argo (use observe-argocd), direct Helm without Flux (use observe-helm), generic ownership (use scout-observe), authoring Flux CRDs (Flux is its own tool — this skill is about observing Flux-managed resources, not configuring Flux).
observe-crossplane
Use when the user wants to observe CROSSPLANE-managed resources specifically — the controller-specific observer skill for Crossplane. Natural phrasing: "is this a Crossplane managed resource?", "which XR / Claim / Composition produced this?", "show me Crossplane composed children", "what does the `apiextensions.crossplane.io/composed-<hash>` manager mean?", "trace this resource back to the Claim", "is this from `*.crossplane.io` or `*.upbound.io`?", "show me ProviderConfig secrets". Load whenever intent involves Crossplane specifically — XRs (Composite Resources), Claims, Compositions, MRDs (managed-resource-definitions), provider managed resources, ProviderConfigs, or the crossplane-system namespace. Do NOT load for: generic ownership (use scout-observe), Helm/Argo/Flux (use their specific skills), authoring Crossplane CRDs themselves.
observe-confighub-managed
Use when the user wants to observe CONFIGHUB-managed resources specifically — resources where the desired state lives in a ConfigHub Unit, delivered through Argo or Flux. Natural phrasing: "is this a ConfigHub unit?", "which ConfigHub Unit / Space produced this?", "show me ConfigHub-delivered-via-Argo resources", "what does `confighub.com/UnitSlug` mean?", "is this delivered via Argo OCI or Flux Kustomize?", "trace this back to the ConfigHub revision". Load when the user is specifically asking about ConfigHub-as-source-of-truth. Do NOT load for: vanilla Argo without ConfigHub (use observe-argocd), vanilla Flux (use observe-flux), generic ownership (use scout-observe), authoring ConfigHub units (use cub skills, not cub-scout).
observe-argocd
Use when the user wants to observe ARGO CD-managed resources specifically — the controller-specific observer skill for Argo. Natural phrasing: "is this resource managed by Argo CD?", "show me Argo applications in this cluster", "trace this Argo-owned deployment back to source", "which ApplicationSet generated this app?", "did Argo apply the latest commit?", "explain the Argo CSA migration default", "what tracking-id annotation does Argo write?". Load whenever intent involves Argo CD specifically — Applications, ApplicationSets, sync status, tracking-id annotation, the kubectl-client-side-apply migration default, or Argo-as-deliverer-for-ConfigHub. Do NOT load for: generic ownership detection (use scout-observe), comparing live state to git (use scout-compare), the ConfigHub authoring side (use cub skills), or general Argo CRD authoring (Argo is a separate tool — this skill is about *observing* Argo-managed resources, not configuring Argo itself).
migrate-from-kubectl
Use when the user is MIGRATING from ad-hoc `kubectl apply` toward GitOps (Argo / Flux / ConfigHub) — and needs to find the manual edits, decide what to do with each (revert / port to git / accept as canonical), and plan the transition. Natural phrasing: "find all the manual edits in this cluster", "we have years of kubectl-apply, help us move to GitOps", "which resources have been hand-edited?", "audit drift caused by humans not controllers", "port my cluster state to git", "show me everything kubectl-* has touched". Composes attribution layer (`cause: manual-edit`) + `map orphans` (resources without a controller owner) + `scan` (risk classification) + `snapshot` / `import --git-path` preview once a repo skeleton exists. Read-only throughout — the migration itself is user-driven. Do NOT load for: real-time triage (use triage-unhealthy-workload), single-resource drift question (use investigate-drift), a fleet conformance audit (use audit-fleet-conformance), or any mutating action.
investigate-drift
Use when the user wants to compare live and desired state and inspect available manager and source evidence. Natural phrasing: "why is this Deployment different from the git manifest?", "which recognized manager is recorded for this path?", "controller-drift or interactive-manager evidence?", "compare three-way + attribution for deploy/api". Composes `compare three-way` + `compare drift` + the attribution layer (`cause` / `managerHint` / `gitSource` / `bindingSource`). Do NOT promise who changed the value or which manager wrote last: path-level manager evidence is not time-ordered, and resource-level `explain` evidence is not field-specific. Do NOT load for: a triage where the workload won't start (use triage-unhealthy-workload), pure inventory (use scout-observe), generating a fingerprinted evidence artifact (use scout-verify and the no-manual-edits-since predicate), or any mutating fix (cub-scout never mutates).
cub-scout
Use when working in the cub-scout repo or when answering capability-assistant questions ("can cub-scout do X?", "should I use cub-scout or kubectl here?", "how does cub-scout differ from cub?"). This is the umbrella router — it points you at the verb-grouped scenario skills under `skills/scout-*/` and the workflow / observer / reference skills planned for batches 2–5. For a specific verb-group task (observe / diagnose / compare / attribute / adopt existing config / govern / integrate / verify) load the corresponding `scout-*` skill directly.
confighub-source-truth
Use when the user wants a STRATEGY-TYPED, PILOT-ACCEPTANCE-SHAPED VERDICT about whether ConfigHub / controller / runtime agree under a declared delivery strategy — the `compare source-truth` workflow with the explicit `--strategy <name>` requirement. Natural phrasing: "give me a source-truth verdict for deploy/api", "verify under git-argo strategy that ConfigHub matches the cluster", "run the source-truth contract for upstream Pilot acceptance", "compare source-truth confighub-oci-flux strategy across the namespace", "produce strategy-relative correctness evidence", "show me where the strategy declaration is being violated". Composes `compare source-truth --strategy <s>` + the source-truth evidence contract + (optionally) `receipt verify --strategy <s>` for a fingerprinted version. Requires CONNECTED MODE. Do NOT load for: a single-resource live drift question without a declared strategy (use investigate-drift), a triage (use triage-unhealthy-workload), or a fleet-wide audit that doesn't need strategy framing (use audit-fleet-conformance). cub-scout NEVER infers a strategy — this skill enforces that boundary.
audit-fleet-conformance
Use when the user wants to verify CONFORMANCE ACROSS A FLEET — multiple namespaces, multiple clusters, or a defined View scope. Natural phrasing: "which clusters are conformant?", "audit fleet conformance against this View", "show me all outliers in prod fleet", "compare every service against its source-truth strategy", "scope-wide three-way check for drift", "fleet-level compliance audit", "which deployments drift across the cluster?". Composes `compare three-way --view` + `compare source-truth` + `fleet outliers` for multi-resource / multi-cluster checks. Requires connected mode for the View + ConfigHub surfaces. Do NOT load for: a single resource (use investigate-drift), a triage (use triage-unhealthy-workload), incident evidence for one event (use operator-incident-evidence), or anything mutating.
ai-agent-readonly-context
Use when the user is WIRING CUB-SCOUT INTO AN AI AGENT (Claude / Codex / a custom LLM workflow) and needs the patterns for read-only context, MCP gateway tools, deterministic context snapshots, and the prompt-shape that makes cub-scout's output reliable for LLMs. Natural phrasing: "set up cub-scout as a Claude tool", "expose cub-scout to my agent over MCP", "give the LLM a deterministic snapshot of this cluster", "what cub-scout patterns work well for AI agents?", "MCP config for cub-scout in Claude Code", "best practices for wiring cub-scout into Codex / Cursor / Continue", "AI-ready cluster context", "prompt template for cub-scout output". Composes `mcp serve` + `context-pack` + `--presentation ai` + the structured JSON contracts. Do NOT load for: a specific verb invocation (load the corresponding scout-* skill), authoring an MCP server in general (this is about wiring CUB-SCOUT specifically), or any mutating workflow (cub-scout never mutates; the read-only triad is the whole point of this skill).
recorded-field-attribution
Use when asked which manager is recorded for a field on a known Kubernetes resource, especially when the resource and exact canonical field path are supplied. Route a known exact-path question directly to the recorded `explain` MCP tool instead of doing broad rediscovery first. This is a preference for compact evidence, not a requirement to call a tool.