* Fix `allowed-tools` to use spec-compliant space-delimited strings Per the agentskills.io specification, `allowed-tools` must be a single string of space-delimited patterns, not a YAML list. Converted all 23 SKILL.md files from the `- Item` list format to the correct `"Item1 Item2"` string format. Also updated the frontmatter examples in CLAUDE.md and the workflow-skill-design skill template to match. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix remaining allowed-tools format in firebase-apk-scanner and workflow-skill-design docs - Convert firebase-apk-scanner from comma-separated to space-delimited - Update anti-patterns.md and tool-assignment-guide.md examples from YAML lists to space-delimited strings - Remove unnecessary quotes from SKILL.md template placeholder Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Cover commands, new SKILL.md files, and fix template placeholder Extends the previous spec-compliance fixes: * Convert command frontmatter (commands/*.md) — per Claude Code docs, command files use the same frontmatter as skills, so the same space-delimited rule applies. * Convert three SKILL.md files added since the original PR: mutation-testing, trailmark-structural, trailmark-summary. * Fix the placeholder in the workflow-skill-design template. The previous "[minimum tools needed, space-delimited]" was YAML flow-sequence syntax, which parses as a list — the opposite of what the placeholder claims. Replaced with a concrete-looking space-delimited example plus a comment. Zeroize-audit agent files still use `allowed-tools:` in YAML list form. They are intentionally excluded: per the project's own docs (workflow-skill-design references), agents declare tools with `tools:` (not `allowed-tools:`). Fixing those requires changing the field name as well as the format and is out of scope for this PR. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * zeroize-audit agents: switch allowed-tools to tools Subagents declare their tool allowlist via `tools:` (comma-separated), not `allowed-tools:` — see Claude Code's subagent docs and this repo's own designing-workflow-skills/SKILL.md:47: > Skills use `allowed-tools:` in frontmatter. Agents use `tools:` > in frontmatter. Before this change, the zeroize-audit agents declared their tool list under `allowed-tools:`, which Claude Code does not read for subagents. The field was effectively a no-op; the spawned agents had no tool restriction enforced. Renames the field on all 11 agents to `tools:` and reformats the YAML list as comma-separated to match the documented format and existing agents elsewhere in the repo (e.g. function-analyzer.md, spec-compliance-checker.md). Tool sets are unchanged. Behavior change: tools now actually constrain what each spawned agent can call. The lists are the ones the original author intended. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * skill-improver: convert command allowed-tools to space-delimited The two command files in plugins/skill-improver/commands/ still used the JSON flow-array format (`allowed-tools: ["..."]`), which the rest of this PR converted everywhere else. Convert them to the spec-compliant space-delimited string form for consistency. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Dan Guido <dan@trailofbits.com>
Entry Point Analyzer
A Claude skill for systematically identifying state-changing entry points in smart contract codebases to guide security audits.
Purpose
When auditing smart contracts, examining each file or function individually is inefficient. What auditors need is to start from entry points—the externally callable functions that represent the attack surface. This skill automates the identification and classification of state-changing entry points, excluding view/pure/read-only functions that cannot directly cause loss of funds or state corruption.
Supported Languages
| Language | File Extensions | Framework Support |
|---|---|---|
| Solidity | .sol |
OpenZeppelin, custom modifiers |
| Vyper | .vy |
Native patterns |
| Solana | .rs |
Anchor, Native |
| Move | .move |
Aptos, Sui |
| TON | .fc, .func, .tact |
FunC, Tact |
| CosmWasm | .rs |
cw-ownable, cw-controllers |
Access Classifications
The skill categorizes entry points into four levels:
- Public (Unrestricted) — Callable by anyone; highest audit priority
- Role-Restricted — Limited to specific roles (admin, governance, guardian, etc.)
- Review Required — Ambiguous access patterns needing manual verification
- Contract-Only — Internal integration points (callbacks, hooks)
Output
Generates a structured markdown report with:
- Summary table of entry point counts by category
- Detailed tables for each access level
- Function signatures with file:line references
- Restriction patterns and role assignments
- List of analyzed files
Usage
Trigger the skill with requests like:
- "Analyze the entry points in this codebase"
- "Find all external functions and access levels"
- "List audit flows for src/core/"
- "What privileged operations exist in this project?"
Directory Filtering
Specify a subdirectory to limit scope:
- "Analyze only
src/core/" - "Find entry points in
contracts/protocol/"
Role Detection
The skill infers roles from common patterns:
| Pattern | Detected Role |
|---|---|
onlyOwner, msg.sender == owner |
Owner |
onlyAdmin, ADMIN_ROLE |
Admin |
onlyGovernance, governance |
Governance |
onlyGuardian, onlyPauser |
Guardian |
onlyKeeper, onlyRelayer |
Keeper/Relayer |
onlyStrategy, strategist |
Strategist |
Dynamic checks (authorized[msg.sender]) |
Review Required |
Installation
/plugin install trailofbits/skills/plugins/entry-point-analyzer
License
See LICENSE.txt for terms.