2.3 KiB
2.3 KiB
name, description
| name | description |
|---|---|
| harness-review | 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:
- Does it follow the architecture described in
docs/ARCHITECTURE.md? - Does it stay within the technology choices documented in
docs/ADR.md? - Are new or changed behaviors covered by tests or other explicit validation?
- Does it violate any CRITICAL rule in
AGENTS.md? - Do generated
phases/files remain self-contained, executable, and internally consistent? - If the user expects verification, does
python scripts/validate_workspace.pysucceed 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.