# Audit

> Brief project status (/status) or evidence-backed feature gap analysis (/audit). Use for "what's next", session pulse, what's implemented, or gap tables. Not for pre-commit diff review (review).

- Skill: `axidify/audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add axidify/audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/axidify/audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: Axidify (https://skillmd.com/u/axidify)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/axidify/audit

---


# Audit

Two modes — pick from the user's ask:

| Mode | Trigger | Output |
|------|---------|--------|
| **Brief status** | "status", "what's next", `/status` | ≤12 lines, no gap table |
| **Feature audit** | "what's implemented", gap analysis, `/audit` | Evidence-backed gap table |

**Not this skill:** reviewing a diff before commit → **review**.

## Brief status (≤12 lines)

1. **Current state** — 1–2 sentences
2. **Branch / tree** — branch; dirty working tree if relevant (`git status`)
3. **Recent changes** — session work or last few commits
4. **Next 3 priorities** — ordered
5. **Blockers** — if any

For feature-level gaps with code references, switch to **feature audit** below.

## Feature audit checklist

1. Apply **discover-project** if needed
2. Search broadly: feature name, routes, models, tests, permissions, jobs — not only one folder
3. Per capability: **Implemented**, **Partial**, **UI only**, **Backend only**, **Not implemented**, **Unknown**
4. Every claim needs a **code reference** (path, symbol, or line)
5. Walk the main **end-to-end flow** as the code actually runs
6. Gap table: `| Feature | Current | Expected | Gap | Priority |`
7. If the project uses `docs/status/`, offer to create or update `[module]-status.md`

## Optional passes

- Test coverage map for the module
- Deprecated APIs, TODO/FIXME density in scope

## Verification rules

- No reference → **not implemented**
- Uncertain → **unknown** — do not guess
- Do not infer backend from UI alone or UI from schema alone

## Related skills

- **discover-project** — ground in repo layout first
- **document** — update `docs/status/` when the project uses it
- **test** — map test coverage for the module
- **plan** — next implementation steps after brief status

