[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CBNK6FS5QTDKCRMPT7NFW2":3,"skill-same:01M6CBNK6FS5QTDKCRMPT7NFW2":99},{"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":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":6,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6CBNK6FS5QTDKCRMPT7NFW2","prepare-for-confighub",null,"Use when the user is ADOPTING ConfigHub — they have existing live K8s + GitOps state (an existing cluster, live Argo ApplicationSets, Flux Kustomizations, or secondarily a git repo of manifests) and want to PREVIEW what a ConfigHub import would look like before committing. Natural phrasing: \"show me the proposed units before I apply\", \"I want to adopt ConfigHub for this app\", \"what would ConfigHub see in our cluster?\", \"what would ConfigHub see in our argocd setup?\", \"preview what would land in ConfigHub if I imported this repo\". Composes `cub-scout import --dry-run` + `import --git-path` + `import argocd` + `import cluster-aggregator` + `import parse-repo` + `app` for the **preview-only** flow. Do NOT load for: actually applying the proposal (that's `cub-scout import apply`, user-driven), live conformance audits (use audit-fleet-conformance), or comparing live to ConfigHub once units exist (use scout-compare). The whole skill is read-only and refuses to invoke `import apply`.","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\u002Fprepare-for-confighub\u002FSKILL.md",[],[19,9,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],"prepare","prepare for confighub","for","invoke","parse","manifests","unit","proposal","app","get","aggregator","map","preview","show","status","cub scout","when","only","use","view","read","repo","argocd","changeset","Bash","show me","flow","audit","state","git","release","run","2026-11-10 10:12:30",false,"---\nname: prepare-for-confighub\ndescription: 'Use when the user is ADOPTING ConfigHub — they have existing live K8s + GitOps state (an existing cluster, live Argo ApplicationSets, Flux Kustomizations, or secondarily a git repo of manifests) and want to PREVIEW what a ConfigHub import would look like before committing. Natural phrasing: \"show me the proposed units before I apply\", \"I want to adopt ConfigHub for this app\", \"what would ConfigHub see in our cluster?\", \"what would ConfigHub see in our argocd setup?\", \"preview what would land in ConfigHub if I imported this repo\". Composes `cub-scout import --dry-run` + `import --git-path` + `import argocd` + `import cluster-aggregator` + `import parse-repo` + `app` for the **preview-only** flow. Do NOT load for: actually applying the proposal (that''s `cub-scout import apply`, user-driven), live conformance audits (use audit-fleet-conformance), or comparing live to ConfigHub once units exist (use scout-compare). The whole skill is read-only and refuses to invoke `import apply`.'\nphase: cross-cutting\nallowed-tools: Bash(.\u002Fcub-scout import parse-repo *) Bash(cub-scout import parse-repo *) Bash(cub scout import parse-repo *) Bash(.\u002Fcub-scout import cluster-aggregator *) Bash(cub-scout import cluster-aggregator *) Bash(cub scout import cluster-aggregator *) Bash(.\u002Fcub-scout app list *) Bash(cub-scout app list *) Bash(cub scout app list *) Bash(.\u002Fcub-scout app list) Bash(cub-scout app list) Bash(cub scout app list) Bash(.\u002Fcub-scout map workloads *) Bash(cub-scout map workloads *) Bash(cub scout map workloads *) Bash(.\u002Fcub-scout scan *) Bash(cub-scout scan *) Bash(cub scout scan *) Bash(.\u002Fcub-scout status) Bash(cub-scout status) Bash(cub scout status) Bash(kubectl get *) Bash(kubectl describe *) 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(argocd appset get *) Bash(argocd appset list *) Bash(flux get *)\n---\n\n# prepare-for-confighub\n\nThe adoption-preview loop. The user has existing live K8s + GitOps state and wants to KNOW what a ConfigHub import would produce **before** committing. Start from the live cluster when possible; use local repo parsing only when the manifest repository itself is under review. This skill is the **preview** flow — every verb is read-only, and `import apply` (the mutating write) is **explicitly out of band**. The user runs that themselves after reviewing the proposal.\n\n## When to use\n\nExplicit phrasings:\n\n- \"Show me the proposed units before I apply\"\n- \"I want to adopt ConfigHub for this app — what would it look like?\"\n- \"What would ConfigHub see in this live cluster?\"\n- \"What would ConfigHub see in our Argo CD setup?\"\n- \"Preview what would land in ConfigHub if I imported this repo\"\n- \"Walk me through ConfigHub adoption for `payments-api`\"\n- \"Compare ApplicationSet generator import vs a raw `--git-path` import for this repo\"\n\nImplicit intents:\n\n- The user is **before** ConfigHub adoption, not in steady state\n- The user wants **reviewable** output, not a live mutation\n- The user is comparing options (\"what if I use ApplicationSet vs raw YAML import?\")\n- The user is gating on team-review or compliance approval before the actual write\n\n## Do not load for\n\n- Actually applying the proposal (`cub-scout import apply`) — that's user-driven, not in this skill's allowed-tools\n- Live conformance audits **once** units exist — [`audit-fleet-conformance`](..\u002Faudit-fleet-conformance\u002FSKILL.md)\n- Comparing live state to existing ConfigHub units — [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md) (specifically `compare three-way`)\n- The write into ConfigHub from rendered resources (`cub variant upload`) — that's `cub`, not cub-scout. Route to [`confighub\u002Fconfighub-skills`](https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fconfighub-skills).\n- Triage \u002F drift investigation — the corresponding workflow skills\n\n## The loop\n\n1. **Identify the source.** Where is the structure today? Live namespace (`import --dry-run -n \u003Cns>`)? Cluster Argo Applications (`import argocd`)? Multi-cluster snapshot (`import cluster-aggregator`)? Local git repo (`--git-path \u003Cdir>`)? Pick the verb.\n2. **Run the preview verb.** ASCII for review-by-eye; `--json` if the output feeds a PR-bot or a CI check.\n3. **Save a review artifact when needed.** `cub-scout import ... --json > proposal.json` gives reviewers a deterministic proposal without writing ConfigHub state.\n4. **Iterate.** Adjust the source structure (rename, regroup, split namespaces) until the proposal looks right. cub-scout doesn't change anything; you just re-run the preview.\n5. **Hand off the mutation.** Once the proposal is approved, the user runs `cub-scout import apply --space \u003Cs>` themselves. cub-scout's `prepare-for-confighub` skill **never** invokes apply.\n\n## Step-by-step\n\n### Step 1 — pick the source verb\n\n| Source | Verb | Notes |\n|--------|------|-------|\n| Live namespace or cluster | `cub-scout import --dry-run -n \u003Cnamespace> --json` | First adoption path. Reads current workloads, ownership, and labels before any write. |\n| Local git checkout | `cub-scout import --git-path \u003Crepo> --dry-run --json` | Advanced path. Classifies kustomize \u002F helm \u002F raw manifests; emits proposed slugs + spaces + targets without upload or render. |\n| Existing Argo Applications | `cub-scout import argocd --space \u003Cs>` | Reads Argo state from the cluster, proposes one ConfigHub unit per Application. Preserves ApplicationSet generator origin as hierarchy. |\n| Multi-cluster bundle | `cub-scout import cluster-aggregator --space \u003Cs>` | Aggregator-pattern. Aggregates per-cluster snapshots into a single ConfigHub proposal. |\n| Just structure parsing | `cub-scout import parse-repo \u003Crepo>` | Lower-level. Extracts ApplicationSet directories, helm chart paths, kustomization roots. Used as a primitive. |\n\nThe verbs are **preview** by default. None of them write to ConfigHub.\n\n### Step 2 — run the preview\n\n**Git-path preview (most common):**\n\n```bash\n$ cub-scout import --git-path .\u002Fplatform-config --dry-run --json | jq '.'\n{\n  \"units\": [\n    {\"slug\": \"apps-prod-api\", \"path\": \"apps\u002Fprod\u002Fapi\", \"kind\": \"Deployment\", \"rendererHint\": \"kustomize\", \"confidence\": \"high\"},\n    {\"slug\": \"apps-prod-worker\", \"path\": \"apps\u002Fprod\u002Fworker\", \"kind\": \"Deployment\", \"rendererHint\": \"kustomize\", \"confidence\": \"high\"}\n  ],\n  \"spaces\": [\"platform-prod\"],\n  \"targets\": [\"Kubernetes:prod-use2\"],\n  \"unsupported\": []\n}\n```\n\n**Argo-import preview:**\n\n```bash\n$ cub-scout import argocd guestbook --space payments --dry-run\n```\n\nThe output structure is per-Application: each gets a proposed slug, the source path the Application reads, and the renderer hint (kustomize \u002F helm \u002F raw). ApplicationSet generators are preserved — see [`observe-argocd`](..\u002Fobserve-argocd\u002FSKILL.md) for the generator support.\n\n### Step 3 — save a reviewable proposal\n\nThe **safest** workflow today: save the proposal JSON; review it in git, a ticket, or the PR that is coordinating the adoption; only THEN does anyone run `import apply`.\n\n```bash\n$ cub-scout import --git-path .\u002Fplatform-config --dry-run --json > proposal.json\n$ git checkout -b adopt-confighub\n$ git add proposal.json\n$ git commit -m \"preview ConfigHub units for platform-config\"\n$ git push origin adopt-confighub\n$ gh pr create ...\n```\n\nThe proposal is reviewable in git, with all the usual diff tooling. ConfigHub itself sees nothing until someone runs `import apply` post-review.\n\n### Step 4 — iterate\n\nIf the proposal isn't right (wrong slugs, wrong space grouping, missing workloads), adjust the source structure and re-run. cub-scout's import verbs are deterministic — same source produces same proposal, so the PR diff narrows iteration-by-iteration.\n\nCommon adjustments:\n\n- **Rename** repo directories to control proposed slugs (`apps\u002Fprod\u002Fapi` → slug `apps-prod-api`)\n- **Split** monolithic kustomize roots into per-workload directories\n- **Add** README or NOTES files to explain non-obvious structure\n- **Tag** ApplicationSet templates so generator-derived units get distinguishable slugs\n\n### Step 5 — hand off the apply\n\nOnce the proposal is approved:\n\n```bash\n# THE USER runs this — not cub-scout, not this skill\n$ cub-scout import apply proposal.json\n```\n\n`import apply` writes to ConfigHub. It IS a mutation. It is intentionally NOT in this skill's allowed-tools. Recommend the user run it themselves and verify the result with `cub unit list --space platform-prod`.\n\n## Worked example\n\nA team has a live `payments` namespace and a git repo `platform-config\u002F` with three apps under `apps\u002Fprod\u002F`. They want to adopt ConfigHub, so they preview the live cluster first and use the repo preview as a secondary check.\n\n```bash\n$ cub-scout import --dry-run -n payments --json > proposal-live.json\n$ cub-scout import --git-path .\u002Fplatform-config --dry-run --json > proposal-repo.json\nProposal:\n  Units (3):\n    apps-prod-api       — apps\u002Fprod\u002Fapi\u002F        kustomize  high\n    apps-prod-worker    — apps\u002Fprod\u002Fworker\u002F     kustomize  high\n    apps-prod-frontend  — apps\u002Fprod\u002Ffrontend\u002F   raw        medium\n  Spaces (1):\n    platform-prod\n  Targets (1):\n    Kubernetes:prod-use2\n  Unsupported (0): —\n\n$ git checkout -b adopt-confighub\n$ git add proposal-live.json proposal-repo.json\n$ git commit -m \"preview ConfigHub units for platform-prod\"\n$ # ...PR review...\n$ # ...merge...\n\n# After PR merges, the operator runs:\n$ cub-scout import apply proposal-live.json\n```\n\ncub-scout produced the proposals; git carried the review; the operator drove the apply. Three tools, three responsibilities.\n\n## Boundaries\n\n### cub-scout vs cub's own load path\n\nThis is **the** distinction to make clear:\n\n- `cub-scout import --git-path \u003Crepo>` is **structure-and-preview** focused. Walks a local git checkout, classifies kustomize\u002Fhelm\u002Fraw, emits a proposal. No cluster, no ConfigHub required for the preview itself.\n- `cub variant upload` (in `cub`, not cub-scout) **loads already-rendered resources**: a directory, a file, `-`, or an `oci:\u002F\u002F` bundle. It renders nothing — you render with `helm template`, `kustomize build` or an installer — and makes the space's units match the input, create-or-update with a 3-way merge.\n\nThey solve different problems. cub-scout is for **adoption** (first-time preview\u002Fimport); `cub variant upload` is for **ongoing load** of rendered configuration. Don't claim they overlap.\n\n> `cub gitops discover` and `cub gitops import` **no longer exist**: cub deleted the `gitops` group on 2026-07-25 with no replacement, and `cub gitops` exits 1 with `unknown command`. If a user asks for that flow, say so rather than running it ([#573](https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fissues\u002F573)).\n\n### apply boundary\n\n`cub-scout import apply` IS the mutating write. The user runs it directly; this skill describes its shape but does not invoke it. Defense in depth: not in `allowed-tools`.\n\n## Tool boundary\n\n- **Allowed (agent-callable preview):**\n  - `cub-scout import parse-repo *` — pure parser\n  - `cub-scout import cluster-aggregator *` — emits proposal as JSON\n  - `cub-scout app list *` — read-only ConfigHub App inventory\n  - `map workloads`, `scan`, `status`; `cub \u003Centity> get \u002F list` for the entities named in allowed-tools; `argocd app get`, `argocd appset get\u002Flist`, `flux get`\n- **Preview, but not auto-approved:** `cub-scout import --git-path \u003Cdir>` and `cub-scout import --dry-run` change nothing as written, but a later flag overrides them (`--git-path=` clears the path, `--dry-run=false` turns preview off), so a wildcard grant would admit a real import. The host asks before each run.\n- **Not allowed (user-driven only):**\n  - `cub-scout import apply *` — writes ConfigHub units\n  - `cub-scout import argocd *` — without `--dry-run` it creates units, can disable Argo auto-sync, can delete the Argo Application (`cmd\u002Fcub-scout\u002Fimport_argocd.go:465-488`). The wildcard cannot enforce `--dry-run`, so the verb is out of allowed-tools entirely; recommend the user run `cub-scout import argocd \u003Capp> --dry-run` themselves and feed the proposal to the agent for review.\n  - `cub-scout app create *` — `app list` is the read-only form in allowed-tools\n  - `cub * create\u002Fupdate\u002Fdelete`, `cub variant upload` (different tool), `kubectl apply\u002Fedit\u002Fpatch\u002Fdelete`\n\n## References\n\n- [`scout-ingest`](..\u002Fscout-ingest\u002FSKILL.md) — the verb group this skill composes\n- [`observe-argocd`](..\u002Fobserve-argocd\u002FSKILL.md) — ApplicationSet generator detail\n- [`observe-flux`](..\u002Fobserve-flux\u002FSKILL.md) — Kustomization \u002F source structure\n- [`observe-confighub-managed`](..\u002Fobserve-confighub-managed\u002FSKILL.md) — the result-side view of ConfigHub-managed resources\n- ApplicationSet generator support: `#363`\n- Render integration investigation: `#364` (verdict: keep tools separate)\n- Examples: [`examples\u002Fargo-import-confighub-demo\u002F`](..\u002F..\u002Fexamples\u002Fargo-import-confighub-demo\u002F), [`examples\u002Fflux-import-confighub-demo\u002F`](..\u002F..\u002Fexamples\u002Fflux-import-confighub-demo\u002F), [`examples\u002Ffleet-import\u002F`](..\u002F..\u002Fexamples\u002Ffleet-import\u002F)\n\n## Constraints\n\n- This skill is **preview-only**. `import apply` is explicitly out of band — recommend the user runs it themselves after PR review.\n- Save proposal JSON for review today. A future `import --git-path --output-dir` flow is tracked separately for emitting proposed unit YAMLs directly.\n- For deeply-nested Helm or templated structure, the parser produces lower-confidence proposals; surface those explicitly. cub-scout's import is for **adoption**, not for renderer reconstruction.\n- Helm \u002F Kustomize back-resolution at file:line precision is currently raw-YAML only (#440 stage B); templated sources fall back to resource-level anchors.\n","# prepare-for-confighub\n\nThe adoption-preview loop. The user has existing live K8s + GitOps state and wants to KNOW what a ConfigHub import would produce **before** committing. Start from the live cluster when possible; use local repo parsing only when the manifest repository itself is under review. This skill is the **preview** flow — every verb is read-only, and `import apply` (the mutating write) is **explicitly out of band**. The user runs that themselves after reviewing the proposal.\n\n## When to use\n\nExplicit phrasings:\n\n- \"Show me the proposed units before I apply\"\n- \"I want to adopt ConfigHub for this app — what would it look like?\"\n- \"What would ConfigHub see in this live cluster?\"\n- \"What would ConfigHub see in our Argo CD setup?\"\n- \"Preview what would land in ConfigHub if I imported this repo\"\n- \"Walk me through ConfigHub adoption for `payments-api`\"\n- \"Compare ApplicationSet generator import vs a raw `--git-path` import for this repo\"\n\nImplicit intents:\n\n- The user is **before** ConfigHub adoption, not in steady state\n- The user wants **reviewable** output, not a live mutation\n- The user is comparing options (\"what if I use ApplicationSet vs raw YAML import?\")\n- The user is gating on team-review or compliance approval before the actual write\n\n## Do not load for\n\n- Actually applying the proposal (`cub-scout import apply`) — that's user-driven, not in this skill's allowed-tools\n- Live conformance audits **once** units exist — [`audit-fleet-conformance`](..\u002Faudit-fleet-conformance\u002FSKILL.md)\n- Comparing live state to existing ConfigHub units — [`scout-compare`](..\u002Fscout-compare\u002FSKILL.md) (specifically `compare three-way`)\n- The write into ConfigHub from rendered resources (`cub variant upload`) — that's `cub`, not cub-scout. Route to [`confighub\u002Fconfighub-skills`](https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fconfighub-skills).\n- Triage \u002F drift investigation — the corresponding workflow skills\n\n## The loop\n\n1. **Identify the source.** Where is the structure today? Live namespace (`import --dry-run -n \u003Cns>`)? Cluster Argo Applications (`import argocd`)? Multi-cluster snapshot (`import cluster-aggregator`)? Local git repo (`--git-path \u003Cdir>`)? Pick the verb.\n2. **Run the preview verb.** ASCII for review-by-eye; `--json` if the output feeds a PR-bot or a CI check.\n3. **Save a review artifact when needed.** `cub-scout import ... --json > proposal.json` gives reviewers a deterministic proposal without writing ConfigHub state.\n4. **Iterate.** Adjust the source structure (rename, regroup, split namespaces) until the proposal looks right. cub-scout doesn't change anything; you just re-run the preview.\n5. **Hand off the mutation.** Once the proposal is approved, the user runs `cub-scout import apply --space \u003Cs>` themselves. cub-scout's `prepare-for-confighub` skill **never** invokes apply.\n\n## Step-by-step\n\n### Step 1 — pick the source verb\n\n| Source | Verb | Notes |\n|--------|------|-------|\n| Live namespace or cluster | `cub-scout import --dry-run -n \u003Cnamespace> --json` | First adoption path. Reads current workloads, ownership, and labels before any write. |\n| Local git checkout | `cub-scout import --git-path \u003Crepo> --dry-run --json` | Advanced path. Classifies kustomize \u002F helm \u002F raw manifests; emits proposed slugs + spaces + targets without upload or render. |\n| Existing Argo Applications | `cub-scout import argocd --space \u003Cs>` | Reads Argo state from the cluster, proposes one ConfigHub unit per Application. Preserves ApplicationSet generator origin as hierarchy. |\n| Multi-cluster bundle | `cub-scout import cluster-aggregator --space \u003Cs>` | Aggregator-pattern. Aggregates per-cluster snapshots into a single ConfigHub proposal. |\n| Just structure parsing | `cub-scout import parse-repo \u003Crepo>` | Lower-level. Extracts ApplicationSet directories, helm chart paths, kustomization roots. Used as a primitive. |\n\nThe verbs are **preview** by default. None of them write to ConfigHub.\n\n### Step 2 — run the preview\n\n**Git-path preview (most common):**\n\n```bash\n$ cub-scout import --git-path .\u002Fplatform-config --dry-run --json | jq '.'\n{\n  \"units\": [\n    {\"slug\": \"apps-prod-api\", \"path\": \"apps\u002Fprod\u002Fapi\", \"kind\": \"Deployment\", \"rendererHint\": \"kustomize\", \"confidence\": \"high\"},\n    {\"slug\": \"apps-prod-worker\", \"path\": \"apps\u002Fprod\u002Fworker\", \"kind\": \"Deployment\", \"rendererHint\": \"kustomize\", \"confidence\": \"high\"}\n  ],\n  \"spaces\": [\"platform-prod\"],\n  \"targets\": [\"Kubernetes:prod-use2\"],\n  \"unsupported\": []\n}\n```\n\n**Argo-import preview:**\n\n```bash\n$ cub-scout import argocd guestbook --space payments --dry-run\n```\n\nThe output structure is per-Application: each gets a proposed slug, the source path the Application reads, and the renderer hint (kustomize \u002F helm \u002F raw). ApplicationSet generators are preserved — see [`observe-argocd`](..\u002Fobserve-argocd\u002FSKILL.md) for the generator support.\n\n### Step 3 — save a reviewable proposal\n\nThe **safest** workflow today: save the proposal JSON; review it in git, a ticket, or the PR that is coordinating the adoption; only THEN does anyone run `import apply`.\n\n```bash\n$ cub-scout import --git-path .\u002Fplatform-config --dry-run --json > proposal.json\n$ git checkout -b adopt-confighub\n$ git add proposal.json\n$ git commit -m \"preview ConfigHub units for platform-config\"\n$ git push origin adopt-confighub\n$ gh pr create ...\n```\n\nThe proposal is reviewable in git, with all the usual diff tooling. ConfigHub itself sees nothing until someone runs `import apply` post-review.\n\n### Step 4 — iterate\n\nIf the proposal isn't right (wrong slugs, wrong space grouping, missing workloads), adjust the source structure and re-run. cub-scout's import verbs are deterministic — same source produces same proposal, so the PR diff narrows iteration-by-iteration.\n\nCommon adjustments:\n\n- **Rename** repo directories to control proposed slugs (`apps\u002Fprod\u002Fapi` → slug `apps-prod-api`)\n- **Split** monolithic kustomize roots into per-workload directories\n- **Add** README or NOTES files to explain non-obvious structure\n- **Tag** ApplicationSet templates so generator-derived units get distinguishable slugs\n\n### Step 5 — hand off the apply\n\nOnce the proposal is approved:\n\n```bash\n# THE USER runs this — not cub-scout, not this skill\n$ cub-scout import apply proposal.json\n```\n\n`import apply` writes to ConfigHub. It IS a mutation. It is intentionally NOT in this skill's allowed-tools. Recommend the user run it themselves and verify the result with `cub unit list --space platform-prod`.\n\n## Worked example\n\nA team has a live `payments` namespace and a git repo `platform-config\u002F` with three apps under `apps\u002Fprod\u002F`. They want to adopt ConfigHub, so they preview the live cluster first and use the repo preview as a secondary check.\n\n```bash\n$ cub-scout import --dry-run -n payments --json > proposal-live.json\n$ cub-scout import --git-path .\u002Fplatform-config --dry-run --json > proposal-repo.json\nProposal:\n  Units (3):\n    apps-prod-api       — apps\u002Fprod\u002Fapi\u002F        kustomize  high\n    apps-prod-worker    — apps\u002Fprod\u002Fworker\u002F     kustomize  high\n    apps-prod-frontend  — apps\u002Fprod\u002Ffrontend\u002F   raw        medium\n  Spaces (1):\n    platform-prod\n  Targets (1):\n    Kubernetes:prod-use2\n  Unsupported (0): —\n\n$ git checkout -b adopt-confighub\n$ git add proposal-live.json proposal-repo.json\n$ git commit -m \"preview ConfigHub units for platform-prod\"\n$ # ...PR review...\n$ # ...merge...\n\n# After PR merges, the operator runs:\n$ cub-scout import apply proposal-live.json\n```\n\ncub-scout produced the proposals; git carried the review; the operator drove the apply. Three tools, three responsibilities.\n\n## Boundaries\n\n### cub-scout vs cub's own load path\n\nThis is **the** distinction to make clear:\n\n- `cub-scout import --git-path \u003Crepo>` is **structure-and-preview** focused. Walks a local git checkout, classifies kustomize\u002Fhelm\u002Fraw, emits a proposal. No cluster, no ConfigHub required for the preview itself.\n- `cub variant upload` (in `cub`, not cub-scout) **loads already-rendered resources**: a directory, a file, `-`, or an `oci:\u002F\u002F` bundle. It renders nothing — you render with `helm template`, `kustomize build` or an installer — and makes the space's units match the input, create-or-update with a 3-way merge.\n\nThey solve different problems. cub-scout is for **adoption** (first-time preview\u002Fimport); `cub variant upload` is for **ongoing load** of rendered configuration. Don't claim they overlap.\n\n> `cub gitops discover` and `cub gitops import` **no longer exist**: cub deleted the `gitops` group on 2026-07-25 with no replacement, and `cub gitops` exits 1 with `unknown command`. If a user asks for that flow, say so rather than running it ([#573](https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fissues\u002F573)).\n\n### apply boundary\n\n`cub-scout import apply` IS the mutating write. The user runs it directly; this skill describes its shape but does not invoke it. Defense in depth: not in `allowed-tools`.\n\n## Tool boundary\n\n- **Allowed (agent-callable preview):**\n  - `cub-scout import parse-repo *` — pure parser\n  - `cub-scout import cluster-aggregator *` — emits proposal as JSON\n  - `cub-scout app list *` — read-only ConfigHub App inventory\n  - `map workloads`, `scan`, `status`; `cub \u003Centity> get \u002F list` for the entities named in allowed-tools; `argocd app get`, `argocd appset get\u002Flist`, `flux get`\n- **Preview, but not auto-approved:** `cub-scout import --git-path \u003Cdir>` and `cub-scout import --dry-run` change nothing as written, but a later flag overrides them (`--git-path=` clears the path, `--dry-run=false` turns preview off), so a wildcard grant would admit a real import. The host asks before each run.\n- **Not allowed (user-driven only):**\n  - `cub-scout import apply *` — writes ConfigHub units\n  - `cub-scout import argocd *` — without `--dry-run` it creates units, can disable Argo auto-sync, can delete the Argo Application (`cmd\u002Fcub-scout\u002Fimport_argocd.go:465-488`). The wildcard cannot enforce `--dry-run`, so the verb is out of allowed-tools entirely; recommend the user run `cub-scout import argocd \u003Capp> --dry-run` themselves and feed the proposal to the agent for review.\n  - `cub-scout app create *` — `app list` is the read-only form in allowed-tools\n  - `cub * create\u002Fupdate\u002Fdelete`, `cub variant upload` (different tool), `kubectl apply\u002Fedit\u002Fpatch\u002Fdelete`\n\n## References\n\n- [`scout-ingest`](..\u002Fscout-ingest\u002FSKILL.md) — the verb group this skill composes\n- [`observe-argocd`](..\u002Fobserve-argocd\u002FSKILL.md) — ApplicationSet generator detail\n- [`observe-flux`](..\u002Fobserve-flux\u002FSKILL.md) — Kustomization \u002F source structure\n- [`observe-confighub-managed`](..\u002Fobserve-confighub-managed\u002FSKILL.md) — the result-side view of ConfigHub-managed resources\n- ApplicationSet generator support: `#363`\n- Render integration investigation: `#364` (verdict: keep tools separate)\n- Examples: [`examples\u002Fargo-import-confighub-demo\u002F`](..\u002F..\u002Fexamples\u002Fargo-import-confighub-demo\u002F), [`examples\u002Fflux-import-confighub-demo\u002F`](..\u002F..\u002Fexamples\u002Fflux-import-confighub-demo\u002F), [`examples\u002Ffleet-import\u002F`](..\u002F..\u002Fexamples\u002Ffleet-import\u002F)\n\n## Constraints\n\n- This skill is **preview-only**. `import apply` is explicitly out of band — recommend the user runs it themselves after PR review.\n- Save proposal JSON for review today. A future `import --git-path --output-dir` flow is tracked separately for emitting proposed unit YAMLs directly.\n- For deeply-nested Helm or templated structure, the parser produces lower-confidence proposals; surface those explicitly. cub-scout's import is for **adoption**, not for renderer reconstruction.\n- Helm \u002F Kustomize back-resolution at file:line precision is currently raw-YAML only (#440 stage B); templated sources fall back to resource-level anchors.\n",{"name":5,"phase":56,"description":7,"allowed-tools":57},"cross-cutting","Bash(.\u002Fcub-scout import parse-repo *) Bash(cub-scout import parse-repo *) Bash(cub scout import parse-repo *) Bash(.\u002Fcub-scout import cluster-aggregator *) Bash(cub-scout import cluster-aggregator *) Bash(cub scout import cluster-aggregator *) Bash(.\u002Fcub-scout app list *) Bash(cub-scout app list *) Bash(cub scout app list *) Bash(.\u002Fcub-scout app list) Bash(cub-scout app list) Bash(cub scout app list) Bash(.\u002Fcub-scout map workloads *) Bash(cub-scout map workloads *) Bash(cub scout map workloads *) Bash(.\u002Fcub-scout scan *) Bash(cub-scout scan *) Bash(cub scout scan *) Bash(.\u002Fcub-scout status) Bash(cub-scout status) Bash(cub scout status) Bash(kubectl get *) Bash(kubectl describe *) 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(argocd appset get *) Bash(argocd appset list *) Bash(flux get *)","main","261862e7ec5e5c93ce377ccfd6b583f5ac03c95c","skills\u002Fprepare-for-confighub",1,"https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout","https:\u002F\u002Fgithub.com\u002Fconfighub","http:\u002F\u002Fwww.confighub.com","Public repo for ConfigHub","2026-11-11 04:47:05",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add confighub\u002Fcub-scout --skill prepare-for-confighub",{"tool":73,"command":74},"bunx","bunx skills add confighub\u002Fcub-scout --skill prepare-for-confighub",{"tool":76,"command":77},"pnpm","pnpm dlx skills add confighub\u002Fcub-scout --skill prepare-for-confighub","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fconfighub\u002Fcub-scout\u002Fblob\u002Fmain\u002Fskills\u002Fprepare-for-confighub\u002FSKILL.md",true,[81,87,91,95],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"_meta.json","REFERENCE","参考文档",122,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fxrp\u002F_meta.json",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"skill-card.md",1711,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fxrp\u002Fskill-card.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"SOURCE.md",236,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fxrp\u002FSOURCE.md",{"path":96,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":97,"sourceHtmlUrl":98},"TRUST.auto.yaml",2193,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Fchains\u002Fxrp\u002FTRUST.auto.yaml",[100,133,153,172,195,212],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":111,"publishedAt":51},"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",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[112,113,114,115,116,117,118,119,120,121,43,122,123,124,125,126,37,127,128,34,129,130,30,131,28,132,35],"triage","workload","triage unhealthy workload","kubernetes","diagnose","doctor","logs","ci","payments","api","loop","explain","check","broken","question","rollout","never","route","drift","time","now",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":51},"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",[139],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},[141,142,143,115,144,145,119,146,147,121,44,43,148,42,41,38,149,37,128,150,34,32,129,151,28,27,25,152,35],"verify","scout verify","scout","acceptance","produce","attestation","provenance","postmortem","fix","evidence","me","managed",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":51},"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",[],[160,161,143,162,115,116,163,117,118,164,147,165,44,43,125,37,166,128,36,167,34,32,168,169,30,28,170,171,35],"observe","scout observe","bot","deployment","risk","inventory","version","hooks","back","health-check","resources","meaning",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":181,"publishedAt":51},"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",[178],{"categoryNo":179,"categoryName":180,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000023","Skill与智能体开发",[182,183,143,162,184,185,186,187,50,49,188,189,43,190,42,39,191,36,192,193,160,28,25,194,35],"MCP","scout mcp","mcp server","ai agent","auth","config","server","SET","model","snapshot","ready","up","agent-context",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":51},"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",[],[202,203,143,115,116,49,47,145,204,189,165,205,44,43,42,40,126,39,206,38,37,36,160,34,32,207,29,208,209,27,25,210,211,22,23],"ingest","scout ingest","adoption","discovery","write","structure","adopt","argo","reading","exported",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":218,"publishedAt":51},"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",[],[219,143,220,186,221,222,46,165,141,44,43,223,42,38,224,37,225,226,227,160,34,32,228,28,229,230,25,231,232,233,234,35],"scout govern","change","governance","blast radius","history","catalog","diff","say","snapshots","project","mutation","impact","render","blast-radius","which","inspect"]