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/drn/dots/deploy-auditnpx skills add drn/dots --skill deploy-auditgit clone --depth 1 https://github.com/drn/dotsWhat 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.00076 | $0.01376 |
| Opus 5 | $0.00038 | $0.00688 |
| Sonnet 5 | $0.00015 | $0.00275 |
| Haiku 4.5 | $0.00008 | $0.00138 |
Grade A, and why
deploy-audit 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 2d 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 — 144 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Pre-Deploy Risk Audit
Audit the commits pending between a base branch and a deployed branch/tag, assess the risk of each change, and open the GitHub compare diff for human review. This is an informational audit — it does not block or change anything on its own.
Arguments
$ARGUMENTS- Optional:<base>..<deployed>(e.g.master..production), or just the deployed ref if the base is the repo's default branch. If omitted, detect candidates from context below and ask the user to confirm.
Context
- Remote: !
git remote get-url origin 2>/dev/null | head -1 - Default branch: !
git branch -r 2>/dev/null | grep -oE 'origin/(main|master)' | head -1 - Remote branches: !
git branch -r 2>/dev/null | grep -viE 'HEAD|dependabot' | head -30 - Recent tags: !
git tag --sort=-creatordate 2>/dev/null | head -10
Instructions
Work through the following steps in order, gathering enough evidence at each one to give the final risk report real teeth rather than a generic checklist.
Step 1: Determine the two refs
Parse $ARGUMENTS for <base>..<deployed>. If only one ref is given, treat it
as the deployed ref and use the detected default branch as base. If nothing is
given, look at the remote branches/tags in Context above for likely
candidates (a production/release/deploy branch, or the most recent tag)
and ask the user to confirm the base and deployed refs before proceeding.
Refs and the org/repo derived from the remote URL are treated as untrusted
input for shell purposes: if either contains characters outside
[A-Za-z0-9._/-], do not interpolate it directly into a shell command —
quote it and confirm with the user first.
Run git fetch origin for both refs to ensure they are current.
Step 2: Enumerate pending commits
git log --oneline <deployed>..<base>
git diff --stat <deployed>..<base>
If this returns nothing, report "Nothing pending — <deployed> and <base>
are in sync" and stop.
Read full commit messages for risk signal:
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.
- 2d ago First seen · 144 lines · 76 tokens per session scan A 299591d3a2fb
deploy-audit is a skill published in the GitHub repository drn/dots (23 stars, last pushed 4d ago), licensed MIT. It adds 76 tokens to every session and 1,376 once invoked, about $0.0004 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-30.
Other skills, from other repositories
dsh-ci-test-reliability
Design, review, and diagnose DeepSeek Harness tests and fixtures that can fail nondeterministically under CI concurrency, shared host resources, clocks, process-global state, subprocesses, network listeners, or asynchronous teardown. Use when adding or changing tests with those risks, investigating flaky CI, or…
ci-security-scanning-with-strix
Add security scanning to CI/CD with Strix — GitHub Actions, GitLab CI, or any pipeline — so every pull request gets a diff-scoped AI pentest that blocks vulnerable code before it merges, with results as PR comments and SARIF uploaded to code scanning. Covers both the self-hosted open-source CLI (runs in your runner)…
multi-agent-release-manager
Cleans up the workspace, formats code, runs presubmit checks, and uploads CLs to Gerrit.
dsh-web-pre-push-checks
Use before pushing, opening or updating a pull request, or claiming dsh-web checks pass. Selects the required repository gates and diff-specific generation, build, and GUI evidence.
babysit
Same-session monitoring loop for PRs, CI runs, tickets, and deployments using the monitorstart / monitorupdate / autonudgestop MCP tools. The loop re-injects your check instructions into THIS session on an idle interval — same context, same tools — and works from dashboard chat, Slack threads, and Discord DMs. Use…
azsdk-common-pipeline-analysis
Analyze Azure SDK CI/CD pipeline failures into a structured diagnosis, and define the required output format. Load this skill before calling azsdkanalyzepipeline, which returns raw failure data that this skill interprets and formats. USE FOR: "pipeline failed", "build failure", "CI check failing", "tests failing in…