stale-patch-reconciliation — Reconcile a stale patch/diff against a current checkout.
Scanned 9/11/2026
Install to Claude Code
npx -y skills add AtlasOmnia/hermes-custom-pack --skill stale-patch-reconciliation --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Stale Patch Reconciliation?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/atlasomnia-stale-patch-reconciliation)More formats (shields.io, HTML) on the badges page.
---
name: stale-patch-reconciliation
description: stale-patch-reconciliation — Reconcile a stale patch/diff against a current checkout.
version: 1.0.0
created_by: agent
---
# Stale Patch Reconciliation
Use when a patch/diff must be compared with, repaired against, or refreshed for a moving checkout — "is this patch still needed", "does upstream already contain it", "what changed since it was written", "reconcile X.diff with HEAD", or "make apply-patches pass again".
This skill has two explicit modes:
- **Analysis mode (default):** read-only archaeology and a minimal repair plan. Do not edit, reset, stash, clean, update, or restart.
- **Repair mode (only when authorized):** implement the invariant in an isolated worktree, run focused gates, regenerate the patch from the current baseline and an explicit file allowlist, then apply it to the live checkout only after clean/reverse checks pass. Preserve unrelated dirty work exactly.
Deliverable shape: (1) behavioral invariant, (2) exact gaps/call sites, (3) upstream status, (4) drift cause, (5) minimal repair, (6) focused gate evidence, and (7) artifact/applicator verification. Coordinate writer ownership through `shared-worktree-agent-orchestration`.
## Core sequence
1. **Read the full patch first.** Paginate the whole diff; note every file touched and the old-file line numbers of each hunk. The hunks are the map for later drift attribution.
2. **Git history archaeology** — does the feature exist anywhere?
- `git log --all --oneline -i --grep=<feature>` — commits mentioning it by name
- `git log --all --oneline -S'<feature>'` — commits adding/removing the string (catches renames/variants)
- `git log origin/main -S'<feature>'` — **empty means NOT upstream** (private branches don't count as upstream)
- `git merge-base --is-ancestor <sha> HEAD && echo YES || echo NO` — ancestry test
- `git branch -a --contains <sha>` — which branches carry the commits
3. **Snapshot-branch trap.** If `git merge-base HEAD <branch>` returns EMPTY output, the branch is likely built on a parentless snapshot commit. Confirm with `git log --format='%h parents: %P' -1 <sha>` — no parents = root/snapshot commit (e.g. "chore: snapshot upstream main for private feature review"). Such a branch shares NO ancestry with HEAD, so lineage tools mislead; treat the branch's cumulative diff as the feature and ignore ancestry.
4. **Quantify staleness read-only.** `git apply --check <patch>` validates without applying (safe). Per-file apply map:
```bash
for f in $(grep '^diff --git' <patch> | awk '{print $3}' | cut -d/ -f2-); do
git apply --check --include="$f" <patch> >/dev/null 2>&1 && echo "OK $f" || echo "FAIL $f"
done
```
CAUTION: exit code after a pipe reflects the last command (`head`), not `git apply` — read the error text, not `$?`. Files whose hunks apply cleanly today are "context-compatible"; failed files are where the rework lives.
5. **Attribute drift.** `git log --oneline <branch-or-sha>..HEAD -- <paths>` lists upstream commits since the branch point. Read the ones touching failing files to explain each failed hunk (parser renames, schema field additions, UI refactors). Report drift as "hunk N fails because upstream renamed X → Y" — that is the minimal-plan input.
6. **Read current call sites.** Grep current line numbers for every function the patch touches and compare signatures against the patch's expectations. Note which upstream refactors the reimplementation must target (e.g. new parser API, new CommandDef fields).
7. **Live-checkout concurrency (shared worktrees).** The tree can change MID-analysis — a concurrent writer may implement the very feature being reconciled. Re-verify `git status --porcelain` and re-grep at the END; report a final snapshot with "may already be stale" on line numbers. Distinguish pre-existing dirty files from concurrent-writer edits so the parent doesn't lose work.
## Repair mode: isolated three-way reconciliation
When the user authorizes implementation or the applicator must be repaired:
1. **Freeze ownership before mutation.** Recheck Git root, branch, HEAD, complete status, OS writers/descendants, and any waiting launcher. Record pre-existing dirty files as protected. A controller that has not yet produced a report may still have mutated the tree; perform a delayed post-launch status scan before trusting its preflight.
2. **Create a clean detached worktree from the current HEAD.** Never trial-apply a stale patch directly to a dirty authoritative checkout. Use `git apply --3way --index <patch>` there; inspect every `git diff --name-only --diff-filter=U` conflict and preserve current upstream behavior plus the patch's invariant. Do not resolve conflicts by taking all of `ours` or all of `theirs`.
3. **Treat conflict placement as suspect.** Three-way application can match a weak context anchor inside an existing helper or test class. For additive tests, rebuild from the current HEAD file and insert only the patch's added block at a stable semantic anchor; then run the test file. This avoids duplicated commands, missing delimiters, and tests nested inside another test.
4. **Run focused gates in the isolated tree.** Start with `git diff --check`, language syntax/type checks, and the smallest RED→GREEN tests for each invariant. Use the project's real dependency environment; if a temporary worktree lacks dependencies, reify from the lockfile in that worktree (offline when the cache is complete) rather than mutating the live checkout. Report unavailable tests as unavailable, never as passing.
5. **Regenerate the artifact for the current baseline.** From a clean current-HEAD worktree, produce each patch with an explicit reviewed file allowlist. Do not include unrelated dirty files, generated output, dependencies, or broad historical branch deltas. Keep the refreshed artifact outside the source checkout when necessary.
6. **Prove applicator behavior twice.** `git apply --check` against a clean current-HEAD worktree must pass; `git apply -R --check` against the repaired tree must also pass. Run the real applicator once and require zero missing/non-clean patches. Re-run it only after inspecting a failure; never loop the same command under `set -e` or through a pipeline that masks the true exit code.
7. **Close out independently.** Re-scan the live process tree, verify the authoritative checkout contains only the intended feature changes plus protected pre-existing dirt, run final focused gates at the same tree, and report exact paths, hashes, exit codes, and any deferred lifecycle gate separately.
## Pitfalls
- macOS system `python3` (3.9.x) cannot import the hermes-agent repo: `TypeError: unsupported operand type(s) for |: 'type' and 'type'` — PEP 604 annotations are syntax-valid but runtime-invalid on <3.10, so `python3 -m py_compile` PASSES while import fails. Always use `./.venv/bin/python` for imports/tests in that repo.
- Running `./.venv/bin/python -m pytest` from a gateway session can trip the terminal tool's lifecycle guard — `ValueError: embedded null byte` in `cron/lifecycle_guard.py`, triggered whenever the command's FIRST EXECUTABLE TOKEN contains a `/` (relative `.venv/bin/python` counts; bare `python3` and slash-as-argument forms pass). Verified workarounds, lightest first: (1) run the command inside `execute_code` via plain `subprocess.run([...])` — the sandbox bypasses the guard; (2) use bare `python3 -m pytest` / `python3 -c` when the system interpreter has the deps; (3) shift the slash path to an argument (`file .venv/bin/python` passes). Full root-cause detail: see the pitfalls section of this skill.
- **Task-spec line numbers go stale under parallel uncommitted work.** A delegated spec citing `supervisor.py:309/428` and `policy.py:158` matched the live tree at `348/422` and `157` because a parallel task had uncommitted edits in the same files. Verify every cited line against the actual file before editing; anchor patches on unique string context, never on line numbers.
- **`patch` `replace_all` matches EXACT text.** Two sites that look identical can differ in formatting (one `raise` on a single line, an identical-looking one wrapped across three), so `replace_all` silently leaves a site untouched. After any multi-site replace, grep the file for the old identifier and confirm EVERY site changed.
- **Prove zero new failures when the suite was already red.** When an API change lands while tests still use the old signature, every affected test fails the same way (e.g. 38/38 `TypeError: ... unexpected keyword argument` at test-helper lines, plus cascades like `FileNotFoundError` from a helper that raised earlier). Categorize failures by error type and failing line before claiming your change is clean — do not touch tests owned by another lane.
- "Upstream contains it" requires the origin/main check, not just local branches — private feature branches (`fix/*`, `feat/*`) routinely carry unmerged work.
- A parentless snapshot branch makes `git log <branch>..HEAD` show the feature commits as "not in HEAD" even when HEAD contains equivalent code — verify with content greps, not lineage alone.
- Applicators may contain archive-first fallbacks that silently skip a refreshed root artifact while exiting 0. When refreshing a patch, inspect branch precedence, make the root artifact win when present, and verify both a real apply and a second idempotent run.
## Reference
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!