initial commit

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

@@ -0,0 +1,57 @@
+---
+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.