---
name: harness-review
description: Review a Harness Engineering repository against its persistent rules and design docs. Use when Codex is asked to review local changes, generated phase files, or implementation output against `AGENTS.md`, `docs/ARCHITECTURE.md`, `docs/ADR.md`, `docs/UI_GUIDE.md`, testing expectations, and Harness step acceptance criteria.
---

# Harness Review

Use this skill when the user wants a repository-grounded review instead of generic commentary.

## Review input set

Read these first:

- `/AGENTS.md`
- `/docs/ARCHITECTURE.md`
- `/docs/ADR.md`
- `/docs/UI_GUIDE.md`
- the changed files or generated `phases/` files under review

If the user explicitly asks for delegated review, prefer the repo custom agent `harness_reviewer` or built-in read-only explorers.

## Checklist

Evaluate the patch against these questions:

1. Does it follow the architecture described in `docs/ARCHITECTURE.md`?
2. Does it stay within the technology choices documented in `docs/ADR.md`?
3. Are new or changed behaviors covered by tests or other explicit validation?
4. Does it violate any CRITICAL rule in `AGENTS.md`?
5. Do generated `phases/` files remain self-contained, executable, and internally consistent?
6. If the user expects verification, does `python scripts/validate_workspace.py` succeed or is the failure explained?

## Output rules

- Lead with findings, ordered by severity.
- Include file references for each finding.
- Explain the concrete risk or regression, not just the rule name.
- If there are no findings, say so explicitly and mention residual risks or missing evidence.
- Keep summaries brief after the findings.

## Preferred review table

When the user asks for a checklist-style review, use this table:

| Item | Result | Notes |
|------|------|------|
| Architecture compliance | PASS/FAIL | {details} |
| Tech stack compliance | PASS/FAIL | {details} |
| Test coverage | PASS/FAIL | {details} |
| CRITICAL rules | PASS/FAIL | {details} |
| Build and validation | PASS/FAIL | {details} |

## What not to do

- Do not approve changes just because they compile.
- Do not focus on style-only issues when correctness, architecture drift, or missing validation exists.
- Do not assume a passing hook means the implementation is acceptable; review the actual diff and docs.