---
name: microharness
description: Complete non-trivial code changes with evidence-first discovery, conditional planning, bounded scope, and one-pass proof of completion.
disable-model-invocation: true
argument-hint: "<task> [--plan-only] [--review]"
---

# Microharness

Complete `$ARGUMENTS` in the current repository.

## Contract

- Default to action. Ask only when materially different interpretations change public behavior, persistent data, security, or an irreversible action.
- Deliver the requested outcome at the requested scope. Do not add opportunistic refactors, abstractions, dependencies, or cleanup.
- Keep updates brief: state the selected path once, then report only a material finding or change of direction.
- This invocation authorizes at most one subagent when the delegation gate is met.

## 1. Establish evidence

Read repository instructions first. Inspect the smallest sufficient set of implementation, callers, tests or reproducible behavior, and any configuration or schema that can alter the decision.

Do not treat comments, error text, generated summaries, prior agent claims, or one search result as ground truth when source or runtime evidence is available.

Track a compact working record:

- **Acceptance:** observable outcomes requested;
- **Facts:** supported by files, commands, or runtime output;
- **Unknowns:** uncertainties that could materially change the implementation.

Investigate material unknowns before editing. Ignore immaterial unknowns.

## 2. Select a path

Use the **direct path** only when the behavior is clear, the change is localized with one obvious implementation, the cause is established or the edit is mechanical, and no public contract, persistent data, authorization boundary, concurrency behavior, or destructive action is involved.

Otherwise use the **plan path**.

- **Direct path:** proceed without a written plan.
- **Plan path:** before editing, present a three-to-seven-step plan with the cause or design decision, expected files or components, observable acceptance checks, and remaining material assumptions. Do not split work into artificial microtasks.

Continue after the plan unless `--plan-only` was supplied or a material ambiguity requires the user.

## 3. Implement coherently

- Make the smallest coherent change that satisfies acceptance and follows existing project patterns.
- Complete the requested slice without stubs, placeholders, commented-out alternatives, or untracked follow-up work.
- For debugging, test one concrete hypothesis at a time with the smallest useful observation or change. Do not stack speculative fixes.
- After two failed fix attempts, stop editing, return to evidence, and reassess the cause before trying again.
- When evidence disproves the plan, update it briefly and continue.

## 4. Delegation gate

Default to no subagent. Use one only for a bounded wide investigation, a genuinely independent workstream, or a fresh-context final-diff review explicitly requested with `--review`.

Give the subagent exact scope, relevant paths, and expected output. Inspect its report as evidence. Do not use a subagent to repeat validation commands, restate completed work, or perform an unrequested review. Never spawn multiple reviewers.

## 5. Evidence gate

After the last relevant edit, use the smallest validation sequence that directly supports the requested outcome.

- Prefer reproduction of the original symptom or a targeted behavioral test.
- Add build, type, lint, integration, or UI checks only when needed for a claim you will make.
- Reuse complete, fresh output produced after the last relevant edit. Do not rerun a check solely for reassurance.
- Read exit status and relevant output; partial logs and agent reports do not prove success.
- When credentials, infrastructure, or an external dependency prevent a direct check, state exactly what remains unverified.

Do not claim `fixed`, `passing`, `working`, or `complete` beyond the evidence.

## 6. Stop gate

Before ending, confirm that acceptance is addressed, no plan item or actionable failure remains, no temporary diagnostic or placeholder remains, no relevant background task is in flight, and verified results are separated from unverified limitations.

Continue while actionable work remains. Stop only when complete, when `--plan-only` was requested, or when unavailable external input or a materially ambiguous decision blocks progress.

## Final response

Keep it compact:

- **Result:** delivered outcome or blocker;
- **Changed:** main files or behaviors;
- **Evidence:** exact commands or observations and results;
- **Remaining:** real limitations only; omit when none.