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 pantheon-org/tekhne --skill yaml-validatorgit clone --depth 1 https://github.com/pantheon-org/tekhneWrote 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/pantheon-org/tekhne/yaml-validator)<a href="https://agentmods.dev/skills/pantheon-org/tekhne/yaml-validator"><img src="https://agentmods.dev/badge/skills/pantheon-org/tekhne/yaml-validator.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
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.00057 | $0.03302 |
| Opus 5 | $0.00028 | $0.01651 |
| Sonnet 5 | $0.00011 | $0.00660 |
| Haiku 4.5 | $0.00006 | $0.00330 |
Grade A, and why
k8s-yaml-validator 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 4d 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 — 407 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Kubernetes YAML Validator
Validation Mindset
Mental Model: Validation is a layered funnel—syntax → schema → cluster constraints → runtime behavior. Each layer catches different classes of errors.
Decision Framework:
- Syntax first: Fix YAML structure before schema issues (broken YAML can't be validated)
- Schema second: Verify API compliance before cluster-specific checks
- Cluster third: Test against real constraints (RBAC, quotas, admission webhooks)
- Runtime last: Consider how the resource behaves in production
When to use this skill:
- Before applying any YAML to a cluster (development, staging, production)
- When debugging mysterious kubectl apply failures
- During CI/CD pipeline execution (catch errors early)
- When working with unfamiliar CRDs (validation guides learning)
- After generating YAML with k8s-yaml-generator
Validation philosophy: Report all issues, prioritize by severity, suggest fixes but never apply them automatically.
Overview
This skill provides a comprehensive validation workflow for Kubernetes YAML resources, combining syntax linting, schema validation, cluster dry-run testing, and intelligent CRD documentation lookup. Validate any Kubernetes manifest with confidence before applying it to the cluster.
IMPORTANT — REPORT-ONLY: Do NOT modify files, use the Edit tool, or offer to apply fixes. Generate a comprehensive validation report with suggested fixes shown as before/after code blocks, then let the user decide what to do next.
Validation Workflow
Follow this sequential validation workflow. Each stage catches different types of issues:
Stage 0: Pre-Validation Setup (Resource Count Check)
Before running any validation tools, check the file complexity:
- Count the number of resources by counting
---document separators or parsing the file - If the file contains 3 or more resources, immediately load
references/validation_workflow.md:Read references/validation_workflow.md - Note the resource count for the validation report summary
What ships with it
18 files 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.
- .audits/2026-03-06/analysis.md 1.1 KB
- .audits/2026-03-06/audit.json 458 B
- .audits/2026-03-06/remediation-plan.md 2.1 KB
- .audits/latest 10 B
- assets/.yamllint 1.6 KB
- assets/certificate-crd-test.yaml 248 B
- assets/comprehensive-test.yaml 1.0 KB
- assets/deployment-test.yaml 501 B
- evals/scenario-01.md 3.8 KB
- evals/scenario-02.md 3.9 KB
- evals/scenario-03.md 4.0 KB
- evals/scenario-04.md 3.8 KB
- evals/scenario-05.md 3.7 KB
- references/k8s_best_practices.md 3.6 KB
- references/validation_workflow.md 13 KB
- scripts/detect_crd_wrapper.sh 1.0 KB runs code
- scripts/detect_crd.py 8.8 KB runs code
- scripts/setup_tools.sh 2.3 KB runs code
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.
- 4d ago First seen · 407 lines · 57 tokens per session scan A cba0cd1cf02d
k8s-yaml-validator is a skill published in the GitHub repository pantheon-org/tekhne (10 stars, last pushed today), licensed MIT. It adds 57 tokens to every session and 3,302 once invoked, about $0.0003 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-09-03.
Other skills, from other repositories
comet-github-ci-triage
A workflow for diagnosing failed GitHub Actions checks on a Comet pull request. GitHub Actions runs automated builds and tests; a pull request is a proposed code change waiting to be reviewed and merged.
ci-auto-fix
Diagnoses a failed CI check, classifies it with an explicit verdict (code-bug | workflow-bug | dep-bug | env-bug | flaky | unsure), confidence-gates the fix (>=90 auto, 80-89 ask, <80 escalate), applies it, pushes, and iteratively verifies until CI passes — reverting the last commit if a brand-new failure appears.…
fix-ci-until-green
Drive a failing GitHub Actions run to green in as few CI runs as possible, with a bounded fix-critique-commit-push-recheck loop that batches every evidenced fix into each push. Use when the user supplies a GitHub Actions run URL or run ID and wants the failure fixed, or asks to "make CI green", "fix the failing…
gh-fix-ci
Diagnoses failing or setup-stuck GitHub Actions checks on a PR, identifies root cause, and proposes or applies targeted fixes. Triggers when the user asks to fix CI, diagnose failing checks, fix a failing workflow, address GitHub Actions errors, get a green build, or continue PR queue work without waiting on unrelated…
ci-failure-triage
Diagnose failed CI runs, build logs, test output, deployment checks, or pipeline summaries and produce a root-cause hypothesis, reproduction path, likely owner, fix plan, and escalation guidance. Use when Codex needs to triage broken builds, flaky tests, failed checks, or release-blocking automation failures.
gh-fix-ci
Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use gh to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.