Simplify

Simplify

Review changed code for reuse opportunities, quality, and architecture compliance.

Input

The user input is: $ARGUMENTS

• File paths or git ref: Review specific files or changes since a commit
• Empty: Review all uncommitted changes (git diff + git diff --staged)

Step 1: Identify Changed Code

# If no specific input, check all changes
git diff --name-only
git diff --staged --name-only

Step 2: Analyze with Graph + LLM (before reading files)

Use the graph → LLM → manual priority. Claude should NOT read changed files directly — let LLM do the reading.

Graph (if code-review-graph available): Run build_or_update_graph_tool, then:

• get_impact_radius_tool on each changed file — shows blast radius and downstream consumers
• query_graph_tool with imports_of on changed files — reveals architecture boundary violations instantly
• query_graph_tool with importers_of on changed files — shows what depends on the changed code
• Do NOT use get_architecture_overview_tool, list_communities_tool, or detect_changes_tool — all three can overflow context (90-300K chars)

LLM (MANDATORY) — Check LM Studio first (Bash tool, wait for result):

CRAFT_SCRIPTS=$(find ~/.claude/plugins -name "llm-agent.sh" -path "*/craft-skills/*" -exec dirname {} \; 2>/dev/null | head -1) && curl -s --max-time 2 ${LLM_URL:-http://127.0.0.1:1234} > /dev/null 2>&1 && echo "LLM_AVAILABLE:$CRAFT_SCRIPTS" || echo "LLM_UNAVAILABLE"

If LLM_AVAILABLE, run with Bash tool (run_in_background: true, timeout 300000ms):

bash "$CRAFT_SCRIPTS/llm-agent.sh" "Review these changed files for: 1) Reuse opportunities — check if the project's shared modules already have equivalent utilities 2) Architecture boundary violations (cross-module imports between business modules) 3) Unnecessary complexity or premature abstractions 4) Naming consistency. Changed files: [list from git diff]. Also check these related files flagged by graph: [high-risk files from get_impact_radius_tool]" <project-root>

Then unload: bash "$CRAFT_SCRIPTS/llm-unload.sh". If LLM_UNAVAILABLE, fall back to reading files graph flagged as high-risk. Filter out false positives about plugins/skills.

Wait for LLM results before proceeding to Steps 3-5. The LLM handles the file reading — Claude's role in Steps 3-5 is to triage and verify LLM findings using graph data, not to re-read every file.

If LLM is unavailable, fall back to reading only the files graph flagged as high-risk.

Step 3: Reuse Check

Triage LLM findings (if available) and graph results for reuse opportunities:

• Shared components: Is there an existing shared component that could replace custom code?
• Shared hooks/utilities: Is there an existing utility that duplicates new logic?
• Form fields: Are raw inputs used instead of existing form components (if applicable)?
• Cross-module patterns: Is the same utility being created in multiple modules? Should it be shared?

Only read a specific file if the LLM flagged an issue you need to verify.

Step 4: Architecture Boundary Check

Use graph imports_of results and LLM findings:

• Are all imports from shared modules or the same module?
• Are new types/utilities placed in the correct module?
• Should any new shared functionality be in the project's shared module instead?

Step 5: Quality Review

Based on LLM findings, check for:

• Unnecessary complexity: Can this be simplified without losing functionality?
• Premature abstraction: Is a helper/utility created for a one-time operation?
• Missing error handling at boundaries: User input validation, API response handling
• Excessive error handling internally: Trust internal code, don't over-validate
• Consistent naming: Do new names follow existing codebase conventions?

UI/UX quality check (conditional, deterministic): If the changed files include UI components (.tsx, .vue, .svelte) AND .claude/aesthetic-direction.md exists, invoke craft-skills:design-review via the Skill tool. It will screenshot the affected routes and audit them against the aesthetic direction and any feature ux-brief.md. This replaces the older opportunistic ui-ux-pro-max invocation — it is deterministic, visual (not just code-based), and cheap (Haiku-first, ~15K tokens per audit).

If .claude/aesthetic-direction.md does not exist, skip silently (no-op). The user can enable this by running craft-skills:aesthetic-direction once.

Step 6: Verification

Iron Law: Evidence before assertions.

Run the project's verification commands:

1. npm run lint
2. npx tsc --noEmit
3. npm run format
4. npm run build

Report actual output, not assumptions about output.

Step 7: Report

Present findings with specific file:line references:

## Review Findings

### Reuse Opportunities
- `src/domain/X/ui/CustomButton.tsx:15` — could use shared `Button` component instead

### Architecture Concerns
- `src/modules/rooms/RoomList.tsx:8` — imports from another business module (boundary violation)

### Quality
- `src/domain/X/utils/formatDate.ts` — single-use utility, inline instead

### Verification
- Lint: PASS
- TypeScript: PASS
- Build: PASS