accelint-ts-audit-all

What this skill does

# Audit All

Comprehensive TypeScript file audit system that systematically applies multiple audit skills with progress tracking and interactive approval.

## NEVER Do When Running Audits

- **NEVER skip the initial test coverage step** - Refactoring without test coverage first leads to undetected breakage. Always run `accelint-ts-testing` before any code changes.
- **NEVER run best-practices and performance sequentially** - Running them separately creates contradictory recommendations for the same code. Always run in parallel to see merged suggestions.
- **NEVER present issues one-by-one for approval** - Always show ALL issues in a numbered table first, then display each issue's detailed before/after code, THEN ask for numbered list acceptance. This prevents wildly inconsistent presentations and allows users to spot conflicts across parallel processes.
- **NEVER skip displaying the overview table** - BLOCKING: You MUST display the emoji severity table with ALL issues before showing any detailed changes. No exceptions.
- **NEVER ask for approval before showing all detailed changes** - BLOCKING: You MUST show the complete before/after code for EVERY issue before asking "Apply which issues?"
- **NEVER auto-apply all recommendations** - Each change needs user approval (accept/deny/other) to maintain code ownership and prevent unwanted modifications.
- **NEVER run one-off commands instead of documented verification commands** - The audit-process file documents EXACT verification commands. Use those commands verbatim. Never improvise with `npm test`, `bun test`, or similar unless they match the documented commands exactly.
- **NEVER skip saving progress after completing a step** - After EVERY step completion, immediately save detailed progress to audit-process file BEFORE moving to next step. Context limits will break otherwise.
- **NEVER skip the 100-pass PBT verification** - When property-based tests are added, you MUST run the test suite 100 times to verify stability. Random failures are common with PBT. This is a blocking requirement - do not proceed until 100 consecutive passes are achieved. Run the tests without coverage reporting on to increase speed and stability.
- **NEVER lose progress when context runs out** - Save detailed progress to audit-process file after each step. Context limits are guaranteed in large audits.
- **NEVER assume property-based tests are stable** - Random test failures are common with PBT. Run new property tests 100 times to verify stability before accepting. Run the tests without coverage reporting on to increase speed and stability.
- **NEVER add PERF comments everywhere** - Only add `// PERF:` comments when they provide meaningful insight that future developers wouldn't discover on their own.
- **NEVER mark a file complete without all 9 steps** - Partial audits leave files in inconsistent states. Complete all steps or mark as in-progress.
- **NEVER move on from a broken build** - Fix compilation errors, test failures, and lint issues immediately before proceeding to the next step.
- **NEVER run audit in main branch** - Always create an isolated worktree to prevent conflicts with parallel audits and allow safe experimentation.

## Before Starting an Audit, Ask

Apply these tests before launching a comprehensive audit:

### Scope Validation
- **Is this path valid and accessible?** Verify the file or directory exists before creating TODO lists.
- **Are there test and build commands available?** Check package.json or ask user for verification commands before starting.
- **How many files will this audit?** Large directories (>5 files) will require multiple sessions. Set expectations upfront.

### Session Management
- **Is this a new audit or resuming?** Check for existing audit-process files in `.agents/audit/` before creating new ones.
- **Will this fit in one session?** Estimate ~1-5 files per session max. Plan for resumption if larger.
- **Are verification commands known?** Document exact test/build/lint commands in the audit-process file from the start.

### Change Philosophy
- **What's the user's risk tolerance?** Some users want every suggestion, others only critical fixes. Clarify before first interactive prompt.
- **Should performance micro-optimizations be included?** 1.05x-1.15x gains may not be worth code churn for all projects.

## How to Use

This skill creates and maintains an audit process file that tracks progress across sessions. It systematically runs four audit skills on each file with interactive approval.

### Workflow Overview

1. **Initialize** - Create TODO list and audit tracking files
2. **For each file** - Run 9-step audit process with user approval
3. **Track progress** - Save after each step to survive context limits
4. **Archive completed** - Move finished files to history file

## Main Audit Workflow

### Step 1: Initialize the Audit

**Check for existing audit:** Look in `.agents/audit/` directory (in the original repository root) for existing audit-process files.

**Note:** Ensure `.agents/audit/` is in your project's `.gitignore` to prevent committing audit tracking files.

If resuming an existing audit, read the audit-process file to understand current status:

1. **Check completion status:**
   - Review "Current Status" section for files completed vs remaining
   - Review "Files to Audit" section for pending/completed breakdown
   - If all files are marked "Completed", the audit is done

2. **Check worktree status (backwards compatibility):**
   - If "Worktree Information" section exists: verify worktree still exists and switch to it
   - If no worktree documented: this is a legacy audit from before worktree support. Continue in current branch without creating a worktree.
   - Note: Only NEW audits created after this feature will use worktrees

3. **Continue from "Resume Instructions" section**

Skip to Step 2 if resuming.

**For new audits, create isolated worktree:**

BLOCKING: All audit work MUST happen in an isolated worktree to prevent conflicts with parallel audits and allow safe rollback.

1. **Create worktree with timestamped branch:**
   ```bash
   timestamp=$(date +%Y%m%d-%H%M%S)
   git worktree add .agents/worktrees/audit-${timestamp} -b audit/${timestamp}
   ```

2. **Switch to the worktree directory:**
   ```bash
   cd .agents/worktrees/audit-${timestamp}
   ```

3. **Log the worktree path** - You will work in this directory for the entire audit

**Important:** The worktree is created in `.agents/worktrees/` (not `.agents/audit/`) to avoid conflicts with the gitignored `.agents/audit/` directory where tracking files are stored.

**Create tracking files:**

**MANDATORY - READ ENTIRE FILE**: Before creating any tracking files, you MUST read
[`assets/audit-process-template.md`](assets/audit-process-template.md) completely
from start to finish to understand the exact format and structure required.
**NEVER set any range limits when reading this file.**

Similarly, you MUST read [`assets/audit-history-template.md`](assets/audit-history-template.md)
to understand the archival format.

**Do NOT load** these templates again after the initial setup - they are only needed
once at the start of a new audit.

Create timestamped tracking files in the ORIGINAL repository (not in the worktree):
- Go back to the original repository root: `cd $(git rev-parse --show-toplevel)`
- Create `.agents/audit/audit-process-${timestamp}.md` (use same timestamp as worktree)
- Create `.agents/audit/audit-history-${timestamp}.md` (same timestamp)
- Return to the worktree: `cd .agents/worktrees/audit-${timestamp}`

**Important:** Tracking files live in the original repo's `.agents/audit/` directory (which should be gitignored) so they are NOT committed with audit changes.

**Build the TODO list:**

Find all TypeScript files in the target directory, excluding `.test.ts`, `.spec.ts`, and `.bench.ts` files. If given a single file, validate it's not a test/benchmark file.

**Populate the audit-process file:**
-