The weak version of this article says Claude Code can enhance Ethereum audits with Foundry. That is too broad to trust.

The useful version asks a sharper question: when can an agent help turn a vulnerability finding into a submission-ready mainnet-fork PoC without inventing addresses, skipping the causal chain, or replacing deployed contracts with mocks?

foundry-poc-mainnet-fork is worth saving because the repository answers that question as a skill, not as a prompt trick. Its SKILL.md defines required inputs, a mandatory reading order, finding categories, hard rules, proof shapes, style rules, and an output checklist. The examples are not runnable fixtures. They are pattern references for different bug shapes. That is the article: a narrow procedure for making Claude useful in high-stakes PoC writing, with clear places to stop.

The problem is not Solidity syntax

Most models can write Solidity-shaped code. That is not the hard part of an audit PoC.

The hard part is proving the right thing. A weak PoC can fork the wrong block, start from an already-impacted actor, mock the protocol, prank a role that should have been reached through the real permission path, or assert a midpoint instead of the realized loss. Those files look technical and still fail as evidence.

The rescued article should therefore stop selling the skill as productivity. The real value is discipline. It tells Claude where it may act, what evidence it must request first, and which shortcuts are disallowed.

What the source actually is

The repository is a Claude Code skill named foundry-poc-mainnet-fork. The README frames it for smart contract security researchers who need a Foundry PoC against real deployed contracts. Installation is the normal skill path:

cd ~/.claude/skills
git clone https://github.com/cholakovvv/foundry-poc-mainnet-fork.git

After restarting Claude Code, the user verifies loading with:

/skills

That matters because this is not a general MCP server, scanner, or audit platform. It is an instruction package. Claude should invoke it only when the task matches the skill description: write a Foundry PoC that reproduces a real smart contract vulnerability against deployed EVM contracts on a mainnet fork.

The required-input gate is the first quality filter

The skill refuses to write code until the user has supplied four things:

1. Full vulnerability description: root cause, attack path, impact.
2. Chain: ethereum, arbitrum, base, optimism, polygon, bnb, avalanche, or chain ID.
3. Fork target: latest, a block number, or a timestamp converted to a block.
4. Real deployed addresses for every contract in the attack path, labeled by role.

This is exactly why the original seed should be rescued. A good Codex/Claude article should teach readers to treat missing inputs as a stop condition. If the finding is summary-level, ask for the full report. If addresses are missing, ask. If the timestamp is not mapped to a block, ask. If the chain is ambiguous, ask.

For audit work, refusal is a feature. An agent that guesses protocol addresses is not helping.

Classification before code

The strongest rule in the source is the classification step. Before it writes a test, Claude must state whether the finding is:

(a) frozen historical impact
(b) forward-looking risk
(a+b) both

That category changes where the PoC starts. A frozen historical issue may correctly fork after the bad state already exists. A forward-looking issue must start from a safe actor and reproduce a new instance of the vulnerable state. A mixed case can mention existing affected value, but the primary proof should still reproduce the forward-looking chain.

This is a practical guard against a common model mistake: using a past broken state as evidence for a bug that is supposed to affect future users. In a bounty report, that distinction changes severity and credibility.

The hard rules are review hooks

The SKILL.md hard rules are concrete enough for a human reviewer to check:

- Foundry only.
- Real deployed contracts only.
- `vm.createSelectFork(...)` is the first statement in `setUp()`.
- Execute the full causal chain end to end.
- No mocks.
- No minimal protocol reimplementations.
- No guessed addresses.
- No `vm.store` shortcuts unless a limitation is explicitly documented.

This is how a skill becomes useful beyond one session. The reviewer does not need to read Claude's private reasoning. They can inspect the generated test file and ask: where is the fork, which addresses are constants, which contract calls are real, what actor starts the chain, and what final assertion proves impact?

Proof shape depends on impact

The examples show why the article should include proof-shape guidance.

For theft or pool drain, a revert is not the proof. The test needs balance deltas. The pool drain example ends with attacker value-token gain and a pool-near-zero assertion. For routing DoS, the example separates a revert proof from a stranding proof. For freeze, the examples README describes attempting recovery at the point where recovery should be possible and proving it fails while quantifying stranded value.

A practical review checklist looks like this:

Theft: attacker balance after > attacker balance before.
Pool drain: attacker gain plus pool balance near zero.
Freeze: recovery path reverts or returns the wrong value, with affected value quantified.
DoS: the next legitimate call fails or returns zero when it should succeed.
Privilege escalation: unauthorized caller exercises a permission that should be gated.

The article should teach readers to reject PoCs that only prove an intermediate state.

A safe prompt shape

A good user prompt should make the skill's gates explicit:

Using the foundry-poc-mainnet-fork skill, write a Foundry PoC for this finding.

Finding:
[paste full finding]

Chain: ethereum
Fork: block 24900000
RPC env var: MAINNET_RPC_URL
Addresses:
- Target protocol: 0x...
- Affected pool: 0x...
- Token: 0x...
- Admin or keeper role: 0x...

Before writing code, state the category, starting actor, fork block, and causal chain.
If any required address or chain fact is missing, stop and ask.
After code, return the exact forge command with -vvvv.

That prompt is not long for style. It mirrors the source's operating contract. It gives Claude less room to guess.

Run the generated PoC before believing it

The README says the skill was validated across four production bounty findings and aims to pass forge test -vvvv on the first try or flag a blocker. Treat that as maintainer evidence, not as a guarantee.

The adoption gate is local output:

forge test -vvvv --match-test test_<ShortVulnName>

A passing test is still not enough by itself. The reviewer should read the trace and the assertions. Did the test fork the intended chain and block? Did the attacker or legitimate actor call the same contracts that would be called on-chain? Did a shortcut bypass the protocol pipeline? Does the final assertion encode the vulnerability, or merely confirm setup?

Where this skill should not be used

The source is intentionally narrow, and the article should preserve that narrowness.

Do not use it for Solana, Cosmos, Aptos, Move, or non-EVM chains. Do not use it for Hardhat tests. Do not use it for fuzz or invariant harnesses. Do not use it for local-state unit tests. Do not use it when the report is too vague to identify contracts, chain, fork target, and causal chain.

Also do not use it as a substitute for an auditor. It can structure a PoC, but it cannot make an ambiguous finding true. If the model cannot verify a deployed address or the causal path needs protocol knowledge that is not in context, stopping is the correct output.

Embargo and disclosure boundaries

Bug bounty findings often include private protocol details. A team should decide where the finding text can be sent before using any AI-assisted workflow.

The minimal policy:

- Do not paste embargoed findings into an unapproved model environment.
- Keep real addresses only if they are already public or approved for the tool context.
- Store generated PoCs inside the audit repo, not a shared scratch directory.
- Remove accidental private data from prompts and traces before sharing externally.
- Attach forge output and the final test file to the review, not a prose claim.

The skill makes Claude more useful. It does not remove disclosure obligations.

How to adopt it without lowering the bar

A team can trial the skill in one afternoon:

1. Install it in a local Claude Code skills directory.
2. Pick one already-disclosed EVM finding with known addresses.
3. Ask the skill to classify before writing any code.
4. Compare the generated causal chain with the human-written report.
5. Run `forge test -vvvv`.
6. Review proof shape, shortcuts, address constants, and final assertions.
7. Only then try it on an active bounty workspace.

If the skill saves boilerplate but weakens proof quality, do not adopt it. If it forces clearer inputs and produces reviewable first drafts, it belongs in the security research toolkit.

Save the article as a skill playbook. foundry-poc-mainnet-fork is useful because it narrows Claude Code to a specific audit job: classify the finding, require real addresses, fork real state, execute the causal chain, and prove impact with assertions that reviewers can inspect.

Practical takeaway

Use foundry-poc-mainnet-fork only when the finding, chain, fork target, and real contract addresses are known. Make Claude state the category and causal chain before code, run the generated test with forge test -vvvv, and reject any PoC that guesses addresses, uses mocks, bypasses the protocol path, or proves only a midpoint.