Athena review

Skill bencrooks-dev/Athena/skills/athena-review

Two-pass code review — first checks spec compliance (did we build what was asked?), then code quality (is it built well?). Use after implementing features or before merging.From its SKILL.md

Install

npx -y skills add bencrooks-dev/Athena --skill athena-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.6 KB, as published. Nobody here has run it

Athena Review — Auditor

Two-pass code review. Order matters — spec compliance first, quality second. No point polishing code that doesn't meet requirements.

Pass 1: Spec Compliance

Check the implementation against the spec/plan:

Find the relevant spec or plan document (check docs/plans/, docs/specs/, docs/athena/specs/, or ask the user)
For each requirement in the spec:
- Is it implemented? → DONE
- Is it missing? → MISSING
- Is it partially done? → PARTIAL (explain what's missing)
Check for over-building:
- Any features NOT in the spec? → EXTRA (flag for removal)
Output:

Spec Compliance
═══════════════
[DONE]    Requirement 1 description
[DONE]    Requirement 2 description
[MISSING] Requirement 3 description — not found in codebase
[EXTRA]   Feature X — not in spec, consider removing

Result: 8/10 requirements met, 1 missing, 1 extra

If anything is MISSING → stop here. Fix spec gaps before reviewing quality. There's no point reviewing code quality on incomplete work.

Pass 2: Code Quality

Only run this after Pass 1 is fully green (all DONE, no MISSING).

Check for concrete issues, not style preferences:

CRITICAL (must fix):

Security vulnerabilities (injection, XSS, hardcoded secrets)
Data loss risks (missing error handling at system boundaries)
Race conditions or deadlocks
Broken error handling that swallows exceptions

IMPORTANT (should fix):

Missing tests for key behavior
Dead code or commented-out code
Unclear naming that will confuse future readers
Functions doing too many things (>1 responsibility)

MINOR (optional):

Minor naming improvements
Small readability tweaks
Documentation gaps in complex logic

Output:

Code Quality
════════════
CRITICAL: [n] issues
IMPORTANT: [n] issues
MINOR: [n] issues

[CRITICAL] File:line — Description of issue
[IMPORTANT] File:line — Description of issue
...

Verdict: [APPROVE / REQUEST CHANGES]

Rules

Spec compliance before quality — always, no exceptions
Be specific — "File:line — what's wrong" not "error handling could be better"
No style nitpicks — don't enforce personal preferences (tabs vs spaces, etc.)
Acknowledge what's good — 1-2 sentences on strengths before issues
APPROVE means approve — don't approve with a laundry list of concerns