[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CBMMT6C7SRVHMKZ6KESW2T":3,"skill-same:01M6CBMMT6C7SRVHMKZ6KESW2T":91},{"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":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":6,"ownerHtmlUrl":67,"ownerBlogUrl":68,"ownerDescription":69,"updatedAt":70,"install":71,"resources":84},"01M6CBMMT6C7SRVHMKZ6KESW2T","pilot-fleet-conformance",null,"Use when Pilot (or another acceptance-judge tool) is rendering a FLEET-WIDE CONFORMANCE VERDICT across multiple clusters \u002F namespaces \u002F 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\u002FWATCH\u002FASK\u002FBLOCK 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.","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\u002Fpilot-fleet-conformance\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,48,49,50,51,52,53,54],"fleet","conformance","pilot fleet conformance","up","alert","say","cub scout","scout compare","show","attach","time","project","argo","unit","rendering","companion","reading","which","Bash","git","acceptance","audit","payments","compliance","kubectl","real-time","verify","release","loop","tool","changeset","ask","list","view","strategy","use","2026-11-10 10:12:30",false,"---\nname: pilot-fleet-conformance\ndescription: 'Use when Pilot (or another acceptance-judge tool) is rendering a FLEET-WIDE CONFORMANCE VERDICT across multiple clusters \u002F namespaces \u002F 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\u002FWATCH\u002FASK\u002FBLOCK 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.'\nphase: cross-cutting\nallowed-tools: Bash(.\u002Fcub-scout compare three-way *) Bash(cub-scout compare three-way *) Bash(cub scout compare three-way *) Bash(.\u002Fcub-scout compare source-truth *) Bash(cub-scout compare source-truth *) Bash(cub scout compare source-truth *) Bash(.\u002Fcub-scout fleet outliers *) Bash(cub-scout fleet outliers *) Bash(cub scout fleet outliers *) Bash(.\u002Fcub-scout views resolve *) Bash(cub-scout views resolve *) Bash(cub scout views resolve *) Bash(.\u002Fcub-scout views project *) Bash(cub-scout views project *) Bash(cub scout views project *) Bash(.\u002Fcub-scout receipt verify *) Bash(cub-scout receipt verify *) Bash(cub scout receipt verify *) Bash(.\u002Fcub-scout receipt list *) Bash(cub-scout receipt list *) Bash(cub scout receipt list *) Bash(.\u002Fcub-scout receipt show *) Bash(cub-scout receipt show *) Bash(cub scout receipt show *) Bash(.\u002Fcub-scout receipt validate *) Bash(cub-scout receipt validate *) Bash(cub scout receipt validate *) Bash(.\u002Fcub-scout map list *) Bash(.\u002Fcub-scout map workloads *) Bash(.\u002Fcub-scout map orphans *) Bash(cub-scout map list *) Bash(cub-scout map workloads *) Bash(cub-scout map orphans *) Bash(cub scout map list *) Bash(cub scout map workloads *) Bash(cub scout map orphans *) Bash(.\u002Fcub-scout scan *) Bash(cub-scout scan *) Bash(cub scout scan *) Bash(.\u002Fcub-scout summary list *) Bash(cub-scout summary list *) Bash(cub scout summary list *) Bash(kubectl get *) 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 view list)\n\n---\n\n# pilot-fleet-conformance\n\nThe fleet-wide conformance scenario from **Pilot's** side. Pilot is asked for a verdict across a fleet — multiple clusters, multiple namespaces, or a ConfigHub View scope — and synthesizes a single fleet-level PASS \u002F WATCH \u002F ASK \u002F BLOCK from per-resource cub-scout evidence.\n\nThis is the **judge-driven** companion to [`audit-fleet-conformance`](..\u002Faudit-fleet-conformance\u002FSKILL.md) (the operator-driven audit loop). Same cub-scout verbs feed both; the difference is framing: an operator runs an audit to find what's wrong; Pilot renders a verdict that downstream consumers (compliance dashboards, governance tickets, release boards) act on.\n\n## When to use\n\nExplicit phrasings:\n\n- \"Pilot, give me the fleet verdict for prod\"\n- \"Is the payments fleet conformant against `git-argo`?\"\n- \"Render the conformance report Pilot can attach to the compliance ticket\"\n- \"What does Pilot say across all 12 clusters?\"\n- \"Per-cluster PASS\u002FWATCH\u002FASK\u002FBLOCK rolled up to a fleet verdict\"\n- \"Fleet conformance check on Hub View `monthly-spend-by-team`\"\n- \"Which clusters are out of conformance with their declared strategy?\"\n\nImplicit intents:\n\n- The user is **operating across many resources** — namespace, View, or full fleet\n- The output needs to be a **single verdict** with structured drill-down, not a per-resource checklist\n- The judgment is **strategy-anchored** — the user has declared what the source of truth should be\n- The result feeds a **dashboard \u002F ticket \u002F compliance flow**, not an interactive triage\n\n## Do not load for\n\n- A **single-resource pre-deploy gate** — [`pilot-cd-gate`](..\u002Fpilot-cd-gate\u002FSKILL.md)\n- An **operator-driven** audit checklist (same verbs, different framing) — [`audit-fleet-conformance`](..\u002Faudit-fleet-conformance\u002FSKILL.md)\n- A **real-time event-driven** fleet response (Pilot subscribes to a watch stream) — [`pilot-watch-alert-response`](..\u002Fpilot-watch-alert-response\u002FSKILL.md)\n- A **postmortem evidence assembly** — [`pilot-incident-evidence`](..\u002Fpilot-incident-evidence\u002FSKILL.md)\n- A **drift classification** per resource — [`pilot-patch-and-drift`](..\u002Fpilot-patch-and-drift\u002FSKILL.md)\n- Anything that **mutates** the fleet. Pilot's mutation path is `cub` \u002F Argo \u002F Flux, never cub-scout.\n\n## The Pilot ↔ cub-scout fleet loop\n\n```\n   compliance dashboard \u002F release board \u002F governance ticket\n        │\n        ▼\n   Pilot (acceptance judge)\n        │  \"render the fleet verdict for view:monthly-spend-by-team\"\n        │\n        ├──► cub-scout views resolve \u003Curl-or-uuid>          # confirm scope\n        │\n        ├──► cub-scout fleet outliers --view \u003Cuuid>         # cross-cluster outliers\n        │\n        ├──► cub-scout compare three-way --view \u003Cuuid>      # per-resource DRY\u002FWET\u002FLIVE\n        │     --format json\n        │\n        ├──► for each resource in scope:\n        │      cub-scout compare source-truth \u003Cr> --strategy \u003Cs>\n        │     --format json                                  # per-resource verdict\n        │\n        └──► (optional, for audit attachment)\n              for each resource in scope:\n                cub-scout receipt verify \u003Cr> --strategy \u003Cs>\n                  --save                                    # fingerprinted artifact\n              cub-scout receipt list --format json          # the artifact inventory\n        │\n        ▼\n   Pilot's fleet verdict = max-severity over per-resource verdicts\n        │\n        ▼\n   downstream consumer reads the verdict\n        │  PASS  → conformant fleet, no action needed\n        │  WATCH → conformant with caveats; attach receipts; review at next sync\n        │  ASK   → human-needed; the per-resource ASKs surface proof gaps\n        │  BLOCK → halt promotion \u002F release; quarantine the divergent resources\n        └────────────────────────────────────────────────────\n```\n\n## Scope sources\n\nPilot's fleet verdict needs a defined scope. cub-scout exposes three scope shapes:\n\n| Scope | Verb path | Use when |\n|-------|-----------|----------|\n| **View** | `views resolve \u003Curl-or-uuid>` → `--view \u003Cuuid>` on the audit verbs | The team declared the scope in ConfigHub (preferred for governance) |\n| **Namespace** | `--scope namespace\u002F\u003Cns>` | One namespace's workloads |\n| **Cluster** | `--scope cluster` | Entire kubeconfig context |\n| **Multi-cluster** | `fleet outliers --view \u003Cuuid>` | Cross-cluster comparison against a View baseline (connected mode only) |\n\nViews are declared via `cub view create` (out of cub-scout's scope — `cub` operation). cub-scout reads them via `views resolve`. If the team doesn't have a View, Pilot can still render a fleet verdict over a namespace or cluster scope; the scope is just less semantically anchored.\n\n## Verdict synthesis (per-resource → fleet)\n\nPilot's synthesis policy is **max-severity** by default:\n\n| Per-resource verdicts | Fleet verdict |\n|-----------------------|---------------|\n| All PASS | **PASS** |\n| Some WATCH, rest PASS | **WATCH** |\n| Some ASK, rest PASS\u002FWATCH | **ASK** (humans needed for the proof gaps) |\n| Any BLOCK | **BLOCK** (one divergent resource halts the fleet verdict) |\n\n`fleet outliers` adds a cross-cluster dimension: if all per-cluster resource counts match the View baseline, the fleet is **outlier-free**; if one cluster diverges, Pilot's verdict downgrades to at least WATCH and may escalate to BLOCK depending on the missing resource's role.\n\nThis skill does NOT prescribe the synthesis policy beyond max-severity — Pilot may want a different aggregation (majority, weighted by criticality). The cub-scout side is verdict-producing per resource; the fleet roll-up is Pilot's call.\n\n## Step-by-step\n\n### Step 1 — resolve the scope\n\n```bash\n$ cub-scout views resolve https:\u002F\u002Fhub.confighub.com\u002Fviews\u002Fpayments-prod-conformance\nView: payments-prod-conformance\n  scope: cluster\n  columns: [team, service, replicas, source_truth_strategy]\n  resolved at: 2026-05-22T10:30:00Z\n```\n\nIf no View applies, fall back to a namespace scope; the rest of the loop is identical except `--scope namespace\u002F\u003Cns>` replaces `--view \u003Cuuid>`.\n\n### Step 2 — outliers (true fleet shape)\n\n```bash\n$ cub-scout fleet outliers --view payments-prod-conformance\nView: payments-prod-conformance\nClusters: 12\n\n  payments-api   EXPECTED 3 deploys \u002F cluster   prod-euw1: 2 (outlier: missing payments-api-worker)\n  payments-db    EXPECTED 1 deploy \u002F cluster    ALL match\n  payments-cron  EXPECTED 4 deploys \u002F cluster   staging-use2: 3 (outlier: missing payments-cron-billing)\n```\n\n`fleet outliers` emits per-row mismatches. Each outlier is at minimum a **WATCH** for Pilot's fleet verdict (the per-cluster resource count doesn't match the View baseline); it escalates to **BLOCK** if the missing resource is in the View's critical-set (a separate policy Pilot enforces).\n\n### Step 3 — per-resource three-way + source-truth\n\n```bash\n# Three-way conformance across the View (DRY\u002FWET\u002FLIVE per resource)\n$ cub-scout compare three-way --view payments-prod-conformance --format json \\\n    | jq '.summary'\n{\n  \"agreement\": \"partial\",\n  \"agreed\": 18,\n  \"converging\": 1,\n  \"diverged\": 3,\n  \"scope\": \"view:payments-prod-conformance\"\n}\n\n# Strategy-anchored source-truth per resource\n$ for r in $(cub-scout views project --view payments-prod-conformance --format json \\\n              | jq -r '.[] | \"\\(.kind)\u002F\\(.name) -n \\(.namespace)\"'); do\n    cub-scout compare source-truth $r --strategy git-argo --format json \\\n      | jq '{resource: \"'\"$r\"'\", status: .status, source_truth: .source_truth, proof_gaps: .proof_gaps}'\n  done\n```\n\nEach per-resource output has `status` (PASS\u002FWATCH\u002FBLOCK\u002FASK) + `source_truth` (AGREED\u002FMISMATCH\u002FINCOMPLETE\u002FBLOCKED\u002FUNKNOWN) + `proof_gaps[]` (a string array of free-form missing-evidence entries) + `safe_next_action` (a free-form human-readable next step). Pilot collects these into the synthesis matrix. Field names are snake_case per `pkg\u002Fagent\u002Fsource_truth.go:280-287`.\n\n### Step 4 — persist fleet evidence as receipts (audit-quality)\n\n```bash\n# Per-resource receipts, saved to the immutable local store\n$ for r in $(cub-scout views project --view payments-prod-conformance --format json \\\n              | jq -r '.[] | \"\\(.kind)\u002F\\(.name) -n \\(.namespace)\"'); do\n    cub-scout receipt verify $r --strategy git-argo --save\n  done\n\n# Audit inventory: every fleet receipt with verdict BLOCK or WATCH\n$ cub-scout receipt list --format json \\\n    | jq '[.[] | select(.verdict == \"BLOCK\" or .verdict == \"WATCH\")]'\n```\n\nThe receipt store is **immutable** (each filename is canonical and `O_EXCL`-protected; duplicate saves return `os.ErrExist` and never overwrite). The fleet audit produces a fingerprint-stable evidence pack that can be archived for compliance review.\n\n## Worked example\n\nPilot is asked for the daily fleet verdict on View `payments-prod-conformance`, strategy `git-argo`:\n\n```bash\n$ cub-scout fleet outliers --view payments-prod-conformance\nView: payments-prod-conformance\nClusters: 12\n\n  payments-api   EXPECTED 3 deploys \u002F cluster   prod-euw1: 2 (outlier)\n  payments-cron  EXPECTED 4 deploys \u002F cluster   staging-use2: 3 (outlier)\n\n$ cub-scout compare three-way --view payments-prod-conformance --format json \\\n    | jq '.summary'\n{\n  \"agreement\": \"partial\",\n  \"agreed\": 18,\n  \"converging\": 1,\n  \"diverged\": 3\n}\n\n$ # per-resource source-truth (abbreviated)\n$ ... 18 PASS, 1 WATCH, 3 BLOCK\n```\n\nPilot's synthesis:\n- 22 resources in scope\n- 18 PASS + 1 WATCH + 3 BLOCK per source-truth\n- 2 cluster-level outliers (counted as WATCH)\n- Max-severity verdict → **BLOCK**\n\nPilot's verdict surface to the compliance dashboard:\n\n```json\n{\n  \"fleet\": \"payments-prod\",\n  \"view\": \"payments-prod-conformance\",\n  \"strategy\": \"git-argo\",\n  \"verdict\": \"BLOCK\",\n  \"rollup\": {\n    \"PASS\": 18,\n    \"WATCH\": 1,\n    \"ASK\": 0,\n    \"BLOCK\": 3,\n    \"outliers\": 2\n  },\n  \"blockers\": [\n    \"Deployment\u002Fpayments-api in prod-use1 (source_truth=MISMATCH)\",\n    \"Deployment\u002Fpayments-worker in prod-use1 (source_truth=MISMATCH)\",\n    \"Deployment\u002Fpayments-db in prod-euw1 (source_truth=MISMATCH)\"\n  ],\n  \"evidence_path\": \"\u002Fpath\u002Fto\u002Faudit\u002Freceipts\u002F2026-05-22\u002F\",\n  \"next_step\": \"investigate the 3 BLOCK resources via pilot-patch-and-drift\"\n}\n```\n\nDownstream consumer (compliance dashboard) reads the verdict, halts promotion, escalates to the team with the per-resource breakdown.\n\n## Standalone vs connected\n\nMost of this skill **requires connected mode** (`cub auth login`):\n\n- `compare three-way` (DRY layer needs ConfigHub) — connected\n- `compare source-truth` — connected (the contract is meaningless without all 3 surfaces)\n- `views resolve` \u002F `views project` — connected\n- `fleet outliers` — connected (cross-cluster snapshots live in ConfigHub)\n- `receipt verify --strategy \u003Cs>` — connected (source-truth-pass predicate requires it)\n\nStandalone-mode fleet conformance is narrower:\n- Per-resource `compare drift` against files (no DRY layer)\n- `receipt verify --predicate applied-matches-spec` (cluster-only)\n- No View scope; falls back to namespace \u002F cluster scope\n\nPilot should run `cub-scout status` in the pipeline preamble; if standalone and the fleet verdict requires `--strategy`, escalate to ASK with a \"connected mode required\" message.\n\n## CI \u002F dashboard integration\n\nFor periodic fleet audits, the verbs are CI-shaped:\n\n```bash\n# Daily cron — render the fleet verdict, exit non-zero if BLOCK\n$ cub-scout compare three-way --view payments-prod-conformance --fail-on warning\n# exit 2 if any resource in the View has a hard mismatch\n```\n\nFor receipts-attached audits (preferred for compliance):\n\n```bash\n# Per-resource receipt save + collect into audit branch\n$ .\u002Ffleet-audit.sh > audit-results.txt\n$ cub-scout receipt list --format json > audit-receipts.json\n$ git add audit-receipts.json && git commit -m \"fleet audit $(date -u +%F)\"\n```\n\nPilot's typical batch shape: run per-resource `receipt verify --strategy \u003Cs> --save` overnight; in the morning, walk `cub-scout receipt list --format json` for the verdict roll-up.\n\n## Tool boundary\n\n- **Allowed (cub-scout):** Compare verbs; `fleet outliers`; `views resolve` \u002F `project`; `receipt verify` \u002F `show` \u002F `validate` \u002F `list`; `scan`; `map`; `summary list`. All read-only.\n- **Allowed (cluster):** `kubectl get`. NOT `kubectl apply\u002Fedit\u002Fpatch\u002Fdelete`.\n- **Allowed (ConfigHub):** `cub \u003Centity> get \u002F list` for the entities named in allowed-tools. NOT `cub * create \u002F update \u002F delete \u002F sync`.\n- **Pilot itself may mutate** via `cub` or controller verbs, but the fleet-conformance verdict is Pilot's evidence-driven judgment; cub-scout never decides on Pilot's behalf.\n\n## References\n\n- [`audit-fleet-conformance`](..\u002Faudit-fleet-conformance\u002FSKILL.md) — operator-side counterpart (same verbs, different framing)\n- [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md) — the four Compare verbs (cub-scout side)\n- [`scout-govern`](..\u002Fscout-govern\u002FSKILL.md) — fleet outliers, views, summary\n- [`scout-verify`](..\u002Fscout-verify\u002FSKILL.md) — receipt persistence\n- [`confighub-source-truth`](..\u002Fconfighub-source-truth\u002FSKILL.md) — strategy-typed verdict\n- [`pilot-cd-gate`](..\u002Fpilot-cd-gate\u002FSKILL.md) — single-resource pre-deploy gate companion\n- [`pilot-patch-and-drift`](..\u002Fpilot-patch-and-drift\u002FSKILL.md) — drill-down for the BLOCK resources Pilot flags\n- [`pilot-watch-alert-response`](..\u002Fpilot-watch-alert-response\u002FSKILL.md) — event-driven companion (this skill is periodic-driven)\n- Views integration: `#391` (parent), `#414` (compare three-way --view), `#403` (views resolve), `#420` (views project --with-reality)\n- Source-truth contract: `#393`, `#418` (Phase 2 strategies)\n\n## Constraints\n\n- Connected mode is required for the View + ConfigHub + fleet surfaces.\n- The strategy is **caller-declared** per resource (or uniform across the View when the team declares fleet-wide policy). cub-scout never infers it.\n- Synthesis policy (max-severity, majority, weighted, etc.) is **Pilot's** choice. cub-scout provides per-resource verdicts; the roll-up shape is Pilot-side.\n- `fleet outliers` requires the View to be **declared with cluster scope** (`cub view create --scope cluster`). Namespace-scoped Views can't be cross-clustered.\n- Per-resource receipts in a fleet audit can be high-volume. The local receipt store handles large-N writes (each filename is canonical so collisions are predictable), but downstream consumers should expect `receipt list` to return many entries.\n","# pilot-fleet-conformance\n\nThe fleet-wide conformance scenario from **Pilot's** side. Pilot is asked for a verdict across a fleet — multiple clusters, multiple namespaces, or a ConfigHub View scope — and synthesizes a single fleet-level PASS \u002F WATCH \u002F ASK \u002F BLOCK from per-resource cub-scout evidence.\n\nThis is the **judge-driven** companion to [`audit-fleet-conformance`](..\u002Faudit-fleet-conformance\u002FSKILL.md) (the operator-driven audit loop). Same cub-scout verbs feed both; the difference is framing: an operator runs an audit to find what's wrong; Pilot renders a verdict that downstream consumers (compliance dashboards, governance tickets, release boards) act on.\n\n## When to use\n\nExplicit phrasings:\n\n- \"Pilot, give me the fleet verdict for prod\"\n- \"Is the payments fleet conformant against `git-argo`?\"\n- \"Render the conformance report Pilot can attach to the compliance ticket\"\n- \"What does Pilot say across all 12 clusters?\"\n- \"Per-cluster PASS\u002FWATCH\u002FASK\u002FBLOCK rolled up to a fleet verdict\"\n- \"Fleet conformance check on Hub View `monthly-spend-by-team`\"\n- \"Which clusters are out of conformance with their declared strategy?\"\n\nImplicit intents:\n\n- The user is **operating across many resources** — namespace, View, or full fleet\n- The output needs to be a **single verdict** with structured drill-down, not a per-resource checklist\n- The judgment is **strategy-anchored** — the user has declared what the source of truth should be\n- The result feeds a **dashboard \u002F ticket \u002F compliance flow**, not an interactive triage\n\n## Do not load for\n\n- A **single-resource pre-deploy gate** — [`pilot-cd-gate`](..\u002Fpilot-cd-gate\u002FSKILL.md)\n- An **operator-driven** audit checklist (same verbs, different framing) — [`audit-fleet-conformance`](..\u002Faudit-fleet-conformance\u002FSKILL.md)\n- A **real-time event-driven** fleet response (Pilot subscribes to a watch stream) — [`pilot-watch-alert-response`](..\u002Fpilot-watch-alert-response\u002FSKILL.md)\n- A **postmortem evidence assembly** — [`pilot-incident-evidence`](..\u002Fpilot-incident-evidence\u002FSKILL.md)\n- A **drift classification** per resource — [`pilot-patch-and-drift`](..\u002Fpilot-patch-and-drift\u002FSKILL.md)\n- Anything that **mutates** the fleet. Pilot's mutation path is `cub` \u002F Argo \u002F Flux, never cub-scout.\n\n## The Pilot ↔ cub-scout fleet loop\n\n```\n   compliance dashboard \u002F release board \u002F governance ticket\n        │\n        ▼\n   Pilot (acceptance judge)\n        │  \"render the fleet verdict for view:monthly-spend-by-team\"\n        │\n        ├──► cub-scout views resolve \u003Curl-or-uuid>          # confirm scope\n        │\n        ├──► cub-scout fleet outliers --view \u003Cuuid>         # cross-cluster outliers\n        │\n        ├──► cub-scout compare three-way --view \u003Cuuid>      # per-resource DRY\u002FWET\u002FLIVE\n        │     --format json\n        │\n        ├──► for each resource in scope:\n        │      cub-scout compare source-truth \u003Cr> --strategy \u003Cs>\n        │     --format json                                  # per-resource verdict\n        │\n        └──► (optional, for audit attachment)\n              for each resource in scope:\n                cub-scout receipt verify \u003Cr> --strategy \u003Cs>\n                  --save                                    # fingerprinted artifact\n              cub-scout receipt list --format json          # the artifact inventory\n        │\n        ▼\n   Pilot's fleet verdict = max-severity over per-resource verdicts\n        │\n        ▼\n   downstream consumer reads the verdict\n        │  PASS  → conformant fleet, no action needed\n        │  WATCH → conformant with caveats; attach receipts; review at next sync\n        │  ASK   → human-needed; the per-resource ASKs surface proof gaps\n        │  BLOCK → halt promotion \u002F release; quarantine the divergent resources\n        └────────────────────────────────────────────────────\n```\n\n## Scope sources\n\nPilot's fleet verdict needs a defined scope. cub-scout exposes three scope shapes:\n\n| Scope | Verb path | Use when |\n|-------|-----------|----------|\n| **View** | `views resolve \u003Curl-or-uuid>` → `--view \u003Cuuid>` on the audit verbs | The team declared the scope in ConfigHub (preferred for governance) |\n| **Namespace** | `--scope namespace\u002F\u003Cns>` | One namespace's workloads |\n| **Cluster** | `--scope cluster` | Entire kubeconfig context |\n| **Multi-cluster** | `fleet outliers --view \u003Cuuid>` | Cross-cluster comparison against a View baseline (connected mode only) |\n\nViews are declared via `cub view create` (out of cub-scout's scope — `cub` operation). cub-scout reads them via `views resolve`. If the team doesn't have a View, Pilot can still render a fleet verdict over a namespace or cluster scope; the scope is just less semantically anchored.\n\n## Verdict synthesis (per-resource → fleet)\n\nPilot's synthesis policy is **max-severity** by default:\n\n| Per-resource verdicts | Fleet verdict |\n|-----------------------|---------------|\n| All PASS | **PASS** |\n| Some WATCH, rest PASS | **WATCH** |\n| Some ASK, rest PASS\u002FWATCH | **ASK** (humans needed for the proof gaps) |\n| Any BLOCK | **BLOCK** (one divergent resource halts the fleet verdict) |\n\n`fleet outliers` adds a cross-cluster dimension: if all per-cluster resource counts match the View baseline, the fleet is **outlier-free**; if one cluster diverges, Pilot's verdict downgrades to at least WATCH and may escalate to BLOCK depending on the missing resource's role.\n\nThis skill does NOT prescribe the synthesis policy beyond max-severity — Pilot may want a different aggregation (majority, weighted by criticality). The cub-scout side is verdict-producing per resource; the fleet roll-up is Pilot's call.\n\n## Step-by-step\n\n### Step 1 — resolve the scope\n\n```bash\n$ cub-scout views resolve https:\u002F\u002Fhub.confighub.com\u002Fviews\u002Fpayments-prod-conformance\nView: payments-prod-conformance\n  scope: cluster\n  columns: [team, service, replicas, source_truth_strategy]\n  resolved at: 2026-05-22T10:30:00Z\n```\n\nIf no View applies, fall back to a namespace scope; the rest of the loop is identical except `--scope namespace\u002F\u003Cns>` replaces `--view \u003Cuuid>`.\n\n### Step 2 — outliers (true fleet shape)\n\n```bash\n$ cub-scout fleet outliers --view payments-prod-conformance\nView: payments-prod-conformance\nClusters: 12\n\n  payments-api   EXPECTED 3 deploys \u002F cluster   prod-euw1: 2 (outlier: missing payments-api-worker)\n  payments-db    EXPECTED 1 deploy \u002F cluster    ALL match\n  payments-cron  EXPECTED 4 deploys \u002F cluster   staging-use2: 3 (outlier: missing payments-cron-billing)\n```\n\n`fleet outliers` emits per-row mismatches. Each outlier is at minimum a **WATCH** for Pilot's fleet verdict (the per-cluster resource count doesn't match the View baseline); it escalates to **BLOCK** if the missing resource is in the View's critical-set (a separate policy Pilot enforces).\n\n### Step 3 — per-resource three-way + source-truth\n\n```bash\n# Three-way conformance across the View (DRY\u002FWET\u002FLIVE per resource)\n$ cub-scout compare three-way --view payments-prod-conformance --format json \\\n    | jq '.summary'\n{\n  \"agreement\": \"partial\",\n  \"agreed\": 18,\n  \"converging\": 1,\n  \"diverged\": 3,\n  \"scope\": \"view:payments-prod-conformance\"\n}\n\n# Strategy-anchored source-truth per resource\n$ for r in $(cub-scout views project --view payments-prod-conformance --format json \\\n              | jq -r '.[] | \"\\(.kind)\u002F\\(.name) -n \\(.namespace)\"'); do\n    cub-scout compare source-truth $r --strategy git-argo --format json \\\n      | jq '{resource: \"'\"$r\"'\", status: .status, source_truth: .source_truth, proof_gaps: .proof_gaps}'\n  done\n```\n\nEach per-resource output has `status` (PASS\u002FWATCH\u002FBLOCK\u002FASK) + `source_truth` (AGREED\u002FMISMATCH\u002FINCOMPLETE\u002FBLOCKED\u002FUNKNOWN) + `proof_gaps[]` (a string array of free-form missing-evidence entries) + `safe_next_action` (a free-form human-readable next step). Pilot collects these into the synthesis matrix. Field names are snake_case per `pkg\u002Fagent\u002Fsource_truth.go:280-287`.\n\n### Step 4 — persist fleet evidence as receipts (audit-quality)\n\n```bash\n# Per-resource receipts, saved to the immutable local store\n$ for r in $(cub-scout views project --view payments-prod-conformance --format json \\\n              | jq -r '.[] | \"\\(.kind)\u002F\\(.name) -n \\(.namespace)\"'); do\n    cub-scout receipt verify $r --strategy git-argo --save\n  done\n\n# Audit inventory: every fleet receipt with verdict BLOCK or WATCH\n$ cub-scout receipt list --format json \\\n    | jq '[.[] | select(.verdict == \"BLOCK\" or .verdict == \"WATCH\")]'\n```\n\nThe receipt store is **immutable** (each filename is canonical and `O_EXCL`-protected; duplicate saves return `os.ErrExist` and never overwrite). The fleet audit produces a fingerprint-stable evidence pack that can be archived for compliance review.\n\n## Worked example\n\nPilot is asked for the daily fleet verdict on View `payments-prod-conformance`, strategy `git-argo`:\n\n```bash\n$ cub-scout fleet outliers --view payments-prod-conformance\nView: payments-prod-conformance\nClusters: 12\n\n  payments-api   EXPECTED 3 deploys \u002F cluster   prod-euw1: 2 (outlier)\n  payments-cron  EXPECTED 4 deploys \u002F cluster   staging-use2: 3 (outlier)\n\n$ cub-scout compare three-way --view payments-prod-conformance --format json \\\n    | jq '.summary'\n{\n  \"agreement\": \"partial\",\n  \"agreed\": 18,\n  \"converging\": 1,\n  \"diverged\": 3\n}\n\n$ # per-resource source-truth (abbreviated)\n$ ... 18 PASS, 1 WATCH, 3 BLOCK\n```\n\nPilot's synthesis:\n- 22 resources in scope\n- 18 PASS + 1 WATCH + 3 BLOCK per source-truth\n- 2 cluster-level outliers (counted as WATCH)\n- Max-severity verdict → **BLOCK**\n\nPilot's verdict surface to the compliance dashboard:\n\n```json\n{\n  \"fleet\": \"payments-prod\",\n  \"view\": \"payments-prod-conformance\",\n  \"strategy\": \"git-argo\",\n  \"verdict\": \"BLOCK\",\n  \"rollup\": {\n    \"PASS\": 18,\n    \"WATCH\": 1,\n    \"ASK\": 0,\n    \"BLOCK\": 3,\n    \"outliers\": 2\n  },\n  \"blockers\": [\n    \"Deployment\u002Fpayments-api in prod-use1 (source_truth=MISMATCH)\",\n    \"Deployment\u002Fpayments-worker in prod-use1 (source_truth=MISMATCH)\",\n    \"Deployment\u002Fpayments-db in prod-euw1 (source_truth=MISMATCH)\"\n  ],\n  \"evidence_path\": \"\u002Fpath\u002Fto\u002Faudit\u002Freceipts\u002F2026-05-22\u002F\",\n  \"next_step\": \"investigate the 3 BLOCK resources via pilot-patch-and-drift\"\n}\n```\n\nDownstream consumer (compliance dashboard) reads the verdict, halts promotion, escalates to the team with the per-resource breakdown.\n\n## Standalone vs connected\n\nMost of this skill **requires connected mode** (`cub auth login`):\n\n- `compare three-way` (DRY layer needs ConfigHub) — connected\n- `compare source-truth` — connected (the contract is meaningless without all 3 surfaces)\n- `views resolve` \u002F `views project` — connected\n- `fleet outliers` — connected (cross-cluster snapshots live in ConfigHub)\n- `receipt verify --strategy \u003Cs>` — connected (source-truth-pass predicate requires it)\n\nStandalone-mode fleet conformance is narrower:\n- Per-resource `compare drift` against files (no DRY layer)\n- `receipt verify --predicate applied-matches-spec` (cluster-only)\n- No View scope; falls back to namespace \u002F cluster scope\n\nPilot should run `cub-scout status` in the pipeline preamble; if standalone and the fleet verdict requires `--strategy`, escalate to ASK with a \"connected mode required\" message.\n\n## CI \u002F dashboard integration\n\nFor periodic fleet audits, the verbs are CI-shaped:\n\n```bash\n# Daily cron — render the fleet verdict, exit non-zero if BLOCK\n$ cub-scout compare three-way --view payments-prod-conformance --fail-on warning\n# exit 2 if any resource in the View has a hard mismatch\n```\n\nFor receipts-attached audits (preferred for compliance):\n\n```bash\n# Per-resource receipt save + collect into audit branch\n$ .\u002Ffleet-audit.sh > audit-results.txt\n$ cub-scout receipt list --format json > audit-receipts.json\n$ git add audit-receipts.json && git commit -m \"fleet audit $(date -u +%F)\"\n```\n\nPilot's typical batch shape: run per-resource `receipt verify --strategy \u003Cs> --save` overnight; in the morning, walk `cub-scout receipt list --format json` for the verdict roll-up.\n\n## Tool boundary\n\n- **Allowed (cub-scout):** Compare verbs; `fleet outliers`; `views resolve` \u002F `project`; `receipt verify` \u002F `show` \u002F `validate` \u002F `list`; `scan`; `map`; `summary list`. All read-only.\n- **Allowed (cluster):** `kubectl get`. NOT `kubectl apply\u002Fedit\u002Fpatch\u002Fdelete`.\n- **Allowed (ConfigHub):** `cub \u003Centity> get \u002F list` for the entities named in allowed-tools. NOT `cub * create \u002F update \u002F delete \u002F sync`.\n- **Pilot itself may mutate** via `cub` or controller verbs, but the fleet-conformance verdict is Pilot's evidence-driven judgment; cub-scout never decides on Pilot's behalf.\n\n## References\n\n- [`audit-fleet-conformance`](..\u002Faudit-fleet-conformance\u002FSKILL.md) — operator-side counterpart (same verbs, different framing)\n- [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md) — the four Compare verbs (cub-scout side)\n- [`scout-govern`](..\u002Fscout-govern\u002FSKILL.md) — fleet outliers, views, summary\n- [`scout-verify`](..\u002Fscout-verify\u002FSKILL.md) — receipt persistence\n- [`confighub-source-truth`](..\u002Fconfighub-source-truth\u002FSKILL.md) — strategy-typed verdict\n- [`pilot-cd-gate`](..\u002Fpilot-cd-gate\u002FSKILL.md) — single-resource pre-deploy gate companion\n- [`pilot-patch-and-drift`](..\u002Fpilot-patch-and-drift\u002FSKILL.md) — drill-down for the BLOCK resources Pilot flags\n- [`pilot-watch-alert-response`](..\u002Fpilot-watch-alert-response\u002FSKILL.md) — event-driven companion (this skill is periodic-driven)\n- Views integration: `#391` (parent), `#414` (compare three-way --view), `#403` (views resolve), `#420` (views project --with-reality)\n- Source-truth contract: `#393`, `#418` (Phase 2 strategies)\n\n## Constraints\n\n- Connected mode is required for the View + ConfigHub + fleet surfaces.\n- The strategy is **caller-declared** per resource (or uniform across the View when the team declares fleet-wide policy). cub-scout never infers it.\n- Synthesis policy (max-severity, majority, weighted, etc.) is **Pilot's** choice. cub-scout provides per-resource verdicts; the roll-up shape is Pilot-side.\n- `fleet outliers` requires the View to be **declared with cluster scope** (`cub view create --scope cluster`). Namespace-scoped Views can't be cross-clustered.\n- Per-resource receipts in a fleet audit can be high-volume. The local receipt store handles large-N writes (each filename is canonical so collisions are predictable), but downstream consumers should expect `receipt list` to return many entries.\n",{"name":5,"phase":60,"description":7,"allowed-tools":61},"cross-cutting","Bash(.\u002Fcub-scout compare three-way *) Bash(cub-scout compare three-way *) Bash(cub scout compare three-way *) Bash(.\u002Fcub-scout compare source-truth *) Bash(cub-scout compare source-truth *) Bash(cub scout compare source-truth *) Bash(.\u002Fcub-scout fleet outliers *) Bash(cub-scout fleet outliers *) Bash(cub scout fleet outliers *) Bash(.\u002Fcub-scout views resolve *) Bash(cub-scout views resolve *) Bash(cub scout views resolve *) Bash(.\u002Fcub-scout views project *) Bash(cub-scout views project *) Bash(cub scout views project *) Bash(.\u002Fcub-scout receipt verify *) Bash(cub-scout receipt verify *) Bash(cub scout receipt verify *) Bash(.\u002Fcub-scout receipt list *) Bash(cub-scout receipt list *) Bash(cub scout receipt list *) Bash(.\u002Fcub-scout receipt show *) Bash(cub-scout receipt show *) Bash(cub scout receipt show *) Bash(.\u002Fcub-scout receipt validate *) Bash(cub-scout receipt validate *) Bash(cub scout receipt validate *) Bash(.\u002Fcub-scout map list *) Bash(.\u002Fcub-scout map workloads *) Bash(.\u002Fcub-scout map orphans *) Bash(cub-scout map list *) Bash(cub-scout map workloads *) Bash(cub-scout map orphans *) Bash(cub scout map list *) Bash(cub scout map workloads *) Bash(cub scout map orphans *) Bash(.\u002Fcub-scout scan *) Bash(cub-scout scan *) Bash(cub scout scan *) Bash(.\u002Fcub-scout summary list *) Bash(cub-scout summary list *) Bash(cub scout summary list *) Bash(kubectl get *) 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 view list)","main","261862e7ec5e5c93ce377ccfd6b583f5ac03c95c","skills\u002Fpilot-fleet-conformance",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":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add confighub\u002Fcub-scout --skill pilot-fleet-conformance",{"tool":77,"command":78},"bunx","bunx skills add confighub\u002Fcub-scout --skill pilot-fleet-conformance",{"tool":80,"command":81},"pnpm","pnpm dlx skills add confighub\u002Fcub-scout --skill pilot-fleet-conformance","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fpilot-fleet-conformance\u002FSKILL.md",true,[85],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"agents\u002Fopenai.yaml","REFERENCE","参考文档",143,"https:\u002F\u002Fgithub.com\u002Fmalinskibeniamin\u002Fskills\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fdemo\u002Fagents\u002Fopenai.yaml",[92,125,146,166,190,210],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":103,"publishedAt":55},"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",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[104,105,106,107,108,109,110,111,41,112,37,47,113,114,115,116,54,117,118,25,119,120,121,29,122,123,124],"triage","workload","triage unhealthy workload","kubernetes","diagnose","doctor","logs","ci","api","explain","check","broken","question","rollout","never","route","drift","map","get","now","when",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":55},"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",[131],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},[45,133,134,107,39,135,111,136,137,112,138,37,139,49,140,52,141,54,118,142,25,27,119,143,122,144,32,145,124],"scout verify","scout","produce","attestation","provenance","show me","postmortem","argocd","fix","evidence","me","app","managed",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":55},"01M6CBPF8WZBM7F9X096WT8PJD","scout-observe","Use when the user wants to SEE what is running in a Kubernetes cluster, who owns it, and how it is structured — the read-only Observe verb group of cub-scout. Natural phrasing: \"what is running in my cluster?\", \"give me a map of resources\", \"who owns this Deployment?\", \"trace this back to its source\", \"show me the ownership tree\", \"scan this cluster for risk\", \"dump the cluster as JSON\", \"stream cluster events\", \"run cub-scout as a bot\", \"what is the connection status?\", \"is this cluster healthy?\". Load when intent is observe \u002F inventory \u002F map \u002F show \u002F list \u002F trace \u002F scan \u002F dump \u002F stream \u002F bot \u002F health-check over a Kubernetes cluster. Do NOT load for: explaining WHY something is broken (use scout-diagnose), comparing cluster state to intended state (use scout-compare), provenance of individual field values (use scout-attribute), or any action that mutates the cluster (cub-scout never mutates — route to cub or kubectl with the user driving).","https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fscout-observe\u002FSKILL.md",[],[153,154,134,155,107,108,156,109,110,157,137,158,138,37,115,54,159,118,160,161,25,27,162,163,121,122,164,165,124],"observe","scout observe","bot","deployment","risk","inventory","version","only","hooks","back","health-check","resources","meaning",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":175,"publishedAt":55},"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",[172],{"categoryNo":173,"categoryName":174,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000023","Skill与智能体开发",[176,177,134,155,178,179,180,181,182,46,183,184,37,185,49,186,187,160,188,22,153,122,32,189,124],"MCP","scout mcp","mcp server","ai agent","auth","config","run","server","SET","model","read","snapshot","ready","agent-context",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":55},"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",[],[197,198,134,107,108,46,199,135,200,184,158,201,138,37,49,202,116,186,203,52,54,160,153,25,27,204,205,206,31,144,32,35,207,208,209],"ingest","scout ingest","state","adoption","discovery","repo","write","structure","aggregator","adopt","exported","invoke","parse",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":216,"publishedAt":55},"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",[],[217,134,218,180,219,220,40,158,45,138,37,221,49,52,222,54,223,24,224,153,25,27,30,122,225,226,32,227,228,36,229,124],"scout govern","change","governance","blast radius","history","catalog","diff","snapshots","mutation","impact","render","blast-radius","inspect"]