القائمة
Check or update anti-hall from the local marketplace clone. Use when the user asks to update anti-hall, check whether anti-hall is current, or refresh the Codex port files.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Explain anti-hall's optional DevSwarm integration from Codex — the hivecontrol reference KB, the (designed, unbuilt) workspace-tier orchestration, and the shipped layered recovery model (Claude-side companion: child self-report → supervisor poke → escalate-to-parent, automatic path NEVER kills, plus the on-demand devswarm-recover CLI — the only kill path). Use when the user asks about DevSwarm, hivecontrol, or the anti-hall liveness supervisor while working in Codex.
Explain and activate anti-hall's optional DevSwarm integration — the hivecontrol reference KB, the (designed, unbuilt) workspace-tier orchestration, and the shipped layered recovery model (child self-report → supervisor poke → escalate-to-parent, automatic path NEVER kills) plus the on-demand devswarm-recover CLI (the only path that ever kills). Use when the user asks "explain the anti-hall DevSwarm integration", "how do I activate the DevSwarm supervisor", "what DevSwarm addons does anti-hall have", "tune the liveness supervisor", "recover a stuck DevSwarm workspace", or anything about hivecontrol / DevSwarm workspaces from an anti-hall angle.
Update anti-hall to the latest released version and show the changelog delta. Use when the user says "update anti-hall", "/anti-hall:update", "upgrade the plugin", "is anti-hall up to date", or "check for an anti-hall update". Fast-forward-pulls the marketplace clone, mirrors the new version into the plugin cache, prints what changed, then has the user reload in-session via /reload-plugins (rarely, a harness build may require a restart — the skill says so when relevant).
Brief the agent that installs or operates anti-hall (in Codex/OMX) on how the whole system works — a DERIVED, live enumeration of every installed hook, the shipped skills, the DevSwarm coordination substrate (mechanical triggers, store, CLI, auto-safe migration), and a docs/KB map. Generated from the real hooks.json and files on disk, never a hardcoded list, so it can't drift. Use when the user asks "brief me on anti-hall", "what's in this build", "how does the whole system work", or when onboarding an agent to install/run anti-hall. For "is it actually installed in Codex / do the guards fire", use anti-hall-doctor.
Brief the agent that installs or operates anti-hall on how the whole system works — a DERIVED, live enumeration of every installed hook (grouped by event, each with its own one-line purpose), the shipped skills, the DevSwarm coordination substrate (mechanical triggers, store, CLI, auto-safe migration), and a docs/KB map. Generated from the actual hooks.json and the files on disk, never a hardcoded list, so it can't drift. Use when the user asks "brief me on anti-hall", "what's in this build", "how does the whole system work", "give me the anti-hall system overview", "what hooks/skills/substrate ship here", or when onboarding an agent to install or run anti-hall. For "is it actually working / do the guards fire", use the `doctor` skill instead.
Iterative TRIO-debate + fix-wave protocol for hardening non-trivial PRs and changes before merge. Spawns a parallel Reviewer + Auditor + Critic trio, dispatches fix waves, loops until convergence (zero NEW P0 or P1 blockers). Use before merging anything with cross-file risk, cross-PR coordination, security-sensitive changes (auth, signing, redaction, prompt-injection defense), schema migrations, production-data touches, shell scripts, CI/workflow YAML, cross-repo coordination, or LLM prompt work — anywhere a silent failure would be expensive. Born from a real project where 7 iteration rounds caught 30+ bugs that solo review would have missed.
| name | anti-hall-update |
| description | Check or update anti-hall from the local marketplace clone. Use when the user asks to update anti-hall, check whether anti-hall is current, or refresh the Codex port files. |
Codex does not expand ${PLUGIN_ROOT} inside a skill's own instructions — that
variable is only set for plugin-bundled hook commands (see
docs/KB-codex-platform-hooks-plugins.md). Codex does show you this skill's own
file path when it selects the skill ("Codex starts with each skill's name,
description, and file path" — official Codex Skills doc). Resolve the plugin
root from that path before running anything below:
# SKILL_FILE = the absolute path Codex showed you for this SKILL.md.
ANTI_HALL_ROOT="$(cd "$(dirname "$SKILL_FILE")/../../.." && pwd)"
test -f "$ANTI_HALL_ROOT/.codex-plugin/plugin.json" || { echo "anti-hall plugin root not found relative to $SKILL_FILE — aborting" >&2; exit 1; }
Use the existing pure-Node update helper:
node "$ANTI_HALL_ROOT/skills/update/scripts/update.js" --check
node "$ANTI_HALL_ROOT/skills/update/scripts/update.js"
For Codex, also re-run the Codex hook installer after a successful update:
node "$ANTI_HALL_ROOT/codex/install-codex.js"
or for global Codex hooks:
node "$ANTI_HALL_ROOT/codex/install-codex.js" --global
Do not force-pull, rebase, or delete plugin cache directories. If the update helper reports a dirty tree, diverged branch, offline state, or missing marketplace clone, surface that result and stop.
After a successful update, also run the capability scan to find what's missing on this machine vs what this build ships:
node "$ANTI_HALL_ROOT/scripts/capability-scan.js"
Read-only — it never installs anything. It reports each opt-in capability (companions under companion/install-*.js, statusline, pending state migrations) as {name, available, active, how}. Present a concise available-vs-active summary:
state-migrations at active: false — run node "$ANTI_HALL_ROOT/scripts/migrate-state.js" (idempotent, safe to re-run) to fold it, same as the Claude-side update flow.devswarm-detect's isDevswarmActive(process.env) — true only
when DEVSWARM_REPO_ID is set, i.e. the current session really is a DevSwarm
workspace (do NOT trigger on machine-level descriptor presence alone; the
session might be running outside DevSwarm). If inside a DevSwarm session, run
its how command (node companion/install-devswarm-supervisor.js)
regardless of the capability scan's active value. The installer is
idempotent (launchctl unload && load on macOS / systemd reload on Linux),
so this both first-installs when absent and refreshes an already-installed
supervisor so the next sweep runs this build's code. Report it plainly
("DevSwarm session detected — installed/refreshed the liveness supervisor to
<version>"). Fail-open: an install/refresh failure is reported, never fatal
to the update. If NOT inside a DevSwarm session, do not install — just
note it's available. (Safe to do unprompted: the supervisor's automatic
sweep never kills — killing is only the separate on-demand
devswarm-recover CLI. Defense in depth: the installed daemon is inert
without work — it only ever acts on descriptors under
~/.anti-hall/devswarm/workspaces/, so it no-ops when DevSwarm isn't
actually running.)isDevswarmActive(process.env) branch. When inside a DevSwarm
session, also run its how command
(node companion/install-devswarm-ingest.js) regardless of the scan's
active value. It is idempotent (launchctl unload && load on macOS /
systemctl --user daemon-reload + restart on Linux), so it first-installs
when absent and refreshes an already-installed daemon to this build's code.
Unlike the supervisor (a periodic sweep), the ingest daemon runs
continuously — the unit uses KeepAlive/Restart=always to re-exec it on
exit; hence a distinct label (com.anti-hall.devswarm-ingest) and log
(~/.anti-hall/devswarm-ingest.log). It is the single native consumer that
wraps hivecontrol workspace monitor and folds messages into the store;
nothing else auto-starts it, so a DevSwarm session without it silently ingests
nothing. Safe to install unprompted and idempotently: the daemon takes an
O_EXCL single-consumer lock, so only ONE instance ever runs even if installs
race. Report it plainly ("DevSwarm session detected — installed/refreshed
the ingest daemon to <version>"). Fail-open: an install/refresh failure is
reported, never fatal to the update. If NOT inside a DevSwarm session, do
not install — just note it's available.active: false (e.g. mcp-reaper — no
active-integration signal) — guide, don't auto-install: print its how
command and let the user decide.active: 'unknown' — the probe couldn't determine state (fail-open); mention it as unverified rather than claiming either state.active: true for everything — say so briefly; no gaps to report.After updating, restart Codex or start a fresh session if plugin/skill discovery does not reflect the new files immediately.