القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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. |
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.
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."
cd "C:/Dev/windrose/src" && git diff --cached
If no staged changes, inform the user and exit.
Analyze all staged changes against these criteria:
any, unknown where concrete types exist)#types/ (path alias for the types/ directory)src/CLAUDE.md)requireModuleByName) for cross-module dependenciesdc.* hooks (dc.useState, dc.useRef, dc.useCallback, dc.useMemo) — NOT React imports. Flag any direct import { useState } from 'preact/hooks' as incorrect.dc.useEffect hooks (return a cleanup function)dc.useCallback and dc.useMemo (not React's versions)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]
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.
How to drive the live Windrose plugin via the windrose MCP tools — find/open maps, see the canvas, place tiles/objects, verify changes. Use whenever interacting with the running Obsidian instance through mcp__windrose__* tools. Eval is the LAST resort; this skill maps every common task to its dedicated tool and documents the proven eval recipes for the rare rest.
Use this skill whenever writing, reviewing, or refactoring any CSS, whether in plain .css files, styled-components, CSS Modules, Tailwind arbitrary values, inline styles in React/Vue/Svelte, or any other frontend context. This skill ensures modern CSS features are used wherever browser support allows — things like clamp(), :has(), container queries, OKLCH colors, scroll-driven animations, anchor positioning, @starting-style, light-dark(), text-wrap: balance, and more. Trigger this skill any time CSS is being written or touched, even indirectly (e.g. a component that needs responsive sizing, a theme system, an animation, a layout). Do NOT default to legacy patterns like px-based media queries, JS-driven animations, or CSS-in-JS workarounds when a native modern CSS feature exists and is supported by the project's browser targets.
Four-axis debug harness for the running Obsidian app — compile, static-verify, runtime-probe, visual-confirm. Use for any UI, plugin, or integration change where you need to see/prove the live state.
Reviews recent code changes for frivolous, overly verbose, or LLM-like comments and removes them. Use when you want to clean up comment noise from recent commits, after generating code, or when explicitly asked to review comments.
Find one insight that eliminates multiple components - "if this is true, we don't need X, Y, or Z"