tdg-personal/defi-amm-security
Security checklist for Solidity AMM contracts, liquidity pools, and swap flows. Covers reentrancy, CEI ordering, donation or inflation attacks, oracle manipulation, slippage, admin controls, and integer math.
84
84%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
82%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong, domain-specific description with excellent trigger term coverage and clear specificity about the security concerns it addresses. Its main weakness is the absence of an explicit 'Use when...' clause, which would help Claude know precisely when to select this skill. The description effectively carves out a distinct niche in DeFi/AMM security auditing.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when reviewing or auditing Solidity smart contracts for AMMs, DEXes, liquidity pools, or token swap mechanisms.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions/checks: reentrancy, CEI ordering, donation/inflation attacks, oracle manipulation, slippage, admin controls, and integer math. These are concrete, well-defined security concerns rather than vague abstractions. | 3 / 3 |
Completeness | Clearly answers 'what does this do' (security checklist covering specific vulnerability categories), but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied by the domain context. | 2 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a user would use: 'Solidity', 'AMM', 'liquidity pools', 'swap', 'reentrancy', 'slippage', 'oracle manipulation', 'inflation attacks'. These are precisely the terms a developer would mention when seeking a security review of DeFi contracts. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche: Solidity AMM contracts and liquidity pool security. The combination of DeFi-specific terms (AMM, swap flows, donation attacks, oracle manipulation) makes it very unlikely to conflict with general security or general Solidity skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
79%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, actionable security skill that provides concrete vulnerable/safe code pairs for critical AMM vulnerability patterns. Its main strengths are executable examples with real library imports and a comprehensive checklist. The main weaknesses are the lack of a clear audit workflow with validation checkpoints and the somewhat monolithic structure that could benefit from progressive disclosure into separate reference files.
Suggestions
Add a sequenced audit workflow section (e.g., '1. Run slither → 2. Review each entrypoint against checklist → 3. Fuzz critical paths → 4. Verify fixes') with explicit validation checkpoints and error recovery guidance.
Consider splitting detailed code examples for each vulnerability category into a referenced file (e.g., PATTERNS.md) and keeping only the checklist and one representative example in the main SKILL.md.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient throughout. It avoids explaining what AMMs are, what Solidity is, or how ERC-20 tokens work. Every section delivers specific patterns without unnecessary preamble, and the one-line explanations between code blocks add context without bloat. | 3 / 3 |
Actionability | Every vulnerability pattern includes executable Solidity code showing both the vulnerable and hardened versions. The audit tools section provides copy-paste-ready CLI commands. Import paths reference real libraries (OpenZeppelin, Uniswap v3) making the code directly usable. | 3 / 3 |
Workflow Clarity | The skill is structured as a checklist-plus-pattern library rather than a sequential workflow, which is appropriate for its purpose. However, the security checklist at the end lacks explicit validation/verification steps—there's no feedback loop for what to do when a check fails, and the audit tools section is disconnected from the checklist without guidance on sequencing (e.g., run slither first, then fuzz, then manual review). | 2 / 3 |
Progressive Disclosure | The content is well-organized with clear section headers and a logical flow from patterns to checklist to tools. However, at ~120 lines with 7 distinct vulnerability categories each containing code examples, some content (like the full oracle manipulation or admin controls examples) could be split into referenced files to keep the main skill leaner. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents