agentsclimarketplace

Guidelines advisor

Skill bg-szy/TOP-SKILLS/skills/skills/guidelines-advisor

Smart contract development advisor based on Trail of Bits' best practices. Analyzes codebase to generate documentation/specifications, review architecture, check upgradeability patterns, assess implementation quality, identify pitfalls, review dependencies, and evaluate testing. Provides actionable recommendations.From its SKILL.md

Install
npx -y skills add bg-szy/TOP-SKILLS --skill guidelines-advisor

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

8.3 KB, ~1.7k tokens by cl100k_base, as published. Nobody here has run it

Guidelines Advisor

Purpose

Systematically analyzes the codebase and provides guidance based on Trail of Bits' development guidelines:

  1. Generate documentation and specifications (plain English descriptions, architectural diagrams, code documentation)
  2. Optimize on-chain/off-chain architecture (only if applicable)
  3. Review upgradeability patterns (if your project has upgrades)
  4. Check delegatecall/proxy implementations (if present)
  5. Assess implementation quality (functions, inheritance, events)
  6. Identify common pitfalls
  7. Review dependencies
  8. Evaluate test suite and suggest improvements

Framework: Building Secure Contracts - Development Guidelines


How This Works

Phase 1: Discovery & Context

Explores the codebase to understand:

  • Project structure and platform
  • Contract/module files and their purposes
  • Existing documentation
  • Architecture patterns (proxies, upgrades, etc.)
  • Testing setup
  • Dependencies

Phase 2: Documentation Generation

Helps create:

  • Plain English system description
  • Architectural diagrams (using Slither printers for Solidity)
  • Code documentation recommendations (NatSpec for Solidity)

Phase 3: Architecture Analysis

Analyzes:

  • On-chain vs off-chain component distribution (if applicable)
  • Upgradeability approach (if applicable)
  • Delegatecall proxy patterns (if present)

Phase 4: Implementation Review

Assesses:

  • Function composition and clarity
  • Inheritance structure
  • Event logging practices
  • Common pitfalls presence
  • Dependencies quality
  • Testing coverage and techniques

Phase 5: Recommendations

Provides:

  • Prioritized improvement suggestions
  • Best practice guidance
  • Actionable next steps

Assessment Areas

I analyze 11 comprehensive areas covering all aspects of smart contract development. For detailed criteria, best practices, and specific checks, see ASSESSMENT_AREAS.md.

Quick Reference:

  1. Documentation & Specifications

    • Plain English system descriptions
    • Architectural diagrams
    • NatSpec completeness (Solidity)
    • Documentation gaps identification
  2. On-Chain vs Off-Chain Computation

    • Complexity analysis
    • Gas optimization opportunities
    • Verification vs computation patterns
  3. Upgradeability

    • Migration vs upgradeability trade-offs
    • Data separation patterns
    • Upgrade procedure documentation
  4. Delegatecall Proxy Pattern

    • Storage layout consistency
    • Initialization patterns
    • Function shadowing risks
    • Slither upgradeability checks
  5. Function Composition

    • Function size and clarity
    • Logical grouping
    • Modularity assessment
  6. Inheritance

    • Hierarchy depth/width
    • Diamond problem risks
    • Inheritance visualization
  7. Events

    • Critical operation coverage
    • Event naming consistency
    • Indexed parameters
  8. Common Pitfalls

    • Reentrancy patterns
    • Integer overflow/underflow
    • Access control issues
    • Platform-specific vulnerabilities
  9. Dependencies

    • Library quality assessment
    • Version management
    • Dependency manager usage
    • Copied code detection
  10. Testing & Verification

    • Coverage analysis
    • Fuzzing techniques
    • Formal verification
    • CI/CD integration
  11. Platform-Specific Guidance

    • Solidity version recommendations
    • Compiler warning checks
    • Inline assembly warnings
    • Platform-specific tools

For complete details on each area including what I'll check, analyze, and recommend, see ASSESSMENT_AREAS.md.


Example Output

When the analysis is complete, you'll receive comprehensive guidance covering:

  • System documentation with plain English descriptions
  • Architectural diagrams and documentation gaps
  • Architecture analysis (on-chain/off-chain, upgradeability, proxies)
  • Implementation review (functions, inheritance, events, pitfalls)
  • Dependencies and testing evaluation
  • Prioritized recommendations (CRITICAL, HIGH, MEDIUM, LOW)
  • Overall assessment and path to production

For a complete example analysis report, see EXAMPLE_REPORT.md.


Deliverables

I provide four comprehensive deliverable categories:

1. System Documentation

  • Plain English descriptions
  • Architectural diagrams
  • Documentation gaps analysis

2. Architecture Analysis

  • On-chain/off-chain assessment
  • Upgradeability review
  • Proxy pattern security review

3. Implementation Review

  • Function composition analysis
  • Inheritance assessment
  • Events coverage
  • Pitfall identification
  • Dependencies evaluation
  • Testing analysis

4. Prioritized Recommendations

  • CRITICAL (address immediately)
  • HIGH (address before deployment)
  • MEDIUM (address for production quality)
  • LOW (nice to have)

For detailed templates and examples of each deliverable, see DELIVERABLES.md.


Assessment Process

When invoked, I will:

  1. Explore the codebase

    • Identify all contract/module files
    • Find existing documentation
    • Locate test files
    • Check for proxies/upgrades
    • Identify dependencies
  2. Generate documentation

    • Create plain English system description
    • Generate architectural diagrams (if tools available)
    • Identify documentation gaps
  3. Analyze architecture

    • Assess on-chain/off-chain distribution (if applicable)
    • Review upgradeability approach (if applicable)
    • Audit proxy patterns (if present)
  4. Review implementation

    • Analyze functions, inheritance, events
    • Check for common pitfalls
    • Assess dependencies
    • Evaluate testing
  5. Provide recommendations

    • Present findings with file references
    • Ask clarifying questions about design decisions
    • Suggest prioritized improvements
    • Offer actionable next steps

Rationalizations (Do Not Skip)

RationalizationWhy It's WrongRequired Action
"System is simple, description covers everything"Plain English descriptions miss security-critical detailsComplete all 5 phases: documentation, architecture, implementation, dependencies, recommendations
"No upgrades detected, skip upgradeability section"Upgradeability can be implicit (ownable patterns, delegatecall)Search for proxy patterns, delegatecall, storage collisions before declaring N/A
"Not applicable" without verificationPremature scope reduction misses vulnerabilitiesVerify with explicit codebase search before skipping any guideline section
"Architecture is straightforward, no analysis needed"Obvious architectures have subtle trust boundariesAnalyze on-chain/off-chain distribution, access control flow, external dependencies
"Common pitfalls don't apply to this codebase"Every codebase has common pitfallsSystematically check all guideline pitfalls with grep/code search
"Tests exist, testing guideline is satisfied"Test existence ≠ test qualityCheck coverage, property-based tests, integration tests, failure cases
"I can provide generic best practices"Generic advice isn't actionableProvide project-specific findings with file:line references
"User knows what to improve from findings"Findings without prioritization = no action planGenerate prioritized improvement roadmap with specific next steps

Notes

  • I'll only analyze relevant sections (won't hallucinate about upgrades if not present)
  • I'll adapt to your platform (Solidity, Rust, Cairo, etc.)
  • I'll use available tools (Slither, etc.) but work without them if unavailable
  • I'll provide file references and line numbers for all findings
  • I'll ask questions about design decisions I can't infer from code

Ready to Begin

What I'll need:

  • Access to your codebase
  • Context about your project goals
  • Any existing documentation or specifications
  • Information about deployment plans

Let's analyze your codebase and improve it using Trail of Bits' best practices!

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most architecture codebase skills give in ~1.7k tokens

Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07

  • Ask the user which candidate to explorein 45 of 811, across 15 files
  • Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
  • Read any relevant architecture decision records firstin 31 of 811, across 8 files
  • Use exact glossary terms in every suggestionin 30 of 811, across 10 files
  • Accept dependencies instead of creating themin 24 of 811, across 5 files
  • Include before and after visualisations for each candidatein 24 of 811, across 5 files
  • Read the domain glossary before exploringin 24 of 811, across 6 files
  • Return results instead of producing side effectsin 23 of 811, across 4 files
  • Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
  • Introduce seams only where things varyin 22 of 811, across 3 files
  • Reduce the number of methodsin 21 of 811, across 2 files
  • Design deep modules with small interfacesin 21 of 811, across 3 files

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,790. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.