[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CBMSHJ9XQC8NSDNDKZVPP1":3,"skill-same:01M6CBMSHJ9XQC8NSDNDKZVPP1":89},{"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":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M6CBMSHJ9XQC8NSDNDKZVPP1","pilot-incident-evidence",null,"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` \u002F Argo \u002F Flux.","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-incident-evidence\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],"evidence","pilot incident evidence","incident","mutation","never","scout compare","show","time","active","assemble","argo","app","close","unit","affected","which","inspect","workload","sre","snapshot","list","changeset","history","Bash","save","attestation","remediation","kubectl","logs","operator","audit","doctor","release","2026-11-10 10:12:30",false,"---\nname: pilot-incident-evidence\ndescription: '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` \u002F Argo \u002F Flux.'\nphase: cross-cutting\nallowed-tools: Bash(.\u002Fcub-scout trace *) Bash(cub-scout trace *) Bash(cub scout trace *) Bash(.\u002Fcub-scout explain *) Bash(cub-scout explain *) Bash(cub scout explain *) Bash(.\u002Fcub-scout compare three-way *) Bash(cub-scout compare three-way *) Bash(cub scout compare three-way *) Bash(.\u002Fcub-scout compare drift *) Bash(cub-scout compare drift *) Bash(cub scout compare drift *) Bash(.\u002Fcub-scout compare source-truth *) Bash(cub-scout compare source-truth *) Bash(cub scout compare source-truth *) Bash(.\u002Fcub-scout doctor *) Bash(cub-scout doctor *) Bash(cub scout doctor *) Bash(.\u002Fcub-scout bundle diff *) Bash(.\u002Fcub-scout bundle inspect *) Bash(.\u002Fcub-scout bundle summarize *) Bash(.\u002Fcub-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(.\u002Fcub-scout history *) Bash(cub-scout history *) Bash(cub scout history *) Bash(.\u002Fcub-scout audit *) Bash(cub-scout audit *) Bash(cub scout audit *) Bash(.\u002Fcub-scout receipt verify *) Bash(cub-scout receipt verify *) Bash(cub scout receipt verify *) Bash(.\u002Fcub-scout receipt show *) Bash(cub-scout receipt show *) Bash(cub scout receipt show *) Bash(.\u002Fcub-scout receipt list *) Bash(cub-scout receipt list *) Bash(cub scout receipt list *) Bash(.\u002Fcub-scout receipt validate *) Bash(cub-scout receipt validate *) Bash(cub scout receipt validate *) Bash(.\u002Fcub-scout snapshot *) Bash(cub-scout snapshot *) Bash(cub scout snapshot *) 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(kubectl get *) Bash(kubectl describe *) Bash(kubectl get events *) Bash(kubectl logs *) 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(argocd app get *) Bash(flux get *)\n\n---\n\n# pilot-incident-evidence\n\nThe incident-evidence scenario from **Pilot's** side. After the incident is past peak (pager no longer firing), Pilot is asked to **render an evidence pack + verdict** that downstream consumers — the postmortem doc, the release-engineering meeting, the audit ticket, the compliance review — all consume.\n\nThis is the **judge-driven** companion to [`operator-incident-evidence`](..\u002Foperator-incident-evidence\u002FSKILL.md) (the SRE-driven postmortem assembly). Same cub-scout verbs feed both; the difference is framing: the operator wants to understand the incident; Pilot wants to render a verdict + a fingerprinted evidence pack on the incident's close-out.\n\nThe receipts v2 chained-attestation surface (`--input-attestation`, shipped in `#463`) is load-bearing here: a multi-stage incident produces a **chain** of per-stage receipts, each referencing the prior, and the final verdict receipt has the full chain inline. cub-scout never mutates; Pilot's \"what should we change\" recommendation is its own surface, not cub-scout's.\n\n## When to use\n\nExplicit phrasings:\n\n- \"Pilot, build the evidence pack for last night's outage\"\n- \"Render the incident verdict + evidence for the SEV-2\"\n- \"Pilot, what does cub-scout have on this incident?\"\n- \"Freeze the evidence before the cluster moves on\"\n- \"Assemble the postmortem inputs from cub-scout\"\n- \"Pilot, attach the verdict + fingerprinted receipts to the audit ticket\"\n- \"Chain the receipts so the postmortem has the full delivery path\"\n\nImplicit intents:\n\n- The incident is **past peak** (pager no longer firing); time pressure has eased\n- Pilot is rendering for an **audience** — postmortem doc, release-engineering meeting, compliance audit\n- The evidence needs to be **immutable** (fingerprinted) — it shouldn't shift if someone fixes the cluster afterwards\n- The output is a **verdict + an evidence pack**, not just a description\n- Multi-stage incidents (deploy → reconciliation → drift → revert) want **chained receipts**, not isolated artifacts\n\n## Do not load for\n\n- **Pager-active triage** (the incident is still firing) — [`triage-unhealthy-workload`](..\u002Ftriage-unhealthy-workload\u002FSKILL.md)\n- A **real-time event-driven response** as the incident unfolds — [`pilot-watch-alert-response`](..\u002Fpilot-watch-alert-response\u002FSKILL.md)\n- A **single-resource pre-deploy gate** that would have prevented the incident — [`pilot-cd-gate`](..\u002Fpilot-cd-gate\u002FSKILL.md)\n- A **periodic fleet audit** — [`pilot-fleet-conformance`](..\u002Fpilot-fleet-conformance\u002FSKILL.md)\n- A **drift-classification deep-dive** in isolation — [`pilot-patch-and-drift`](..\u002Fpilot-patch-and-drift\u002FSKILL.md)\n- An **operator-driven** evidence assembly (SRE writing their own postmortem) — [`operator-incident-evidence`](..\u002Foperator-incident-evidence\u002FSKILL.md)\n- Any **mutating action**. cub-scout doesn't revert \u002F fix \u002F restart. Pilot's mutation path is `cub` \u002F Argo \u002F Flux \u002F kubectl.\n\n## The Pilot ↔ cub-scout incident-evidence loop\n\n```\n   incident SEV-2 fired at 14:00, resolved at 16:00 — close-out at 16:30\n        │\n        ▼\n   Pilot (acceptance judge)\n        │  \"render the evidence pack + verdict for incident-2026-05-22-001\"\n        │\n        ├──► Per affected resource:\n        │      cub-scout trace \u003Cr> -n \u003Cns> --format json     # owner + lineage\n        │      cub-scout explain \u003Cr> -n \u003Cns> --presentation ai\n        │      cub-scout compare three-way \u003Cr> -n \u003Cns>      # DRY\u002FWET\u002FLIVE + attribution\n        │        --format json\n        │      cub-scout history \u003Cr> -n \u003Cns> --since 4h     # ChangeSet timeline\n        │      cub-scout receipt verify \u003Cr> -n \u003Cns>\n        │        --predicate no-manual-edits-since\n        │        --since \u003Cpre-incident timestamp>\n        │        --save                                      # was a manual edit involved?\n        │\n        ├──► Cluster-level capture:\n        │      cub-scout bundle --since 4h                   # debug-bundle archive (replay-able)\n        │      cub-scout snapshot                            # GSF JSON snapshot (offline)\n        │      cub-scout audit list --since 4h               # ConfigHub audit entries\n        │\n        ├──► (multi-stage) Chain the receipts:\n        │      # Stage 1: pre-incident receipt\n        │      cub-scout receipt verify \u003Cr> ... --out stage1.receipt.json\n        │      # Stage 2: at-incident receipt, chained to stage 1\n        │      cub-scout receipt verify \u003Cr> ... \\\n        │        --input-attestation stage1.receipt.json \\\n        │        --out stage2.receipt.json\n        │      # Stage 3: post-resolution receipt, chained to stage 2\n        │      cub-scout receipt verify \u003Cr> ... \\\n        │        --input-attestation stage2.receipt.json \\\n        │        --out stage3.receipt.json\n        │\n        └──► (optional) cub-scout receipt list --format json > incident-receipt-inventory.json\n        │\n        ▼\n   Pilot's evidence pack + verdict:\n        │\n        │  evidence_pack = {\n        │    incident_id: \"incident-2026-05-22-001\",\n        │    verdict: \u003Cmax-severity over all receipts>,\n        │    timeline: [\n        │      {stage: \"pre\", receipt: \"stage1.receipt.json\"},\n        │      {stage: \"at\", receipt: \"stage2.receipt.json\"},\n        │      {stage: \"post\", receipt: \"stage3.receipt.json\"}\n        │    ],\n        │    bundle: \"incident-bundle.tar.gz\",\n        │    snapshot: \"incident-snapshot.json\",\n        │    audit_entries: [...],\n        │    next_step: \"\u003CPilot's recommendation, e.g., open Git PR to remove kubectl-edit access>\"\n        │  }\n        │\n        ▼\n   downstream consumer (postmortem \u002F audit \u002F compliance) reads the pack\n        └────────────────────────────────────────────────────\n```\n\n## The four-tier evidence shape\n\nPilot's incident pack composes four tiers of cub-scout evidence, in increasing audit durability:\n\n| Tier | Verb | Durability | Shape |\n|------|------|------------|-------|\n| **1. Ephemeral** | `compare three-way`, `explain`, `trace`, `history` | One-shot JSON; valid at this moment | Live evidence — the cluster state at incident close-out |\n| **2. Bundle snapshot** | `bundle`, `snapshot` | Tar \u002F JSON archive replay-able offline | Cluster-wide state freeze; survives the cluster being rolled |\n| **3. Fingerprinted receipt** | `receipt verify --save` | Immutable per-resource artifact; SHA-256 fingerprint over RFC 8785 canonical JSON | Typed evidence; verdict per predicate; verifiable later via `receipt validate` |\n| **4. Chained receipts** | `receipt verify --input-attestation \u003Cprior>` | Per-stage receipts linked by `inputAttestations[]`; each ref's fingerprint verified at chain construction | Multi-stage incident timeline as a tamper-evident DAG |\n\nPilot uses tier-1 + tier-2 for the narrative; tier-3 + tier-4 for the **immutable** part of the pack. The chained-receipts tier is what makes a multi-stage incident's evidence trustworthy: tampering with any upstream receipt invalidates every downstream receipt's fingerprint.\n\n## Step-by-step\n\n### Step 1 — define scope and timeline\n\n- What resources were involved? (`deploy\u002Fpayments-api`, maybe `deploy\u002Fpayments-worker`, the upstream `service\u002Fpayments`)\n- What time window? (incident fired 14:00, resolved 16:00; capture from 13:00 to 16:30 to cover pre-and-post state)\n- Was there a **deploy** during the window? a **manual edit**? a **controller reconciliation flap**?\n\n### Step 2 — resource-level evidence (per affected resource)\n\n```bash\n# Owner + lineage\n$ cub-scout trace deploy\u002Fpayments-api -n prod --format json > payments-api-trace.json\n$ cub-scout explain deploy\u002Fpayments-api -n prod --presentation ai > payments-api-explain.txt\n\n# DRY\u002FWET\u002FLIVE + per-field attribution\n$ cub-scout compare three-way deploy\u002Fpayments-api -n prod --format json > payments-api-3way.json\n\n# ChangeSet timeline\n$ cub-scout history deploy\u002Fpayments-api -n prod --since 4h --format json > payments-api-history.json\n\n# Manual-edits check\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --predicate no-manual-edits-since \\\n    --since 2026-05-22T13:00:00Z \\\n    --save \\\n    --out payments-api-manual-edits.receipt.json\n```\n\nThe four outputs together answer: who owns it, how is it diverging now, what changed recently, and was a kubectl-* writer involved.\n\n### Step 3 — cluster-level capture (offline-replay-able)\n\n```bash\n$ cub-scout bundle --since 4h > incident-bundle.tar.gz\n$ cub-scout snapshot > incident-snapshot.json\n$ cub-scout audit list --since 4h --format json > incident-audit.json\n```\n\nThe bundle archives enough cluster state to replay offline (`cub-scout bundle replay` later). The snapshot is GSF JSON for tooling. `audit list` collects connected-mode ConfigHub audit entries.\n\n### Step 4 — multi-stage chained receipts (the load-bearing piece)\n\nFor a multi-stage incident (e.g., deploy at 13:50 → drift at 14:00 → revert at 15:30), capture per-stage receipts and chain them:\n\n```bash\n# Stage 1: pre-incident baseline\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --at-commit \u003Cpre-incident-sha> \\\n    --save \\\n    --out incident\u002Fstage1-pre.receipt.json\n\n# Stage 2: at peak (during the incident)\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --input-attestation incident\u002Fstage1-pre.receipt.json \\\n    --save \\\n    --out incident\u002Fstage2-at.receipt.json\n\n# Stage 3: post-resolution\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --input-attestation incident\u002Fstage2-at.receipt.json \\\n    --save \\\n    --out incident\u002Fstage3-post.receipt.json\n```\n\nThe chain forms a tamper-evident DAG: `stage3` references `stage2` references `stage1`, and each parent's fingerprint is verified at chain construction time. Tampering with `stage1.receipt.json` after the fact would refuse to chain into `stage2` — chain construction errors out upfront rather than silently propagating bad evidence.\n\nThe verify step inside `cub-scout receipt verify --input-attestation` is enforced **at the API boundary** via the `VerifiedAttestationRef` typed wrapper (#463 Codex round-6 P1 fix). Programmatic callers cannot bypass the verify step; the chain integrity property is locked in code.\n\n### Step 5 — Pilot's verdict synthesis\n\nPilot's verdict for the incident pack is **max-severity over the chained receipts**. Note that receipt verdicts are the four-valued enum `PASS \u002F WATCH \u002F BLOCK \u002F INCONCLUSIVE` (per `pkg\u002Fagent\u002Freceipt.go:179-192`); `ASK` is a source-truth `status` value (mapped to receipt `WATCH` when wrapped, per `pkg\u002Fagent\u002Freceipt_predicates.go:396-407`) and is NOT a receipt verdict. Pilot's *incident* verdict can be ASK, but it's derived from `INCONCLUSIVE` receipts, not from an ASK receipt verdict:\n\n| Stage receipts' verdicts | Pilot's incident verdict |\n|--------------------------|--------------------------|\n| All PASS | **PASS** (no incident; close as no-op) |\n| At least one WATCH, rest PASS | **WATCH** (close with a flag) |\n| At least one INCONCLUSIVE | **ASK** (postmortem owners need to fill proof gaps surfaced as receipt omissions) |\n| Any BLOCK | **BLOCK** (real incident; write a postmortem) |\n\nThe chained shape encodes the timeline: PASS → BLOCK → PASS reads as \"we had a manual-edit episode that we recovered from\"; PASS → BLOCK → BLOCK reads as \"we never recovered intent; the live state is still divergent.\"\n\n### Step 6 — assemble the pack for downstream consumption\n\n```json\n{\n  \"incident_id\": \"incident-2026-05-22-001\",\n  \"scope\": \"Deployment\u002Fpayments-api in prod\",\n  \"window\": \"13:00–16:30\",\n  \"verdict\": \"BLOCK\",\n  \"timeline\": [\n    {\"stage\": \"pre\",  \"at\": \"13:00\", \"receipt\": \"stage1-pre.receipt.json\",  \"verdict\": \"PASS\"},\n    {\"stage\": \"at\",   \"at\": \"14:00\", \"receipt\": \"stage2-at.receipt.json\",   \"verdict\": \"BLOCK\"},\n    {\"stage\": \"post\", \"at\": \"16:30\", \"receipt\": \"stage3-post.receipt.json\", \"verdict\": \"PASS\"}\n  ],\n  \"bundle\": \"incident-bundle.tar.gz\",\n  \"snapshot\": \"incident-snapshot.json\",\n  \"audit_entries\": \"incident-audit.json\",\n  \"narrative\": \"explain + trace + 3way outputs (txt + json)\",\n  \"root_cause_hypothesis\": \"manual-edit on image during pager-active triage (kubectl-edit; verified manager string)\",\n  \"recommendation\": \"open Git PR amending apps\u002Fprod\u002Fpayments-api\u002Fdeployment.yaml; remove ad-hoc kubectl-edit access from on-call IAM\"\n}\n```\n\nThe downstream consumer (postmortem author, audit reviewer) reads the verdict + the chained timeline + the cluster-state artifacts. Every receipt is fingerprint-verifiable; `cub-scout receipt validate` exit-coded for CI.\n\n## Worked example\n\nIncident `incident-2026-05-22-001`: `deploy\u002Fpayments-api` in prod fired SEV-2 at 14:00. Resolved by 16:00. Pilot is rendering the close-out pack.\n\n```bash\n# Pre-incident baseline (the controller said this was good at 13:00)\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --at-commit 9e7d12fa \\\n    --save \\\n    --out incident\u002Fstage1-pre.receipt.json\n# verdict: PASS, fingerprint: sha256:abc...\n\n# At incident peak (14:00)\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --input-attestation incident\u002Fstage1-pre.receipt.json \\\n    --save \\\n    --out incident\u002Fstage2-at.receipt.json\n# verdict: BLOCK, evidence shows manual-edit on container image; fingerprint: sha256:def...\n\n# Post-resolution (16:30)\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --input-attestation incident\u002Fstage2-at.receipt.json \\\n    --save \\\n    --out incident\u002Fstage3-post.receipt.json\n# verdict: PASS, the post-resolution Git revision matches LIVE; fingerprint: sha256:789...\n\n# Bundle + snapshot for offline replay\n$ cub-scout bundle --since 4h > incident\u002Fbundle.tar.gz\n$ cub-scout snapshot > incident\u002Fsnapshot.json\n\n# Connected-mode timeline\n$ cub-scout history deploy\u002Fpayments-api -n prod --since 4h --format json > incident\u002Fhistory.json\n$ cub-scout audit list --since 4h --format json > incident\u002Faudit.json\n\n# Receipt inventory for the incident namespace\n$ cub-scout receipt list --format json > incident\u002Freceipt-inventory.json\n```\n\nPilot's verdict pack (rendered as JSON for the audit ticket):\n\n```json\n{\n  \"incident_id\": \"incident-2026-05-22-001\",\n  \"verdict\": \"BLOCK\",\n  \"scope\": \"Deployment\u002Fpayments-api in prod\",\n  \"window\": \"13:00–16:30\",\n  \"chain\": [\"stage1-pre\", \"stage2-at\", \"stage3-post\"],\n  \"verdict_per_stage\": [\"PASS\", \"BLOCK\", \"PASS\"],\n  \"root_cause\": \"manual-edit on container image during pager triage\",\n  \"verified_manager\": \"kubectl-edit\",\n  \"recovered_at\": \"16:00\",\n  \"evidence_paths\": {\n    \"receipts\": \"incident\u002Fstage{1,2,3}-*.receipt.json\",\n    \"bundle\": \"incident\u002Fbundle.tar.gz\",\n    \"snapshot\": \"incident\u002Fsnapshot.json\",\n    \"history\": \"incident\u002Fhistory.json\",\n    \"audit\": \"incident\u002Faudit.json\"\n  },\n  \"recommended_follow_ups\": [\n    \"Open Git PR codifying the image bump as intent\",\n    \"Review on-call IAM (remove kubectl-edit on prod deployments)\",\n    \"Open issue against #449 — investigate whether watch alert fired pre-pager\"\n  ]\n}\n```\n\nThe audit ticket gets the verdict + the chained-receipts manifest. Six months later, an auditor can:\n\n```bash\n$ cub-scout receipt validate incident\u002Fstage1-pre.receipt.json   # exit 0 — fingerprint intact\n$ cub-scout receipt validate incident\u002Fstage2-at.receipt.json    # exit 0 — fingerprint intact\n$ cub-scout receipt validate incident\u002Fstage3-post.receipt.json  # exit 0 — fingerprint intact\n$ cub-scout receipt show incident\u002Fstage2-at.receipt.json --format ascii\n# Same evidence Pilot rendered the verdict from; tamper-evident.\n```\n\nIf any of the receipts had been tampered with between then and now, `receipt validate` would exit 1 — the audit would immediately know the chain was untrustworthy.\n\n## Standalone vs connected\n\nMost of this skill works in **both modes**:\n\n- Standalone: tier-1 + tier-2 + tier-3 (with `--predicate applied-matches-spec` and `--predicate no-manual-edits-since`); chained receipts work. Receipts will carry an `OmissionConfigHubUnitSubject` entry.\n- Connected: adds `--strategy source-truth-pass` (tier-3 quality boost), `cub-scout audit list`, `cub-scout history`, `bindingSource` in attribution. Recommended for production incident packs.\n\nPilot should run `cub-scout status` in the pack-assembly preamble; if standalone, Pilot's pack records the limitation explicitly (the receipts themselves already record it via omissions).\n\n## Tool boundary\n\n- **Allowed (cub-scout):** `trace`, `explain`, all Compare verbs, `doctor`, `bundle`, `history`, `audit`, `receipt verify` \u002F `show` \u002F `validate` \u002F `list`, `snapshot`, `map`. All read-only.\n- **Allowed (cluster):** `kubectl get\u002Fdescribe`, `kubectl get events`, `kubectl logs`. NOT `kubectl apply \u002F edit \u002F patch \u002F delete` \u002F `rollout undo`.\n- **Allowed (ConfigHub):** `cub \u003Centity> get \u002F list` for the entities named in allowed-tools. NOT `cub * create \u002F update \u002F delete`.\n- **Allowed (controllers):** `argocd app get`, `flux get`. NOT `argocd app sync`, `flux reconcile`.\n- **Pilot's recommendation** (\"open a Git PR\", \"remove kubectl-edit access\") is **a recommendation only**. cub-scout doesn't implement the recommendation; Pilot's mutation path is `cub` \u002F Argo \u002F kubectl. This skill produces evidence and a verdict, not a remediation.\n\n## References\n\n- [`operator-incident-evidence`](..\u002Foperator-incident-evidence\u002FSKILL.md) — operator-driven counterpart (SRE writing their own postmortem)\n- [`scout-verify`](..\u002Fscout-verify\u002FSKILL.md) — receipts + chained `--input-attestation`\n- [`scout-observe`](..\u002Fscout-observe\u002FSKILL.md) — `bundle`, `snapshot`, `watch` (the source of replay-able evidence)\n- [`scout-attribute`](..\u002Fscout-attribute\u002FSKILL.md) — `cause` \u002F `managerHint` \u002F `gitSource` per field\n- [`pilot-patch-and-drift`](..\u002Fpilot-patch-and-drift\u002FSKILL.md) — drift-classification companion (per-field, not per-incident)\n- [`pilot-watch-alert-response`](..\u002Fpilot-watch-alert-response\u002FSKILL.md) — real-time companion (the events that may have fired during the incident; this skill replays them in the bundle)\n- [`pilot-cd-gate`](..\u002Fpilot-cd-gate\u002FSKILL.md) — what should have caught the incident pre-deploy (postmortem may recommend tightening this)\n- Chained receipts: `#448` (issue), `#463` (chained-half shipped); `VerifiedAttestationRef` typed wrapper enforces verify at API boundary\n- in-toto Statement v1, RFC 8785 canonical JSON, SHA-256 fingerprint: [`docs\u002Freference\u002Fjson-contracts.md`](..\u002F..\u002Fdocs\u002Freference\u002Fjson-contracts.md) § Receipt Contract\n\n## Constraints\n\n- The incident pack's **immutability** depends on the receipt store's `O_EXCL` atomic file create (cub-scout side). The store at `$XDG_DATA_HOME\u002Fcub-scout\u002Freceipts` is per-host; Pilot should archive receipts to a durable store (S3, ConfigHub bundle catalog) for long-term audit retention.\n- Chained receipts ONLY verify chain integrity at construction time — `cub-scout receipt validate` checks one receipt's fingerprint; verifying a multi-stage chain requires walking each `inputAttestations[]` entry and validating it independently. A future helper may automate this; today it's a manual loop.\n- `--input-attestation` requires the **upstream receipt to be a valid in-toto Statement v1 envelope with a verifiable fingerprint**. Tampered upstreams refuse to chain at the verify-time API boundary (`VerifiedAttestationRef` typed wrapper); Pilot must capture pristine receipts at each stage.\n- `bundle` archives can be large for high-resource clusters. Pilot may want to scope `bundle --namespace \u003Cns>` to the affected namespace rather than the whole cluster.\n- The verdict is **per-incident**, not per-resource. A multi-resource incident produces N chains, and Pilot's incident-level verdict is the max-severity over all chains.\n","# pilot-incident-evidence\n\nThe incident-evidence scenario from **Pilot's** side. After the incident is past peak (pager no longer firing), Pilot is asked to **render an evidence pack + verdict** that downstream consumers — the postmortem doc, the release-engineering meeting, the audit ticket, the compliance review — all consume.\n\nThis is the **judge-driven** companion to [`operator-incident-evidence`](..\u002Foperator-incident-evidence\u002FSKILL.md) (the SRE-driven postmortem assembly). Same cub-scout verbs feed both; the difference is framing: the operator wants to understand the incident; Pilot wants to render a verdict + a fingerprinted evidence pack on the incident's close-out.\n\nThe receipts v2 chained-attestation surface (`--input-attestation`, shipped in `#463`) is load-bearing here: a multi-stage incident produces a **chain** of per-stage receipts, each referencing the prior, and the final verdict receipt has the full chain inline. cub-scout never mutates; Pilot's \"what should we change\" recommendation is its own surface, not cub-scout's.\n\n## When to use\n\nExplicit phrasings:\n\n- \"Pilot, build the evidence pack for last night's outage\"\n- \"Render the incident verdict + evidence for the SEV-2\"\n- \"Pilot, what does cub-scout have on this incident?\"\n- \"Freeze the evidence before the cluster moves on\"\n- \"Assemble the postmortem inputs from cub-scout\"\n- \"Pilot, attach the verdict + fingerprinted receipts to the audit ticket\"\n- \"Chain the receipts so the postmortem has the full delivery path\"\n\nImplicit intents:\n\n- The incident is **past peak** (pager no longer firing); time pressure has eased\n- Pilot is rendering for an **audience** — postmortem doc, release-engineering meeting, compliance audit\n- The evidence needs to be **immutable** (fingerprinted) — it shouldn't shift if someone fixes the cluster afterwards\n- The output is a **verdict + an evidence pack**, not just a description\n- Multi-stage incidents (deploy → reconciliation → drift → revert) want **chained receipts**, not isolated artifacts\n\n## Do not load for\n\n- **Pager-active triage** (the incident is still firing) — [`triage-unhealthy-workload`](..\u002Ftriage-unhealthy-workload\u002FSKILL.md)\n- A **real-time event-driven response** as the incident unfolds — [`pilot-watch-alert-response`](..\u002Fpilot-watch-alert-response\u002FSKILL.md)\n- A **single-resource pre-deploy gate** that would have prevented the incident — [`pilot-cd-gate`](..\u002Fpilot-cd-gate\u002FSKILL.md)\n- A **periodic fleet audit** — [`pilot-fleet-conformance`](..\u002Fpilot-fleet-conformance\u002FSKILL.md)\n- A **drift-classification deep-dive** in isolation — [`pilot-patch-and-drift`](..\u002Fpilot-patch-and-drift\u002FSKILL.md)\n- An **operator-driven** evidence assembly (SRE writing their own postmortem) — [`operator-incident-evidence`](..\u002Foperator-incident-evidence\u002FSKILL.md)\n- Any **mutating action**. cub-scout doesn't revert \u002F fix \u002F restart. Pilot's mutation path is `cub` \u002F Argo \u002F Flux \u002F kubectl.\n\n## The Pilot ↔ cub-scout incident-evidence loop\n\n```\n   incident SEV-2 fired at 14:00, resolved at 16:00 — close-out at 16:30\n        │\n        ▼\n   Pilot (acceptance judge)\n        │  \"render the evidence pack + verdict for incident-2026-05-22-001\"\n        │\n        ├──► Per affected resource:\n        │      cub-scout trace \u003Cr> -n \u003Cns> --format json     # owner + lineage\n        │      cub-scout explain \u003Cr> -n \u003Cns> --presentation ai\n        │      cub-scout compare three-way \u003Cr> -n \u003Cns>      # DRY\u002FWET\u002FLIVE + attribution\n        │        --format json\n        │      cub-scout history \u003Cr> -n \u003Cns> --since 4h     # ChangeSet timeline\n        │      cub-scout receipt verify \u003Cr> -n \u003Cns>\n        │        --predicate no-manual-edits-since\n        │        --since \u003Cpre-incident timestamp>\n        │        --save                                      # was a manual edit involved?\n        │\n        ├──► Cluster-level capture:\n        │      cub-scout bundle --since 4h                   # debug-bundle archive (replay-able)\n        │      cub-scout snapshot                            # GSF JSON snapshot (offline)\n        │      cub-scout audit list --since 4h               # ConfigHub audit entries\n        │\n        ├──► (multi-stage) Chain the receipts:\n        │      # Stage 1: pre-incident receipt\n        │      cub-scout receipt verify \u003Cr> ... --out stage1.receipt.json\n        │      # Stage 2: at-incident receipt, chained to stage 1\n        │      cub-scout receipt verify \u003Cr> ... \\\n        │        --input-attestation stage1.receipt.json \\\n        │        --out stage2.receipt.json\n        │      # Stage 3: post-resolution receipt, chained to stage 2\n        │      cub-scout receipt verify \u003Cr> ... \\\n        │        --input-attestation stage2.receipt.json \\\n        │        --out stage3.receipt.json\n        │\n        └──► (optional) cub-scout receipt list --format json > incident-receipt-inventory.json\n        │\n        ▼\n   Pilot's evidence pack + verdict:\n        │\n        │  evidence_pack = {\n        │    incident_id: \"incident-2026-05-22-001\",\n        │    verdict: \u003Cmax-severity over all receipts>,\n        │    timeline: [\n        │      {stage: \"pre\", receipt: \"stage1.receipt.json\"},\n        │      {stage: \"at\", receipt: \"stage2.receipt.json\"},\n        │      {stage: \"post\", receipt: \"stage3.receipt.json\"}\n        │    ],\n        │    bundle: \"incident-bundle.tar.gz\",\n        │    snapshot: \"incident-snapshot.json\",\n        │    audit_entries: [...],\n        │    next_step: \"\u003CPilot's recommendation, e.g., open Git PR to remove kubectl-edit access>\"\n        │  }\n        │\n        ▼\n   downstream consumer (postmortem \u002F audit \u002F compliance) reads the pack\n        └────────────────────────────────────────────────────\n```\n\n## The four-tier evidence shape\n\nPilot's incident pack composes four tiers of cub-scout evidence, in increasing audit durability:\n\n| Tier | Verb | Durability | Shape |\n|------|------|------------|-------|\n| **1. Ephemeral** | `compare three-way`, `explain`, `trace`, `history` | One-shot JSON; valid at this moment | Live evidence — the cluster state at incident close-out |\n| **2. Bundle snapshot** | `bundle`, `snapshot` | Tar \u002F JSON archive replay-able offline | Cluster-wide state freeze; survives the cluster being rolled |\n| **3. Fingerprinted receipt** | `receipt verify --save` | Immutable per-resource artifact; SHA-256 fingerprint over RFC 8785 canonical JSON | Typed evidence; verdict per predicate; verifiable later via `receipt validate` |\n| **4. Chained receipts** | `receipt verify --input-attestation \u003Cprior>` | Per-stage receipts linked by `inputAttestations[]`; each ref's fingerprint verified at chain construction | Multi-stage incident timeline as a tamper-evident DAG |\n\nPilot uses tier-1 + tier-2 for the narrative; tier-3 + tier-4 for the **immutable** part of the pack. The chained-receipts tier is what makes a multi-stage incident's evidence trustworthy: tampering with any upstream receipt invalidates every downstream receipt's fingerprint.\n\n## Step-by-step\n\n### Step 1 — define scope and timeline\n\n- What resources were involved? (`deploy\u002Fpayments-api`, maybe `deploy\u002Fpayments-worker`, the upstream `service\u002Fpayments`)\n- What time window? (incident fired 14:00, resolved 16:00; capture from 13:00 to 16:30 to cover pre-and-post state)\n- Was there a **deploy** during the window? a **manual edit**? a **controller reconciliation flap**?\n\n### Step 2 — resource-level evidence (per affected resource)\n\n```bash\n# Owner + lineage\n$ cub-scout trace deploy\u002Fpayments-api -n prod --format json > payments-api-trace.json\n$ cub-scout explain deploy\u002Fpayments-api -n prod --presentation ai > payments-api-explain.txt\n\n# DRY\u002FWET\u002FLIVE + per-field attribution\n$ cub-scout compare three-way deploy\u002Fpayments-api -n prod --format json > payments-api-3way.json\n\n# ChangeSet timeline\n$ cub-scout history deploy\u002Fpayments-api -n prod --since 4h --format json > payments-api-history.json\n\n# Manual-edits check\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --predicate no-manual-edits-since \\\n    --since 2026-05-22T13:00:00Z \\\n    --save \\\n    --out payments-api-manual-edits.receipt.json\n```\n\nThe four outputs together answer: who owns it, how is it diverging now, what changed recently, and was a kubectl-* writer involved.\n\n### Step 3 — cluster-level capture (offline-replay-able)\n\n```bash\n$ cub-scout bundle --since 4h > incident-bundle.tar.gz\n$ cub-scout snapshot > incident-snapshot.json\n$ cub-scout audit list --since 4h --format json > incident-audit.json\n```\n\nThe bundle archives enough cluster state to replay offline (`cub-scout bundle replay` later). The snapshot is GSF JSON for tooling. `audit list` collects connected-mode ConfigHub audit entries.\n\n### Step 4 — multi-stage chained receipts (the load-bearing piece)\n\nFor a multi-stage incident (e.g., deploy at 13:50 → drift at 14:00 → revert at 15:30), capture per-stage receipts and chain them:\n\n```bash\n# Stage 1: pre-incident baseline\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --at-commit \u003Cpre-incident-sha> \\\n    --save \\\n    --out incident\u002Fstage1-pre.receipt.json\n\n# Stage 2: at peak (during the incident)\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --input-attestation incident\u002Fstage1-pre.receipt.json \\\n    --save \\\n    --out incident\u002Fstage2-at.receipt.json\n\n# Stage 3: post-resolution\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --input-attestation incident\u002Fstage2-at.receipt.json \\\n    --save \\\n    --out incident\u002Fstage3-post.receipt.json\n```\n\nThe chain forms a tamper-evident DAG: `stage3` references `stage2` references `stage1`, and each parent's fingerprint is verified at chain construction time. Tampering with `stage1.receipt.json` after the fact would refuse to chain into `stage2` — chain construction errors out upfront rather than silently propagating bad evidence.\n\nThe verify step inside `cub-scout receipt verify --input-attestation` is enforced **at the API boundary** via the `VerifiedAttestationRef` typed wrapper (#463 Codex round-6 P1 fix). Programmatic callers cannot bypass the verify step; the chain integrity property is locked in code.\n\n### Step 5 — Pilot's verdict synthesis\n\nPilot's verdict for the incident pack is **max-severity over the chained receipts**. Note that receipt verdicts are the four-valued enum `PASS \u002F WATCH \u002F BLOCK \u002F INCONCLUSIVE` (per `pkg\u002Fagent\u002Freceipt.go:179-192`); `ASK` is a source-truth `status` value (mapped to receipt `WATCH` when wrapped, per `pkg\u002Fagent\u002Freceipt_predicates.go:396-407`) and is NOT a receipt verdict. Pilot's *incident* verdict can be ASK, but it's derived from `INCONCLUSIVE` receipts, not from an ASK receipt verdict:\n\n| Stage receipts' verdicts | Pilot's incident verdict |\n|--------------------------|--------------------------|\n| All PASS | **PASS** (no incident; close as no-op) |\n| At least one WATCH, rest PASS | **WATCH** (close with a flag) |\n| At least one INCONCLUSIVE | **ASK** (postmortem owners need to fill proof gaps surfaced as receipt omissions) |\n| Any BLOCK | **BLOCK** (real incident; write a postmortem) |\n\nThe chained shape encodes the timeline: PASS → BLOCK → PASS reads as \"we had a manual-edit episode that we recovered from\"; PASS → BLOCK → BLOCK reads as \"we never recovered intent; the live state is still divergent.\"\n\n### Step 6 — assemble the pack for downstream consumption\n\n```json\n{\n  \"incident_id\": \"incident-2026-05-22-001\",\n  \"scope\": \"Deployment\u002Fpayments-api in prod\",\n  \"window\": \"13:00–16:30\",\n  \"verdict\": \"BLOCK\",\n  \"timeline\": [\n    {\"stage\": \"pre\",  \"at\": \"13:00\", \"receipt\": \"stage1-pre.receipt.json\",  \"verdict\": \"PASS\"},\n    {\"stage\": \"at\",   \"at\": \"14:00\", \"receipt\": \"stage2-at.receipt.json\",   \"verdict\": \"BLOCK\"},\n    {\"stage\": \"post\", \"at\": \"16:30\", \"receipt\": \"stage3-post.receipt.json\", \"verdict\": \"PASS\"}\n  ],\n  \"bundle\": \"incident-bundle.tar.gz\",\n  \"snapshot\": \"incident-snapshot.json\",\n  \"audit_entries\": \"incident-audit.json\",\n  \"narrative\": \"explain + trace + 3way outputs (txt + json)\",\n  \"root_cause_hypothesis\": \"manual-edit on image during pager-active triage (kubectl-edit; verified manager string)\",\n  \"recommendation\": \"open Git PR amending apps\u002Fprod\u002Fpayments-api\u002Fdeployment.yaml; remove ad-hoc kubectl-edit access from on-call IAM\"\n}\n```\n\nThe downstream consumer (postmortem author, audit reviewer) reads the verdict + the chained timeline + the cluster-state artifacts. Every receipt is fingerprint-verifiable; `cub-scout receipt validate` exit-coded for CI.\n\n## Worked example\n\nIncident `incident-2026-05-22-001`: `deploy\u002Fpayments-api` in prod fired SEV-2 at 14:00. Resolved by 16:00. Pilot is rendering the close-out pack.\n\n```bash\n# Pre-incident baseline (the controller said this was good at 13:00)\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --at-commit 9e7d12fa \\\n    --save \\\n    --out incident\u002Fstage1-pre.receipt.json\n# verdict: PASS, fingerprint: sha256:abc...\n\n# At incident peak (14:00)\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --input-attestation incident\u002Fstage1-pre.receipt.json \\\n    --save \\\n    --out incident\u002Fstage2-at.receipt.json\n# verdict: BLOCK, evidence shows manual-edit on container image; fingerprint: sha256:def...\n\n# Post-resolution (16:30)\n$ cub-scout receipt verify deploy\u002Fpayments-api -n prod \\\n    --strategy git-argo \\\n    --input-attestation incident\u002Fstage2-at.receipt.json \\\n    --save \\\n    --out incident\u002Fstage3-post.receipt.json\n# verdict: PASS, the post-resolution Git revision matches LIVE; fingerprint: sha256:789...\n\n# Bundle + snapshot for offline replay\n$ cub-scout bundle --since 4h > incident\u002Fbundle.tar.gz\n$ cub-scout snapshot > incident\u002Fsnapshot.json\n\n# Connected-mode timeline\n$ cub-scout history deploy\u002Fpayments-api -n prod --since 4h --format json > incident\u002Fhistory.json\n$ cub-scout audit list --since 4h --format json > incident\u002Faudit.json\n\n# Receipt inventory for the incident namespace\n$ cub-scout receipt list --format json > incident\u002Freceipt-inventory.json\n```\n\nPilot's verdict pack (rendered as JSON for the audit ticket):\n\n```json\n{\n  \"incident_id\": \"incident-2026-05-22-001\",\n  \"verdict\": \"BLOCK\",\n  \"scope\": \"Deployment\u002Fpayments-api in prod\",\n  \"window\": \"13:00–16:30\",\n  \"chain\": [\"stage1-pre\", \"stage2-at\", \"stage3-post\"],\n  \"verdict_per_stage\": [\"PASS\", \"BLOCK\", \"PASS\"],\n  \"root_cause\": \"manual-edit on container image during pager triage\",\n  \"verified_manager\": \"kubectl-edit\",\n  \"recovered_at\": \"16:00\",\n  \"evidence_paths\": {\n    \"receipts\": \"incident\u002Fstage{1,2,3}-*.receipt.json\",\n    \"bundle\": \"incident\u002Fbundle.tar.gz\",\n    \"snapshot\": \"incident\u002Fsnapshot.json\",\n    \"history\": \"incident\u002Fhistory.json\",\n    \"audit\": \"incident\u002Faudit.json\"\n  },\n  \"recommended_follow_ups\": [\n    \"Open Git PR codifying the image bump as intent\",\n    \"Review on-call IAM (remove kubectl-edit on prod deployments)\",\n    \"Open issue against #449 — investigate whether watch alert fired pre-pager\"\n  ]\n}\n```\n\nThe audit ticket gets the verdict + the chained-receipts manifest. Six months later, an auditor can:\n\n```bash\n$ cub-scout receipt validate incident\u002Fstage1-pre.receipt.json   # exit 0 — fingerprint intact\n$ cub-scout receipt validate incident\u002Fstage2-at.receipt.json    # exit 0 — fingerprint intact\n$ cub-scout receipt validate incident\u002Fstage3-post.receipt.json  # exit 0 — fingerprint intact\n$ cub-scout receipt show incident\u002Fstage2-at.receipt.json --format ascii\n# Same evidence Pilot rendered the verdict from; tamper-evident.\n```\n\nIf any of the receipts had been tampered with between then and now, `receipt validate` would exit 1 — the audit would immediately know the chain was untrustworthy.\n\n## Standalone vs connected\n\nMost of this skill works in **both modes**:\n\n- Standalone: tier-1 + tier-2 + tier-3 (with `--predicate applied-matches-spec` and `--predicate no-manual-edits-since`); chained receipts work. Receipts will carry an `OmissionConfigHubUnitSubject` entry.\n- Connected: adds `--strategy source-truth-pass` (tier-3 quality boost), `cub-scout audit list`, `cub-scout history`, `bindingSource` in attribution. Recommended for production incident packs.\n\nPilot should run `cub-scout status` in the pack-assembly preamble; if standalone, Pilot's pack records the limitation explicitly (the receipts themselves already record it via omissions).\n\n## Tool boundary\n\n- **Allowed (cub-scout):** `trace`, `explain`, all Compare verbs, `doctor`, `bundle`, `history`, `audit`, `receipt verify` \u002F `show` \u002F `validate` \u002F `list`, `snapshot`, `map`. All read-only.\n- **Allowed (cluster):** `kubectl get\u002Fdescribe`, `kubectl get events`, `kubectl logs`. NOT `kubectl apply \u002F edit \u002F patch \u002F delete` \u002F `rollout undo`.\n- **Allowed (ConfigHub):** `cub \u003Centity> get \u002F list` for the entities named in allowed-tools. NOT `cub * create \u002F update \u002F delete`.\n- **Allowed (controllers):** `argocd app get`, `flux get`. NOT `argocd app sync`, `flux reconcile`.\n- **Pilot's recommendation** (\"open a Git PR\", \"remove kubectl-edit access\") is **a recommendation only**. cub-scout doesn't implement the recommendation; Pilot's mutation path is `cub` \u002F Argo \u002F kubectl. This skill produces evidence and a verdict, not a remediation.\n\n## References\n\n- [`operator-incident-evidence`](..\u002Foperator-incident-evidence\u002FSKILL.md) — operator-driven counterpart (SRE writing their own postmortem)\n- [`scout-verify`](..\u002Fscout-verify\u002FSKILL.md) — receipts + chained `--input-attestation`\n- [`scout-observe`](..\u002Fscout-observe\u002FSKILL.md) — `bundle`, `snapshot`, `watch` (the source of replay-able evidence)\n- [`scout-attribute`](..\u002Fscout-attribute\u002FSKILL.md) — `cause` \u002F `managerHint` \u002F `gitSource` per field\n- [`pilot-patch-and-drift`](..\u002Fpilot-patch-and-drift\u002FSKILL.md) — drift-classification companion (per-field, not per-incident)\n- [`pilot-watch-alert-response`](..\u002Fpilot-watch-alert-response\u002FSKILL.md) — real-time companion (the events that may have fired during the incident; this skill replays them in the bundle)\n- [`pilot-cd-gate`](..\u002Fpilot-cd-gate\u002FSKILL.md) — what should have caught the incident pre-deploy (postmortem may recommend tightening this)\n- Chained receipts: `#448` (issue), `#463` (chained-half shipped); `VerifiedAttestationRef` typed wrapper enforces verify at API boundary\n- in-toto Statement v1, RFC 8785 canonical JSON, SHA-256 fingerprint: [`docs\u002Freference\u002Fjson-contracts.md`](..\u002F..\u002Fdocs\u002Freference\u002Fjson-contracts.md) § Receipt Contract\n\n## Constraints\n\n- The incident pack's **immutability** depends on the receipt store's `O_EXCL` atomic file create (cub-scout side). The store at `$XDG_DATA_HOME\u002Fcub-scout\u002Freceipts` is per-host; Pilot should archive receipts to a durable store (S3, ConfigHub bundle catalog) for long-term audit retention.\n- Chained receipts ONLY verify chain integrity at construction time — `cub-scout receipt validate` checks one receipt's fingerprint; verifying a multi-stage chain requires walking each `inputAttestations[]` entry and validating it independently. A future helper may automate this; today it's a manual loop.\n- `--input-attestation` requires the **upstream receipt to be a valid in-toto Statement v1 envelope with a verifiable fingerprint**. Tampered upstreams refuse to chain at the verify-time API boundary (`VerifiedAttestationRef` typed wrapper); Pilot must capture pristine receipts at each stage.\n- `bundle` archives can be large for high-resource clusters. Pilot may want to scope `bundle --namespace \u003Cns>` to the affected namespace rather than the whole cluster.\n- The verdict is **per-incident**, not per-resource. A multi-resource incident produces N chains, and Pilot's incident-level verdict is the max-severity over all chains.\n",{"name":5,"phase":57,"description":7,"allowed-tools":58},"cross-cutting","Bash(.\u002Fcub-scout trace *) Bash(cub-scout trace *) Bash(cub scout trace *) Bash(.\u002Fcub-scout explain *) Bash(cub-scout explain *) Bash(cub scout explain *) Bash(.\u002Fcub-scout compare three-way *) Bash(cub-scout compare three-way *) Bash(cub scout compare three-way *) Bash(.\u002Fcub-scout compare drift *) Bash(cub-scout compare drift *) Bash(cub scout compare drift *) Bash(.\u002Fcub-scout compare source-truth *) Bash(cub-scout compare source-truth *) Bash(cub scout compare source-truth *) Bash(.\u002Fcub-scout doctor *) Bash(cub-scout doctor *) Bash(cub scout doctor *) Bash(.\u002Fcub-scout bundle diff *) Bash(.\u002Fcub-scout bundle inspect *) Bash(.\u002Fcub-scout bundle summarize *) Bash(.\u002Fcub-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(.\u002Fcub-scout history *) Bash(cub-scout history *) Bash(cub scout history *) Bash(.\u002Fcub-scout audit *) Bash(cub-scout audit *) Bash(cub scout audit *) Bash(.\u002Fcub-scout receipt verify *) Bash(cub-scout receipt verify *) Bash(cub scout receipt verify *) Bash(.\u002Fcub-scout receipt show *) Bash(cub-scout receipt show *) Bash(cub scout receipt show *) Bash(.\u002Fcub-scout receipt list *) Bash(cub-scout receipt list *) Bash(cub scout receipt list *) Bash(.\u002Fcub-scout receipt validate *) Bash(cub-scout receipt validate *) Bash(cub scout receipt validate *) Bash(.\u002Fcub-scout snapshot *) Bash(cub-scout snapshot *) Bash(cub scout snapshot *) 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(kubectl get *) Bash(kubectl describe *) Bash(kubectl get events *) Bash(kubectl logs *) 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(argocd app get *) Bash(flux get *)","main","261862e7ec5e5c93ce377ccfd6b583f5ac03c95c","skills\u002Fpilot-incident-evidence",1,"https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout","https:\u002F\u002Fconfighub.com","https:\u002F\u002Fgithub.com\u002Fconfighub","http:\u002F\u002Fwww.confighub.com","Public repo for ConfigHub","2026-11-14 03:24:15",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add confighub\u002Fcub-scout --skill pilot-incident-evidence",{"tool":75,"command":76},"bunx","bunx skills add confighub\u002Fcub-scout --skill pilot-incident-evidence",{"tool":78,"command":79},"pnpm","pnpm dlx skills add confighub\u002Fcub-scout --skill pilot-incident-evidence","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fpilot-incident-evidence\u002FSKILL.md",true,[83],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"agents\u002Fopenai.yaml","REFERENCE","参考文档",131,"https:\u002F\u002Fgithub.com\u002Fmalinskibeniamin\u002Fskills\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fdependency-maintenance\u002Fagents\u002Fopenai.yaml",[90,123,144,164,188,209],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":101,"publishedAt":52},"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",[96],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[102,36,103,104,105,50,47,106,107,108,42,109,110,111,112,113,114,115,23,116,117,118,119,26,120,121,122],"triage","triage unhealthy workload","kubernetes","diagnose","ci","payments","api","loop","explain","check","broken","question","use","rollout","cub scout","route","drift","map","get","now","when",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":130,"publishedAt":52},"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",[129],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},[131,132,133,104,134,135,106,44,136,108,137,42,138,40,139,140,141,114,23,19,116,25,117,142,120,30,32,143,122],"verify","scout verify","scout","acceptance","produce","provenance","show me","postmortem","argocd","view","fix","me","managed",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":52},"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",[],[151,152,133,153,104,105,154,50,47,155,136,156,137,42,112,114,157,23,158,159,116,25,160,161,119,120,162,163,122],"observe","scout observe","bot","deployment","risk","inventory","version","only","hooks","back","health-check","resources","meaning",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":173,"publishedAt":52},"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",[170],{"categoryNo":171,"categoryName":172,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000023","Skill与智能体开发",[174,175,133,153,176,177,178,179,180,51,181,182,42,183,40,184,38,158,185,186,151,120,32,187,122],"MCP","scout mcp","mcp server","ai agent","auth","config","run","server","SET","model","read","ready","up","agent-context",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":52},"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",[],[195,196,133,104,105,51,197,135,198,182,156,199,137,42,40,200,113,184,201,140,114,158,151,116,25,202,203,204,29,30,32,205,206,207,208],"ingest","scout ingest","state","adoption","discovery","repo","write","structure","aggregator","adopt","reading","exported","invoke","parse",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":52},"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",[],[216,133,217,178,218,219,49,156,131,137,42,41,40,140,220,114,221,222,223,151,116,25,224,120,22,225,32,226,227,34,35,122],"scout govern","change","governance","blast radius","catalog","diff","say","snapshots","project","impact","render","blast-radius"]