npx claudepluginhub joranhonig/grimoireThis skill uses the workspace's default tool permissions.
Assist security researchers in writing clear, effective proof-of-concept code that
examples/price-oracle-fork-test.mdexamples/reentrancy-foundry-poc.mdexamples/sqli-python-poc.mdexamples/ssrf-curl-poc.mdreferences/config-issues.mdreferences/crypto-vulns.mdreferences/forge-poc-templates.mdreferences/general-principles.mdreferences/logic-flaws.mdreferences/memory-corruption.mdreferences/poc-formats.mdreferences/race-conditions.mdreferences/smart-contracts.mdreferences/web-application-vulns.mdscripts/validate-poc.shGuides PoC exploit development for confirmed vulnerabilities in whitebox pentesting, with language recommendations, Python templates, and HTTP request patterns.
Validates user-proposed attack hypotheses on smart contracts by tracing paths, checking guards, preconditions, and known issues for exploitability.
Guides writing effective fuzzing harnesses for security testing to uncover vulnerabilities. Useful for security audits and fuzz-based vulnerability discovery.
Share bugs, ideas, or general feedback.
Assist security researchers in writing clear, effective proof-of-concept code that demonstrates discovered vulnerabilities. PoCs serve as evidence for project maintainers to understand, reproduce, and fix security issues. Every PoC produced under this skill assumes an authorized security research context — pentesting engagements, bug bounty programs, coordinated disclosure, or CTF challenges.
This skill exists because unstructured "write me a PoC" prompts succeed roughly 60% of the time. The opinionated structure here — fixed phases, explicit vulnerability-class references, approach confirmation gates — raises that to approximately 90% one-shot success by front-loading the decisions that cause agent confusion.
A PoC is proof, not a suggestion. It transforms a hypothesis ("I think this is exploitable") into a fact ("here is the exploit running"). Theoretical descriptions are insufficient. If it cannot be run and observed to succeed, it is not done.
Minimum viable proof. Demonstrate the issue exists and its impact. Do not build a full exploit toolkit, do not chain unrelated bugs, do not add features beyond what proves the point.
Benign payloads only. alert(1), sleep(), id, whoami. Never destructive. This
is non-negotiable.
Parameterized targets. localhost, $TARGET, environment variables. Never hardcoded
production URLs. The maintainer must be able to point the PoC at their own test
environment.
Impact communication. Especially for smart contracts: demonstrate monetary impact. Measure balances before and after. Print profit. Reviewers and triagers respond to concrete numbers, not abstract descriptions.
You are responsible for your PoCs. Agents make mistakes. Always review the generated code, verify it demonstrates what you think it demonstrates, and never run it against production without explicit authorization.
When this skill is activated, create a todo list from the following steps. Mark each task in_progress before starting it and completed when done. Use descriptions from the detailed sections below.
- [ ] 1. Gather vulnerability details — study the issue and impacted code, establish vuln class, root cause, attack surface, prerequisites, and impact. Consider dispatching a librarian for external references. Confirm with user.
- [ ] 2. Define exploit flow — formulate goal condition, determine mono/poly flow, sketch steps if multi-step. Confirm with user.
- [ ] 3. Determine PoC approach — choose test case vs script, for smart contracts decide fork/unit test and whether to use forge-poc-templates. Confirm with user.
- [ ] 4. Write the PoC — dispatch a gnome with the full briefing from phases 1-3 to implement the PoC. Review gnome output and confirm with user.
- [ ] 5. Review before delivery — dispatch a familiar to independently verify the PoC against the review checklist. Present familiar's assessment to user for final approval.
Follow these steps in order when writing a proof of concept.
Before writing any code, establish the following:
If any detail is unclear, ask the user before proceeding. A PoC built on incorrect assumptions wastes time.
Study both the impacted code and the issue description provided by the user, make sure to understand the exploit flow deeply.
Librarian. If the vulnerability involves external protocols, specifications, or known vulnerability patterns, consider dispatching a librarian agent to retrieve relevant documentation, prior findings, or security advisories. This is especially useful for protocol-level bugs (e.g., ERC specs, DeFi invariants) where the codebase alone doesn't tell the full story.
Check in with the user before continuing!
With the vulnerability details established, determine how the flaw can be demonstrated.
goal condition
The purpose of a PoC is to demonstrate and test the validity of a bug, but also to demonstrate it's impact. Study the potential impact of the issue and determine what the minimum viable proof of impact is. Formulate a goal condition that's a clear demonstration of the impact:
flow
Determine whether the exploit has multiple steps or whether it requires just a single one.
mono some proof of concepts comprise a single step. A reflected XSS for example might be demonstrated with a single curl statement. poly some proof of concepts comprise multiple steps, especially those formulated as unit tests.
Study the vulnerability and determine which (mono or poly) is necessary to reach the PoC goal condition.
If multiple steps are required, sketch out the exploit flow step by step.
Check in with the user, have them review the flow you designed and leverage their input to adapt.
Select the minimal demonstration that proves the vulnerability exists and conveys its impact. Follow the principle of minimum viable proof — demonstrate the issue without going beyond what is necessary.
Identify the vulnerability class from step 1 and consult the matching reference file:
| Vulnerability Class | Reference File |
|---|---|
| SQL injection, XSS, SSRF, auth bypass, IDOR | references/web-application-vulns.md |
| Buffer overflow, use-after-free, format string | references/memory-corruption.md |
| Weak randomness, ECB, padding oracle, hardcoded secrets | references/crypto-vulns.md |
| TOCTOU, concurrent request races | references/race-conditions.md |
| Business logic flaws | references/logic-flaws.md |
| Misconfiguration, exposed services | references/config-issues.md |
| Smart contract vulnerabilities | references/smart-contracts.md |
| Smart contract (flash loan, reentrancy, price manipulation) | references/forge-poc-templates.md |
| Other / unlisted | references/general-principles.md |
Read the matching reference file before choosing an approach — it contains templates and
conventions specific to the vulnerability class. For general format principles that apply
to all classes, also consult references/general-principles.md and references/poc-formats.md.
Primary PoC approaches:
Test Case Proof of Concepts
Analyze whether it is possible to write the proof of concept as a test case to extend an existing test suite. Determine the best place to put the proof of concept code if that's the case. Then ask the user if they would like to extend the test suite and if this location is correct.
When the target is a smart contract, ask the user whether to use a fork test (live on-chain
state) or a unit test (self-contained, synthetic state) before proceeding. Also determine
whether forge-poc-templates (Immunefi's PoC library) would be useful — it provides base
contracts for flash loans, reentrancy, price manipulation, and balance tracking. Always ask
the user whether to use it, and give a recommendation based on the exploit pattern. Consult
references/smart-contracts.md for approach selection, templates, and conventions, and
references/forge-poc-templates.md for the forge-poc-templates API reference.
Alternative Approaches
The preferred method (after test cases) is a single python script that leverages click and loguru.
Notes
When multiple approaches work, prefer the one that is simplest to reproduce for the maintainer receiving the report.
Confirm
Always confirm the PoC approach with the user.
Delegate to a gnome agent. By this point all decisions have been made — the vulnerability is understood, the exploit flow is designed, and the approach is confirmed. Dispatch a gnome (subagent) to implement the PoC in an isolated context. This keeps the orchestration context clean from implementation details and preserves context for the review phase.
Gnome briefing. Provide the gnome with:
examples/ directory that best matches the chosen approachGnome instructions. The gnome must follow all implementation guidelines below and report back with: the implemented PoC, a summary of decisions made during implementation, and any blockers or assumptions it had to make.
Implementation guidelines (included in gnome briefing):
Structure every PoC with these elements:
Header block (comment at top of file) or comment for the test case:
Title: [Short descriptive title]
Affected: [Component, version, file/endpoint]
Impact: [One-line impact statement]
Author: [Researcher name/handle]
Use the comment standard that best applies for the language/ framework that the PoC is written in.
This means natspec for solidity, javadoc for java, etc.
Implementation rules:
alert(1) or <img src=x> for XSS, sleep() for SQL injection, id or whoami for
command injection, 127.0.0.1 for SSRF. Avoid destructive payloads.[+] Vulnerability confirmed: server returned injected content or [-] Target does not appear vulnerable.// == [ Section Name ] == to let readers quickly skim and distinguish preamble/setup from
the core exploit logic.
Important: Never run the PoC against a production environment without asking the user!
Confirm
Once the gnome returns, review its output for obvious issues and present the completed PoC to the user. Walk them through the implementation and confirm it matches the agreed approach, covers the full exploit flow, and produces clear output.
Delegate to a familiar agent. Dispatch a familiar (subagent using a high-reasoning model) to independently review the PoC produced in phase 4. The familiar acts as a skeptical reviewer — it verifies rather than assumes.
Familiar briefing. Provide the familiar with:
Familiar review checklist. The familiar must verify each item and report its assessment:
Present the familiar's review alongside the PoC to the user for final approval before delivery.
All reference files are listed in the vulnerability-class-to-reference table in step 3. Consult the matching reference before choosing an approach.
For worked examples demonstrating each PoC approach (curl, Python script, Foundry unit
test, Foundry fork test with forge-poc-templates), see the examples/ directory.