Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add llm-d-incubation/llm-d-skills --skill teardown-llm-dgit clone --depth 1 https://github.com/llm-d-incubation/llm-d-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/llm-d-incubation/llm-d-skills/teardown-llm-d)<a href="https://agentmods.dev/skills/llm-d-incubation/llm-d-skills/teardown-llm-d"><img src="https://agentmods.dev/badge/skills/llm-d-incubation/llm-d-skills/teardown-llm-d/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/llm-d-incubation/llm-d-skills/teardown-llm-d"><img src="https://agentmods.dev/badge/skills/llm-d-incubation/llm-d-skills/teardown-llm-d.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00114 | $0.01927 |
| Opus 5 | $0.00057 | $0.00963 |
| Sonnet 5 | $0.00023 | $0.00385 |
| Haiku 4.5 | $0.00011 | $0.00193 |
Grade A, and why
teardown-llm-d-stack scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 238 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Teardown llm-d Stack
Purpose
Cleanly remove a deployed llm-d stack from a Kubernetes namespace. Works with both Helm-based deployments (using helmfile or helm) and Kustomize-based deployments (using kubectl apply -k). No local repo is needed for Helm-only teardown, but Kustomize-based resources require access to the kustomization directory. Always confirms with the user before deleting anything.
Step 1: Locate the Stack and Set NAMESPACE
Use the same detection logic as the deploy and benchmark skills:
- If the
NAMESPACEenvironment variable is set, use it. - Otherwise check for an active
oc project:oc project -q 2>/dev/null - If neither, ask the user for the namespace.
Verify the stack is present:
kubectl get pods -n $NAMESPACE
helm list -n $NAMESPACE
If no llm-d resources are found, tell the user and stop.
Step 2: Inspect What Is Deployed
Gather a full picture before proposing any changes:
# All Helm releases in the namespace
helm list -n $NAMESPACE
# HTTPRoutes and Gateways
kubectl get httproute,gateway -n $NAMESPACE 2>/dev/null
# All deployments (including those created by Kustomize)
kubectl get deployments -n $NAMESPACE
# All services
kubectl get services -n $NAMESPACE
# All pods
kubectl get pods -n $NAMESPACE
# Check for llm-d labels to identify Kustomize-deployed resources
kubectl get deployments,services,serviceaccounts,podmonitors -n $NAMESPACE -l llm-d.ai/guide 2>/dev/null
Identify deployment method:
- If Helm releases exist: Helm-based deployment
- If resources with
llm-d.ai/guidelabels exist but no Helm releases: Kustomize-based deployment - If both exist: Hybrid deployment (common pattern)
Step 3: Present Teardown Plan and Confirm
Before touching anything, show the user exactly what will be removed and ask for confirmation:
Teardown plan for namespace: <NAMESPACE>
Deployment Method: <Helm-based | Kustomize-based | Hybrid>
Helm releases to uninstall:
- <release-1>
- <release-2>
- <release-3>
Kustomize-deployed resources (if applicable):
- Deployments: <list>
- Services: <list>
- ServiceAccounts: <list>
- PodMonitors: <list>
Not removed unless you choose below:
HTTPRoutes: <list or "none found">
Gateways: <list or "none found">
Shall I proceed with the teardown?
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 238 lines · 114 tokens per session scan A b97b213911d8
teardown-llm-d-stack is a skill published in the GitHub repository llm-d-incubation/llm-d-skills (6 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 114 tokens to every session and 1,927 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
azd-deployment
Deploy containerized frontend + backend applications to Azure Container Apps with remote builds, managed identity, and idempotent infrastructure.
openshell-cli
Guide agents through using the OpenShell CLI (openshell) for sandbox management, gateway registration, provider configuration and refresh, policy iteration, settings, service exposure, BYOC workflows, and attached-provider inference. Covers basic through advanced multi-step workflows. Trigger keywords - openshell…
langbot-deploy
Deploy and configure a LangBot instance — Docker / Docker Compose, Kubernetes, the config.yaml model, the Box sandbox runtime, the plugin runtime, and the global API key. Use when installing, deploying, upgrading, or configuring LangBot in production or self-hosted environments. Triggers on "deploy langbot", "langbot…
compute-env-setup
Set up a compute environment on a remote provider so Claude Science jobs can run there. Covers direct SSH/conda hosts, Slurm clusters, container-via-bridge runners, and managed-API providers (Modal, GCP, RunPod). Use when standing up a new provider, porting an env to a different backend, adding a tool that needs its…
azure-cloud-migrate
Assess and migrate cross-cloud workloads to Azure with reports and code conversion. Supports Lambda→Functions, Beanstalk/Heroku/App Engine→App Service, Fargate/Kubernetes/Cloud Run/Spring Boot→Container Apps. WHEN: migrate Lambda to Functions, AWS to Azure, migrate Beanstalk, migrate Heroku, migrate App Engine, Cloud…
atmos-helmfile
Helmfile orchestration: sync/apply/destroy/diff, Kubernetes deployments, varfile generation, EKS integration, source management.