entry-point-analyzer
by trailofbitsentry-point-analyzer helps map state-changing entry points in smart contract codebases for security audit work. It identifies externally callable functions that modify state, groups them by access level, and excludes view, pure, and other read-only paths. Use this entry-point-analyzer guide when you need a focused call-surface inventory for Solidity, Vyper, Solana, Move, TON, or CosmWasm projects.
This skill scores 77/100, which means it is a solid but not top-tier listing candidate. Directory users get a clearly scoped, triggerable workflow for identifying state-changing smart-contract entry points across several major languages, with enough rules and examples to reduce guesswork compared with a generic prompt.
- Explicit trigger conditions for audits, entry points, access control patterns, and privileged operations.
- Strong operational clarity: excludes read-only functions and provides language-specific detection rules and examples.
- Good agent leverage from structured references for Solidity, Vyper, Solana, Move, TON, and CosmWasm.
- No install command or helper scripts, so adoption depends on reading the SKILL.md and references directly.
- Scope is intentionally narrow: it helps map entry points, not broader vulnerability detection or exploit generation.
Overview of entry-point-analyzer skill
The entry-point-analyzer skill helps you map the state-changing attack surface of a smart contract codebase before you start a deeper security review. It is built for audits where the first question is not “is there a bug?” but “which externally reachable functions can change state, and who can call them?”
What entry-point-analyzer is for
Use the entry-point-analyzer skill when you need a practical entry-point inventory for Solidity, Vyper, Solana, Move, TON, or CosmWasm projects. It is especially useful for a entry-point-analyzer for Security Audit workflow: access control review, privileged operation discovery, and audit scoping.
What it filters out
This skill deliberately excludes read-only code paths, pure helpers, and internal-only functions. That makes it more decision-useful than a generic prompt when you want a security-oriented call surface, not a full code walkthrough.
Who benefits most
Best fit: security auditors, protocol engineers, and agents that need to identify public or privileged mutation paths quickly. If your goal is exploit research, gas profiling, or general code quality, this is the wrong tool.
How to Use entry-point-analyzer skill
Install and locate the skill
Use the entry-point-analyzer install flow from the trailofbits/skills plugin repository:
npx skills add trailofbits/skills --skill entry-point-analyzer
Then read the skill entry file first. For this repo, the most useful path is plugins/entry-point-analyzer/skills/entry-point-analyzer/SKILL.md.
Build a strong input prompt
The entry-point-analyzer usage pattern works best when you give it the repository, language, and review goal up front. A strong prompt looks like:
“Analyze this Solidity protocol and list every state-changing external/public entry point, grouped by access control and deployment-time behavior. Exclude view and pure functions. Highlight admin-only, role-gated, fallback, and constructor paths.”
If the codebase mixes languages, say so explicitly. If you only want one module, contract, or package, name it.
Read the support files first
For real output quality, do not stop at SKILL.md. In this skill, the supporting references often clarify language-specific entry-point rules:
references/solidity.mdreferences/vyper.mdreferences/solana.mdreferences/move-aptos.mdreferences/move-sui.mdreferences/ton.mdreferences/cosmwasm.md
These files are where you verify edge cases like fallback handlers, transaction-only functions, message receivers, and access-control patterns.
Workflow that produces useful results
Start by asking for a codebase-wide entry-point map, then follow up with a narrowed pass on the highest-risk entries. For example, after the first inventory, ask for only admin-gated functions, only upgrade or migration paths, or only functions that touch ownership and authorization state. That sequence makes the skill more useful than a one-shot summary.
entry-point-analyzer skill FAQ
Is entry-point-analyzer only for smart contracts?
Yes. The skill is designed for smart contract codebases and chain-specific entry-point conventions. It is not meant for standard backend, frontend, or general-purpose application code.
How is this different from a normal prompt?
A normal prompt often misses language-specific entry-point rules, especially across Solidity, Move, TON, and CosmWasm. The entry-point-analyzer skill gives you a narrower target: state-changing external surfaces only, with exclusion rules that reduce noise.
Is entry-point-analyzer beginner friendly?
Yes, if your goal is to understand the external mutation surface of a contract. It is less friendly if you expect it to find vulnerabilities by itself, because the skill is for scoping and classification rather than exploit detection.
When should I not use it?
Do not use entry-point-analyzer when you need read-only analysis, generic code review, or exploit development. It is also a poor fit if the codebase is not a smart contract system or if you need every function, including internal helpers.
How to Improve entry-point-analyzer skill
Give the analyzer the right boundary
The best entry-point-analyzer usage starts with a clear target scope: one repo, one protocol, or one deployment package. If you include unrelated packages, the result will be noisier and harder to trust.
Specify the access-control question you care about
Users usually want one of three things: “what can anyone call?”, “what is admin-only?”, or “what changes state during deployment or migration?” Ask for that explicitly. The skill is strongest when the output is grouped by callability and privilege, not just listed by file.
Provide language-specific context when it matters
For multi-language repos, tell the skill which framework conventions to prioritize. For example, mention Anchor for Solana, entry_point patterns for CosmWasm, or receive handlers for TON. That reduces false negatives on framework-specific entry paths.
Iterate from inventory to review
First ask for the complete entry-point map. Then ask for the top 5 riskiest functions, the authorization checks they rely on, and any state-changing paths that look unusual or underprotected. This two-step approach gives better results than asking for a full security audit in one pass, because the skill’s output is easiest to validate when it starts from a clean surface map.