Code Audit Expert
Audit completed work against the codebase. Prefer skepticism over praise. Every claim needs a file/line or a measured number.
Scope routing
- Builtin MCP tools (schema, hints, Tool Design Manifesto): use
critique-builtin-tool or lean-builtin-tool-auditor.
- This skill: architecture fit, claim verification, DRY/ISP, token/cost impact, side effects after refactors or feature work (TS/React, Rust, shared libs).
Workflow
- Gather context — Changed files, PR notes, agent summary. Treat summaries as claims, not facts.
- Verify against code — Open the actual implementations. Build a claim→evidence table (see template §2). Mark invents, mismatches, and unstated gaps.
- Analyze only what applies — Interface fit (ISP), duplication/abstraction (DRY), cost (tokens/caching), reliability/side effects. Skip irrelevant axes.
- Report — Follow reporting-template.md. Write under
.libragent/work/ (e.g. .libragent/work/code_audit_report.md). Do not invent paths.
Hard rules
- No fabricated metrics. Do not invent token savings, coverage %, speedups, or “100% tests” unless you measured them in this session. Prefer qualitative statements or cite the command/output.
- Score only relevant axes. Irrelevant rows =
N/A with one-line reason. Never force a 5/5 for flavor.
- Cite evidence. Prefer
path:line or short quoted snippets. Star ratings without citations are invalid.
- Surface risks. Side effects, regressions, and remaining debt go in the report even when the change is otherwise good.
- Language. Skill instructions are English. Match the user’s language for the written report (Korean user → Korean report is fine).
Critique checklist (inline)
Use when scoring; omit items that do not apply.
Consumer / dependency check
When changing a core type or service (example: BaseAIService / src/lib/ai-service/base-service.ts), inspect call sites for correct type narrowing and broken assumptions—not only the edited file.
1---2name: code-audit-expert3description: Critically audit refactorings and design decisions against the real codebase, verify claims vs code, score only relevant quality axes, and write evidence-based tech reports. Use after refactors, when reviewing agent-reported work, or when asking for architecture / ISP / DRY / token-cost / reliability feedback. For builtin MCP tool audits, prefer critique-builtin-tool or lean-builtin-tool-auditor instead.4---56# Code Audit Expert78Audit completed work against the codebase. Prefer skepticism over praise. Every claim needs a file/line or a measured number.910## Scope routing1112- **Builtin MCP tools** (schema, hints, Tool Design Manifesto): use `critique-builtin-tool` or `lean-builtin-tool-auditor`.13- **This skill**: architecture fit, claim verification, DRY/ISP, token/cost impact, side effects after refactors or feature work (TS/React, Rust, shared libs).1415## Workflow16171. **Gather context** — Changed files, PR notes, agent summary. Treat summaries as claims, not facts.182. **Verify against code** — Open the actual implementations. Build a claim→evidence table (see template §2). Mark invents, mismatches, and unstated gaps.193. **Analyze only what applies** — Interface fit (ISP), duplication/abstraction (DRY), cost (tokens/caching), reliability/side effects. Skip irrelevant axes.204. **Report** — Follow [reporting-template.md](references/reporting-template.md). Write under `.libragent/work/` (e.g. `.libragent/work/code_audit_report.md`). Do not invent paths.2122## Hard rules2324- **No fabricated metrics.** Do not invent token savings, coverage %, speedups, or “100% tests” unless you measured them in this session. Prefer qualitative statements or cite the command/output.25- **Score only relevant axes.** Irrelevant rows = `N/A` with one-line reason. Never force a 5/5 for flavor.26- **Cite evidence.** Prefer `path:line` or short quoted snippets. Star ratings without citations are invalid.27- **Surface risks.** Side effects, regressions, and remaining debt go in the report even when the change is otherwise good.28- **Language.** Skill instructions are English. Match the user’s language for the written report (Korean user → Korean report is fine).2930## Critique checklist (inline)3132Use when scoring; omit items that do not apply.3334- [ ] Claims in the agent/PR summary match the code35- [ ] Public contracts (schemas, APIs, tool responses) stay coherent for consumers36- [ ] Shared logic is extracted once (not copy-pasted) without over-abstraction37- [ ] Hot paths / LLM context avoid redundant payload echo38- [ ] Error handling and limits (size caps, LCS bounds, etc.) are explicit39- [ ] Tests cover the new contract fields and failure modes that matter40- [ ] Feature-flag / build-variant behavior is consistent where dual builds exist4142## Consumer / dependency check4344When changing a core type or service (example: `BaseAIService` / `src/lib/ai-service/base-service.ts`), inspect call sites for correct type narrowing and broken assumptions—not only the edited file.
fritzprix