菜单
Generate a security audit scope document from one or more GitHub repo URLs and/or API access descriptions. Outputs a 3-line protocol narrative (mission, user story, attacker story) followed by a scope table with NSLOC, focus areas, and days. Use when scoping a new audit engagement.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Live endpoint threat hunting skill. Systematically scans a system for malicious activity across all categories (Process, File, Network, Persistence, User Account, Registry, etc.) using only native OS tools. Covers macOS, Linux, and Windows at T1 (no privs) and T2 (sudo/admin) levels. Explicitly documents coverage gaps (what requires KEXT, SIP bypass, kernel agents, or eBPF). Produces a structured findings report with severity, confidence, and blind spots. Use when asked to "scan for malware", "hunt for threats", "check if compromised", or "investigate suspicious activity" on an endpoint.
Audit codebase to uncover critical issues explicitly without false positives
Sweeps DeFi protocol Safe multisig wallets for governance misconfigurations and security weaknesses. Given a protocol name, Safe address, or "sweep all", fetches live config and tx history from the Safe Transaction Service API, scores each Safe against a finding pattern library, and produces an audit-ready ranked report. Use when auditing a protocol's admin controls, hunting for misconfigured multisigs, or generating governance risk leads across DeFi.
Commits github changes to repository safely and professionally. use this before any commit made to github.
Takes the active conversation as reference to understand how a skill can be created, with all the lessons learned from the users need in the conversation.
Expert blockchain forensics assistant for investigators and auditors. Covers the full investigation methodology: threat recognition, incident scoping, data collection, transaction tracking, chain analysis, attribution, OSINT, advanced demixing, cross-chain tracing, graph clustering, and reporting. Guides users through investigations via targeted questions. Free and open-source tools are preferred and instructed at point of need. Paid tools are acknowledged but not required. Use when investigating hacks, stolen funds, laundering routes, wallet attribution, or crypto fraud.
| name | audit-scope |
| description | Generate a security audit scope document from one or more GitHub repo URLs and/or API access descriptions. Outputs a 3-line protocol narrative (mission, user story, attacker story) followed by a scope table with NSLOC, focus areas, and days. Use when scoping a new audit engagement. |
User provides one or more of:
No report-days input needed - report writing is hardcoded (see Constants).
Scope is measured in days. Do not attach monetary amounts to the output - days are the unit of measurement here.
For each GitHub repo URL provided:
/tmp/<repo-name>-audit via gh repo clonecloc <repo> --quiet --not-match-f="(?i)(spec|test)" --not-match-d="(test|spec|__tests__|__mocks__)" --include-lang=TypeScript,JavaScript,Kotlin,Java,Go,Python,Rust,Solidity,HCL (exclude test/spec files and dirs, case-insensitive; adjust --include-lang for the repo's stack)For API-only scope (no repo):
Read enough to understand:
Apply these automatically - do not ask user:
| Condition | Discount |
|---|---|
| Multiple repos audited back-to-back (streak) | -0.5d lift-off discount |
| Multiple repos share same domain/features (similarity) | -20-35% off affected component's days |
| Spec/rules doc in scope alongside backend that implements it | -1-2d off backend (domain fluency pre-built) |
Lift-off discount = negative row in table (streak saves ramp time). Similarity discount = bidirectional - applies whenever two components share significant overlapping attack surface, regardless of order. E.g. SDKs and backend sharing the same signing/API domain discount each other: SDKs get discounted because backend covers the server-side of the same flow; backend gets discounted because SDK work already mapped the signing trust boundary. Bake into the component day estimate directly (no separate row).
Base pace: ~300-400 NSLOC/day for deep manual security audit. Adjust for:
Do not pace all NSLOC uniformly. First split the repo into trust-boundary vs non-audited code, then only price the trust boundary at audit depth. Raw cloc NSLOC != auditable NSLOC. This is the #1 source of overquoting - especially on web frontends, where most lines are presentational or read-only.
*Stats mappers, APY/TVL math that only feeds charts, zustand stores, config/utils. Skim for leaked secrets, injection into outbound requests, and any value that feeds transaction sizing - then move on. Do NOT read line-by-line.Contract/SDK out of scope -> frontend crypto pace is faster, not slower. If the on-chain program or signing SDK lives in a separate repo (imported dependency, not vendored), the frontend only orchestrates pre-built instructions. Don't apply the ~200 NSLOC/day crypto pace to it - the frontend can only validate at the guard layer, so those passes are firm but quick. Flag the separate contract/SDK repo as its own potential line item (that's where fund-safety bugs actually live).
Before finalizing days, compare against typical engagement sizes below. These are calibration anchors - if a NSLOC-derived estimate lands well outside the range for its type, re-check the tiering in step 4 (usually display/read-only code priced at audit depth).
| Engagement type | Typical days |
|---|---|
| Red team engagement | ~10-25 |
| Security tool development services | ~15-20 |
| Cloud misconfiguration review | ~8-12 |
| Secure code review | ~10 |
| Low-level secure code review | ~10 |
| Web app penetration test | ~5-8 |
| Android app pentest | ~5 |
| SDK secure code review | ~3-5 |
| Miniapp with lean backend | ~3-4 |
| Incident response | ~2-5 |
| 2-day custom training (build time) | ~20 |
Web/frontend protocol audits track the "web app pentest" row (5-8d), not "secure code review" (~10d), unless the frontend vendors its own contracts/signing code.
Line 1 - Protocol mission + why audit needed:
<Protocol name> is a <what it does>. <Scope components> are/is <role in system> - <why a flaw here = business impact>, making it <risk framing for the engagement>.
Scope components must be woven into this line with clear business justification for auditing them.
Line 2 - User story:
A <user type> <does X> - <SDK/component> <does Y> and <delivers Z to downstream system>.
Line 3 - Attacker story + incentives:
Attacker targets <attack surface> to <attack goal> - enabling <business-critical impact e.g. fund theft, unauthorized access, data breach>.
Columns: Component | NSLOC | Focus Areas | Days
Row order:
Lift-off discount (streak) | - | - | -0.5Report writing | - | - | 1Focus areas per component:
Print narrative (3 lines), blank line, then table. Nothing else.
Protocol: Acme is a payments infrastructure API enabling businesses to move digital assets across chains. The SDKs (sdk-lang1, sdk-lang2) are the sole cryptographic trust boundary between a business's private keys and the Acme API - any signing flaw directly enables fund theft or unauthorized wallet creation, making them the highest-risk component in the integration stack.
User story: A fintech backend creates a wallet and signs a transaction step - the SDK constructs and stamps the activity payload locally, returning a signature the app posts to the Acme API.
Attacker story & incentives: Attacker targets the private key or signing flow to forge activity stamps - enabling unauthorized wallet creation or hijacking transactions to redirect funds to attacker-controlled addresses.
| Component | NSLOC | Focus Areas | Days |
|---|---|---|---|
| sdk-lang1 audit | 943 | P-256 stamp construction, key isolation, body serialization, input validation, logger redaction | 1.5 |
| sdk-lang2 audit (similarity discount) | 1,764 | Signing parity with sdk-lang1, JVM key handling, coroutine error propagation, serialization safety | 2 |
| Lift-off discount (streak) | - | - | -0.5 |
| Report writing | - | - | 1 |
| Total | 2,707 | 4 |