solidity-security

Overview of solidity-security skill

What solidity-security is for

The solidity-security skill is a focused audit and secure-coding guide for Solidity smart contracts. It is best used when you want an agent to review contract logic for common exploit classes, suggest safer patterns, and explain why a design is risky before code reaches production or a formal audit.

Who should install this skill

This skill fits:

• Solidity developers shipping contracts to mainnet or testnets
• auditors doing first-pass reviews
• teams preparing DeFi, token, vault, or admin-controlled contracts for external Security Audit
• engineers who want security feedback that is more structured than a generic “review this code” prompt

It is less useful for non-EVM projects or purely protocol-economic analysis.

The real job-to-be-done

Users do not just want a list of vulnerabilities. They want help turning rough goals like “check this vault for reentrancy and privilege issues” into a repeatable review flow covering exploit paths, safer implementations, and remediation priorities. That is where solidity-security is stronger than an ordinary prompt.

What makes solidity-security different

The skill is narrow and practical. Instead of broad blockchain advice, it centers core Solidity failure modes such as:

• reentrancy
• arithmetic edge cases
• access control mistakes
• unsafe external calls
• security-conscious implementation patterns

That makes it a good fit when precision matters more than breadth.

What to know before adopting

The repository is lightweight: the skill content lives mainly in SKILL.md, with no extra rules, scripts, or reference files. That is good for quick adoption, but it also means output quality depends heavily on the context you provide. If you give only “audit this contract,” expect generic findings. If you provide contract purpose, threat model, privileged roles, and key functions, the solidity-security skill becomes much more useful.

How to Use solidity-security skill

How to install solidity-security

Install from the repository with your skills-compatible client. A common pattern is:

npx skills add https://github.com/wshobson/agents --skill solidity-security

If your agent platform uses a different install mechanism, add the skill from:

https://github.com/wshobson/agents/tree/main/plugins/blockchain-web3/skills/solidity-security

What to read first in the repository

Start with:

• plugins/blockchain-web3/skills/solidity-security/SKILL.md

Because this skill has no supporting README.md, rules/, or references/ files in its folder, SKILL.md is the entire operating manual. Read its “When to Use This Skill” and vulnerability sections first to understand the review lens it applies.

What input the skill needs to work well

The solidity-security usage quality depends on concrete contract context. Provide:

• Solidity version
• contract files or key excerpts
• contract purpose
• user roles and privileged roles
• asset flows: who deposits, withdraws, mints, burns, liquidates, upgrades
• external integrations: oracles, ERC20s, bridges, routers, callbacks
• assumptions about trusted actors
• what kind of output you want: quick scan, deep audit checklist, exploit scenarios, or remediations

Without this, the skill can only produce a generic vulnerability lecture.

Best prompt shape for a first review

A strong starter prompt is:

“Use the solidity-security skill to review these contracts for reentrancy, access control, unsafe external calls, arithmetic or accounting mistakes, and other high-severity issues. For each finding, include impact, exploit path, affected functions, and a concrete remediation. Distinguish confirmed issues from areas needing more context.”

That prompt works because it asks for:

• specific classes of issues
• prioritized output
• exploit reasoning
• implementation advice
• uncertainty handling

How to turn a rough goal into a complete prompt

Weak prompt:

• “Check this Solidity code.”

Better prompt:

• “Use solidity-security for Security Audit preparation on this vault contract. Focus on withdrawal flow, share accounting, admin powers, pausing, upgradeability assumptions, and external token interactions. Identify critical and high findings first, then list medium-risk hardening opportunities.”

The better version narrows scope to business-critical surfaces, which improves signal and reduces filler.

Recommended workflow for audits

A practical solidity-security guide flow is:

1. Ask for a threat-model summary from the contract set.
2. Request a function-by-function risk map.
3. Deep-dive on state-changing external-call paths.
4. Review role-restricted functions and initialization logic.
5. Ask for remediation examples for top findings.
6. Re-run the skill on patched code and ask what risks remain.

This staged workflow usually produces better output than asking for one giant audit pass.

High-value review areas to emphasize

When invoking solidity-security, explicitly ask the agent to focus on:

• withdrawal and payout functions
• callback-capable token interactions
• role transfer and ownership logic
• initialization and upgrade paths
• accounting invariants
• oracle or pricing dependencies
• emergency controls
• assumptions around ERC20 compliance

These are the areas where shallow prompts often miss meaningful risk.

What the skill appears to cover best

Based on the source content, the skill is strongest on common Solidity vulnerability classes and secure implementation patterns, especially reentrancy and related defensive coding habits such as checks-effects-interactions. Use it as a security-focused coding and review assistant, not as a substitute for formal verification or protocol-level economic modeling.

Practical tips that improve output quality

To get better solidity-security usage results:

• paste the exact functions that move funds
• mark which roles are trusted and which are externally controlled
• note whether contracts are upgradeable or proxied
• ask for exploit prerequisites, not just bug names
• request severity ranking with rationale
• ask the model to separate code facts from assumptions

These small additions materially improve decision quality.

What not to expect from the skill

Do not expect the solidity-security skill to automatically:

• run tests
• inspect deployed bytecode
• prove invariants mathematically
• replace a full manual Security Audit
• detect ecosystem-specific issues you never mention

It is most effective as an expert review scaffold for code and architecture context you provide.

solidity-security skill FAQ

Is solidity-security good for Security Audit preparation?

Yes. solidity-security for Security Audit is a strong use case when you want to catch obvious and moderately subtle Solidity issues before paying for an external audit. It helps teams tighten code, document assumptions, and arrive at the audit with fewer preventable findings.

Is this better than a generic “audit my contract” prompt?

Usually yes. A generic prompt often returns a boilerplate list of smart contract risks. The solidity-security skill gives the agent a narrower security frame, which tends to improve focus on exploit paths, secure patterns, and remediation details.

Is solidity-security suitable for beginners?

Yes, with limits. Beginners can use it to learn common Solidity attack surfaces and safer coding patterns. But it should not be treated as a complete curriculum. If you are new, ask the skill to explain each finding in plain language and show secure alternatives.

When is solidity-security a poor fit?

It is a weak fit for:

• non-Solidity chains
• front-end wallet security
• tokenomics design review
• governance game theory
• production incident response without code context

For those jobs, use a broader blockchain security process or a different specialized skill.

Can it review one file or does it need a whole codebase?

It can review a single file, but results improve with surrounding context. For example, a vault contract without its token, oracle, access-control, or proxy context may look safe when key assumptions live elsewhere.

Does the skill cover only classic bugs?

No, but classic bugs are its center of gravity. Expect the strongest performance on known Solidity implementation risks rather than bespoke protocol-economic exploits. If your main concern is insolvency, oracle manipulation, or liquidation design, say so explicitly.

How to Improve solidity-security skill

Give the skill your threat model up front

The fastest way to improve solidity-security output is to define:

• attacker capabilities
• trusted roles
• protected assets
• unacceptable outcomes

Example:

• “Assume any external user is adversarial, admin key is trusted but fallible, and loss of user deposits is the top-risk outcome.”

This helps the agent prioritize real issues over style feedback.

Provide invariants, not just code

Strong inputs include system rules such as:

• total shares should never exceed claimable assets
• only governance can change fee parameters
• user withdrawals must not depend on untrusted callbacks

When you provide invariants, the skill can test logic against intended behavior instead of only scanning syntax patterns.

Ask for exploit narratives

A common failure mode is a flat list of findings without proof of importance. Improve this by asking:

• entry condition
• attack steps
• expected impact
• whether the issue is realistic or only theoretical

That forces the solidity-security skill to reason like an auditor, not a linter.

Make remediation requests specific

Do not ask only “how to fix this?” Ask for:

• minimal patch
• safer design alternative
• tradeoffs of each fix
• whether the patch changes gas costs or UX

Specific remediation prompts produce more actionable outputs than generic secure-coding advice.

Re-run on patched code

After the first pass, paste the revised function or contract and ask:

• what risk was removed
• what residual risk remains
• whether the fix introduced new edge cases
• what tests should be added

This is one of the highest-value ways to use solidity-security install time effectively after adoption.

Common failure modes to watch for

Even with the skill, watch for:

• overstating speculative vulnerabilities
• missing assumptions hidden in inherited contracts
• ignoring role-management details
• giving standard reentrancy advice where the deeper issue is accounting design
• treating all external calls as equally dangerous

You can reduce these errors by providing inheritance context and asking the model to cite the exact function path behind each claim.

Better prompts for deeper reviews

A strong second-round prompt:

“Use solidity-security to review only the withdrawal, reward-claim, and admin-setter paths. Ignore gas micro-optimizations. For each issue, cite the function, state variable, attacker capability required, exploit sequence, and the safest realistic remediation for this codebase.”

This works because it constrains scope and output format at the same time.

Pair the skill with tests and manual review

The best workflow is not skill-only. Use solidity-security to generate hypotheses, then verify them with:

• unit tests
• invariant tests
• fuzzing
• manual line-by-line review

That combination is much stronger than either ordinary prompting or static reading alone.

How to judge if the skill is helping

The solidity-security guide is working if it helps you:

• identify the most dangerous functions faster
• explain exploitability clearly
• produce better patch candidates
• prepare cleaner questions for external auditors
• reduce generic prompt guesswork

If output stays vague after two iterations, the usual cause is missing contract context, not the install itself.