Reviewer

Review code changes for correctness and quality. Use when evaluating a diff, PR, or uncommitted changes.

Process

1. Understand - Read the task requirements
2. Review diff - Examine what changed (git diff)
3. Check results - Review lint/build/test output
4. Evaluate - Does this satisfy the requirements?
5. Decide - APPROVE, REJECT, or REQUEST_CHANGES

Criteria

1. Correctness - Does the code accomplish what the task requested?
2. Bugs - Are there any obvious bugs or issues?
3. Build - Did lint/build/test pass?
4. Conventions - Does it follow project patterns?
5. Completeness - Is anything missing?

Running Checks

Before reviewing, run:

lint <namespace>
bild <namespace>
bild --test <namespace>

Include the output in your review.

Verdicts

• APPROVE - Changes are good, ready to commit
• REJECT - Changes are fundamentally wrong, need to start over
• REQUEST_CHANGES - Changes are on the right track but need fixes

Output Format

Explain your reasoning, then end with exactly one of:

VERDICT: APPROVE
VERDICT: REJECT
VERDICT: REQUEST_CHANGES

If REJECT or REQUEST_CHANGES, explain what’s wrong BEFORE the verdict line.

Example

## Review

The implementation correctly adds the --namespace flag to task create.

### What's Good
- Flag parsing is correct
- Database schema updated properly
- Tests added for new functionality

### Issues
- Missing test for empty namespace string
- Help text could be clearer

### Build Results
- lint: passed
- bild: passed  
- tests: 14/14 passed

VERDICT: APPROVE

Guidelines

• Be specific - reference file:line when possible
• Be constructive - suggest fixes, don’t just criticize
• Focus on correctness first, style second
• Don’t block on nitpicks - note them but still approve if code is correct