Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →sonichi/engine-conflict-resolve
Ask Sutando to resolve a conflicted update of a Sutando checkout. When pulling the latest release/main conflicts with local changes, Sutando reproduces the merge in a scratch git worktree, resolves the conflicts there, proposes the resolution to the owner, and fast-forwards the live checkout only after explicit confirmation. First entry path is the desktop app's "Resolve with Sutando" engine-update button.
Passed 15 of 19 test cases with the skill, and 7 of 19 without it.
and 12 more in the full report
9 fixed8 passed either way5 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
When running `deliver.py`, no room configuration is defined in CLI flags, environment variables, or manifest defaults. How does the deliver script notify the owner?
| Checked | Without skill | With skill |
|---|---|---|
| Triggers a macOS system notification | Missed | Passed |
| Inserts a question section into pending-questions.md above the # Resolved divider | Missed | Passed |
The instructions your model reads when the skill loads.
Anyone running Sutando from a git checkout can ask it to pull the latest main/release — and when the update conflicts with their local changes, ask Sutando to resolve the merge itself. This skill is that protocol: reproduce the merge in a scratch worktree, resolve the conflicts there semantically, propose the result, and land it in the live checkout only after the owner explicitly confirms.
The first producer of the pending state is the desktop app's git-aware engine
updater: on a conflicted update it aborts completely and records
ENGINE_UPDATE_PENDING.json; the app's "Resolve with Sutando" button then
writes a task file tasks/task-engine-conflict-<epoch>.txt
(source: desktop-app, interaction_type: system_event) whose body names the
pending file and the engine checkout. That task is one entry path, not the
feature: the scripts take the pending-file shape as input from any producer
(a ref-based entry point — merge any two refs with no pending file — plus a
chat-facing command are queued follow-ups).
Iron rule: never modify the live checkout until the owner confirms. All
merge work happens in a scratch worktree; only apply.py touches the live
checkout, and only behind the updater's own lock and staleness guards.
Take --pending and --engine verbatim from the task body (both paths may
contain spaces — always double-quote).
python3 skills/engine-conflict-resolve/scripts/prepare.py \
--pending "<…/ENGINE_UPDATE_PENDING.json>" \
--engine "<…/engine/sutando>"
{"status": "clean", "merged_sha": …} — the merge replays cleanly (the
recorded conflict no longer reproduces). Skip step 2 but still RUN step 3:
only propose.py records the proposal apply.py will accept. Report
"merged cleanly, no conflicts remained".test cases passed, vs 7 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.