agentleFS
iktok90-designiktok90-design/ai-smart-contract-auditor/skills/confidence-scoring/SKILL.md

confidence-scoring

Skill36 starsChanged 5 months agoMITView on GitHub

Always-on meta-skill — for every finding produced, attach a confidence level (HIGH/MEDIUM/LOW) and a reasoning trace. Activate on every /audit, /audit-deep, /audit-changes, /audit-live, /quick-scan invocation.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every finding includes a "How I reached this conclusion" snippet:

    line 35
  2. Distinctive:

    Don't mark every finding HIGH to look thorough.

    line 75
  3. Distinctive:

    Don't mark a real, well-evidenced finding LOW to be cautious — that defeats the purpose.

    line 76
  4. Distinctive:

    Don't downgrade Critical severity to compensate for low confidence — they're orthogonal axes.

    line 77

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Confidence scoring (meta-skill)

Per-finding confidence is what separates a noisy linter from a usable auditor. Always attach confidence.

Confidence levels

HIGH

  • Pattern matches exactly with no ambiguous preconditions.
  • Working exploit possible (or already drafted via [[exploit-poc-writer]]).
  • Affected line is reachable from a public/external function with no role gating.
  • Cross-verified by attacker subagent or /verify-finding.
  • Historical incident matches the same pattern at this severity.

MEDIUM

  • Pattern matches but exploit requires non-trivial preconditions:
    • Specific token type (rebasing / fee-on-transfer)
    • Specific chain configuration (sequencer down on L2, oracle behavior)
    • Multi-actor coordination
  • Reachability through trusted-only call paths.
  • One specialist subagent confirms, another offers a benign explanation.

LOW

  • Pattern theoretically present but practical exploitability uncertain.
  • Heavy reliance on assumptions about external integrations not auditable.
  • Defense-in-depth gaps with no clear attack.
  • Conflicting evidence between passes (in /audit-strict).

Reasoning trace requirement

Every finding includes a "How I reached this conclusion" snippet:

Reasoning:
  1. Function withdraw() at Vault.sol:140 sends ether via low-level call.
  2. State update (balance[msg.sender] = 0) happens after the call (CEI violated).
  3. Receiver address is user-controlled (msg.sender).
  4. No nonReentrant modifier on the function.
  5. No external mitigation in surrounding code.
  Conclusion: classic reentrancy, exploitable in a single tx.
  Cross-check: attacker subagent independently constructed a PoC (passing).
  → Confidence: HIGH

When to downgrade

Always downgrade if:

  • The "exploit" requires the attacker to compromise an admin key.
  • The pattern is present but mitigated by an immutable, audited library call.
  • The vuln class is present but the capability requires unrealistic state.

When to escalate to HIGH

Upgrade to HIGH only if:

  • You can articulate the exploit in concrete terms.
  • You can identify the specific value at risk.
  • You can write a PoC that compiles (or you cite a historical incident).

Output integration

In the standard finding format:

[<ID> | <Severity>] <Title>
  Confidence: HIGH | MEDIUM | LOW
  Reasoning:  <trace>
  ...

Don't

  • Don't mark every finding HIGH to look thorough.
  • Don't mark a real, well-evidenced finding LOW to be cautious — that defeats the purpose.
  • Don't downgrade Critical severity to compensate for low confidence — they're orthogonal axes.

Related

  • [[multi-pass-self-critique]] — uses confidence to filter
  • [[false-positive-feedback-loop]] — low-confidence findings are dismissal candidates
  • [[known-good-comparison]] — known-good match → upgrade confidence

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.