athena-mcp 1.0.0

package/skills/glm-audit-skill/references/judging.md

@@ -0,0 +1,45 @@
+# Finding Assessment Protocol
+
+Every candidate finding must clear four sequential checkpoints before it becomes a confirmed finding. A failure at any checkpoint results in rejection or demotion to a lead for further investigation.
+
+## Checkpoint 1 — Path Reconstruction
+
+Walk the full execution path from external entry point to the alleged vulnerability. Document every modifier, require statement, guard clause, and access control check encountered along that path. If you cannot trace a complete unbroken path, the finding fails here.
+
+## Checkpoint 2 — State Feasibility
+
+Demonstrate that the vulnerable contract state can actually be reached in a production deployment. Consider initialization order, proxy patterns, upgrade mechanisms, and realistic transaction sequences. Theoretical states that require impossible preconditions do not pass.
+
+## Checkpoint 3 — Actor Profile
+
+Identify the minimum privilege level required to trigger the vulnerability. The attack must be executable by an unprivileged or semi-privileged actor — owner-only findings are typically informational only. Document the exact actor type and their capabilities.
+
+## Checkpoint 4 — Damage Assessment
+
+Quantify the concrete harm: stolen funds, bricked contracts, corrupted state, or broken invariants. Tie the impact to an identifiable victim class (liquidity providers, token holders, protocol treasury). Abstract or theoretical damage does not qualify.
+
+## Confidence Scoring
+
+Base score starts at 100. Apply deductions:
+
+- Incomplete execution path traced: -20
+- Impact bounded to a single non-compounding scenario: -15
+- Requires specific or unusual contract state to be reachable: -10
+- Actor requires partial privilege (not fully unprivileged): -5
+
+Score below 60 → demote to lead. Score below 40 → reject outright.
+
+## Known-Safe Patterns (skip these)
+
+- `unchecked` arithmetic blocks in Solidity ≥0.8 (overflow reverts by default)
+- SafeERC20 wrapper usage for token interactions
+- `nonReentrant` guards (flag only if cross-contract reentrancy is still possible)
+- Two-step ownership transfer patterns
+
+## Lead Escalation Criteria
+
+Promote a finding to lead status (requires senior auditor review) when:
+
+- The vulnerability spans multiple contracts in an echo/reentrancy chain
+- Two or more independent agents converge on the same attack surface
+- The attack path is partially complete but missing one link that may exist under specific conditions

package/skills/glm-audit-skill/references/report-formatting.md

@@ -0,0 +1,22 @@
+# Audit Report Structure
+
+Save the final report as `{project-name}-audit-report-{timestamp}.md` in the project root directory.
+
+## Section Layout
+
+1. **Executive Summary** — One paragraph: total findings by severity, overall risk posture, and any critical items requiring immediate attention.
+
+2. **Scope & Methodology** — Contracts audited, commit hash, tools used, and audit duration.
+
+3. **Findings** — Ordered by confidence score (descending). Each entry includes:
+   - **ID & Title** with confidence score in brackets (e.g. `[C:85]`)
+   - **Severity**: Critical / High / Medium / Low / Informational
+   - **Location**: `ContractName.functionName()` with line range
+   - **Description**: What the vulnerability is and why it matters
+   - **Proof of Concept**: Concrete scenario demonstrating the issue
+   - **Recommendation**: Actionable fix with diff-style code snippet
+   - **Status**: Open / Acknowledged / Mitigated
+
+4. **Leads** — Trails identified but not fully verified. Each lead includes the partial evidence and reason for demotion (e.g., "missing link in cross-contract path"). These are not confirmed findings but warrant follow-up.
+
+5. **Appendix** — Agent breakdown table showing which agents flagged which findings, plus any tool output worth preserving.

package/skills/glm-audit-skill/references/senior-auditor-sop.md

@@ -0,0 +1,34 @@
+# Senior Auditor Operating Principles
+
+This document defines the analytical mindset that every audit agent should internalize before scanning code. These principles are not about tools or checklists — they are about how to think.
+
+## Principle 1 — Decompose Before You Attack
+
+Before hunting for bugs, fully understand what the contract is supposed to do. Read the documentation, the comments, and the test suite. Build a mental model of the intended behavior. If you cannot articulate the contract's purpose in plain language, you are not ready to look for what goes wrong.
+
+This means: for each function, ask "what is the intended invariant here?" before asking "how can I break it?"
+
+## Principle 2 — Assume Every Assumption Is Wrong
+
+Every `require` statement, every modifier, every unchecked return value embodies an assumption about the world. Your job is to enumerate those assumptions and then stress-test each one.
+
+For each line of code, ask three questions:
+- What does this assume to be true?
+- How was that assumption established?
+- What happens to downstream logic if the assumption is violated?
+
+Pay special attention to assumptions that are validated once during initialization but relied upon forever after. Time is the enemy of assumptions.
+
+## Principle 3 — Think Adversarially, Not Defensively
+
+Once you understand the intended behavior, flip your perspective. Instead of asking "does this code work?", ask "how would I make it fail while looking like it works?" This is the inversion principle: after understanding what code IS supposed to do, engineer scenarios where it does NOT do that — while still passing all existing checks.
+
+The strongest vulnerabilities are those that exist in the gap between what tests verify and what the contract actually permits.
+
+## Principle 4 — Trace the Money, Not the Code
+
+Code-level correctness does not guarantee economic correctness. A function can be bug-free in isolation yet still allow value extraction when composed with other protocols, flash loans, or MEV strategies. Always ask: who benefits from this code path, and could they engineer an advantage that was not intended?
+
+## Principle 5 — Bound Your Confidence
+
+Not every suspicious pattern is a vulnerability. Rate your confidence honestly. A finding you cannot fully trace to a concrete impact is a lead, not a finding. Over-reporting erodes trust; under-reporting misses real risks. Calibrate carefully.