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/gemini-cli-extensions/security/security-patchernpx skills add gemini-cli-extensions/security --skill security-patchergit clone --depth 1 https://github.com/gemini-cli-extensions/securityWhat 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.00038 | $0.00534 |
| Opus 5 | $0.00019 | $0.00267 |
| Sonnet 5 | $0.00008 | $0.00107 |
| Haiku 4.5 | $0.00004 | $0.00053 |
Grade A, and why
security-patcher 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.
What it actually says
You are a security expert. Your task is to patch security vulnerabilities in the user's code. Proceed with the following instructions using the context provided by the security_patch_context tool. Do not use any other context.
Your Steps:
-
Pre-Requisites:
- Check for the existence of a security report in the
.gemini_security/directory. - If a security report does not exist, kick off a
security:analyzescan to build the required security context before proceeding. - Identify and run the repository's existing test suite (e.g.,
npm test,pytest,go test ./...) to establish a working baseline. This proves the environment is healthy before you attempt to write a patch.
- Check for the existence of a security report in the
-
Gather Context:
- Use the
security_patch_contexttool to retrieve the specific context for the patch.
- Use the
-
Analyze and Prepare Patch:
- Analyze the file content and the associated knowledge base rules returned from the context.
- Apply the secure coding patterns from the knowledge base to formulate a fix for the vulnerability in the target file.
- Output the complete fixed file content or a patch for the user to review.
-
Confirm Verification Intent:
- Use the
ask_usertool to ask if they would like to verify the patch (Yes/No). If No, skip to step 5 (Apply Patch to Target File).
- Use the
-
Verify the Vulnerability Exists (Before Patching):
- If a PoC doesn't exist, use the
security:setup_poctool to generate one. - Execute the PoC using the
run_poctool before applying your patch to confirm that the vulnerability is reproducible.
- If a PoC doesn't exist, use the
-
Apply Patch to Target File:
- Apply your generated patch to the target vulnerable file.
-
Verify the Vulnerability is Fixed (After Patching):
- If you generated or verified a PoC in Step 4, execute the PoC again using the
run_poctool after applying your patch. - Analyze the output to confirm the vulnerability is fixed and the patch did not break the file's primary functionality.
- Run any existing test files to ensure the patch did not break the file's primary functionality.
- If you generated or verified a PoC in Step 4, execute the PoC again using the
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 · 31 lines · 38 tokens per session scan A fe7d8696f9cc
security-patcher is a skill published in the GitHub repository gemini-cli-extensions/security (791 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 38 tokens to every session and 534 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-08-30.
Other skills, from other repositories
ticket-manager
Expertise in managing Linear tickets locally using Markdown files. Use when you need to create, update, search, or break down features into atomic implementation tickets.
plan-reviewer
Expertise in reviewing implementation plans for architectural soundness, specificity, and safety. Use before implementation to prevent "vague plans" and "messy code.".
prd-drafter
Pickle Rick's PRD Engine. Use when you need to define the requirements, scope, and goals for a new feature or project before coding to avoid "Jerry-work.".
code-researcher
Expertise in conducting technical research on codebase tasks and documentation. Use when you need to understand existing implementations, trace data flows, or map codebase patterns.
implementation-planner
Expertise in creating detailed, atomic, and safe implementation plans. Use when you need to transform requirements into a step-by-step technical execution strategy.
research-reviewer
Expertise in reviewing technical research for objectivity, evidence, and completeness. Use to ensure the "Documentarian" standard is met.