review-src

name	review-src
description	Perform thorough code review of staged changes in the src directory. Reviews for coding best practices, project patterns, type safety, and potential issues. Runs review-comments skill afterward.

Review Staged Source Changes

Performs a principal-level code review of staged changes in the source repo (the Obsidian vault).

Important: src/ is a symlink to C:\Users\whipl\OneDrive\Documents\Absalom\Projects\dungeon-map-tracker. Changes must be staged there (not in the dev harness at C:\Dev\windrose). The git diff below operates on the source repo's staging area.

Instructions

Step 0: Read Architecture Context

Before reviewing, read src/CLAUDE.md for the project's architecture conventions, coding patterns, and module system rules. This is the baseline for evaluating "project patterns."

Step 1: Get Staged Changes

cd "C:/Dev/windrose/src" && git diff --cached

If no staged changes, inform the user and exit.

Step 2: Thorough Review

Analyze all staged changes against these criteria:

Type Safety

• Proper TypeScript types (avoid any, unknown where concrete types exist)
• Consistent with existing type definitions in #types/ (path alias for the types/ directory)
• Generic constraints where appropriate

Project Patterns

• Follows existing code patterns (see src/CLAUDE.md)
• Uses Datacore's module loading pattern (requireModuleByName) for cross-module dependencies
• Consistent naming conventions
• Proper use of dc.* hooks (dc.useState, dc.useRef, dc.useCallback, dc.useMemo) — NOT React imports. Flag any direct import { useState } from 'preact/hooks' as incorrect.

Logic & Correctness

• Edge cases handled
• Null/undefined safety
• Proper cleanup in dc.useEffect hooks (return a cleanup function)
• Event listener registration/cleanup balanced

Performance

• Unnecessary re-renders avoided
• Proper memoization with dc.useCallback and dc.useMemo (not React's versions)
• Efficient data structures and algorithms

Maintainability

• Clear separation of concerns
• Appropriate abstraction level
• No over-engineering for current requirements

Potential Issues

• Race conditions
• Memory leaks
• Security concerns (XSS, injection)
• Cross-platform compatibility

Step 3: Present Findings

Organize review as:

## Summary
[1-2 sentence summary of the changes]

## Issues Found
### 1. [Issue Title] (`file:line`)
[Description and recommendation]

### 2. ...

## Suggestions
[Non-blocking improvements]

## Good Points
[What's done well]

## Verdict
[Overall assessment and whether changes are ready to commit]

Step 4: Run Review Comments

After presenting the code review, invoke the review-comments skill to check for frivolous or LLM-like comments in the staged changes:

Skill tool: skill="review-comments"

Use git diff --cached (run from src/) as the diff range for the review-comments analysis.