安全审计
- 作者仓库星标 5,723
- 叉子 499
- 作者更新于 2026年6月15日 16:05
- 作者仓库 skills
- 领域
- 工程开发
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @trailofbits · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- macOS · Linux · Windows
- 底层运行要求
- Node.js
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: audit-prep-assistant
description: Prepares codebases for security review using Trail of Bits' checklist. Helps set review goals, r…
category: 工程开发
runtime: Node.js
---
# audit-prep-assistant 输出预览
## PART A: 任务判断
- 适用问题:代码实现、重构、调试或代码审查。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Purpose / The Preparation Process / Step 1: Set Review Goals”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于代码实现、重构、调试或代码审查,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Purpose / The Preparation Process / Step 1: Set Review Goals”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文没有稳定的斜杠命令要求。安装验证后通常全局生效,直接在对话里点名这个 Skill 并描述任务即可。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“Purpose / The Preparation Process / Step 1: Set Review Goals”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: audit-prep-assistant
description: Prepares codebases for security review using Trail of Bits' checklist. Helps set review goals, r…
category: 工程开发
source: trailofbits/skills
---
# audit-prep-assistant
## 什么时候使用
- audit-prep-assistant 是一个工程开发方向的技能,扩展 Agent 在写代码、做 review、跑测试这类场景下的能力 适合处理工程开发场景下的代码实现、调试、重构、测试或代码审查,核心价值是把输入、判断、执行、验证和…
- 面向代码实现、重构、调试或代码审查,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Purpose / The Preparation Process / Step 1: Set Review Goals」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "audit-prep-assistant" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Purpose / The Preparation Process / Step 1: Set Review Goals
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> Node.js | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Audit Prep Assistant
Purpose
Helps prepare for a security review using Trail of Bits' checklist. A well-prepared codebase makes the review process smoother and more effective.
Use this: 1-2 weeks before your security audit
The Preparation Process
Step 1: Set Review Goals
Helps define what you want from the review:
Key Questions:
- What's the overall security level you're aiming for?
- What areas concern you most?
- Previous audit issues?
- Complex components?
- Fragile parts?
- What's the worst-case scenario for your project?
Documents goals to share with the assessment team.
Step 2: Resolve Easy Issues
Runs static analysis and helps fix low-hanging fruit:
Run Static Analysis:
For Solidity:
slither . --exclude-dependencies
For Rust:
dylint --all
For Go:
golangci-lint run
For Go/Rust/C++:
# CodeQL and Semgrep checks
Then I'll:
- Triage all findings
- Help fix easy issues
- Document accepted risks
Increase Test Coverage:
- Analyze current coverage
- Identify untested code
- Suggest new tests
- Run full test suite
Remove Dead Code:
- Find unused functions/variables
- Identify unused libraries
- Locate stale features
- Suggest cleanup
Goal: Clean static analysis report, high test coverage, minimal dead code
Step 3: Ensure Code Accessibility
Helps make code clear and accessible:
Provide Detailed File List:
- List all files in scope
- Mark out-of-scope files
- Explain folder structure
- Document dependencies
Create Build Instructions:
- Write step-by-step setup guide
- Test on fresh environment
- Document dependencies and versions
- Verify build succeeds
Freeze Stable Version:
- Identify commit hash for review
- Create dedicated branch
- Tag release version
- Lock dependencies
Identify Boilerplate:
- Mark copied/forked code
- Highlight your modifications
- Document third-party code
- Focus review on your code
Step 4: Generate Documentation
Helps create documentation:
Flowcharts and Sequence Diagrams:
- Map primary workflows
- Show component relationships
- Visualize data flow
- Identify critical paths
User Stories:
- Define user roles
- Document use cases
- Explain interactions
- Clarify expectations
On-chain/Off-chain Assumptions:
- Data validation procedures
- Oracle information
- Bridge assumptions
- Trust boundaries
Actors and Privileges:
- List all actors
- Document roles
- Define privileges
- Map access controls
External Developer Docs:
- Link docs to code
- Keep synchronized
- Explain architecture
- Document APIs
Function Documentation:
- System and function invariants
- Parameter ranges (min/max values)
- Arithmetic formulas and precision loss
- Complex logic explanations
- NatSpec for Solidity
Glossary:
- Define domain terms
- Explain acronyms
- Consistent terminology
- Business logic concepts
Video Walkthroughs (optional):
- Complex workflows
- Areas of concern
- Architecture overview
How I Work
When invoked, I will:
- Help set review goals - Ask about concerns and document them
- Run static analysis - Execute appropriate tools for your platform
- Analyze test coverage - Identify gaps and suggest improvements
- Find dead code - Search for unused code and libraries
- Review accessibility - Check build instructions and scope clarity
- Generate documentation - Create flowcharts, user stories, glossaries
- Create prep checklist - Track what's done and what's remaining
Adapts based on:
- Your platform (Solidity, Rust, Go, etc.)
- Available tools
- Existing documentation
- Review timeline
Rationalizations (Do Not Skip)
| Rationalization | Why It's Wrong | Required Action |
|---|---|---|
| "README covers setup, no need for detailed build instructions" | READMEs assume context auditors don't have | Test build on fresh environment, document every dependency version |
| "Static analysis already ran, no need to run again" | Codebase changed since last run | Execute static analysis tools, generate fresh report |
| "Test coverage looks decent" | "Looks decent" isn't measured coverage | Run coverage tools, identify specific untested code paths |
| "Not much dead code to worry about" | Dead code hides during manual review | Use automated detection tools to find unused functions/variables |
| "Architecture is straightforward, no diagrams needed" | Text descriptions miss visual patterns | Generate actual flowcharts and sequence diagrams |
| "Can freeze version right before audit" | Last-minute freezing creates rushed handoff | Identify and document commit hash now, create dedicated branch |
| "Terms are self-explanatory" | Domain knowledge isn't universal | Create comprehensive glossary with all domain-specific terms |
| "I'll do this step later" | Steps build on each other - skipping creates gaps | Complete all 4 steps sequentially, track progress with checklist |
Example Output
When I finish helping you prepare, you'll have concrete deliverables like:
=== AUDIT PREP PACKAGE ===
Project: DeFi DEX Protocol
Audit Date: March 15, 2024
Preparation Status: Complete
---
## REVIEW GOALS DOCUMENT
Security Objectives:
- Verify economic security of liquidity pool swaps
- Validate oracle manipulation resistance
- Assess flash loan attack vectors
Areas of Concern:
1. Complex AMM pricing calculation (src/SwapRouter.sol:89-156)
2. Multi-hop swap routing logic (src/Router.sol)
3. Oracle price aggregation (src/PriceOracle.sol:45-78)
Worst-Case Scenario:
- Flash loan attack drains liquidity pools via oracle manipulation
Questions for Auditors:
- Can the AMM pricing model produce negative slippage under edge cases?
- Is the slippage protection sufficient to prevent sandwich attacks?
- How resilient is the system to temporary oracle failures?
---
## STATIC ANALYSIS REPORT
Slither Scan Results:
✓ High: 0 issues
✓ Medium: 0 issues
⚠ Low: 2 issues (triaged - documented in TRIAGE.md)
ℹ Info: 5 issues (code style, acceptable)
Tool: slither . --exclude-dependencies
Date: March 1, 2024
Status: CLEAN (all critical issues resolved)
---
## TEST COVERAGE REPORT
Overall Coverage: 94%
- Statements: 1,245 / 1,321 (94%)
- Branches: 456 / 498 (92%)
- Functions: 89 / 92 (97%)
Uncovered Areas:
- Emergency pause admin functions (tested manually)
- Governance migration path (one-time use)
Command: forge coverage
Status: EXCELLENT
---
## CODE SCOPE
In-Scope Files (8):
✓ src/SwapRouter.sol (456 lines)
✓ src/LiquidityPool.sol (234 lines)
✓ src/PairFactory.sol (389 lines)
✓ src/PriceOracle.sol (167 lines)
✓ src/LiquidityManager.sol (298 lines)
✓ src/Governance.sol (201 lines)
✓ src/FlashLoan.sol (145 lines)
✓ src/RewardsDistributor.sol (178 lines)
Out-of-Scope:
- lib/ (OpenZeppelin, external dependencies)
- test/ (test contracts)
- scripts/ (deployment scripts)
Total In-Scope: 2,068 lines of Solidity
---
## BUILD INSTRUCTIONS
Prerequisites:
- Foundry 0.2.0+
- Node.js 18+
- Git
Setup:
```bash
git clone https://github.com/project/repo.git
cd repo
git checkout audit-march-2024 # Frozen branch
forge install
forge build
forge test
Verification: ✓ Build succeeds without errors ✓ All 127 tests pass ✓ No warnings from compiler
DOCUMENTATION
Generated Artifacts: ✓ ARCHITECTURE.md - System overview with diagrams ✓ USER_STORIES.md - 12 user interaction flows ✓ GLOSSARY.md - 34 domain terms defined ✓ docs/diagrams/contract-interactions.png ✓ docs/diagrams/swap-flow.png ✓ docs/diagrams/state-machine.png
NatSpec Coverage: 100% of public functions
DEPLOYMENT INFO
Network: Ethereum Mainnet Commit: abc123def456 (audit-march-2024 branch) Deployed Contracts:
- SwapRouter: 0x1234...
- PriceOracle: 0x5678... [... etc]
PACKAGE READY FOR AUDIT ✓ Next Step: Share with Trail of Bits assessment team
---
## What You'll Get
**Review Goals Document**:
- Security objectives
- Areas of concern
- Worst-case scenarios
- Questions for auditors
**Clean Codebase**:
- Triaged static analysis (or clean report)
- High test coverage
- No dead code
- Clear scope
**Accessibility Package**:
- File list with scope
- Build instructions
- Frozen commit/branch
- Boilerplate identified
**Documentation Suite**:
- Flowcharts and diagrams
- User stories
- Architecture docs
- Actor/privilege map
- Inline code comments
- Glossary
- Video walkthroughs (if created)
**Audit Prep Checklist**:
- [ ] Review goals documented
- [ ] Static analysis clean/triaged
- [ ] Test coverage >80%
- [ ] Dead code removed
- [ ] Build instructions verified
- [ ] Stable version frozen
- [ ] Flowcharts created
- [ ] User stories documented
- [ ] Assumptions documented
- [ ] Actors/privileges listed
- [ ] Function docs complete
- [ ] Glossary created
---
## Timeline
**2 weeks before audit**:
- Set review goals
- Run static analysis
- Start fixing issues
**1 week before audit**:
- Increase test coverage
- Remove dead code
- Freeze stable version
- Start documentation
**Few days before audit**:
- Complete documentation
- Verify build instructions
- Create final checklist
- Send package to auditors
---
## Ready to Prep
Let me know when you're ready and I'll help you prepare for your security review!
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核