studio-code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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:

```markdown
## Code Review: [File or System Name]

From islee23520/lux, MIT.

More from islee23520/lux