FESADev/.agents/skills/harness-review/SKILL.md

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:

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.