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 niels-emmer/myace --skill devsecops-checklistgit clone --depth 1 https://github.com/niels-emmer/myaceWrote 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/niels-emmer/myace/devsecops-checklist)<a href="https://agentmods.dev/skills/niels-emmer/myace/devsecops-checklist"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/devsecops-checklist/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/niels-emmer/myace/devsecops-checklist"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/devsecops-checklist.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.00036 | $0.00766 |
| Opus 5 | $0.00018 | $0.00383 |
| Sonnet 5 | $0.00007 | $0.00153 |
| Haiku 4.5 | $0.00004 | $0.00077 |
Grade A, and why
DevSecOps Checklist 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 8d 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 — 31 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
A security review without a structure tends to catch whatever the reviewer happens to think of that day and miss whatever they don't. This checklist gives a repeatable set of categories to walk through explicitly for any infrastructure change, so coverage doesn't depend on what's top of mind. It's the working tool behind the security-auditor agent, but it's usable by anyone reviewing an IaC or pipeline diff.
When to use it
For any change touching: identity and access, secrets, network configuration, data storage, container images, dependencies, or CI/CD pipeline definitions. Skip it for changes with none of the above (e.g., a pure documentation change) — mark the whole review N/A rather than force-fitting categories that don't apply.
The checklist
Walk each category and mark it PASS (verified, no issue), FAIL (issue found — blocking), or N/A (doesn't apply to this diff), with a one-line note for anything not PASS/N/A:
- Identity — Does the change use managed identity (Azure Managed Identity, AWS IAM roles, GCP Workload Identity Federation) over long-lived keys? Are IAM roles scoped to least privilege (no
*actions, no*resources where avoidable)? Is the blast radius of each grant proportionate to what it's for? - Secrets — Are there any hardcoded credentials, API keys, or tokens in this diff? Are secrets injected at deploy time from a secrets manager, never baked into artifacts, config files, or logs? Is there a rotation path for any new secret?
- Network exposure — Are resources private by default? Any public IP,
0.0.0.0/0ingress, or open bucket ACL? Is ingress restricted to the sources that actually need it (security groups, NSGs, WAF rules)? - Data protection — Is data encrypted at rest and in transit? Are encryption keys managed (KMS/Key Vault) rather than defaulting to provider-managed where the data warrants it? Is backup/retention configured for stateful data?
- Supply chain — Are container images scanned for CVEs? Are base images minimal and pinned? Are dependencies pinned and from trusted sources? Is there an SBOM for production images?
- Pipeline integrity — Are CI/CD secrets scoped to the jobs that need them? Are pipeline definitions protected from untrusted PRs (no secret exposure on
pull_requestfrom forks)? Is the pipeline itself reviewed like code? - Compliance mapping — Does the change touch regulated data or workloads (PCI, HIPAA, GDPR, CIS benchmarks)? Is the mapping to the relevant standard explicit rather than assumed?
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.
- 8d ago First seen · 31 lines · 36 tokens per session scan A d95d8175fea9
DevSecOps Checklist is a skill published in the GitHub repository niels-emmer/myace (1 stars, last pushed 5d ago), licensed MIT. It adds 36 tokens to every session and 766 once invoked, about $0.0002 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
loom-ci-cd
Designs and implements CI/CD pipelines for automated testing, builds, deployment, and security scanning.
keel
Measure whether a codebase's verification actually touches the world, or whether it is checking itself. Keel gathers the verification edges it can read in a target (GitHub Actions, CircleCI, GitLab CI, Travis, package scripts, Makefile, Rakefile, pyproject and a dozen tool configs) — and reports the surfaces it…
pre-merge
The CI gate. Takes a feature branch from "eng says done" to "PR open against staging with green checks". Runs the project's preflight-resolved pipeline from devkit/policy.json components[]: sync → parallel correctness + security waves → coverage → regression tail → security/migration → PRD-consistency → open PR. Emits…
merge
The ship gate — the only skill that merges. --staging merges the feature→staging PR on green CI, deploys, verifies, emits a human test script and stamps the staging sign-off on approval. --production ships the double-confirmed release to main and deploys production. Never self-certifies staging; nothing reaches main…
loom-fluxcd
GitOps continuous delivery toolkit for Kubernetes with Flux CD.
google-cloud-slo-alert-configuration
Configures PromQL-based Service Level Objective (SLO) alerting policies for Google Cloud resources registered in App Hub or individually specified. Generates Terraform output. Use when the user asks to configure an SLO or Service Level Objective. Don't use for standard alerting policies.