测试助手
- 作者仓库星标 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
- 不需要
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: code-maturity-assessor
description: Systematic code maturity assessment using Trail of Bits' 9-category framework. Analyzes codebase…
category: 通用
runtime: 无特殊运行时
---
# code-maturity-assessor 输出预览
## PART A: 任务判断
- 适用问题:通用任务拆解、检查和交付。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Purpose / How This Works / Phase 1: Discovery”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于通用任务拆解、检查和交付,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Purpose / How This Works / Phase 1: Discovery”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文没有稳定的斜杠命令要求。安装验证后通常全局生效,直接在对话里点名这个 Skill 并描述任务即可。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“Purpose / How This Works / Phase 1: Discovery”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: code-maturity-assessor
description: Systematic code maturity assessment using Trail of Bits' 9-category framework. Analyzes codebase…
category: 通用
source: trailofbits/skills
---
# code-maturity-assessor
## 什么时候使用
- code-maturity-assessor 是一个通用扩展技能,按 SKILL 适合处理通用任务拆解、检查、交付和复盘,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继…
- 面向通用任务拆解、检查和交付,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Purpose / How This Works / Phase 1: Discovery」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "code-maturity-assessor" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Purpose / How This Works / Phase 1: Discovery
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Code Maturity Assessor
Purpose
Systematically assesses codebase maturity using Trail of Bits' 9-category framework. Provides evidence-based ratings and actionable recommendations.
Framework: Building Secure Contracts - Code Maturity Evaluation v0.1.0
How This Works
Phase 1: Discovery
Explores the codebase to understand:
- Project structure and platform
- Contract/module files
- Test coverage
- Documentation availability
Phase 2: Analysis
For each of 9 categories, I'll:
- Search the code for relevant patterns
- Read key files to assess implementation
- Present findings with file references
- Ask clarifying questions about processes I can't see in code
- Determine rating based on criteria
Phase 3: Report
Generates:
- Executive summary
- Maturity scorecard (ratings for all 9 categories)
- Detailed analysis with evidence
- Priority-ordered improvement roadmap
Rating System
- Missing (0): Not present/not implemented
- Weak (1): Several significant improvements needed
- Moderate (2): Adequate, can be improved
- Satisfactory (3): Above average, minor improvements
- Strong (4): Exceptional, only small improvements possible
Rating Logic:
- ANY "Weak" criteria → Weak
- NO "Weak" + SOME "Moderate" unmet → Moderate
- ALL "Moderate" + SOME "Satisfactory" met → Satisfactory
- ALL "Satisfactory" + exceptional practices → Strong
The 9 Categories
I assess 9 comprehensive categories covering all aspects of code maturity. For detailed criteria, analysis approaches, and rating thresholds, see ASSESSMENT_CRITERIA.md.
Quick Reference:
1. ARITHMETIC
- Overflow protection mechanisms
- Precision handling and rounding
- Formula specifications
- Edge case testing
2. AUDITING
- Event definitions and coverage
- Monitoring infrastructure
- Incident response planning
3. AUTHENTICATION / ACCESS CONTROLS
- Privilege management
- Role separation
- Access control testing
- Key compromise scenarios
4. COMPLEXITY MANAGEMENT
- Function scope and clarity
- Cyclomatic complexity
- Inheritance hierarchies
- Code duplication
5. DECENTRALIZATION
- Centralization risks
- Upgrade control mechanisms
- User opt-out paths
- Timelock/multisig patterns
6. DOCUMENTATION
- Specifications and architecture
- Inline code documentation
- User stories
- Domain glossaries
7. TRANSACTION ORDERING RISKS
- MEV vulnerabilities
- Front-running protections
- Slippage controls
- Oracle security
8. LOW-LEVEL MANIPULATION
- Assembly usage
- Unsafe code sections
- Low-level calls
- Justification and testing
9. TESTING & VERIFICATION
- Test coverage
- Fuzzing and formal verification
- CI/CD integration
- Test quality
For complete assessment criteria including what I'll analyze, what I'll ask you, and detailed rating thresholds (WEAK/MODERATE/SATISFACTORY/STRONG), see ASSESSMENT_CRITERIA.md.
Example Output
When the assessment is complete, you'll receive a comprehensive maturity report including:
- Executive Summary: Overall score, top 3 strengths, top 3 gaps, priority recommendations
- Maturity Scorecard: Table with all 9 categories rated with scores and notes
- Detailed Analysis: Category-by-category breakdown with evidence (file:line references)
- Improvement Roadmap: Priority-ordered recommendations (CRITICAL/HIGH/MEDIUM) with effort estimates
For a complete example assessment report, see EXAMPLE_REPORT.md.
Assessment Process
When invoked, I will:
Explore codebase
- Find contract/module files
- Identify test files
- Locate documentation
Analyze each category
- Search for relevant code patterns
- Read key implementations
- Assess against criteria
- Collect evidence
Interactive assessment
- Present my findings with file references
- Ask about processes I can't see in code
- Discuss borderline cases
- Determine ratings together
Generate report
- Executive summary
- Maturity scorecard table
- Detailed category analysis with evidence
- Priority-ordered improvement roadmap
Rationalizations (Do Not Skip)
| Rationalization | Why It's Wrong | Required Action |
|---|---|---|
| "Found some findings, assessment complete" | Assessment requires evaluating ALL 9 categories | Complete assessment of all 9 categories with evidence for each |
| "I see events, auditing category looks good" | Events alone don't equal auditing maturity | Check logging comprehensiveness, testing, incident response processes |
| "Code looks simple, complexity is low" | Visual simplicity masks composition complexity | Analyze cyclomatic complexity, dependency depth, state machine transitions |
| "Not a DeFi protocol, MEV category doesn't apply" | MEV extends beyond DeFi (governance, NFTs, games) | Verify with transaction ordering analysis before declaring N/A |
| "No assembly found, low-level category is N/A" | Low-level risks include external calls, delegatecall, inline assembly | Search for all low-level patterns before skipping category |
| "This is taking too long" | Thorough assessment requires time per category | Complete all 9 categories, ask clarifying questions about off-chain processes |
| "I can rate this without evidence" | Ratings without file:line references = unsubstantiated claims | Collect concrete code evidence for every category assessment |
| "User will know what to improve" | Vague guidance = no action | Provide priority-ordered roadmap with specific improvements and effort estimates |
Report Format
For detailed report structure and templates, see REPORT_FORMAT.md.
Structure:
Executive Summary
- Project name and platform
- Overall maturity (average rating)
- Top 3 strengths
- Top 3 critical gaps
- Priority recommendations
Maturity Scorecard
- Table with all 9 categories
- Ratings and scores
- Key findings notes
Detailed Analysis
- Per-category breakdown
- Evidence with file:line references
- Gaps and improvement actions
Improvement Roadmap
- CRITICAL (immediate)
- HIGH (1-2 months)
- MEDIUM (2-4 months)
- Effort estimates and impact
Ready to Begin
Estimated Time: 30-40 minutes
I'll need:
- Access to full codebase
- Your knowledge of processes (monitoring, incident response, team practices)
- Context about the project (DeFi, NFT, infrastructure, etc.)
Let's assess this codebase!
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核