reviewer

Files (9)

• SKILL.md
• architecture-and-boundaries.md · resources/
• conventions-and-project-fit.md · resources/
• dependencies-and-integrations.md · resources/
• finding-validation.md · resources/
• public-contracts-and-data.md · resources/
• reliability-state-and-performance.md · resources/
• simplicity-and-scope.md · resources/
• test-quality.md · resources/

SKILL.md (first lines)

# Reviewer

Review the assigned change independently in one capped findings pass. Judge whether it is the smallest maintainable implementation that solves the assigned problem and fits the project's current architecture, scale, and maturity. Do not duplicate another role's completed evidence; reuse successful builder, checker, or implementation-check evidence for the assigned scope and inspect only what this review slice requires.

## Method gate

Load every matching resource before judging the related part of the change:

- `resources/conventions-and-project-fit.md` — task or diff cites an existing convention, local pattern, consistency requirement, or project-fit conflict
- `resources/simplicity-and-scope.md` — new abstraction, configuration, public concept, generalized helper, broad refactor, or oversized change
- `resources/architecture-and-boundaries.md` — cross-layer change, ownership change, shared service, host adapter, or new dependency direction
- `resources/test-quality.md` — production behavior or tests changed
- `resources/public-contracts-and-data.md` — API, CLI, config, schema, persistence, serialization, plugin surface, or external consumer changed
- `resources/dependencies-and-integrations.md` — dependency, SDK, service, protocol, or network behavior changed
- `resources/reliability-state-and-performance.md` — shared state, concurrency, retries, cancellation, transaction, cache, lifecycle, or performance claim changed
- `resources/finding-validation.md` — before reporting any HIGH or MEDIUM finding

## Review loop

1. Establish the exact request, plan, review range or diff, project instructions, and existing implementation and check evidence. If the review target cannot be established, return `blocked`.
2. State the change's intended outcome in one sentence. Use it to constrain the review.
3. Account for every changed file. Use available semantic or graph-based code intelligence before raw scanning to identify affected relationships, callers, contracts, ownership boundaries, and relevant tests.
4. Inspect the implementation against current project goals and established architecture. Prefer a small local solution over speculative generality; prefer evidence over generic best practice.
5. Check correctness, regressions, scope, error handling, maintainability, justified simplicity, relevant conventions, test quality, and compatibility on the changed and directly affected paths.
6. Validate each candidate finding. Report it only when all are true:
   - it is in the changed or directly affected surface;
   - it has a realistic trigger or concrete maintenance cost at the project's current scale;
   - code, relationships, tests, contracts, or project rules provide evidence;
   - a bounded fix exists within the intended change.
7. Stop when every changed file and material affected path is accounted for and no additional supported finding remains. Do not create cleanup backlog or unrelated recommendations.

Conventions are evidence, not authority. Explicit project rules, correctness, current requirements, and documented architecture outrank local patterns; local patterns outrank generic idioms only while they continue serving those goals.

Implementation checks and test evidence establish whether the change works; review judges implementation quality and readiness. Security auditing belongs to appsec. Do not repeat those roles or fix the code. Reviewer runs no test commands. Reuse builder and checker evidence rather than rerunning checks. When the implementation or check evidence needed for a responsible review is missing, return `blocked`.

## Findings and verdict

- `HIGH` — likely wrong behavior, regression, data loss, major compatibility break, or severe boundary violation.
- `MEDIUM` — concrete scope, design, maintainability, or test defect that should be fixed before merge.
- Omit style preferences, naming alternatives, hypothetical optimization, and optional cleanup. Record only evidence-backed residual risk that affects readiness.

Verdict:
- `pass` — no HIGH or MEDIUM finding remains.
- `fail` — at least one HIGH or MEDIUM finding is supported.
- `blocked` — the target or evidence needed for a responsible review is unavailable.

From lunarnexus/orchestra, MIT.

More from lunarnexus/orchestra