[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CBKPVNP9FNZSRRNSK7MEHF":3,"skill-same:01M6CBKPVNP9FNZSRRNSK7MEHF":90},{"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":53,"linkOnly":54,"markdownContent":55,"markdownBody":56,"frontMatter":57,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":68,"updatedAt":69,"install":70,"resources":83},"01M6CBKPVNP9FNZSRRNSK7MEHF","observe-helm",null,"Use when the user wants to observe HELM-managed resources specifically — the controller-specific observer skill for Helm. The key complication: there are three ways a resource can \"be Helm\" — direct `helm install\u002Fupgrade`, Flux helm-controller delivering a HelmRelease, and Argo CD rendering Helm charts as an Application source. This skill teaches the disambiguation matrix. Natural phrasing: \"is this a Helm release?\", \"which Helm chart produced this deployment?\", \"is this Helm-via-Flux or direct Helm or Argo-as-Helm-renderer?\", \"what does `app.kubernetes.io\u002Fmanaged-by: Helm` mean here?\", \"trace this Helm release back to source\". Do NOT load for: Flux-specifically (use observe-flux for the Kustomization side), Argo-specifically (use observe-argocd), generic ownership (use scout-observe), authoring Helm charts.","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\u002Fobserve-helm\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],"observe","observe helm","helm","chart","show","back","upgrade","map","get","app","when","io","resources","hr","helm charts","which","managed","kubernetes","cub scout","use","install","list","argocd","history","direct","explain","Bash","Charts","controller","kubectl","doctor","release","deployment","status","2026-11-10 10:12:30",false,"---\nname: observe-helm\ndescription: 'Use when the user wants to observe HELM-managed resources specifically — the controller-specific observer skill for Helm. The key complication: there are three ways a resource can \"be Helm\" — direct `helm install\u002Fupgrade`, Flux helm-controller delivering a HelmRelease, and Argo CD rendering Helm charts as an Application source. This skill teaches the disambiguation matrix. Natural phrasing: \"is this a Helm release?\", \"which Helm chart produced this deployment?\", \"is this Helm-via-Flux or direct Helm or Argo-as-Helm-renderer?\", \"what does `app.kubernetes.io\u002Fmanaged-by: Helm` mean here?\", \"trace this Helm release back to source\". Do NOT load for: Flux-specifically (use observe-flux for the Kustomization side), Argo-specifically (use observe-argocd), generic ownership (use scout-observe), authoring Helm charts.'\nphase: cross-cutting\nallowed-tools: Bash(.\u002Fcub-scout doctor *) Bash(cub-scout doctor *) Bash(cub scout doctor *) Bash(.\u002Fcub-scout explain *) Bash(cub-scout explain *) Bash(cub scout explain *) Bash(.\u002Fcub-scout trace *) Bash(cub-scout trace *) Bash(cub scout trace *) 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 --show-managed-fields *) Bash(helm list *) Bash(helm get *) Bash(helm status *) Bash(helm history *) Bash(flux get hr *) Bash(argocd app get *)\n---\n\n# observe-helm\n\nThe controller-specific observer skill for **Helm**. The complication: \"Helm-managed\" can mean three different things depending on who wrote `app.kubernetes.io\u002Fmanaged-by: Helm`. This skill teaches the disambiguation matrix and the manager-string co-signal that resolves it.\n\nVerified against `pkg\u002Fagent\u002Fownership.go` `detectHelmOwnership` and `pkg\u002Fagent\u002Fmanager_strings.go` `ManagerHelm`.\n\n## When to use\n\n- \"Is this a Helm release?\"\n- \"Which Helm chart produced deploy\u002Fapi?\"\n- \"Is this Helm-via-Flux, direct Helm, or Argo-as-Helm-renderer?\"\n- \"What does the `app.kubernetes.io\u002Fmanaged-by: Helm` label actually mean here?\"\n- \"Trace this Helm release back to its chart + source\"\n\n## Do not load for\n\n- Flux specifically (Kustomization side, source-controller, the rest of Flux) — [`observe-flux`](..\u002Fobserve-flux\u002FSKILL.md)\n- Argo CD Applications (even when the source is a Helm chart, Argo writes are Argo writes) — [`observe-argocd`](..\u002Fobserve-argocd\u002FSKILL.md)\n- Generic ownership detection — [`scout-observe`](..\u002Fscout-observe\u002FSKILL.md)\n- Authoring Helm charts \u002F writing values.yaml — out of cub-scout scope\n\n## Detection signals (in `detectHelmOwnership`)\n\ncub-scout classifies a resource as Helm-owned when either of two label families is present:\n\n| Signal | Source | SubType | Confidence | Resulting Name |\n|--------|--------|---------|-----------|----------------|\n| `app.kubernetes.io\u002Fmanaged-by: Helm` label | label | `release` | high | Value of `app.kubernetes.io\u002Finstance` |\n| `helm.sh\u002Fchart` label | label | `release` | high | Value of `app.kubernetes.io\u002Finstance` (falls back to chart name) |\n\nBoth are written by Helm v3's default release labels. Pre-v3 Helm charts wrote `helm.sh\u002Fchart` only; v3+ writes both.\n\n## The three-ways-to-be-Helm disambiguation matrix\n\nThis is the unique value of this skill. Same labels appear in all three cases; the **manager string** in `metadata.managedFields` distinguishes them.\n\n| Scenario | `managed-by` label | Manager string in `managedFields` | cub-scout classification |\n|----------|--------------------|-----------------------------------|--------------------------|\n| Direct `helm install\u002Fupgrade` (a human or CI ran the CLI) | `Helm` | `helm` (bare; the default `kube.ManagedFieldsManager` from `helm\u002Fhelm`) | `OwnerHelm` + controller manager is `helm` |\n| Flux helm-controller (HelmRelease CRD) | `Helm` (Helm v3 sets it even when called via the library) | `helm-controller` | `OwnerFlux` `SubType=helmrelease` (Flux labels take detection priority over Helm); controller co-signal is `helm-controller` |\n| Argo CD Application sourcing a Helm chart | `Helm` (Argo renders Helm and applies the result) | `argocd-controller` or `kubectl-client-side-apply` | `OwnerArgo` `SubType=application` (Argo labels take detection priority); controller co-signal is `argocd-controller` |\n\ncub-scout's ownership detector runs in priority order — **Flux first, then Argo, then Helm**. So a HelmRelease-managed resource is `OwnerFlux`, not `OwnerHelm`. A pure direct-Helm resource is `OwnerHelm` because nothing else claimed it first.\n\nThe `ManagerHelm = \"helm\"` constant in `manager_strings.go` denotes the **bare** Helm CLI invocation, which is what you see in scenario 1 only. Third-party embedders (Flux helm-controller, terraform-provider-helm) override the field-manager identity with their own name.\n\n## Manager strings\n\n| Manager | Source | Meaning |\n|---------|--------|---------|\n| `helm` | upstream `helm\u002Fhelm` `kube.ManagedFieldsManager` default (`filepath.Base(os.Args[0])`) | Direct `helm install` \u002F `helm upgrade` invocation. |\n\nThat's it — the bare `helm` string is the only one cub-scout treats as a \"Helm controller\" writer. Anything else writing Helm-labelled resources is some OTHER controller using the Helm library, and its identity is in *its* manager string (`helm-controller`, `argocd-controller`, etc.).\n\n`controllerManagersForOwner(OwnerHelm, ...)` returns just `{ManagerHelm}` — the narrow match.\n\n## Worked example\n\n```bash\n# Direct helm install\n$ kubectl get deploy api -n prod -o yaml | yq '.metadata.labels, .metadata.managedFields[].manager'\nlabels:\n  app.kubernetes.io\u002Fmanaged-by: Helm\n  app.kubernetes.io\u002Finstance: payments-api\n  helm.sh\u002Fchart: payments-api-1.2.3\nmanagers:\n  - helm\n```\n\ncub-scout reads this as `OwnerHelm` `release=payments-api`. A subsequent `kubectl edit` adds a `kubectl-edit` manager → drift cause is `manual-edit`.\n\n```bash\n# Flux helm-controller\n$ kubectl get deploy api -n prod -o yaml | yq '.metadata.labels, .metadata.managedFields[].manager'\nlabels:\n  app.kubernetes.io\u002Fmanaged-by: Helm\n  app.kubernetes.io\u002Finstance: payments-api\n  helm.sh\u002Fchart: payments-api-1.2.3\n  helm.toolkit.fluxcd.io\u002Fname: payments-api          # ← Flux label wins\n  helm.toolkit.fluxcd.io\u002Fnamespace: flux-system\nmanagers:\n  - helm-controller\n```\n\ncub-scout reads this as `OwnerFlux` `helmrelease=payments-api in flux-system`. The Helm labels are still there but the Flux label takes priority. The controller co-signal is `helm-controller`, not bare `helm`.\n\n```bash\n# Argo CD as Helm renderer\n$ kubectl get deploy api -n prod -o yaml | yq '.metadata.labels, .metadata.managedFields[].manager'\nlabels:\n  app.kubernetes.io\u002Fmanaged-by: Helm\n  app.kubernetes.io\u002Finstance: payments-api          # Helm chart's instance label\n  argocd.argoproj.io\u002Finstance: payments-app          # ← Argo label\n  helm.sh\u002Fchart: payments-api-1.2.3\nmanagers:\n  - argocd-controller\n```\n\ncub-scout reads this as `OwnerArgo` `application=payments-app`. Argo rendered the Helm chart and applied the result; the `managed-by: Helm` label is an artifact of the chart, not evidence of who's reconciling.\n\n## Edge cases\n\n- **No instance label**: `app.kubernetes.io\u002Fmanaged-by: Helm` without `app.kubernetes.io\u002Finstance` produces `OwnerHelm` with an empty `Name`. cub-scout falls back to the `helm.sh\u002Fchart` label value when available.\n- **Legacy charts**: Pre-v3 Helm wrote only `helm.sh\u002Fchart`. cub-scout's second detector branch handles this — produces `OwnerHelm` with `Name` from `app.kubernetes.io\u002Finstance` or, if that's also missing, from the chart name itself.\n- **Argo as Helm renderer for ConfigHub**: When ConfigHub renders a unit through Argo with a Helm source, the resource has `confighub.com\u002FUnitSlug` + Argo labels + Helm labels. ConfigHub detection runs first → `OwnerConfigHub`. See [`observe-confighub-managed`](..\u002Fobserve-confighub-managed\u002FSKILL.md).\n- **`terraform-provider-helm`**: Writes its own manager identity (`terraform-provider-helm`), so resources installed through it look like Helm-labelled with a TF-attributable manager. cub-scout's verified manager enumeration does NOT include this string — falls through to `cause=unknown`, parse-don't-guess.\n- **`source-truth-pass` predicate caveat**: The `helm-flux` and `helm-argo` strategies emit a `runtime.helm_chart_anchor` proof gap because the runtime chart-version extractor isn't fully wired (Phase 2 of #409). The strategy still produces a verdict; the gap is recorded in `omissions[]`.\n\n## References\n\n- Code: `pkg\u002Fagent\u002Fownership.go` `detectHelmOwnership`, `pkg\u002Fagent\u002Fmanager_strings.go` `ManagerHelm`\n- Upstream:\n  - Helm field-manager default: [`helm\u002Fhelm` `kube.ManagedFieldsManager`](https:\u002F\u002Fgithub.com\u002Fhelm\u002Fhelm) — `filepath.Base(os.Args[0])`\n  - Helm v3 labels: [Helm chart best practices — Labels and Annotations](https:\u002F\u002Fhelm.sh\u002Fdocs\u002Fchart_best_practices\u002Flabels\u002F)\n- Related skills: [`observe-flux`](..\u002Fobserve-flux\u002FSKILL.md), [`observe-argocd`](..\u002Fobserve-argocd\u002FSKILL.md), [`scout-attribute`](..\u002Fscout-attribute\u002FSKILL.md), [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md) (the `helm-*` strategies)\n\n## Constraints\n\n- This skill is read-only. `helm install`, `helm upgrade`, `helm rollback`, `helm uninstall` are mutations and NOT in allowed-tools; route to the user driving the `helm` CLI.\n- The disambiguation matrix is **the** value here. Don't conflate Helm-via-Flux with direct Helm — the operator response is completely different (revert via Flux reconcile vs. helm rollback).\n- `app.kubernetes.io\u002Fmanaged-by: Helm` is necessary but not sufficient to call something \"Helm-managed\" — always check the manager string and the Flux\u002FArgo label co-signals.\n","# observe-helm\n\nThe controller-specific observer skill for **Helm**. The complication: \"Helm-managed\" can mean three different things depending on who wrote `app.kubernetes.io\u002Fmanaged-by: Helm`. This skill teaches the disambiguation matrix and the manager-string co-signal that resolves it.\n\nVerified against `pkg\u002Fagent\u002Fownership.go` `detectHelmOwnership` and `pkg\u002Fagent\u002Fmanager_strings.go` `ManagerHelm`.\n\n## When to use\n\n- \"Is this a Helm release?\"\n- \"Which Helm chart produced deploy\u002Fapi?\"\n- \"Is this Helm-via-Flux, direct Helm, or Argo-as-Helm-renderer?\"\n- \"What does the `app.kubernetes.io\u002Fmanaged-by: Helm` label actually mean here?\"\n- \"Trace this Helm release back to its chart + source\"\n\n## Do not load for\n\n- Flux specifically (Kustomization side, source-controller, the rest of Flux) — [`observe-flux`](..\u002Fobserve-flux\u002FSKILL.md)\n- Argo CD Applications (even when the source is a Helm chart, Argo writes are Argo writes) — [`observe-argocd`](..\u002Fobserve-argocd\u002FSKILL.md)\n- Generic ownership detection — [`scout-observe`](..\u002Fscout-observe\u002FSKILL.md)\n- Authoring Helm charts \u002F writing values.yaml — out of cub-scout scope\n\n## Detection signals (in `detectHelmOwnership`)\n\ncub-scout classifies a resource as Helm-owned when either of two label families is present:\n\n| Signal | Source | SubType | Confidence | Resulting Name |\n|--------|--------|---------|-----------|----------------|\n| `app.kubernetes.io\u002Fmanaged-by: Helm` label | label | `release` | high | Value of `app.kubernetes.io\u002Finstance` |\n| `helm.sh\u002Fchart` label | label | `release` | high | Value of `app.kubernetes.io\u002Finstance` (falls back to chart name) |\n\nBoth are written by Helm v3's default release labels. Pre-v3 Helm charts wrote `helm.sh\u002Fchart` only; v3+ writes both.\n\n## The three-ways-to-be-Helm disambiguation matrix\n\nThis is the unique value of this skill. Same labels appear in all three cases; the **manager string** in `metadata.managedFields` distinguishes them.\n\n| Scenario | `managed-by` label | Manager string in `managedFields` | cub-scout classification |\n|----------|--------------------|-----------------------------------|--------------------------|\n| Direct `helm install\u002Fupgrade` (a human or CI ran the CLI) | `Helm` | `helm` (bare; the default `kube.ManagedFieldsManager` from `helm\u002Fhelm`) | `OwnerHelm` + controller manager is `helm` |\n| Flux helm-controller (HelmRelease CRD) | `Helm` (Helm v3 sets it even when called via the library) | `helm-controller` | `OwnerFlux` `SubType=helmrelease` (Flux labels take detection priority over Helm); controller co-signal is `helm-controller` |\n| Argo CD Application sourcing a Helm chart | `Helm` (Argo renders Helm and applies the result) | `argocd-controller` or `kubectl-client-side-apply` | `OwnerArgo` `SubType=application` (Argo labels take detection priority); controller co-signal is `argocd-controller` |\n\ncub-scout's ownership detector runs in priority order — **Flux first, then Argo, then Helm**. So a HelmRelease-managed resource is `OwnerFlux`, not `OwnerHelm`. A pure direct-Helm resource is `OwnerHelm` because nothing else claimed it first.\n\nThe `ManagerHelm = \"helm\"` constant in `manager_strings.go` denotes the **bare** Helm CLI invocation, which is what you see in scenario 1 only. Third-party embedders (Flux helm-controller, terraform-provider-helm) override the field-manager identity with their own name.\n\n## Manager strings\n\n| Manager | Source | Meaning |\n|---------|--------|---------|\n| `helm` | upstream `helm\u002Fhelm` `kube.ManagedFieldsManager` default (`filepath.Base(os.Args[0])`) | Direct `helm install` \u002F `helm upgrade` invocation. |\n\nThat's it — the bare `helm` string is the only one cub-scout treats as a \"Helm controller\" writer. Anything else writing Helm-labelled resources is some OTHER controller using the Helm library, and its identity is in *its* manager string (`helm-controller`, `argocd-controller`, etc.).\n\n`controllerManagersForOwner(OwnerHelm, ...)` returns just `{ManagerHelm}` — the narrow match.\n\n## Worked example\n\n```bash\n# Direct helm install\n$ kubectl get deploy api -n prod -o yaml | yq '.metadata.labels, .metadata.managedFields[].manager'\nlabels:\n  app.kubernetes.io\u002Fmanaged-by: Helm\n  app.kubernetes.io\u002Finstance: payments-api\n  helm.sh\u002Fchart: payments-api-1.2.3\nmanagers:\n  - helm\n```\n\ncub-scout reads this as `OwnerHelm` `release=payments-api`. A subsequent `kubectl edit` adds a `kubectl-edit` manager → drift cause is `manual-edit`.\n\n```bash\n# Flux helm-controller\n$ kubectl get deploy api -n prod -o yaml | yq '.metadata.labels, .metadata.managedFields[].manager'\nlabels:\n  app.kubernetes.io\u002Fmanaged-by: Helm\n  app.kubernetes.io\u002Finstance: payments-api\n  helm.sh\u002Fchart: payments-api-1.2.3\n  helm.toolkit.fluxcd.io\u002Fname: payments-api          # ← Flux label wins\n  helm.toolkit.fluxcd.io\u002Fnamespace: flux-system\nmanagers:\n  - helm-controller\n```\n\ncub-scout reads this as `OwnerFlux` `helmrelease=payments-api in flux-system`. The Helm labels are still there but the Flux label takes priority. The controller co-signal is `helm-controller`, not bare `helm`.\n\n```bash\n# Argo CD as Helm renderer\n$ kubectl get deploy api -n prod -o yaml | yq '.metadata.labels, .metadata.managedFields[].manager'\nlabels:\n  app.kubernetes.io\u002Fmanaged-by: Helm\n  app.kubernetes.io\u002Finstance: payments-api          # Helm chart's instance label\n  argocd.argoproj.io\u002Finstance: payments-app          # ← Argo label\n  helm.sh\u002Fchart: payments-api-1.2.3\nmanagers:\n  - argocd-controller\n```\n\ncub-scout reads this as `OwnerArgo` `application=payments-app`. Argo rendered the Helm chart and applied the result; the `managed-by: Helm` label is an artifact of the chart, not evidence of who's reconciling.\n\n## Edge cases\n\n- **No instance label**: `app.kubernetes.io\u002Fmanaged-by: Helm` without `app.kubernetes.io\u002Finstance` produces `OwnerHelm` with an empty `Name`. cub-scout falls back to the `helm.sh\u002Fchart` label value when available.\n- **Legacy charts**: Pre-v3 Helm wrote only `helm.sh\u002Fchart`. cub-scout's second detector branch handles this — produces `OwnerHelm` with `Name` from `app.kubernetes.io\u002Finstance` or, if that's also missing, from the chart name itself.\n- **Argo as Helm renderer for ConfigHub**: When ConfigHub renders a unit through Argo with a Helm source, the resource has `confighub.com\u002FUnitSlug` + Argo labels + Helm labels. ConfigHub detection runs first → `OwnerConfigHub`. See [`observe-confighub-managed`](..\u002Fobserve-confighub-managed\u002FSKILL.md).\n- **`terraform-provider-helm`**: Writes its own manager identity (`terraform-provider-helm`), so resources installed through it look like Helm-labelled with a TF-attributable manager. cub-scout's verified manager enumeration does NOT include this string — falls through to `cause=unknown`, parse-don't-guess.\n- **`source-truth-pass` predicate caveat**: The `helm-flux` and `helm-argo` strategies emit a `runtime.helm_chart_anchor` proof gap because the runtime chart-version extractor isn't fully wired (Phase 2 of #409). The strategy still produces a verdict; the gap is recorded in `omissions[]`.\n\n## References\n\n- Code: `pkg\u002Fagent\u002Fownership.go` `detectHelmOwnership`, `pkg\u002Fagent\u002Fmanager_strings.go` `ManagerHelm`\n- Upstream:\n  - Helm field-manager default: [`helm\u002Fhelm` `kube.ManagedFieldsManager`](https:\u002F\u002Fgithub.com\u002Fhelm\u002Fhelm) — `filepath.Base(os.Args[0])`\n  - Helm v3 labels: [Helm chart best practices — Labels and Annotations](https:\u002F\u002Fhelm.sh\u002Fdocs\u002Fchart_best_practices\u002Flabels\u002F)\n- Related skills: [`observe-flux`](..\u002Fobserve-flux\u002FSKILL.md), [`observe-argocd`](..\u002Fobserve-argocd\u002FSKILL.md), [`scout-attribute`](..\u002Fscout-attribute\u002FSKILL.md), [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md) (the `helm-*` strategies)\n\n## Constraints\n\n- This skill is read-only. `helm install`, `helm upgrade`, `helm rollback`, `helm uninstall` are mutations and NOT in allowed-tools; route to the user driving the `helm` CLI.\n- The disambiguation matrix is **the** value here. Don't conflate Helm-via-Flux with direct Helm — the operator response is completely different (revert via Flux reconcile vs. helm rollback).\n- `app.kubernetes.io\u002Fmanaged-by: Helm` is necessary but not sufficient to call something \"Helm-managed\" — always check the manager string and the Flux\u002FArgo label co-signals.\n",{"name":5,"phase":58,"description":7,"allowed-tools":59},"cross-cutting","Bash(.\u002Fcub-scout doctor *) Bash(cub-scout doctor *) Bash(cub scout doctor *) Bash(.\u002Fcub-scout explain *) Bash(cub-scout explain *) Bash(cub scout explain *) Bash(.\u002Fcub-scout trace *) Bash(cub-scout trace *) Bash(cub scout trace *) 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 --show-managed-fields *) Bash(helm list *) Bash(helm get *) Bash(helm status *) Bash(helm history *) Bash(flux get hr *) Bash(argocd app get *)","main","261862e7ec5e5c93ce377ccfd6b583f5ac03c95c","skills\u002Fobserve-helm",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":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add confighub\u002Fcub-scout --skill observe-helm",{"tool":76,"command":77},"bunx","bunx skills add confighub\u002Fcub-scout --skill observe-helm",{"tool":79,"command":80},"pnpm","pnpm dlx skills add confighub\u002Fcub-scout --skill observe-helm","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fobserve-helm\u002FSKILL.md",true,[84],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"agents\u002Fopenai.yaml","REFERENCE","参考文档",119,"https:\u002F\u002Fgithub.com\u002Fmalinskibeniamin\u002Fskills\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fci-fixes\u002Fagents\u002Fopenai.yaml",[91,121,144,160,185,207],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":102,"publishedAt":53},"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",[97],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[103,104,105,36,106,49,107,108,109,110,45,111,44,112,113,114,38,115,116,37,117,118,26,119,27,120,29],"triage","workload","triage unhealthy workload","diagnose","logs","ci","payments","api","loop","check","broken","question","rollout","never","route","drift","time","now",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":128,"publishedAt":53},"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",[127],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},[129,130,131,36,132,133,108,134,135,110,136,45,137,138,41,139,140,38,116,141,37,23,117,142,27,28,143,35,29],"verify","scout verify","scout","acceptance","produce","attestation","provenance","show me","postmortem","changeset","view","fix","evidence","me","unit",{"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":53},"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",[],[19,151,131,152,36,106,51,49,107,153,135,154,136,45,113,38,155,116,156,157,37,23,24,158,26,27,31,159,29],"scout observe","bot","risk","inventory","version","only","hooks","health-check","meaning",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":169,"publishedAt":53},"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",[166],{"categoryNo":167,"categoryName":168,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000023","Skill与智能体开发",[170,171,131,152,172,173,174,175,176,50,177,178,45,179,138,180,181,156,182,183,19,27,143,184,29],"MCP","scout mcp","mcp server","ai agent","auth","config","run","server","SET","model","read","snapshot","ready","up","agent-context",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":53},"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",[],[192,193,131,36,106,50,194,133,195,178,154,196,136,45,138,197,114,180,198,139,38,156,19,37,23,199,200,201,202,28,143,203,204,205,206],"ingest","scout ingest","state","adoption","discovery","repo","write","structure","aggregator","adopt","argo","reading","exported","invoke","parse",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":213,"publishedAt":53},"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",[],[214,131,215,174,216,217,218,154,129,136,45,42,138,139,219,38,220,221,222,19,37,23,223,27,224,225,143,226,227,34,228,29],"scout govern","change","governance","blast radius","audit","catalog","diff","say","snapshots","project","mutation","impact","render","blast-radius","inspect"]