HorizonBrute Skill: /post-update
Model preference: #midcost (per horizon_aios_model_prefs.md; overridable by a prompt directive).
Reconcile a running Horizon AIOS install with an update that has just landed in the tree. A git pull/merge changes files on disk, but many changes do NOT take effect until a reapply step runs against the live install (ACLs, scheduled tasks, skill links, git hooks). This skill finds what changed, decides what must be reapplied, and drives those steps by delegating to the existing tools. It never re-implements them.
When to invoke
- After pulling a sizable AIOS update (a version bump, a merged feature branch, a batch that touches hardening / posture / skills / hooks).
- Periodically as install hygiene (e.g. every few weeks) even without a known-big update.
- Any time you are unsure whether the running install still matches the tree.
This is a manual deployer tool. It is intentionally not scheduled — the deployer decides when to run it.
What it does NOT do
- It does not re-implement
/doctor,/harden, or/resync-user-skills— it calls them. - It does not schedule itself or install a cron/Scheduled Task.
- It does not modify source; it reconciles the live install to the source already on disk.
Step-by-step execution
Step 1 — Identify the update range
1.1 Find the commit the install was at BEFORE the update and where it is now. Prefer the reflog:
git -C "$HORIZON_ROOT" reflog -20
Look for the most recent pull, merge, reset, or checkout entry. The commit just before it is the pre-update HEAD; current HEAD is post-update.
1.2 If the reflog is ambiguous, ask the deployer for the pre-update SHA/tag, or fall back to the last release tag: git -C "$HORIZON_ROOT" describe --tags --abbrev=0.
1.3 Capture the changed-file set:
git -C "$HORIZON_ROOT" diff --stat <pre>..<post>
git -C "$HORIZON_ROOT" diff --name-only <pre>..<post>
If there is no VCS history (a tarball deploy), fall back to running /doctor and skip to Step 4 — you can still reconcile posture even without a diff.
Step 2 — Classify changed files
Sort the changed paths into two buckets:
- Inert in tree — takes effect just by being present; NO action. Docs,
.gitignore, indexes, wiki, comments-only changes. - Needs reapply — changing the file on disk does NOT change the running install until a step runs. Use the mapping in Step 3 to identify these.
Step 3 — Map trigger files to reapply actions
For each changed path, match against this table (match by filename/dir, not full path). Collect the unique set of actions triggered.
| Changed file / pattern | Reapply action |
|---|---|
horizon_aios_harden.py, horizon_aios_acl_posture.py, file_acl_hardening.toml, *acl*hardening* |
Re-run /harden (run /doctor first to preview drift) |
horizon_aios_doctor.py |
Run /doctor (diagnostic; also the verifier for the harden step) |
anything under skills_bin/, skills_sbin/, or usr_skills/ (added/removed/renamed skill dirs) |
Run /resync-user-skills |
horizon_aios_setup_maintenance_schedule.py, horizon_aios_nightly_maintenance.py |
Run python "$HORIZON_SYSTEM/sbin/horizon_aios_setup_maintenance_schedule.py" to (re)register the maintenance task |
git hook sources (hooks/, *pre-commit*, *pre-push*) |
Reinstall hooks per the repo's hook-install script |
templates/docker/*, Dockerfile |
Rebuild container images (only if containers are in use) |
bootstrap.*, horizon_aios_create_brain.py |
No action unless reprovisioning or creating a brain |
onboarding / env scripts (*onboard*, *_environment.config.json) |
Re-run the onboarding/env script to refresh resolved paths |
If a changed file plausibly needs reapply but matches nothing above, surface it in the report as needs review rather than silently classifying it inert.
Step 4 — Print the prioritized checklist
Report, in this order:
- The update range (pre → post SHA) and a one-line summary of the theme.
- Reapply actions, ordered: read-only checks first (
/doctor), then posture (/harden), then task/skill registration, then optional (Docker rebuild, deployer overrides). - For each action: the trigger file(s) that caused it and a one-line "why".
- Any needs review files.
- The inert set, collapsed to a count (e.g. "14 docs/index changes — no action").
Step 5 — Drive the reapply (with confirmation)
5.1 Offer to run the actions in order. Run read-only steps (/doctor) freely.
5.2 /harden changes real ACLs — confirm with the deployer before running it. Show the /doctor drift first so they see what will change.
5.3 After registering the maintenance task, remind the deployer to record it in their automations registry if their deployment tracks one.
5.4 Re-run /doctor at the end to confirm the install is clean.
Notes for the executing agent
- Use
$HORIZON_ROOT/$HORIZON_SYSTEMenv vars — never hardcode install paths. - The value of this skill is the mapping and ordering, not the execution — always delegate execution to the owning skill/script so their own logic and model preferences apply.
/hardenis privileged and mutating; treat it as the one step that always needs explicit go-ahead.- If the diff is empty but
/doctorreports drift, trust/doctor— the install can drift without a code change (manual edits, a partial prior run). - Keep the report tight; a deployer wants the action list, not a file-by-file dump.