code-review

name	code-review
description	Review code for correctness, maintainability, security, and adherence to ArtStroy project standards. Use when reviewing PRs, local changes, or specific files for quality assurance.

Code Review

Professional and thorough code review for ArtStroy — both local development changes and pull requests.

Workflow

1. Determine Review Target

• Remote PR: PR number or URL provided → checkout and review that PR
• Local changes: no PR specified → review current staged/working tree changes

2. Preparation

For PRs:

1. Read the PR description and existing comments to understand intent
2. Review the diff — do not just read the files in isolation
3. Check the branch was created from master (not from another feature branch)

For local changes:

1. git status — identify what changed
2. git diff + git diff --staged — read the actual diff
3. For substantial changes: run bun run build to catch type errors and build failures before review

3. Review Pillars

Correctness: Does the code achieve its purpose without bugs or logical errors?

Maintainability: Is the code clean, well-structured, and easy to modify?

• Single responsibility per function/component
• No deeply nested conditionals (> 3 levels)
• Descriptive names (no tmp, data2, handleClick2)

Readability: Is the code consistently formatted?

• TypeScript: follows existing patterns in the file
• Astro/MDX: follows src/content/config.ts schema
• No unnecessary comments explaining what (code should be self-explanatory); comments for why

Security (see security-headers-check and dependency-audit for deeper audit):

• No hardcoded secrets, API keys, or tokens
• No dangerouslySetInnerHTML without sanitization
• No external script injection in MDX or Astro templates

Edge cases: Does the code handle missing data, empty arrays, null values?

Testability: Is new logic covered by tests or at minimum testable in isolation?

4. ArtStroy-Specific Checks

Astro/MDX:

• astro check must pass (zero TypeScript errors)
• New frontmatter fields must be added to src/content/config.ts schema
• No # (h1) in MDX article body
• Code blocks in MDX must have language tags

React components:

• Props typed (no implicit any)
• Client directives used correctly: client:load for immediate interactivity, client:visible for lazy hydration
• No direct DOM manipulation — use React state/refs
• DaisyUI classes for UI primitives

Conventional Commits:

• Commit messages follow type(scope): description format
• Description starts with lowercase imperative verb
• No generic messages ("fix stuff", "update files")

5. Feedback Structure

## Code Review — {branch/PR}

### Critical (blocks merge)
- [ ] {issue}: {file:line} — {what to change and why}

### Improvements (non-blocking but recommended)
- [ ] {issue}: {suggestion}

### Nitpicks (optional)
- [ ] {minor style issue}

### Verdict
[ ] APPROVED
[ ] CHANGES REQUESTED

Tone

• Constructive, professional, specific
• Explain why a change is requested, not just what
• For approvals, acknowledge specific value of the contribution
• Distinguish between opinion and requirement ("I'd prefer X" vs. "This will cause a type error")