agentleFS
RecusiveRecusive/Skills/full-audit/SKILL.md

full-audit

Skill2 starsChanged 8 months agoMITView on GitHub

Run all 10 expert audit lenses sequentially, writing everything into ONE comprehensive document. Works in TWO modes — (1) Plan mode: provide a plan file path to audit a plan before implementation. (2) Repo mode: audit actual code changes (uncommitted changes, branch/PR vs main, or general repo health). Use this skill when the user says "full audit", "run all audits", "audit everything", "complete audit", "full spectrum audit", "10-lens audit", "audit the repo", "audit my changes", "audit this PR", or wants every expert perspective examined. This is the nuclear option — every lens, every perspective, one document.

4 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. About 0 are common, 16 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈16

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Check what the user provided:

    line 18
  2. Distinctive:

    If no plan path was provided, ask the user what to audit:

    line 27
  3. Distinctive:

    Read every changed file in full.

    line 47
  4. Distinctive:

    No specific diff — each lens reads the codebase broadly.

    line 58
  5. Distinctive:

    Plan mode: Read the plan document completely.

    line 64
  6. Distinctive:

    Repo mode: Read all changed files and the diff.

    line 65
  7. Distinctive:

    Ask the user: "This will run N lenses.

    line 87
  8. Distinctive:

    If the user confirms, proceed.

    line 89
  9. Distinctive:

    Run each relevant lens one at a time, in this order (user-facing surface → infrastructure):

    line 93
  10. Distinctive:

    Use the Skill tool:

    line 114
  11. Distinctive:

    Follow the skill's analysis instructions completely — read files, check gotchas, evaluate through the lens.

    line 126
  12. Distinctive:

    IMPORTANT: Do NOT let the lens write a separate report file: Instead, collect all findings from each lens and hold them for Phase 3.

    line 128
  13. Distinctive:

    After each lens completes, capture:

    line 131
  14. Very specific:

    After ALL lenses have completed, write ONE file: reviews/audit-plan-full.md

    line 144
  15. Distinctive:

    After writing the document:

    line 291
  16. Distinctive:

    Every lens runs independently: Don't let findings from Lens 1 bias Lens 5.

    line 303
  17. Distinctive:

    Cross-cutting concerns are the gold: If 2+ lenses flag related issues, elevate it.

    line 305

≈ “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

Full Spectrum Audit

You are running a full spectrum audit — all 10 expert lenses, sequentially, writing everything into ONE document: reviews/audit-plan-full.md.

Do NOT write separate files per lens. Everything goes into one document under headings.

This is thorough by design. It takes time. That's the point.


Detect Mode

Check what the user provided:

  • Plan path given (e.g., docs/plans/tracked/todo/some-plan.md) → Plan Mode
  • No path given OR user said "audit repo" / "audit changes" / "audit this PR" → Repo Mode

Repo Mode: Determine Scope

If no plan path was provided, ask the user what to audit:

What would you like me to audit?

1. **Uncommitted changes** — audit your current working tree changes (staged + unstaged)
2. **Branch vs main** — audit all commits on the current branch since it diverged from main (PR review)
3. **General repo health** — broad codebase health check against conventions and best practices

Which one? (1/2/3)

Based on their answer, gather the audit material:

Option 1: Uncommitted Changes

git diff                    # unstaged changes
git diff --staged           # staged changes
git status                  # overview of what's changed

Read every changed file in full.

Option 2: Branch vs Main

git log main..HEAD --oneline              # commits on this branch
git diff main...HEAD                       # all changes vs main
git diff main...HEAD --stat               # files changed summary

Read every changed file in full.

Option 3: General Repo Health

No specific diff — each lens reads the codebase broadly. Focus on recent files, core files, and convention compliance.


Phase 1: Read & Scope

Plan mode: Read the plan document completely. Repo mode: Read all changed files and the diff.

Then determine which of the 10 lenses are relevant.

Relevance rules:

LensSkip when...
Design EngineerBackend-only, no UI changes
UX EngineerNo user-facing behavior changes
Frontend EngineerNo React/TS/CSS changes
Backend EngineerNo Rust/Tauri changes
Structural EngineerSingle-file change, no new modules
Repo MaintainerNever skip
Production ReadinessNever skip
DX EngineerNo user-facing behavior changes
Performance EngineerNo new state, listeners, IPC, or I/O
Accessibility EngineerNo interactive UI changes

After reading, announce:

  • Which lenses will run (and why)
  • Which lenses are being skipped (and why)
  • Ask the user: "This will run N lenses. Ready to proceed?"

If the user confirms, proceed. If they want to adjust, honor that.

Phase 2: Sequential Audit

Run each relevant lens one at a time, in this order (user-facing surface → infrastructure):

  1. Design Engineer
  2. UX Engineer
  3. Frontend Engineer
  4. Backend Engineer
  5. Structural Engineer
  6. Repo Maintainer
  7. Production Readiness
  8. DX Engineer
  9. Performance Engineer
  10. Accessibility Engineer

For each lens:

Step: Announce

--- Lens N/10: [Expert Name] ---

Step: Invoke the skill

Use the Skill tool:

  • Skill("audit-as-design-eng")
  • Skill("audit-as-ux-eng")
  • Skill("audit-as-frontend-eng")
  • Skill("audit-as-backend-eng")
  • Skill("audit-as-structural-eng")
  • Skill("audit-as-repo-maintainer")
  • Skill("audit-as-prod-readiness")
  • Skill("audit-as-dx-eng")
  • Skill("audit-as-perf-eng")
  • Skill("audit-as-a11y-eng")

Follow the skill's analysis instructions completely — read files, check gotchas, evaluate through the lens.

IMPORTANT: Do NOT let the lens write a separate report file. Instead, collect all findings from each lens and hold them for Phase 3. If a lens writes to a file, that's fine as intermediate work, but the FINAL output is ONE combined document.

Step: Record findings

After each lens completes, capture:

  • Lens name and verdict
  • Critical issues (full detail)
  • Recommendations (full detail)
  • Nice-to-haves
  • The signature section output (Visual State Coverage, User Journey Map, etc.)

Step: Continue to next lens


Phase 3: Write the Single Document

After ALL lenses have completed, write ONE file: reviews/audit-plan-full.md

This document contains EVERYTHING — the master summary at the top, then the FULL output of each lens under its own heading. Not summaries — the complete lens output.

Document Structure

# Full Spectrum Audit: [Title]

**Date**: [current date]
**Mode**: [Plan / Uncommitted Changes / Branch vs Main / Repo Health]
**Source**: [plan path OR branch name OR "working tree"]
**Lenses Run**: [N]/10
**Lenses Skipped**: [list with reasons]

---

## Master Verdict: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[2-3 sentence justification synthesizing across ALL lenses.]

## Verdict by Lens

| # | Lens | Verdict | Critical | Recommendations |
|---|------|---------|----------|-----------------|

## All Critical Issues (Must Fix)

Collected from every lens, deduplicated, ordered by severity:

| # | Issue | Lens(es) | File(s) | Impact | Fix |
|---|-------|----------|---------|--------|-----|

## Cross-Cutting Concerns

Issues flagged by 2+ lenses — systemic problems:

| Concern | Flagged By | Root Cause | Unified Fix |
|---------|-----------|------------|-------------|

## All Recommendations

| # | Recommendation | Lens | File(s) | Fix |
|---|---------------|------|---------|-----|

---

# Lens Reports

---

## 1. Design Engineer

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output here — everything the design engineer found, including:
- Files reviewed table
- Critical issues table
- Recommendations table
- Design System Compliance section
- Visual State Coverage matrix
- Verdict Details (Token Fidelity, State Coverage, Dark Mode, Animation, Consistency)]

---

## 2. UX Engineer

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output — User Journey Map, issues, recommendations, Interaction Consistency Check, Verdict Details]

---

## 3. Frontend Engineer

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output — Render Path Analysis, Type Safety Assessment, issues, recommendations, Verdict Details]

---

## 4. Backend Engineer

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output — Error Path Analysis, Resource Lifecycle Audit table, issues, recommendations, Verdict Details]

---

## 5. Structural Engineer

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output — Dependency Map, Boundary Crossing Analysis, issues, recommendations, Verdict Details]

---

## 6. Repo Maintainer

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output — Convention Compliance Checklist, Reuse Opportunities, issues, recommendations, Verdict Details]

---

## 7. Production Readiness

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output — Failure Mode Analysis table, Environment Checklist, issues, recommendations, Verdict Details]

---

## 8. DX Engineer

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output — Error Message Audit table, Developer Journey, issues, recommendations, Verdict Details]

---

## 9. Performance Engineer

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output — Resource Budget table, Hot Path Analysis, issues, recommendations, Verdict Details]

---

## 10. Accessibility Engineer

**Verdict**: [APPROVE / APPROVE WITH CHANGES / NEEDS REWORK]

[FULL lens output — Keyboard Navigation Walkthrough, ARIA Checklist, issues, recommendations, Verdict Details]

For skipped lenses: Include a brief entry:

## N. [Lens Name]

**Skipped** — [reason, e.g., "No Rust/Tauri changes in this plan"]

Phase 4: Output

After writing the document:

  1. Print: Full spectrum audit written to reviews/audit-plan-full.md
  2. Print the Master Verdict
  3. Print the Verdict by Lens table
  4. Print the All Critical Issues table
  5. Print the Cross-Cutting Concerns table

Policies

  • ONE file. Everything goes into reviews/audit-plan-full.md. No separate lens files.
  • Full lens output, not summaries. Each lens section contains the COMPLETE analysis — tables, checklists, verdict details, everything.
  • Every lens runs independently. Don't let findings from Lens 1 bias Lens 5.
  • Deduplication in the master section. Critical issues and recommendations that appear in multiple lenses get listed once in the master tables with all source lenses noted. Each individual lens section still contains its own full findings.
  • Cross-cutting concerns are the gold. If 2+ lenses flag related issues, elevate it.
  • The master verdict is not a vote. One critical NEEDS REWORK can override nine APPROVEs.
  • Repo mode is code review, not plan review. Findings reference specific lines, functions, and patterns in actual files.

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.

Reviews can't be read right now.

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.