Borrowing it
Nothing to install: this file belongs to nikicat/secrets-dispatcher. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/nikicat/secrets-dispatcher/master/.claude/skills/secrets-rule/SKILL.mdgit clone --depth 1 https://github.com/nikicat/secrets-dispatcherWrote 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/nikicat/secrets-dispatcher/secrets-rule)<a href="https://agentmods.dev/skills/nikicat/secrets-dispatcher/secrets-rule"><img src="https://agentmods.dev/badge/skills/nikicat/secrets-dispatcher/secrets-rule/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/nikicat/secrets-dispatcher/secrets-rule"><img src="https://agentmods.dev/badge/skills/nikicat/secrets-dispatcher/secrets-rule.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.00103 | $0.01342 |
| Opus 5.5 | $0.00041 | $0.00537 |
| Sonnet 5.5 | $0.00021 | $0.00268 |
| Haiku 4.5 | $0.00010 | $0.00134 |
Grade A, and why
secrets-rule 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 — 131 lines — stays where its author put it; the contents beside it link to each section on GitHub.
secrets-dispatcher Trust Rule Management
Create or modify trust rules based on the user's request. The user may provide:
- A free-text description: "block evolution from accessing secrets"
- A request ID prefix from history: "b260def"
- A vague concern: "something is accessing my keyring"
Step 1: Understand the Request
Parse $ARGUMENTS (or the user's message if auto-triggered). Determine:
- Intent: block (deny), allow (approve), ignore, or investigate?
- Target: which application/process?
- Scope: all request types, or specific ones (search, get_secret, write, delete, unlock)?
If the intent is unclear, ask ONE focused question using AskUserQuestion. Don't ask about things you can resolve from history/logs.
Step 2: Gather Evidence
Run these in parallel to identify the exact process details:
In-memory history (most useful — has full process chain with exe paths):
secrets-dispatcher history -json
If a request ID prefix was given, filter to it:
secrets-dispatcher history -json | jq '.[] | select(.request.id | startswith("PREFIX"))'
Otherwise, search for entries matching the user's description — look at process names, exe paths, search_attributes, unit names.
Journald logs for the current session (shows request flow, denials, errors):
journalctl --user -u secrets-dispatcher.service --since today --no-pager | tail -200
From the evidence, extract:
sender_info.process_chain[].exe— full executable path (preferred for rules)sender_info.process_chain[].name— comm name (CAUTION: truncated to 15 chars by Linux)sender_info.unit_name— systemd unit if applicablerequest.type— what request types the process makesrequest.search_attributes— search patterns usedrequest.items[].attributes— secret attributes accessed
Step 3: Present Findings
Show the user a brief summary of what you found:
- The process exe path and chain
- What request types it made and how often
- What secrets/attributes it accessed
- Any existing rules that already match or partially overlap
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 · 131 lines · 103 tokens per session scan A 902230e652d3
secrets-rule is a skill published in the GitHub repository nikicat/secrets-dispatcher (12 stars, last pushed 2mo ago), licensed MIT. It adds 103 tokens to every session and 1,342 once invoked, about $0.0004 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-30.
Other skills, from other repositories
least-privilege-access-design
Analyze a system's access patterns and design least-privilege controls: classify data and APIs by risk, select the narrowest API surface for each operation, define authorization policies with multi-party approval for sensitive actions, establish emergency access override procedures, and optionally introduce a…
implementing-rbac-hardening-for-kubernetes
Harden Kubernetes Role-Based Access Control by implementing least-privilege policies, auditing role bindings, eliminating cluster-admin sprawl, and integrating external identity providers.
agt-policy-authoring
Create and validate a minimal AGT Copilot CLI policy tailored to the repository being inspected.
auditing-aws-s3-bucket-permissions
Systematically audit AWS S3 bucket permissions to identify publicly accessible buckets, overly permissive ACLs, misconfigured bucket policies, and missing encryption settings using AWS CLI, S3audit, and Prowler to enforce least-privilege data access controls.
cis-aws-database-4.2
Ensure Fine-Grained Access Control is implemented.
breaking-down-the-work
Splits scope into a product-first work breakdown that follows the 100% rule, keeps pieces from overlapping, uses outline numbers, and gives every piece a dictionary entry. Use when an epic, feature, or new subsystem needs a clean split into deliverables, or one source of truth before folders or work begin. Do not use…