@su-record/vibe 2.16.4 → 3.0.0

package/skills/characterization-test/templates/test-template.ts

@@ -1,101 +0,0 @@
-/**
- * Characterization test template — lock existing behavior before refactoring.
- *
- * Instructions:
- *   1. Replace {{MODULE_NAME}} with the module under test.
- *   2. Replace {{IMPORT_PATH}} with the relative import path.
- *   3. Replace {{FUNCTION_NAME}} with each public export to characterize.
- *   4. Run once to generate snapshots: npx vitest run --update {{TEST_FILE}}
- *   5. Verify all tests pass BEFORE making any changes to the source.
- *
- * IMPORTANT: Capture ACTUAL behavior, not expected/ideal behavior.
- * If the current code has a bug, capture the buggy output — fix it separately.
- */
-
-import { describe, it, expect, vi, beforeEach } from 'vitest';
-// import { {{FUNCTION_NAME}} } from '{{IMPORT_PATH}}';
-
-describe('{{MODULE_NAME}} — characterization tests', () => {
-  beforeEach(() => {
-    vi.clearAllMocks();
-  });
-
-  // -------------------------------------------------------------------------
-  // Happy path — normal inputs
-  // -------------------------------------------------------------------------
-
-  it('should handle typical input', () => {
-    // const result = {{FUNCTION_NAME}}({{TYPICAL_INPUT}});
-    // expect(result).toMatchSnapshot();
-  });
-
-  it('should handle minimum valid input', () => {
-    // const result = {{FUNCTION_NAME}}({{MIN_INPUT}});
-    // expect(result).toMatchSnapshot();
-  });
-
-  it('should handle maximum valid input', () => {
-    // const result = {{FUNCTION_NAME}}({{MAX_INPUT}});
-    // expect(result).toMatchSnapshot();
-  });
-
-  // -------------------------------------------------------------------------
-  // Edge cases — boundary values
-  // -------------------------------------------------------------------------
-
-  it('should handle empty string input', () => {
-    // const result = {{FUNCTION_NAME}}('');
-    // expect(result).toMatchSnapshot();
-  });
-
-  it('should handle empty array input', () => {
-    // const result = {{FUNCTION_NAME}}([]);
-    // expect(result).toMatchSnapshot();
-  });
-
-  it('should handle zero / false / null-like values', () => {
-    // const result = {{FUNCTION_NAME}}(0);
-    // expect(result).toMatchSnapshot();
-  });
-
-  // -------------------------------------------------------------------------
-  // Error paths — failure modes
-  // -------------------------------------------------------------------------
-
-  it('should handle null input', () => {
-    // expect(() => {{FUNCTION_NAME}}(null)).toThrowErrorMatchingSnapshot();
-  });
-
-  it('should handle undefined input', () => {
-    // expect(() => {{FUNCTION_NAME}}(undefined)).toThrowErrorMatchingSnapshot();
-  });
-
-  it('should handle invalid type input', () => {
-    // expect(() => {{FUNCTION_NAME}}({{INVALID_INPUT}})).toThrowErrorMatchingSnapshot();
-  });
-
-  // -------------------------------------------------------------------------
-  // Side effects — external interactions
-  // -------------------------------------------------------------------------
-
-  it('should call external dependency with correct arguments', () => {
-    // const spy = vi.spyOn({{DEPENDENCY}}, '{{METHOD}}');
-    // {{FUNCTION_NAME}}({{TYPICAL_INPUT}});
-    // expect(spy).toHaveBeenCalledWith({{EXPECTED_ARGS}});
-    // expect(spy).toHaveBeenCalledTimes(1);
-  });
-
-  // -------------------------------------------------------------------------
-  // Branching paths — one test per major branch
-  // -------------------------------------------------------------------------
-
-  it('should take branch A when condition is true', () => {
-    // const result = {{FUNCTION_NAME}}({{BRANCH_A_INPUT}});
-    // expect(result).toMatchSnapshot();
-  });
-
-  it('should take branch B when condition is false', () => {
-    // const result = {{FUNCTION_NAME}}({{BRANCH_B_INPUT}});
-    // expect(result).toMatchSnapshot();
-  });
-});

package/skills/claude-md-guide/SKILL.md

@@ -1,353 +0,0 @@
----
-name: claude-md-guide
-user-invocable: false
-invocation: [auto]
-tier: standard
-description: "Guide for writing effective CLAUDE.md files from scratch. Evidence-based methodology from 40+ sources including research papers, official docs, and real-world examples. Covers 3-layer architecture, Curse of Instructions mitigation, progressive disclosure, and maintenance. Use when creating new CLAUDE.md, improving existing ones, or teaching team members how to write project instructions for AI agents."
-triggers: [claude-md guide, write claude.md, create claude.md, claude.md 작성, 클로드 문서, project instructions, claude-md]
-priority: 55
-chain-next: [agents-md]
----
-
-# claude-md-guide — CLAUDE.md Writing Guide
-
-> **Principle**: "Would the agent make a mistake without this?" → If No, delete it. If Yes, keep it.
-
-## Why This Matters
-
-Research shows that LLM compliance drops **exponentially** as the number of instructions increases (Curse of Instructions):
-
-| Instructions | GPT-4o Compliance | Claude Sonnet Compliance |
-|-------------|------------------|--------------------------|
-| 1 | ~85% | ~90% |
-| 5 | ~44% | ~59% |
-| 10 | ~15% | ~44% |
-| 15+ | ~5% | ~15% |
-
-**Conclusion**: Every line has a cost. A short, precise CLAUDE.md is better than a long, comprehensive one.
-
----
-
-## Step 1: Project Exploration — Auto-Collect
-
-Explore the project before writing CLAUDE.md:
-
-```
-Glob: pattern="package.json"       → Check stack and scripts
-Glob: pattern="*.config.*"         → Build/lint configuration
-Glob: pattern="tsconfig.json"      → TypeScript configuration
-Glob: pattern=".env.example"       → Environment variable structure
-Glob: pattern="Makefile"           → Build system
-Glob: pattern="docker-compose.*"   → Infrastructure structure
-Glob: pattern="CLAUDE.md"          → Check for existing file
-Glob: pattern="AGENTS.md"          → Check for compatible file
-```
-
-Summarize the collected information for the user, then ask about any missing context.
-
-## Step 2: Interview — Extract Non-Discoverable Information
-
-Only ask about information that cannot be found through auto-exploration. **One question at a time, multiple-choice when possible:**
-
-### Question Categories
-
-**1. Runtime Traps**
-- Are there runtime differences not visible in the code? (e.g., Bun vs Node, ESM vs CJS)
-- Are there bugs that only occur in certain environments?
-
-**2. Forbidden Patterns**
-- Are there libraries/patterns that must never be used?
-- Are there approaches that caused problems in the past?
-
-**3. Non-standard Conventions**
-- Are there naming/structure rules that differ from standards?
-- Are there special workflows agreed upon by the team?
-
-**4. Architecture Decisions**
-- Are there design reasons that can't be inferred from the code alone?
-- Is there business context behind why certain patterns were chosen?
-
-**5. Boundaries**
-- Are there files/directories the agent must never touch?
-- Are there areas that require approval before changes are made?
-
-## Step 3: Structure Design — 3-Layer Architecture
-
-Separate the collected information into 3 layers:
-
-### Layer 1: CLAUDE.md (Project Constitution)
-
-**Auto-loaded every session** → only universal, stable information.
-
-```markdown
-# {Project Name}
-
-{1-2 sentences on what the project is. Only if the purpose isn't clear from the code.}
-
-## Tech Stack
-{Only what can't be inferred immediately from package.json. e.g., "Bun runtime (not Node)"}
-
-## Commands
-{Only what's missing from package.json scripts or non-intuitive}
-- `npm run build && npx vitest run` — build then test (order matters)
-
-## Conventions
-{Only what the linter can't catch}
-- ESM only — imports need `.js` extension
-- {Any non-standard naming rules}
-
-## Gotchas
-{Things the agent will repeatedly get wrong}
-- **{Trap title}.** {Specific do/don't explanation}
-
-## Boundaries
-✅ Always: {things to always do}
-⚠️ Ask first: {things requiring approval first}
-🚫 Never: {absolute prohibitions}
-```
-
-### Layer 2: SPEC.md (Per-Feature Design Document)
-
-**Loaded only when working on a specific feature** → focus on what and why, leave how to the agent.
-
-Storage location: `.vibe/specs/YYYY-MM-DD-{topic}.md`
-
-```markdown
-# {Feature Name} SPEC
-
-## Purpose (Why)
-## Requirements (What)
-## Success Criteria (Acceptance Criteria)
-## Technical Constraints (Constraints)
-## Boundaries (Out of Scope)
-```
-
-### Layer 3: plan.md (Execution Plan)
-
-**Per-session task list** → 2-5 minute units, with file paths specified.
-
-Storage location: `.vibe/specs/{name}-execplan.md`
-
-```markdown
-# Execution Plan
-
-## Task 1: {Title}
-- Files: `src/foo.ts`, `src/foo.test.ts`
-- Action: {Specific change}
-- Verify: `npm test src/foo.test.ts`
-
-## Task 2: ...
-```
-
-## Step 4: Writing — Apply Evidence-Based Principles
-
-### Size Limits
-
-| Grade | Lines | When Appropriate |
-|-------|-------|-----------------|
-| Optimal | 60-150 | Most projects |
-| Acceptable | 150-200 | Complex monorepos |
-| Warning | 200-300 | Separation needed |
-| Danger | 300+ | Agent ignores half of it |
-
-### Attention Distribution by Position (Lost in the Middle Effect)
-
-LLMs focus on the **beginning and end** of a document and **ignore the middle**:
-
-```
-Attention: ████████░░░░░░░░████████
-           ^start    ^middle(↓20-40%)  ^end
-```
-
-**Countermeasures**:
-- **Most important rules** → place at the top of the document
-- **Frequently violated rules** → place at the bottom (end) of the document
-- **Background information** → place in the middle (OK if ignored)
-
-### Include vs Exclude Checklist
-
-**✅ Include (non-discoverable, operationally important)**
-
-| Type | Example |
-|------|---------|
-| Runtime traps | "Bun runtime, not Node" |
-| Forbidden patterns | "Never use `any`, use `unknown` + type guards" |
-| SSOT location | "Only edit `constants.ts` for stack mapping" |
-| Order invariants | "Build before test, always" |
-| Non-standard commands | Compound commands, special flags |
-| Security rules | Auth, path traversal prevention, etc. |
-
-**❌ Exclude (discoverable or delegate to other tools)**
-
-| Type | Reason | Alternative |
-|------|--------|-------------|
-| Directory structure | Discoverable via `ls` | The code itself |
-| Tech stack list | In `package.json` | The code itself |
-| Code style (indentation, semicolons) | Linter catches it | ESLint, Prettier |
-| API documentation | Readable from code | Swagger, JSDoc |
-| General best practices | LLM already knows | Unnecessary |
-| API keys, secrets | Goes stale quickly | `.env`, vault |
-| Per-feature detailed instructions | Move to Layer 2 | SPEC.md |
-
-### Emphasis Techniques
-
-Use these when important rules keep getting ignored:
-
-```markdown
-**IMPORTANT**: {critical rule}
-**MUST**: {mandatory action}
-**NEVER**: {absolute prohibition}
-```
-
-However, adding emphasis to every line **nullifies the emphasis**. Use only for P1 rules.
-
-### Progressive Disclosure
-
-Don't put everything in CLAUDE.md — reference it:
-
-```markdown
-# Architecture
-See @docs/ARCHITECTURE.md for design decisions.
-
-# Security
-@.claude/rules/security.md
-```
-
-Claude Code follows `@` references and loads them only when needed.
-
-## Step 5: Validation — Writing Quality Check
-
-Validate the written CLAUDE.md:
-
-### Line-by-Line Validation
-
-4 questions for every line:
-
-1. **Would the agent make a mistake without this?** → If No, delete
-2. **Is it needed in every session?** → If No, move to Layer 2/3
-3. **Can a linter/hook replace it?** → If Yes, move to linter/hook
-4. **Is it discoverable from code?** → If Yes, delete
-
-### Anchoring Warning
-
-Mentioning a technology name biases the agent toward it:
-- ❌ "We use React" → unnecessary (it's in package.json)
-- ✅ "Never use jQuery, even for legacy code" → useful (prevents a trap)
-
-### Token Efficiency
-
-| Problem | Example | Improvement |
-|---------|---------|-------------|
-| Verbose explanation | "Please always make sure to..." | "Always:" |
-| Duplication | Same rule repeated in different wording | State it once |
-| Unnecessary context | "As we discussed..." | Delete |
-
-## Step 6: Maintenance — A Living Document
-
-### Incremental Addition Pattern
-
-Don't try to write it perfectly from the start:
-
-```
-1. Start with a minimal CLAUDE.md (30-50 lines)
-2. Observe where the agent makes mistakes
-3. Only add rules for recurring mistakes
-4. Clean up unnecessary lines every 2-3 weeks
-```
-
-### Reflection Loop (Addy Osmani Pattern)
-
-```
-Agent task complete
-  → Ask "What was different from expectations?"
-  → When a recurring pattern is found, add 1 line to CLAUDE.md
-  → If the root cause is code structure, fix the code and don't add a rule
-```
-
-### Warning Signs
-
-| Signal | Meaning | Response |
-|--------|---------|----------|
-| Over 300 lines | Information overload | Split or trim |
-| Same mistake repeats | Rule is lost in noise | Emphasize or consolidate |
-| Adding rules has no effect | File is too long | Fix root cause |
-| Team ignores rules | Discoverable information | Delete |
-
----
-
-## Quick Reference: Guide by Project Scale
-
-### Small (fewer than 10 files)
-
-```markdown
-# {Project Name}
-
-## Commands
-- `{build}` — {description}
-- `{test}` — {description}
-
-## Gotchas
-- **{Trap 1}.** {description}
-- **{Trap 2}.** {description}
-
-## Never
-- 🚫 {prohibited item}
-```
-
-**Target: 20-30 lines**
-
-### Medium (10-50 files)
-
-Above + add Conventions and Boundaries sections.
-
-**Target: 60-150 lines**
-
-### Large (50+ files, monorepo)
-
-Root CLAUDE.md (shared rules) + CLAUDE.md per subdirectory.
-
-```
-project/
-├── CLAUDE.md              ← shared (60 lines)
-├── packages/api/CLAUDE.md ← API-specific (30 lines)
-├── packages/web/CLAUDE.md ← web-specific (30 lines)
-└── .claude/rules/         ← path-specific rules
-    ├── security.md
-    └── testing.md
-```
-
-**Target: root 100 lines + each subdirectory 30 lines**
-
----
-
-## Session Separation Principle
-
-Splitting CLAUDE.md writing into separate sessions improves quality:
-
-| Session | Goal | Output |
-|---------|------|--------|
-| Session 1 | Project exploration + interview | Draft |
-| Session 2 | Validation + optimization | Final version |
-| Ongoing | Incremental maintenance | Continuous improvement |
-
-After writing: run `→ /agents-md` skill for optimization validation.
-
----
-
-## References
-
-### Research
-- [Curse of Instructions: LLMs Cannot Follow Multiple Instructions at Once](https://openreview.net/forum?id=R6q67CDBCH)
-- [Lost in the Middle: How Language Models Use Long Contexts](https://arxiv.org/abs/2307.03172)
-- [The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions](https://arxiv.org/html/2404.13208v1)
-- [Context Length Alone Hurts LLM Performance Despite Perfect Retrieval](https://arxiv.org/html/2510.05381v1)
-
-### Official Docs
-- [Claude Code Best Practices](https://code.claude.com/docs/en/best-practices)
-- [Using CLAUDE.md Files](https://claude.com/blog/using-claude-md-files)
-
-### Community
-- [Addy Osmani: AGENTS.md](https://addyosmani.com/blog/agents-md/)
-- [HumanLayer: Writing a good CLAUDE.md](https://www.humanlayer.dev/blog/writing-a-good-claude-md)
-- [Builder.io: CLAUDE.md Guide](https://www.builder.io/blog/claude-md-guide)
-- [GitHub Blog: How to Write a Great agents.md](https://github.blog/ai-and-ml/github-copilot/how-to-write-a-great-agents-md-lessons-from-over-2500-repositories/)

package/skills/claude-md-guide/rubrics/anti-patterns.md

@@ -1,88 +0,0 @@
-# CLAUDE.md Anti-Patterns
-
-## Anti-pattern 1: Discoverable Content
-
-**Symptom**: Listing things the agent can find by reading the repo.
-
-```markdown
-# Bad
-- Components are in src/components/
-- Uses React 18 with TypeScript
-- Run tests with npm test
-```
-
-```markdown
-# Good
-(delete these — they're in package.json and the repo structure)
-```
-
-## Anti-pattern 2: Instruction Overload
-
-**Symptom**: 300+ line CLAUDE.md full of best practices.
-
-LLM compliance drops to ~5% after 15+ instructions. Every line competes for attention.
-
-Fix: Keep under 150 lines. Move feature-specific rules to SPEC files.
-
-## Anti-pattern 3: Emphasis Inflation
-
-**Symptom**: IMPORTANT, CRITICAL, MUST on every other line.
-
-When everything is critical, nothing is. Reserve emphasis words for P1 rules only.
-
-## Anti-pattern 4: Past-Tense History
-
-**Symptom**: Phase tables, progress logs, "we decided to..." narratives.
-
-```markdown
-# Bad
-## Progress
-- Phase 1 ✅ Auth
-- Phase 2 ✅ Dashboard
-- Phase 3 🚧 Payments
-```
-
-This is context noise, not guidance. Delete it.
-
-## Anti-pattern 5: Technology Anchoring
-
-**Symptom**: Listing what you use instead of what to avoid.
-
-```markdown
-# Bad
-We use Zod for validation, Prisma for ORM, Tailwind for styling.
-```
-
-```markdown
-# Good
-Never use joi or yup — Zod is the only validation library.
-```
-
-Naming a technology biases the agent toward it. Only name tech in prohibitions.
-
-## Anti-pattern 6: Vague Prohibitions
-
-**Symptom**: Rules without specific triggers.
-
-```markdown
-# Bad
-- Write clean, readable code
-- Follow best practices
-- Keep functions small
-```
-
-The agent already knows these. They consume tokens and provide no new signal.
-
-## Anti-pattern 7: Missing Boundaries
-
-**Symptom**: No section on what the agent should never touch.
-
-Without explicit boundaries, agents will "helpfully" refactor generated files, edit lock files, or push to main.
-
-Always include: what's off-limits, what requires human approval first.
-
-## Anti-pattern 8: Stale Secrets/Keys
-
-**Symptom**: API keys or connection strings in CLAUDE.md.
-
-These belong in `.env` only. CLAUDE.md is committed to version control.

package/skills/design-audit/SKILL.md

@@ -1,154 +0,0 @@
----
-name: design-audit
-user-invocable: true
-invocation: [command, auto]
-tier: standard
-description: "Design technical quality audit — a11y, performance, responsive, theming, AI slop detection with 5-dimension scoring. Use when design-audit, ui-audit, a11y-check, design-check."
-triggers: [design-audit, ui-audit, a11y-check, design-check]
-priority: 50
----
-
-# Design Audit — Technical Quality Inspection
-
-Perform a read-only technical quality audit across 5 dimensions. No code modifications — report only.
-
-## Usage
-
-```
-/design-audit <target>        # Audit specific component/page
-/design-audit .               # Audit all changed UI files
-```
-
-## 5-Dimension Scoring
-
-Each dimension scored 0–4:
-
-| Score | Meaning |
-|-------|---------|
-| 0 | Critical failures — unusable |
-| 1 | Major issues — degraded experience |
-| 2 | Moderate issues — functional but rough |
-| 3 | Minor issues — good with polish needed |
-| 4 | Excellent — production ready |
-
-### 1. Accessibility (a11y)
-
-- [ ] All interactive elements keyboard-reachable (`tabIndex`, focus order)
-- [ ] ARIA roles and labels on custom widgets
-- [ ] Color contrast ≥ 4.5:1 (text), ≥ 3:1 (large text, UI components)
-- [ ] Images have meaningful `alt` text (not "image" or filename)
-- [ ] Form inputs linked to `<label>` or `aria-label`
-- [ ] Focus indicator visible on all interactive elements
-- [ ] Screen reader announcements for dynamic content (`aria-live`)
-- [ ] Skip-to-content link present on pages with navigation
-
-### 2. Performance
-
-- [ ] Images: `loading="lazy"` on below-fold, `srcset` for responsive, WebP/AVIF formats
-- [ ] Fonts: `font-display: swap`, subset if possible, ≤3 font files
-- [ ] CSS: No unused large frameworks, critical CSS inlined or above-fold prioritized
-- [ ] JS: Code-split at route level, no blocking scripts in `<head>`
-- [ ] Layout shifts: Explicit `width`/`height` on media, skeleton placeholders
-- [ ] Bundle: No duplicate dependencies, tree-shaking enabled
-
-### 3. Responsive
-
-- [ ] Breakpoints use `min-width` (mobile-first) or consistent direction
-- [ ] Touch targets ≥ 44×44px on mobile
-- [ ] No horizontal scroll at any breakpoint
-- [ ] Typography scales appropriately (clamp or breakpoint-based)
-- [ ] `@container` queries where component-level responsiveness needed
-- [ ] Navigation adapts (hamburger, drawer, or tab bar on mobile)
-
-### 4. Theming
-
-- [ ] Colors use CSS custom properties (not hardcoded hex/rgb)
-- [ ] Dark mode support or explicit opt-out documented
-- [ ] Spacing uses design tokens (not arbitrary pixel values)
-- [ ] Border radius, shadows consistent via tokens
-- [ ] Component variants use data attributes or CSS classes, not inline styles
-
-### 5. AI Slop Detection
-
-- [ ] No cyan-on-dark or neon accent color schemes without brand justification
-- [ ] No purple-to-blue gradient backgrounds as default aesthetic
-- [ ] No hero metric template (oversized number + tiny label) without data purpose
-- [ ] No identical card grids (3-up with icon + title + description)
-- [ ] No glassmorphism applied as default surface treatment
-- [ ] No bounce/elastic easing on functional animations
-- [ ] No Inter/Roboto as lazy font choice (match brand personality instead)
-- [ ] No gradient text on metrics or statistics
-
-## Severity Tagging
-
-| Severity | Meaning | Example |
-|----------|---------|---------|
-| P0 | Blocker — breaks functionality | Missing focus trap on modal |
-| P1 | Critical — significant UX impact | No keyboard navigation |
-| P2 | Important — noticeable quality gap | Touch targets too small |
-| P3 | Minor — polish opportunity | Inconsistent border radius |
-
-## Platform Adaptation
-
-When running on mobile stacks (React Native, Flutter, iOS, Android):
-- Skip web-specific items: CSS variables, `@container`, `srcset`, `font-display`
-- Focus on: visual hierarchy, cognitive load, accessibility, AI slop detection
-- Adapt responsive checks to platform conventions (safe areas, orientation)
-
-## Output Format
-
-```markdown
-## Design Audit Report: {target}
-
-### Scores
-| Dimension | Score | Grade |
-|-----------|-------|-------|
-| Accessibility | 3/4 | Good |
-| Performance | 2/4 | Moderate |
-| Responsive | 4/4 | Excellent |
-| Theming | 1/4 | Major Issues |
-| AI Slop | 3/4 | Good |
-| **Overall** | **13/20** | **65%** |
-
-### Findings
-
-#### P0 (Blocker)
-- None
-
-#### P1 (Critical)
-- [A11Y] Modal missing focus trap — {file}:{line}
-- [THEME] 12 hardcoded color values — should use CSS variables
-
-#### P2 (Important)
-- [PERF] Images without lazy loading — {file}:{line}
-
-#### P3 (Minor)
-- [SLOP] Purple-to-blue gradient matches AI template aesthetic
-
-### Recommendations
-1. {Priority-ordered actionable items}
-```
-
-## Preparation
-
-Before running the audit:
-
-1. **Read** `.vibe/design-context.json`
-   - If missing → display: "Run `/design-teach` first for better results" → proceed with defaults
-   - If parse error → display warning → proceed with defaults → recommend `/design-teach`
-   - If present → weight findings by `audience.context`, `constraints.accessibility`, `brand.personality`
-2. **Read** `.vibe/design-system/*/MASTER.md` (if exists) for token reference
-
-## Next Steps
-
-| If Result Shows | Recommended Next |
-|----------------|-----------------|
-| Design system inconsistencies | `/design-normalize` — align tokens |
-| UX/usability concerns | `/design-critique` — deeper UX review |
-| Ship-ready (score ≥ 16/20) | `/design-polish` — final micro-details |
-
-## Important
-
-- **Read-only**: This skill produces a report. It does NOT modify code.
-- **Context-aware**: If `.vibe/design-context.json` exists, findings are weighted by project brand and audience.
-- **Incremental**: When run on `.` (changed files), only audits files in current diff.