configs/claude-code/skills/review-full/SKILL.md
Whole-codebase review using 8 specialized review agents in parallel against a repomix-packed snapshot.
npx skillsauth add jimweller/dotfiles review-fullInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
STARTER_CHARACTER = 🔎
Review the entire codebase across 8 focus areas in parallel. Each agent reads from a single repomix-packed snapshot via MCP. Output goes to per-area files in .llmtmp/review-full/.
Arguments: $ARGUMENTS
If $ARGUMENTS is provided, treat it as a path relative to the repo root. Otherwise pack the whole repo.
$ARGUMENTS is a Claude Code template substitution, not a shell variable. It is replaced in the markdown before bash runs. Use plain assignment plus a conditional fallback. Do NOT use ${1:-...} or ${ARGUMENTS:-...} parameter expansion forms; both expand the substituted text inside ${...} and produce invalid bash when the argument contains slashes or is empty.
PROJECT_ROOT=$(git rev-parse --show-toplevel)
PROJECT_ROOT=$(cd -P "$PROJECT_ROOT" && pwd -P)
TARGET_PATH="$ARGUMENTS"
[ -z "$TARGET_PATH" ] && TARGET_PATH="$PROJECT_ROOT"
# Resolve to physical absolute path and verify it stays inside the repo (no traversal, no symlink escape).
TARGET_PATH=$(cd -P "$TARGET_PATH" 2>/dev/null && pwd -P) || { echo "TARGET_PATH does not exist"; exit 1; }
case "$TARGET_PATH" in
"$PROJECT_ROOT"|"$PROJECT_ROOT"/*) ;;
*) echo "TARGET_PATH escapes PROJECT_ROOT"; exit 1 ;;
esac
TARGET_NAME=$(basename "$TARGET_PATH")
[ "$TARGET_PATH" = "$PROJECT_ROOT" ] && TARGET_NAME="repo"
OUTPUT_DIR="$PROJECT_ROOT/.llmtmp/review-full"
rm -rf "$OUTPUT_DIR"
mkdir -p "$OUTPUT_DIR"
REPOMIX_FILE="$OUTPUT_DIR/repomix.xml"
npx repomix -o "$REPOMIX_FILE" --quiet --output-show-line-numbers "$TARGET_PATH"
The repomix file lives inside OUTPUT_DIR (.llmtmp/review-full/), which is gitignored and wiped at the start of every run by Step 2. No /tmp leakage and no trap needed. A trap does not work here because each bash code block in this skill runs in a separate shell process; an EXIT trap registered in Step 3 would fire as soon as Step 3's bash block ends, deleting the file before Step 4 (attach_packed_output) can read it.
Repomix reads .repomixignore from the project root automatically.
Verify the file was created. Confirm REPOMIX_FILE before proceeding.
Call attach_packed_output with filePath=REPOMIX_FILE. Record the returned outputId string. This is the codebase access handle the agents will use.
Do not delegate this step to a subagent. The orchestrator must own the outputId.
Send a single message with 8 Task tool uses, one per review area. Each Task uses the corresponding subagent_type:
| Agent | Subagent type | Output file |
| --------------------- | --------------------- | ----------------- |
| Architecture & Design | review-architecture | architecture.md |
| Correctness & Bugs | review-correctness | correctness.md |
| Operational Readiness | review-ops | ops.md |
| Performance | review-performance | performance.md |
| Code Quality | review-quality | quality.md |
| Security | review-security | security.md |
| SOLID Principles | review-solid | solid.md |
| Testing | review-testing | testing.md |
Each Task prompt contains:
outputId from Step 4read_repomix_output and grep_repomix_output for navigation<OUTPUT_DIR>/<area>.md. Use H2 header followed by findings or 'No findings.'"After all 8 agents complete, verify each file in <OUTPUT_DIR>:
## <Area>)No findings.If a file fails any of those checks, treat the agent as having silently failed and re-dispatch that one agent. Do NOT accept a stub like ## Testing\n with no body or content that omits the H2 header.
Produce a summary in the conversation:
# Full Review Summary
Target: <TARGET_NAME>
Files reviewed: <count from repomix>
## Findings Counts
| Area | High | Medium | Low |
| --------------------- | ---- | ------ | --- |
| Architecture & Design | <N> | <N> | <N> |
| Correctness & Bugs | <N> | <N> | <N> |
| Operational Readiness | <N> | <N> | <N> |
| Performance | <N> | <N> | <N> |
| Code Quality | <N> | <N> | <N> |
| Security | <N> | <N> | <N> |
| SOLID Principles | <N> | <N> | <N> |
| Testing | <N> | <N> | <N> |
## Output Files
- `.llmtmp/review-full/architecture.md`
- `.llmtmp/review-full/correctness.md`
- `.llmtmp/review-full/ops.md`
- `.llmtmp/review-full/performance.md`
- `.llmtmp/review-full/quality.md`
- `.llmtmp/review-full/security.md`
- `.llmtmp/review-full/solid.md`
- `.llmtmp/review-full/testing.md`
Read individual files for detailed findings.
Do not load the file contents into the conversation. The summary is the artifact; files are persistent for follow-up.
testing
Search saved session transcripts for past decisions, actions, errors, and context that has left the current conversation window.
data-ai
Review a PRD for defects via Claude opus subagent.
development
Markdown authoring guidelines for formatting, code blocks, and structure. Use when writing or editing markdown files.
development
--- name: md-style description: README style guide for concise, direct documentation. Use when writing or editing README files. ß--- <!-- markdownlint-disable-file MD041 --> # README Style Guide Write concise, direct README files for experienced engineers. ## Principles - **No fluff** - Skip tables of contents, verbose explanations, development history - **No roadmaps** - Document current state only, not plans or decisions. Readme is an engineering specification. Not a project plan or chan