studio-code-review

name	studio-code-review
description	Review a file or small set of files for standards, architecture, SOLID, performance, testability, and implementation risks, with optional specialist subreviews.
category	review
source	chronos-adapted
source_path	.claude/skills/code-review/SKILL.md

Studio Code Review

Use this skill to perform a structured review of implementation quality on a target file, directory, or focused change set.

This skill is read-only unless the user explicitly asks for fixes in a separate step.

Phase 1 — Load Target Context

Read the target file or files in full.

Also read any nearby coding standards or architecture guidance that exists in the repository, such as:

• README
• contributor guides
• architecture docs
• ADRs
• lint or test configuration

If no formal standards are present, infer conventions from neighboring code rather than inventing a style.

Phase 2 — Identify Relevant Specialists

Determine whether this review would benefit from parallel Task-based specialists.

Examples:

• language or engine specialist for core runtime code
• UI specialist for presentation code
• shader or rendering specialist for graphics code
• QA or testability specialist for logic-heavy changes

Only spawn specialists that clearly fit the target. Avoid project-specific role names when they are not available.

Phase 3 — ADR and Architecture Intent Check

Look for architecture references in:

• ADR files
• nearby design docs
• story or task files
• code comments or headers

If ADRs or design decisions are referenced, read the relevant parts and compare the implementation against them.

Classify deviations as:

• Architectural Violation — contradicts an explicit decision
• Architecture Drift — meaningfully diverges without clear justification
• Minor Deviation — small difference that does not alter the main design intent

If no references exist, note that the ADR compliance check was skipped.

Phase 4 — Standards Compliance

Evaluate the implementation against repository conventions and these common checks:

• documentation on public APIs where the codebase expects it
• manageable method size and complexity
• dependency injection or clean dependency boundaries where appropriate
• configuration separated from hardcoded values where the codebase expects that
• interface use versus unnecessary concrete coupling

Do not treat every checklist item as universal law. Match the local codebase style.

Phase 5 — Architecture and SOLID

Check:

Architecture

• dependency direction is sensible
• layers are not inverted
• UI does not own core state unless that is the project pattern
• cross-system communication uses the project's preferred coordination pattern
• the code is consistent with established patterns nearby

SOLID

• single responsibility
• open for extension where appropriate
• subtype substitutability
• interface segregation
• dependency inversion

Call out concrete examples with file and line references when possible.

Phase 6 — Runtime and Operational Concerns

Check for practical risks relevant to the code under review:

• frame or time-step correctness if real-time logic exists
• unnecessary allocations in hot paths
• null or empty-state handling
• thread-safety or async safety where applicable
• cleanup and lifecycle correctness
• error handling and observability

Tailor this section to the technology involved rather than forcing game-only rules onto every review.

Phase 7 — Parallel Specialist Reviews

If specialists are useful, spawn them in parallel via Task.

Possible specialist prompts:

• architecture specialist: review dependency boundaries and system fit
• language specialist: review idioms, correctness, and maintainability
• UI specialist: review state ownership, rendering concerns, and accessibility
• QA specialist: review testability, seams, hooks, and acceptance-criteria coverage

Collect all findings before issuing the final review.

Phase 8 — Output Format

Use this structure:

## Code Review: [File or System Name]

### Specialist Findings
[Summarize specialist input or say none were used]

### ADR / Architecture Intent
[Compliant / Drift / Violation / Not checked]

### Standards Compliance
[Key passes and failures]

### Architecture
[Clean / Minor Issues / Violations Found]

### SOLID
[Compliant / Issues Found]

### Runtime and Operational Concerns
[List relevant risks]

### Positive Observations
[Always include what is done well]

### Required Changes
[Must-fix items]

### Suggestions
[Non-blocking improvements]

### Verdict
[Approved / Approved with Suggestions / Changes Required]

Phase 9 — Next-Step Guidance

• If approved: recommend the next workflow step such as merge, close the task, or continue implementation.
• If changes are required: list the smallest concrete changes needed before re-review.
• If an architectural violation exists: recommend updating the implementation or recording a fresh architecture decision before continuing.

Verdict: COMPLETE when the review is fully written and evidence-backed.