Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →davekilleen/dex-update
Preview and safely adopt a Dex update through the receipt-backed lifecycle (look → back up → apply → verify → rewindable).
Passed 4 of 10 test cases with the skill, and 1 of 10 without it.
and 7 more in the full report
6 fixed2 passed either way13 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
For the conflict on my configuration file, I select to keep my version exactly as it is. Go ahead and execute that choice using the conflict resolution preview.
| Checked | Without skill | With skill |
|---|---|---|
| Must implement the retention choice by leaving the file completely untouched. | Missed | Passed |
| Must avoid making any service call to the conflict resolution engine for items designated to be kept as is. | Missed | Passed |
The instructions your model reads when the skill loads.
Use this skill when someone wants the latest Dex capabilities or asks what an update would change. Keep the conversation plain and reassuring. The skill collects choices and renders lifecycle results; it never edits, copies, renames, deletes, or merges vault files itself.
Every lifecycle operation goes through core.lifecycle.service version 1.5.0. Treat its response as authoritative. Do not fall back to direct file operations, Git mutation, an update script, or a hand-built repair when the service refuses.
Use the service operations in this order:
build_and_preview_topology_migration to check the installed layout as part of the normal update read.build_inventory_and_plan for the verified inventory and ledger-aware plan.adopt items, ask build_and_preview_adoption for the exact preview and approval token.build_and_preview_conflict_resolution.execute_approved_adoption, and unchanged resolution previews and tokens to execute_approved_conflict_resolution.read_lifecycle_state for the verified post-update state and retention warning, then render every receipt.For a split vault whose update needs new release bytes, never ask the user to
run Git. Before presenting a delivery update, ask deliver_latest_release
through core.lifecycle.service. It proves the newest immutable release in an
isolated cache, fetches only that pinned tag and its release-channel ref into
Dex's private brain store, then proves the fetched bytes again. This delivery
step does not change vault content.
Only when delivery returns its exact release identity, ask
build_and_preview_delivered_release through core.lifecycle.service with
that identity. Show every returned write and ask: “Apply this exact update?”
Only a fresh explicit yes to that unchanged preview permits
execute_approved_delivered_release with the same preview and approval token.
Render its lifecycle receipt. Then ask read_lifecycle_state — the applied
version now appears in the same rewind list /dex-rollback uses. If delivery,
preview, or execution refuses, stop; no vault-content change was made.
Immediately after a successful apply, run the post-update canary — one
read-only walk through the same doors every later command will use. From the
vault root, run python3 core/health/post_update.py --vault . (the direct
file path matters: it keeps the canary runnable even when the installed
test cases passed, vs 1 / 10 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.