AgentStack
SKILL verified MIT Self-run

Full Audit

skill-recusive-skills-full-audit · by Recusive

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…

No reviews yet
0 installs
13 views
0.0% view→install

Install

$ agentstack add skill-recusive-skills-full-audit

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Full Audit? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

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:

| Lens | Skip when... | |------|-------------| | Design Engineer | Backend-only, no UI changes | | UX Engineer | No user-facing behavior changes | | Frontend Engineer | No React/TS/CSS changes | | Backend Engineer | No Rust/Tauri changes | | Structural Engineer | Single-file change, no new modules | | Repo Maintainer | Never skip | | Production Readiness | Never skip | | DX Engineer | No user-facing behavior changes | | Performance Engineer | No new state, listeners, IPC, or I/O | | Accessibility Engineer | No 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.