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 agentmods add skills/flyteorg/flyte-agent-plugins/deploy-flyte-kindnpx skills add flyteorg/flyte-agent-plugins --skill deploy-flyte-kindgit clone --depth 1 https://github.com/flyteorg/flyte-agent-pluginsWrote 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/flyteorg/flyte-agent-plugins/deploy-flyte-kind)<a href="https://agentmods.dev/skills/flyteorg/flyte-agent-plugins/deploy-flyte-kind"><img src="https://agentmods.dev/badge/skills/flyteorg/flyte-agent-plugins/deploy-flyte-kind.svg" alt="Measured on agentmods" 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 | $0.00123 | $0.12614 |
| Opus 5 | $0.00062 | $0.06307 |
| Sonnet 5 | $0.00025 | $0.02523 |
| Haiku 4.5 | $0.00012 | $0.01261 |
Grade F, and why
deploy-flyte-kind scanned grade F with 4 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 3d 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.
Asks for rootmediumPrivilege escalation
A mod that escalates privileges can change anything on the machine, not only the project.
flyte.local" | sudo tee -a /etc/hosts` so it runs in this session), then **ask Downloads and executes remote codehighSupply chain
curl | sh runs whatever the server returns today, which is not necessarily what it returned when this was reviewed.
curl -fsSL https://get.docker.com | sh Cloud metadata endpointhighServer-side request forgery
One request to 169.254.169.254 can return temporary IAM credentials.
`OSError: Generic S3 error: Error performing PUT http://169.254.169.254/latest/api/token`. Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
curl -fsSL https://get.docker.com | sh How it starts
The opening of the file, as written. The whole thing — 1,106 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Deploy Flyte to a kind cluster
Stand up Flyte on a kind cluster: the flyte-binary plus a hosted PostgreSQL and an S3-compatible object store. For evaluation only — no TLS, no auth, static credentials.
kind runs anywhere Docker runs, so the cluster can live on the user's own machine (default) or a DigitalOcean VM (droplet) — the host is a choice made in Step 0.
The PostgreSQL and object store are independent choices the user makes in Step 2:
- PostgreSQL — Supabase or another external/self-hosted PostgreSQL.
- Object store — AWS S3 or Cloudflare R2.
Both are hosted; kind runs only the flyte-binary. The user supplies connection details for each.
Step 0: Choose the host, check prerequisites, and check for an existing cluster
First, ask the user where kind should run (use AskUserQuestion):
- the user's own machine (default), or
- a DigitalOcean VM (droplet) — the only cloud-VM host this skill supports.
Do not offer or hand-roll AWS EC2 or GCP VM setups; for a real cloud deployment, point the user at the AWS deployment skill instead.
If the user picks the droplet, every kind, kubectl, and helm command
below runs on the droplet (over SSH) — only the SDK/CLI and browser run on the
user's own machine. Provision it and install the tools there first (needs a few
GB of headroom for kind, so ≥ 4 vCPU / 8 GB):
# create the droplet (dashboard or doctl)
doctl compute droplet create flyte-kind \
--image ubuntu-24-04-x64 --size s-4vcpu-8gb --region nyc1 \
--ssh-keys <your-ssh-key-id>
# SSH in and install Docker, kind, kubectl, helm ON the droplet
ssh root@<droplet-ip>
curl -fsSL https://get.docker.com | sh
curl -Lo /usr/local/bin/kind \
https://github.com/kubernetes-sigs/kind/releases/latest/download/kind-linux-amd64 \
&& chmod +x /usr/local/bin/kind
curl -Lo /usr/local/bin/kubectl \
"https://dl.k8s.io/release/$(curl -Ls https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" \
&& chmod +x /usr/local/bin/kubectl
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
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.
- 3d ago First seen · 1,106 lines · 123 tokens per session scan F 20105867ca33
deploy-flyte-kind is a skill published in the GitHub repository flyteorg/flyte-agent-plugins (2 stars, last pushed 6d ago), licensed Apache-2.0. It adds 123 tokens to every session and 12,614 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it F with 4 findings (asks for root, downloads and executes remote code, cloud metadata endpoint). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
qdrant-deployment-options
Guides Qdrant deployment selection. Use when someone asks 'how to deploy Qdrant', 'Docker vs Cloud', 'local mode', 'embedded Qdrant', 'Qdrant EDGE', 'which deployment option', 'self-hosted vs cloud', or 'need lowest latency deployment'. Also use when choosing between deployment types for a new project.
n8n-azure
Application-specific configuration for deploying n8n to Azure Container Apps with PostgreSQL. Infrastructure should be generated fresh by the azure-prepare → azure-validate → azure-deploy pipeline.
stateful-workloads
Covers running stateful systems — databases, queues, search indexes — on Kubernetes, including StatefulSets and stable identity, durable storage, backup and failover built into the platform rather than bolted on, and the tradeoff between self-managing a stateful service and paying for a managed one. Use this whenever…
scylladb-kubernetes
Guide users deploying and operating ScyllaDB on Kubernetes via the official ScyllaDB Operator. Use this skill when a user is setting up a ScyllaCluster, configuring node storage/CPU pinning for ScyllaDB pods, installing the Operator, or troubleshooting a Kubernetes-based ScyllaDB deployment. Triggers on "ScyllaDB…
n8n-impl-deployment
Use when deploying n8n v1.x to production or configuring Docker/queue mode. Prevents data loss from missing volume mounts or incorrect database configuration. Covers Docker/Docker Compose setup, 100+ environment variables, queue mode with Redis/BullMQ, worker processes, webhook processor, PostgreSQL/SQLite…
n8n-azure
Application-specific configuration for deploying n8n to Azure Container Apps with PostgreSQL. Infrastructure should be generated fresh by the azure-prepare → azure-validate → azure-deploy pipeline.