58 lines
2.3 KiB
Markdown
58 lines
2.3 KiB
Markdown
---
|
|
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.
|