메뉴
Check installed o9k pillars and companion frameworks for updates, and apply the safe ones. Use when the user invokes /o9k-update, asks whether anything is out of date, or acts on the SessionStart 'updates available' notice.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Guided first-install and reconfiguration flow for o9k. Use when the user invokes /o9k-init, on a fresh o9k install, or when the user wants to set up, reconfigure, or extend their companion stack. Detects what's installed, interviews the user (bundle, git, conflicts), resolves collisions with migration, then executes the setup.
Token usage report for the current project from Claude Code session transcripts. Use when the user asks how many tokens were used/saved, invokes /o9k-stats, or wants to verify the o9k pillars are paying off.
Meta-skill for the o9k doctrine and arbitration — who owns output style, the repo map, dispatch, memory, the plan. Load at session start, on conflicts between efficiency skills, and whenever unsure Path A vs Path B — if a team-up roster exists, external CLI tmux workers require team-up + dispatch mailbox/watcher (not bare dispatch). Also use when caveman vs other output-styles collide.
Personalized o9k orientation for the human. Use when the user invokes /o9k-guide, asks how o9k works or what they need to do, right after first-time setup, or when the SessionStart hook flags an unresolved arbitration. Explains what runs automatically, the few one-time actions left, and on-demand commands (/o9k-init, /o9k-stats, /o9k-update). Agent-only: if a team-up roster exists, external CLI spawns still require dispatch path B — this guide does not exempt that.
Cost-gated subagent dispatch for context isolation. Use for broad searches, lookups, log analysis, doc digestion, independent subtasks, OR whenever you spawn an external CLI worker via the team-up companion (planner/implementer/reviewer in tmux, cursor-agent/claude/codex/hermes). Path A = in-host RESULT subagents. Path B = mailbox run + team-up dispatch --run-id + cheap in-host watcher (runs wait) — REQUIRED for every external CLI tmux spawn when a team-up roster exists; bare dispatch without a watcher is an incomplete spawn (parent never gets notified).
Install a conflict-free stack of third-party o9k companion frameworks in one command. MUST use when the user asks to set up companions, install the recommended stack, add memory/docs/methodology/symbol tools alongside o9k, or extend an existing bundle — never hand-install MCP servers without checking arbitration first. Wraps install/o9k-companions.sh and enforces the one-owner-per-concern rule from using-o9k.
| name | o9k-update |
| description | Check installed o9k pillars and companion frameworks for updates, and apply the safe ones. Use when the user invokes /o9k-update, asks whether anything is out of date, or acts on the SessionStart 'updates available' notice. |
o9k checks its dependencies for updates automatically in the background (once per
O9K_UPDATE_INTERVAL_HOURS, default 24h) and mentions anything updatable at
session start. This skill is the on-demand and apply path.
node "${CLAUDE_PLUGIN_ROOT}/scripts/update-check.mjs" --report
Forces a fresh check (ignores the cache) and prints: each npm-global companion's installed→latest version, both o9k channels (npm global package + git marketplace clone), and the exact commands to apply. Nothing is changed.
Only after showing the report and getting a yes (unless the user has already
opted into O9K_UPDATE_CHECK=auto):
node "${CLAUDE_PLUGIN_ROOT}/scripts/update-check.mjs" --apply
Scope: --apply only updates npm-global CLIs (including its-over-9k
when installed via npm i -g its-over-9k). Host configs (Codex/Cursor/
OpenCode/Hermes hook wiring, skills) are touched when:
its-over-9k npm package was just updated (auto-refresh — marketplace
files on disk changed), orO9K_REFRESH_HOSTS=on, or--refresh-hosts separately.Every file --refresh-hosts writes gets a .o9k-bak backup first.
It deliberately does not touch:
/plugin marketplace update o9k
instead (Claude Code manages that clone; a manual pull could clobber it).
After that marketplace update, always run:
node "${CLAUDE_PLUGIN_ROOT}/scripts/update-check.mjs" --refresh-hosts
CLAUDE_PLUGIN_ROOT; other hosts need
this re-bake because wrappers bake absolute paths and skills are copies./plugin owns those.uvx; npx-based MCPs
(Context7) too. Nothing to pin.| Channel | How installed | Update path |
|---|---|---|
| npm | npm i -g its-over-9k | --apply runs npm i -g its-over-9k@latest, then auto --refresh-hosts |
| git marketplace | /plugin marketplace add Bumblebiber/its-over-9k | /plugin marketplace update o9k, then --refresh-hosts |
Both may be present. Report both; never auto-update the Claude marketplace clone.
CLI shortcut when npm-installed: o9k update / o9k update --apply.
Coming from its-over-9k@1.x? That was the old hmem CLI. Clean reinstall:
npm uninstall -g its-over-9k
npm i -g hmem-mcp && hmem init
npm i -g its-over-9k@latest && o9k setup
Offer to run the /plugin marketplace update for the user when the report flags
the git clone as behind — and chain --refresh-hosts immediately after.
--report and --apply now also check that every enabled pillar's skills are
wired to the actual hosts you use (Claude Code, Cursor, Codex, OpenCode,
Hermes). The check is a local fs walk — instant, no network.
Three drift cases, three remedies:
| Case | Signal | Fix |
|---|---|---|
| New pillar (enabled pillar has skills in the marketplace but none wired to any host yet) | NEW PILLAR in report | Run /o9k-init — not fixable with --refresh-hosts alone; new pillars need MCP arbitration, config files, and host wiring. |
| Missing canonical (existing pillar gained a new upstream skill; some skills wired, some not) | skills missing canonical in report | Run --refresh-hosts — copies the new skill into ~/.agents/skills/o9k/ and wires hosts. |
| Missing links (canonical skills exist but a host's symlink or Cursor rule is missing/wrong) | skills missing links in report | Run --refresh-hosts — re-syncs canonical skills + re-wires host hooks. |
Concrete example: a pillar installed as a plugin, source skills present under
plugins/<pillar>/skills/ but NOT exposed under ~/.claude/skills/ or
~/.agents/skills/o9k/. Old /o9k-update saw nothing wrong (npm companions
current). Now --report flags it as NEW PILLAR → recommends /o9k-init.
NEW PILLAR is an offer, not a task. Pillars are opt-in — report it and let
/o9k-init ask. Never wire a pillar the user never said yes to.
After a marketplace update (/plugin marketplace update o9k) or an npm bump
of its-over-9k, always ensure hosts are refreshed (npm path does this
automatically on --apply). The skill check here is a separate safety net —
it catches drift regardless of how the pillar arrived.
O9K_UPDATE_CHECK | Behaviour |
|---|---|
off | No checking at all. |
notify (default) | Background check; report updatable deps; apply nothing. |
auto | Additionally auto-apply the safe npm-global updates in the background. |
If the user wants a different default, set it in their environment (e.g. shell profile or Claude Code env). Auto mode never auto-updates Claude marketplace plugins or the git clone — those stay notify-only by design.
Apply caveman brevity. A clean report is one line ("everything up to date") only when npm companions, o9k channels, and skills/host wiring are all current. When updates or skills drift exist, list them compactly and offer the apply — never dump the raw script output verbatim if a one-line summary conveys it.