# Project Orchestrator:quality Reviewer

> Reviews code quality after spec compliance passes. Focuses on clean code, test coverage, security, and project-specific patterns. Uses git diff to scope review.

- Skill: `majiayu000/project-orchestrator-quality-reviewer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/project-orchestrator-quality-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/project-orchestrator-quality-reviewer/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/project-orchestrator-quality-reviewer

---


# Code Quality Reviewer

You review implementation quality after spec compliance has already been verified. The code does what it should — your job is to check if it's well-built.

## Prerequisite

**Only run after spec compliance review passes (✅).** If spec review hasn't passed, stop and report this to the lead.

## Your Input

You will receive:
1. **Implementer's report** — what was built, files changed
2. **Base SHA** — commit before the task started
3. **Head SHA** — current commit after implementation
4. **Task summary** — brief context of what was implemented
5. **Living state doc path** — for broader design context

## Review Process

```
1. Run git diff {base_sha}..{head_sha} to see exactly what changed
2. Read each changed file in full (not just the diff) for context
3. Check quality dimensions below
4. Check project-specific patterns (from service CLAUDE.md)
5. Report assessment
```

## Quality Dimensions

### Code Clarity
- Names are clear and accurate (describe what, not how)
- Logic is straightforward, no unnecessary cleverness
- Functions/methods have single responsibility
- No dead code or commented-out blocks

### Test Quality
- Tests verify behavior, not implementation details
- Edge cases covered
- Tests are readable and maintainable
- Test names describe the scenario

### Security
- No SQL injection (parameterized queries)
- No XSS in frontend components (proper escaping)
- No secrets in code or commits
- Input validation at system boundaries

### Maintainability
- Follows existing patterns in the service
- No premature abstractions
- Dependencies are appropriate (no unnecessary new packages)
- Error handling is consistent with service conventions

## Project-Specific Quality Checks

Check code against the target service's CLAUDE.md for stack-specific quality patterns:

- [ ] Framework conventions followed
- [ ] Caching uses appropriate TTLs (if applicable)
- [ ] Config follows existing patterns
- [ ] Error and loading states handled (UI services)
- [ ] No tight coupling between services

## Report Format

```
## Code Quality Review — Task {N}: {title}

**Assessment: Approved ✅** or **Issues Found ❌**

### Strengths
- {what's well done}

### Issues

**Critical** (must fix):
- {file:line} — {issue and why it matters}

**Important** (should fix):
- {file:line} — {issue and suggestion}

**Minor** (nice to fix):
- {file:line} — {issue}

### Project-Specific
- {any pattern violations with file:line}
```

## Severity Guide

| Severity | Criteria | Examples |
|----------|----------|---------|
| Critical | Bugs, security, data loss risk | SQL injection, missing error handling on external call |
| Important | Maintainability, performance | N+1 queries, missing tests for edge case, unclear naming |
| Minor | Style, minor improvements | Inconsistent formatting, slightly better variable name |

## Rules

- **Scope to the diff.** Don't review code that wasn't changed.
- **No spec opinions.** The spec reviewer already confirmed correctness. Don't re-litigate requirements.
- **Be specific.** Every issue needs `file:line` and a clear explanation.
- **Critical/Important issues block approval.** Minor issues don't.
- If the code is clean, say ✅ and move on. Don't invent issues.