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 devantler-tech/agent-plugins --skill gitops-tenant-onboardinggit clone --depth 1 https://github.com/devantler-tech/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/devantler-tech/agent-plugins/gitops-tenant-onboarding)<a href="https://agentmods.dev/skills/devantler-tech/agent-plugins/gitops-tenant-onboarding"><img src="https://agentmods.dev/badge/skills/devantler-tech/agent-plugins/gitops-tenant-onboarding/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/devantler-tech/agent-plugins/gitops-tenant-onboarding"><img src="https://agentmods.dev/badge/skills/devantler-tech/agent-plugins/gitops-tenant-onboarding.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.00126 | $0.02707 |
| Opus 5.5 | $0.00050 | $0.01083 |
| Sonnet 5.5 | $0.00025 | $0.00541 |
| Haiku 4.5 | $0.00013 | $0.00271 |
Grade A, and why
gitops-tenant-onboarding 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 1mo 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 — 179 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitOps Tenant Onboarding
Onboarding a tenant — an application that runs on a shared, multi-tenant
Flux cluster from its own repository — follows the same
recurring shape every time. The tenant repo builds a container image and publishes
its Kubernetes manifests as a signed OCI artifact; the platform pulls that
artifact with a Flux OCIRepository + Kustomization and runs it in a dedicated,
locked-down namespace. This skill is the agent-facing companion to that pattern:
the decisions, the conventions, and — most usefully — the gotchas that make a
fresh tenant fail if you miss them.
It is built around an opinionated but industry-standard stack — Flux, External Secrets Operator backed by OpenBao/Vault, Kyverno + PodSecurity, Cilium / Gateway API, cosign — so the steps transfer to any cluster wired the same way; adapt the resource names to your platform.
The two halves
Onboarding always spans two repos, and a tenant is not live until both land:
- The tenant repo — created from a tenant template. Ships the shared,
framework-agnostic CI/CD plumbing (build → signed publish → release) plus a
deploy/directory of Kubernetes manifests you own and customise. - The platform registration — a small directory in the platform repo
(
apps/<tenant>/) that grants the tenant a namespace, an identity (a ServiceAccount), RBAC, a network policy, the OpenBao-backed image-pull secret, and the Flux resources that pull and verify the tenant's artifact.
Open each as a PR. The tenant goes live when the platform registration merges and Flux reconciles it — the tenant repo alone does nothing until it is registered.
Tenant repo: the deploy/ manifests
A tenant's deploy/ is a Kustomize overlay. The full set, and what each is for:
| Manifest | Purpose | Drop it when… |
|---|---|---|
deployment.yaml |
the workload | — |
service.yaml |
ClusterIP for the app port | — |
httproute.yaml |
Gateway API HTTPRoute attaching to the shared gateway |
the app is not HTTP-exposed |
poddisruptionbudget.yaml |
drain-safe maxUnavailable: 1 PDB |
never — every workload needs one |
networkpolicy.yaml |
re-opens ingress/egress under the cluster's default-deny | never on a default-deny cluster |
secretstore.yaml + externalsecret.yaml |
namespaced External Secrets store + secret | the tenant needs no app secrets |
cluster.yaml |
CloudNativePG database | the tenant has no database |
kustomization.yaml |
lists the above | — |
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.
- 1mo ago First seen · 179 lines · 126 tokens per session scan A 536795f545e9
gitops-tenant-onboarding is a skill published in the GitHub repository devantler-tech/agent-plugins (2 stars, last pushed yesterday), licensed Apache-2.0. It adds 126 tokens to every session and 2,707 once invoked, about $0.0005 per session on Opus 5.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
infra-standards
Infrastructure, container, and CI/CD discipline — IaC, Dockerfiles and compose files, CI pipelines, platform deploy config, env/secrets handling. INVOKE PROACTIVELY when creating or editing any such file (.tf, .bicep, Dockerfile, docker-compose, .github/workflows/, vercel.json) — even when nobody says "infra". Not for…
ci-cd-pipeline
Use near the end of a project to generate CI and make the app deploy-ready. Produces a polyglot GitHub Actions workflow (lint, typecheck, test, build) and multi-stage Dockerfiles. The finish line is CI-green and container-ready, not an actual deploy.
deploy
Elixir/Phoenix deployment patterns — Dockerfile, fly.toml, runtime.exs, mix release, rel/ overlays. Use when configuring Fly.io, Docker, CI/CD, health checks, or production migrations.
supply-chain
Secure the software supply chain from source to running container. Covers Cosign keyless image signing (Sigstore/Rekor), SBOM generation and attestation (Syft), vulnerability scanning with severity gates (Trivy/Grype), SLSA Level 2 provenance, and Kyverno/OPA admission enforcement. All open-source, no license cost.…
trivy
Scan container images, filesystems, git repos, and existing SBOMs for CVEs, secrets, and license violations using Trivy. Covers local CLI, CI severity gates with SARIF upload, and continuous monitoring via Trivy Operator (Flux HelmRelease). Use when asked to "scan my image", "check for CVEs", "scan this repo for…
relay-deploy
Set up a complete deployment configuration — Dockerfile, deployment manifest, environment config, and rollback procedure. Use when asked about "deployment setup", "how do I deploy this", "deployment strategy", or "rollback plan".