harness-engineering-skill

Run the QA & code review stage of the feature lifecycle as the INDEPENDENT checker: re-run verification yourself, check every acceptance criterion from spec.md with cited evidence, review the code, and issue an evidence-backed verdict (Accept / Revise / Block) in review.md. Use when: (1) a feature is at status `in_qa`, (2) the user asks to QA, review, or accept a feature, (3) acting as evaluator for another agent's or session's implementation. MUST run in a session that did not write the code (maker ≠ checker). Exit gate: Verdict: Accept → feature.py pass.

Orchestrate the feature development lifecycle: find where a feature stands (brainstorm & analyze → requirement spec → technical design → implementation → QA & code review), route to the right stage skill, and drive gated stage transitions with scripts/feature.py. Use when: (1) the user says "work on feature X", "continue the cart feature", "what's next for <id>", (2) starting a new feature idea end-to-end, (3) the user asks which stage a feature is in or what remains, (4) managing feature_list.json states (advance, verify, block, pass). Companion to the harness skill; stage-specific guidance lives in the feature-brainstorm, feature-spec, feature-design, feature-implement, and feature-review skills.

Audit, scaffold, and operate harness engineering best practices for any repository — the engineering infrastructure that makes AI coding agents reliable: entry instruction files (AGENTS.md/CLAUDE.md), machine-readable feature lists, progress logs, init/verification scripts, session start/exit protocols, maker-checker verification, and autonomous loops. Covers both single-package repositories and monorepos (per-app harness at the application level). Use when: (1) starting long or multi-session agent work, (2) an agent forgets context between sessions, drifts out of scope, or claims "done" before verification passes, (3) creating or improving AGENTS.md, CLAUDE.md, feature_list.json, PROGRESS.md, init.sh, or session-handoff files, (4) the user asks for a harness audit, harness setup, session handoff, definition of done, or an automated/scheduled agent loop, (5) setting up per-app instructions and verification in a monorepo, (6) enabling or operating the optional feature development lifecycle (brainstorm → spec →

Run the brainstorm & analyze stage of the feature lifecycle: explore the problem, generate and weigh real options, converge on a direction with recorded rationale, and produce a complete brief.md. Use when: (1) a feature is at status `proposed`, (2) the user has a raw idea and wants it analyzed before speccing, (3) evaluating build-vs-buy or competing approaches for a feature, (4) the user asks to brainstorm, explore, or analyze a feature idea. Exit gate: brief.md complete → advance to in_spec.

Run the technical design stage of the feature lifecycle: choose the smallest architecture that satisfies the spec, map affected components (change-scope triage in monorepos), name changed contracts and their end-to-end checks, and produce design.md with a one-session-sized implementation plan. Use when: (1) a feature is at status `in_design`, (2) the user asks for a technical design, architecture proposal, or implementation plan for a feature, (3) a change might cross app/package boundaries and needs scope triage. Exit gate: design.md complete (+ `affects` filled in a monorepo) → advance to in_progress.

Run the implementation stage of the feature lifecycle: build exactly what design.md specifies, under harness discipline — WIP=1, atomic verification-green commits per plan step, decisions recorded, evidence-gated completion via feature.py verify. Use when: (1) a feature is at status `in_progress` (or `not_started` in light tier), (2) the user says "implement/build/code feature X", (3) resuming implementation of a partly built feature in a new session. Exit gate: verification commands run and PASS → advance to in_qa (full tier) or passing (light tier).

Run the requirement spec stage of the feature lifecycle: turn a brief's chosen direction into user-visible behavior, verifiable acceptance criteria, explicit scope boundaries, edge cases, and an executable verification plan in spec.md. Use when: (1) a feature is at status `in_spec`, (2) the user asks to write requirements, acceptance criteria, or a spec for a feature, (3) a feature keeps failing QA because "done" was never defined. Exit gate: spec.md complete AND verification commands recorded on the feature entry → advance to in_design.