Hook parity across fleet — CC-native, OpenCode/Kilo hookless (accepted, not fleet-parity gap)

decision Fri Jul 03 2026 00:00:00 GMT+0000 (Coordinated Universal Time) hooksfleetclaude-codeopencodekiloparitydecision

Hook parity assessment 2026-07-03

Claude Code fires 6 lifecycle events via ~/.claude/settings.json:

Event	Purpose	Fleet-portable?
`SessionStart`	Memory-pull, okf-lookup warm, cavemem load, skills-sync	Partial — okf-lookup is a plain node script; the rest depend on CC internals
`UserPromptSubmit`	okf-prompt-lookup surfaces top-3 concept files as system message	Yes — pure node script + stdin prompt
`PreToolUse`	RTK Bash-tool token compression + env-var injection (cargo, tauri)	Partial — RTK is transparent shim, env injection is CC tool-invocation shape
`PostToolUse`	Cavemem event record, RTK stats emit	No — cavemem is CC-specific; RTK stats are per-invocation
`Stop`	Cavemem flush, memory-push	Partial — memory-push is a node script; cavemem is CC-specific
`SessionEnd`	Cavemem close, session-scoped cleanup	No — session boundary is a CC concept

OpenCode and Kilo have zero hooks configured. Neither publishes a lifecycle-hook surface CC's config shape maps onto:

OpenCode has no equivalent to UserPromptSubmit or SessionStart — hooks are not part of the OpenCode config schema in 2026-Q3.
Kilo Code publishes a chat.message plugin surface but requires writing a TypeScript/Bun plugin per hook. No equivalent to CC's declarative JSON hooks.

Keep hooks CC-only. Remove hook parity from the fleet-parity claim.

The fleet-parity invariant applies to:

✅ Rules (AGENTS.md, knowledge/rules/ — all 3 clients read the same tree)
✅ Skills (all 3 client skills dirs now mirror to 37 skills via sync-skills.ps1 — locked 2026-07-03)
✅ MCP servers (each client authors its own MCP config via sync-agent-configs.ps1, but all reference the same env-var-backed secrets)
✅ SOFA identity (single shared chirag127 across all 3 clients)
❌ Hooks — CC-only. Documented here.

OpenCode has no hook surface. Building one requires forking OpenCode, filing an upstream PR, waiting for merge, keeping our fork thin. Per fork-thin-upstream-tracking, that's a real commitment; the value of okf-lookup-on-prompt for OpenCode (which is our free-tier failover) doesn't justify the operational cost while OpenCode remains fallback-only.
Kilo Code requires a Bun/TS plugin per hook. Same math: plugin maintenance overhead > current value.
The rules that hooks enforce (okf-lookup before answering, memory pull at session start) are restated in AGENTS.md and auto-imported — OpenCode and Kilo pick them up on read, they just don't fire automatically. When operating in OpenCode/Kilo, the human or the agent runs npx tsx scripts/okf-prompt-lookup.ts "<prompt>" manually per the okf-lookup-before-acting rule.

Update agent-fleet-parity rule to explicitly scope-limit: "hooks are CC-only; rules + skills + MCP + SOFA identity apply to all 3."
okf-lookup-before-acting rule already documents the manual fallback for OpenCode/Kilo. No change needed.
Future CC-hook additions do NOT need a matching OpenCode/Kilo plan — CC is the primary, hooks live there, other agents run the same scripts on-demand.

OpenCode ships a JSON hook surface (would remove the plugin burden).
Kilo publishes a declarative hook config (no Bun/TS plugin required).
The fleet-primary changes from CC — if OpenCode becomes primary on any machine, revisit hook portability.
CC hooks grow beyond 6 events or start doing non-portable things (like touching ~/.anthropic/ internals) — the boundary between "CC-optimization" and "fleet-mandated behavior" needs re-evaluation.