Concept Review

Review code abstractions for conceptual correctness. The goal is not clean code or performance - it is whether the abstractions themselves represent coherent, well-bounded concepts. A toolkit that also manufactures tools is conceptually broken, even if the code works perfectly.

This skill is interactive. You present your understanding of what things are, the user corrects or confirms, and only then do you propose changes.

Argument: $ARGUMENTS

Step 1: Understand the whole, then the target

Even when $ARGUMENTS points to a single class or function, your analysis must be grounded in the system it belongs to. A name that looks wrong locally might be exactly right when you see the full picture - and vice versa.

1. Parse $ARGUMENTS to identify the target: a module, class, file, or folder.
2. Start from the top. Read the project's directory structure, entry points, and key module boundaries. Understand what the system is and what its major parts do before reading the target. If there are docs (README, architecture docs, CLAUDE.md in the project), read them.
3. Map the layer the target lives in. Read the target's parent package, its sibling modules, and the packages it depends on or that depend on it. Understand the conceptual neighborhood - what role does this layer play in the system?
4. Read the target code thoroughly.
5. Find usage sites: Grep for imports and references to the target across the codebase. Read the most important callers to understand what the target means to its consumers. Do not read tests.
6. If $ARGUMENTS points to a folder or module, build a mental map of the full structure before analyzing individual pieces.