Audit Scope Skill

Inputs

User provides one or more of:

• GitHub repo URL(s)
• API documentation / access description (no repo)
• Named scope components (e.g. "also include the webhook service")

No report-days input needed - report writing is hardcoded (see Constants).

Constants (hardcoded, never ask user)

• Report writing: always 1 day

Scope is measured in days. Do not attach monetary amounts to the output - days are the unit of measurement here.

Step-by-step execution

1. Ingest repos

For each GitHub repo URL provided:

• Clone to /tmp/<repo-name>-audit via gh repo clone
• Run cloc <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)
• Record NSLOC per repo (source lines only - exclude test/spec files, Markdown, YAML, Gradle, shell)
• Never estimate NSLOC manually - always run cloc

For API-only scope (no repo):

• NSLOC = N/A
• Estimate days from endpoint count and complexity description

2. Explore repo structure

Read enough to understand:

• What the component does (SDK? API server? webhook handler?)
• Core tech: cryptographic primitives, auth mechanisms, external dependencies
• Language-specific security surface (JVM, Node, etc.)
• Key files: entry point, signing/crypto logic, error handling, config/env

3. Identify discounts

Apply these automatically - do not ask user:

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).

4. Estimate days per component

Base pace: ~300-400 NSLOC/day for deep manual security audit. Adjust for:

• Cryptographic code: slower (~200 NSLOC/day)
• Boilerplate-heavy languages (Kotlin, Java): filter ~30% noise
• Framework-heavy TS backends (NestJS, etc.): DTOs, decorators, module definitions don't need line-by-line audit - pace ~400-500 NSLOC/day for those layers
• Narrow attack surface (signer-only, no HTTP): faster
• Wide attack surface (HTTP API, DB, auth): slower

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.

• Excluded entirely (not in NSLOC, not priced): presentational React/Vue UI, charts, visualizers, layout/page JSX, styles, assets. These have no trust boundary. On a frontend this is often 60-80% of cloc's count.
• Skim only (~0.5d flat, not per-NSLOC): read-only data-fetch and display logic - react-query hooks that fetch stats, *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.
• Full audit depth: the actual trust boundary - transaction/instruction construction, signing & approval flow, output/slippage guards, auth, proxy/SSRF surface, input validation on server routes. This is usually a minority of the lines but where all the findings are.

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).

4b. Sanity-check against common scope sizes

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).

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.

5. Build narrative (3 lines, before table)

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>.

6. Build scope table

Columns: Component | NSLOC | Focus Areas | Days

Row order:

1. One row per auditable component (repo or API surface)
2. Lift-off discount row (if streak): Lift-off discount (streak) | - | - | -0.5
3. Similarity discount already baked into component days (no separate row)
4. Report writing row: Report writing | - | - | 1
5. Total row: sum all days

Focus areas per component:

• Name the specific crypto primitives, key-handling patterns, auth mechanisms, serialization paths, and language-specific risks
• 4-6 items, comma-separated

7. Output

Print narrative (3 lines), blank line, then table. Nothing else.

Example output shape

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.

Expected output table example:

Edge cases

• Single repo, no streak: no lift-off row, no similarity discount
• 3+ repos: apply lift-off once (-0.5d), apply similarity discount to each repo after the first
• API-only scope: NSLOC = N/A, days from endpoint/complexity estimate, note estimation method
• Mixed repo + API: repo gets cloc, API gets endpoint-based estimate; both in same table
• Web/frontend repo: expect raw cloc to be dominated by presentational UI. Report NSLOC as the auditable surface (trust boundary + skim), not raw cloc, and say so. The trust boundary is: what the app builds & signs, output/slippage guards, wallet/session handling, and any server/proxy routes (SSRF, allowlists, rate-limit, secret exposure). A frontend audit is typically 4-6 days even at 20k+ raw NSLOC; if the estimate exceeds that, check whether display/read-only code got priced at audit depth.