Create a structured audit document and save it to the project's docs/audits/ directory.
Trigger: when the user asks for an audit, review, or assessment of any system, feature, data quality, process, or component. Also triggered directly via /create-audit.
Arguments: $ARGUMENTS — a description of what to audit (e.g. "data quality for user profiles", "API endpoint security", "deployment pipeline reliability").
Steps
Parse the audit subject from $ARGUMENTS. If empty or vague, infer the subject from recent conversation context. If still unclear, ask the user what they want audited.
Investigate the subject thoroughly. Read relevant source files, configs, logs, test results, git history, and any external state (API responses, deployment status) needed to form an evidence-based assessment. Do not guess — verify.
Generate the audit document with this structure:
# <Audit Title> — <YYYY-MM-DD>
<One-line summary of what was audited and why.>
## Scope
What was included and excluded from this audit.
## Findings
### <Finding Category 1>
| Item | Status | Details |
| ---- | ------ | ------- |
| ... | ... | ... |
<Narrative explanation of the findings with evidence (file paths, line numbers, metrics, command output).>
### <Finding Category 2>
...
## Issues
| Severity | Issue | Location | Recommendation |
| -------- | ----- | -------- | -------------- |
| CRITICAL | ... | ... | ... |
| WARNING | ... | ... | ... |
| INFO | ... | ... | ... |
If no issues: "No issues found."
## Summary
<2-3 sentence verdict. What's healthy, what needs attention, what's the recommended next action.>
Generate a filename in the format: <topic-slug>-<YYYY-MM-DD>.md (e.g. data-quality-2026-04-05.md, api-security-2026-04-09.md). Use lowercase kebab-case.
Write the file to docs/audits/<filename>. Create the docs/audits/ directory if it doesn't exist.
Report to the user: show the file path and a brief summary of findings (critical/warning/info counts). Do not dump the full document into chat. To turn a specific CRITICAL/WARNING finding into an isolated reproduction with a failing test, hand it to /reproduce-bug <finding>.
Rules
- Every claim in the audit must be backed by evidence (a file read, command output, metric, or test result). No assumptions.
- Severity levels: CRITICAL = broken or actively harmful, WARNING = degraded or risky, INFO = improvement opportunity.
- Do not fix issues found. Report them. The user decides what to act on.
- Do not commit the audit file. Leave it as an untracked file for the user to review.
- Keep the document concise. Tables over prose where possible. No filler.
1---2name: create-audit3description: Create an evidence-based audit document and save it to docs/audits/. Triggers on: "audit", "review", "assessment".4---56Create a structured audit document and save it to the project's `docs/audits/` directory.78Trigger: when the user asks for an audit, review, or assessment of any system, feature, data quality, process, or component. Also triggered directly via `/create-audit`.910Arguments: `$ARGUMENTS` — a description of what to audit (e.g. "data quality for user profiles", "API endpoint security", "deployment pipeline reliability").1112## Steps13141. **Parse the audit subject** from `$ARGUMENTS`. If empty or vague, infer the subject from recent conversation context. If still unclear, ask the user what they want audited.15162. **Investigate the subject thoroughly.** Read relevant source files, configs, logs, test results, git history, and any external state (API responses, deployment status) needed to form an evidence-based assessment. Do not guess — verify.17183. **Generate the audit document** with this structure:1920 ```markdown21 # <Audit Title> — <YYYY-MM-DD>2223 <One-line summary of what was audited and why.>2425 ## Scope2627 What was included and excluded from this audit.2829 ## Findings3031 ### <Finding Category 1>3233 | Item | Status | Details |34 | ---- | ------ | ------- |35 | ... | ... | ... |3637 <Narrative explanation of the findings with evidence (file paths, line numbers, metrics, command output).>3839 ### <Finding Category 2>4041 ...4243 ## Issues4445 | Severity | Issue | Location | Recommendation |46 | -------- | ----- | -------- | -------------- |47 | CRITICAL | ... | ... | ... |48 | WARNING | ... | ... | ... |49 | INFO | ... | ... | ... |5051 If no issues: "No issues found."5253 ## Summary5455 <2-3 sentence verdict. What's healthy, what needs attention, what's the recommended next action.>56 ```57584. **Generate a filename** in the format: `<topic-slug>-<YYYY-MM-DD>.md` (e.g. `data-quality-2026-04-05.md`, `api-security-2026-04-09.md`). Use lowercase kebab-case.59605. **Write the file** to `docs/audits/<filename>`. Create the `docs/audits/` directory if it doesn't exist.61626. **Report to the user**: show the file path and a brief summary of findings (critical/warning/info counts). Do not dump the full document into chat. To turn a specific CRITICAL/WARNING finding into an isolated reproduction with a failing test, hand it to `/reproduce-bug <finding>`.6364## Rules6566- Every claim in the audit must be backed by evidence (a file read, command output, metric, or test result). No assumptions.67- Severity levels: **CRITICAL** = broken or actively harmful, **WARNING** = degraded or risky, **INFO** = improvement opportunity.68- Do not fix issues found. Report them. The user decides what to act on.69- Do not commit the audit file. Leave it as an untracked file for the user to review.70- Keep the document concise. Tables over prose where possible. No filler.
kaiohenricunha