harness

Repo-grounded ideation, research, and technical solution design before planning or implementation.

Research and define codebase issues before implementation planning. Use when the human explicitly invokes `$diagnose-issue`, or when an active documented workflow such as `planning-workflow`, `shape-requirements`, or `architect` routes a current-code question here. Do not select it directly from a generic bug, ticket, symptom, or design concern; enter through `planning-workflow` instead. Do not use when the user asks for a step-by-step implementation plan, direct implementation, or code review of an existing diff.

Coordinate planning from intent to implementation. Route through shape-requirements, diagnose-issue, review-spec, create-plan, plan-review, and handoff-work. Use when starting feature work, fixing a non-trivial issue, or running the full plan-build cycle.

Shape requirements before planning or implementing. Gate underspecified build, fix, or plan tasks. Interview when the user says "interview me about", "ask me questions about", "help me think through", "I need to spec out", "let's flesh out", or has a vague idea to turn into a brief.

Operate one manually stepped Harness Factory work item from intake through triage, planning, implementation, continuation, publication, and merge acknowledgement. Use when asked to run, resume, inspect, or recover Factory; interpret its next reaction or durable evidence; or apply guarded Linear projections.

Brief a code change, diff, branch, commit range, or pull request so the user can decide whether to approve, merge, revise, or build on it. Use when the user asks for a walkthrough of what changed or how it works, wants behavior or day-to-day impact, asks about API, contract, or boundary changes, questions diff size or complexity, or wants accepted tradeoffs.

Delegate one scoped implementation to an isolated executor while the parent retains authority and review control.

Review a spec document against codebase reality, identifying gaps and ensuring sound, robust implementations.

Manual-only `$audit` workflow. Use only when the user explicitly names `$audit`, `audit`, or `skills/audit`; agents must not choose it automatically for adjacent work.

Create a scoped, code-backed implementation plan from a todo, spec, issue, review notes, or raw instructions. Use for multi-step work, cross-area changes, executor handoffs, or a reviewable plan before coding.

Review a given implementation critically and adversarially against its plan or spec. Look for antipatterns, red flags, bugs, unnecessary complexity, plan drift, and missing tests. Trigger when the user says "review this implementation", "review these changes", "review this branch", "adversarial review", "challenge these changes", or wants code scrutinized before merging.

Use when the user asks to hand off work, prepare a handoff, document work for another agent, or when another agent or session will continue or review the work.

Run and close the harness `change-review` workflow for current code changes. Use when the user asks to run a review, run a full review, run a review for these changes, run the change review workflow, run a harness review, run a multi-agent review, or compile and act on harness reviewer results. If the requested steps are not explicit, run all change-review steps.

Review recently modified code for behavior-preserving clarity, simplicity, consistency, and maintainability. Trigger when the user wants a code quality, readability, maintainability, or simplification review of a diff or implementation.

Review a pull request for concrete harness documentation drift.