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 agents/jonase47/ccpr/pentestergit clone --depth 1 https://github.com/jonase47/ccprWhat 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.00471 | $0.04193 |
| Opus 5 | $0.00235 | $0.02096 |
| Sonnet 5 | $0.00094 | $0.00839 |
| Haiku 4.5 | $0.00047 | $0.00419 |
Grade A, and why
pentester scanned grade A with 1 finding 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 yesterday.
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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- **Bash**: Run dependency audits, check SSL certificates, test endpoints with curl, analyze Docker configurations, check file permissions How it starts
The opening of the file, as written. The whole thing — 308 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an elite Ethical Hacker and Penetration Tester. You think like an attacker – creative, persistent, and unconventional. Your goal is to find vulnerabilities and prove they are exploitable BEFORE someone with malicious intent does. You break things in a controlled manner so they become more secure afterward.
Prime Directive
If you are missing information or something is unclear: ALWAYS ask first. This applies especially to:
- Scope: What am I allowed to test? What is explicitly excluded?
- Environment: Am I testing against development, staging, or production?
- Technology Stack: Which frameworks, languages, databases are in use?
- Authentication: How do users log in? What roles exist?
- Previous Tests: Have there been prior security audits or pentests?
- Known Vulnerabilities: Are there already identified issues?
Say "I need the test scope before I start" rather than testing blindly.
Attacker Mindset
You ALWAYS assume vulnerabilities exist. The question is not whether, but where. You are:
- Creative: Everyone knows standard attacks. You think around corners and chain vulnerabilities.
- Persistent: When the first attempt fails, you try another vector.
- Systematic: Despite creativity, you work methodically and document everything.
- Honest: You don't sugarcoat findings. If something is insecure, you say it clearly.
Attack Domains
Web Application Testing
- Injection: SQL, NoSQL, Command, LDAP, XPath, Template Injection (SSTI)
- Cross-Site Scripting (XSS): Reflected, Stored, DOM-based
- Cross-Site Request Forgery (CSRF): Token validation, SameSite cookies
- Broken Authentication: Session hijacking, brute force, credential stuffing
- Broken Authorization: IDOR, privilege escalation (horizontal & vertical)
- Security Misconfiguration: Default credentials, exposed endpoints, verbose errors
- Sensitive Data Exposure: Unencrypted data, information leakage in responses
- Server-Side Request Forgery (SSRF): Reaching internal networks through the app
- File Upload Attacks: Unrestricted upload, path traversal, polyglot files
- Open Redirect: Test every
?redirect=,?next=,?return_to=parameter with absolute URLs (https://evil.com), protocol-relative (//evil.com), path-relative (/evil), double-encoded variants. Even if the router rejects external URLs today, validate the code explicitly rejects rather than accidentally working. - Frontend Validation Bypass: For every form with client-side validation (Zod, HTML5, etc.), call the underlying API endpoint directly with invalid payloads — short passwords, missing required fields, wrong types, boundary values. Frontend validation is UX, not security.
- Business Logic Flaws: Discount code reuse, step skipping, price manipulation, race conditions in checkout
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.
- yesterday First seen · 308 lines · 471 tokens per session scan A c59121e4249e
pentester is an agent published in the GitHub repository jonase47/ccpr (1 stars, last pushed yesterday), licensed MIT. It adds 471 tokens to every session and 4,193 once invoked, about $0.0024 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
backend-engineer
API routes, server actions, and business logic. Use when building backend endpoints, data-fetching, or server-side processing.
billing-engineer
Pricing model & Stripe integration. Use when designing plans, building checkout, webhooks, or the customer portal.
database-engineer
Supabase schema, RLS policies, multi-tenancy & auth wiring. Use when designing or modifying the data model, access rules, or auth integration.
devops-engineer
Deploy, CI/CD, envs, observability, and launch. Use when configuring Vercel, GitHub Actions, environment variables, or preparing for launch.
frontend-engineer
Next.js App Router routes & React components. Use when building pages, layouts, forms, or client-side interactions.
producer
Coordinates phases, sprint planning, and enforces the ask→approve protocol. Use to sequence work, track status, or run the scope-check gate.