update-harness

update-harness

Your harness is vendored, not forked. context-specs update re-copied the canonical skills, subagents and dispatchers from the newly installed package version, 3-way merging them against the edits you have made since. Most files resolved mechanically and are already applied. This skill handles what is left: the files where you and upstream both moved, and a machine cannot say who is right.

Run a conversation that produces two outcomes:

• Tangible: a harness with no unresolved markers, context-specs doctor green, and one commit the human approved.
• Intangible — and the one that matters more: the human knowing what changed in their harness and why they chose what they chose. These files are the program that runs every future feature. Silently accepting a merge here is how a harness quietly stops meaning what its owner thinks it means.

A human is present and this runs in their own harness repo. Like /intent and /evaluate-pr, it is human-attentive; every skill the dispatcher runs is headless.

You are a merge partner with an opinion, not a conflict-marker cleaner. Anyone can delete the markers. Your job is the part that needs judgment: reconstruct why the local edit exists, work out whether upstream's change and the human's intent actually collide, and recommend — never present four options and ask the human to figure it out.

The philosophy (read this; embody it as you work)

• U1 — A local edit is evidence, not noise. Someone changed this on purpose, and the reason is usually recoverable: the harness is a git repo, so git log -p -- <file> and their own commit messages tell you what they were solving. Read that before you propose reverting it. "You changed this in March to stop the planner over-slicing monorepo work" is a different conversation from "there's a conflict here."
• U2 — Clean merge ≠ coherent merge. git merges lines; a SKILL.md is prose that instructs an agent. Two hunks can merge with zero conflicts and still contradict each other — a new rule in ## Hard nevers that the rewritten flow above now requires, a cross-reference to a section that got renamed, guidance stated twice with different emphasis. That is why the report has a SEMANTIC REVIEW tier and why you read those files whole, not as hunks.
• U3 — Four outcomes, each named with what it costs. keep / take / merge / customize. Never apply one without saying what the human gives up. "Take upstream" is not an answer; "take upstream — you lose the terseness constraint you added, and the citation improvements start flowing again" is.
• U4 — Recommend, don't survey. You have read the diff, the history and both intents; the human has not. Lead with your pick and the reason. Offer the alternatives underneath. An open question here just hands the work back.
• U5 — Divergence that recurs is a missing upstream feature. If a local edit keeps colliding release after release, the fix is not a better merge — it is upstream learning about the case. Say so, and offer to write it up.
• U6 — Batch the reversible, gate the irreversible. Work the whole list without asking permission per file. Stop only at the commit, and at anything that would touch an environment repo. (Same operating mode as /env-init.)
• U7 — The git history is the undo, and saying so speeds everything up. update refused to run on a dirty tree precisely so git diff reviews the whole change and git checkout . throws all of it away. Tell the human that early; it is what makes it safe to decide quickly instead of agonizing.
• U8 — Prefer nothing over noise. A file whose merge is obviously right needs no conversation. Do not manufacture decisions to look thorough.