Extension throws `opts.skills` TypeError on Oh My Pi (omp): `event.systemPromptOptions` is undefined in `before_agent_start`

[Taamyuk]

Environment

• Host: Windows 10 Pro (x64)
• Runtime: Oh My Pi (omp) v17.2.7
• Extension: pi-cache-optimizer@2.8.0 (installed via omp plugin install npm:pi-cache-optimizer)

Steps to reproduce

1. Install under omp: omp plugin install npm:pi-cache-optimizer
2. Run any headless session, e.g. omp -p "reply with exactly: ok"

Actual behavior
The extension loads successfully (no module-resolution error — omp rewrites @earendil-works/pi-coding-agent imports
onto its host @oh-my-pi/pi-coding-agent), but every run emits:

Extension error (C:\Users\Taam.omp\plugins\node_modules\pi-cache-optimizer\index.ts): undefined is not an object
(evaluating 'opts.skills')

The session itself continues (errors are isolated per extension), but the skill-compression and stable-prefix reorder
features never run.

Root cause
In the before_agent_start handler (index.ts), the code calls compressSkillsInSystemPrompt(strippedPrompt, event.systemPromptOptions) (and later optimizeSystemPrompt(..., event.systemPromptOptions)). On omp, the
before_agent_start event payload does not include a systemPromptOptions field, so event.systemPromptOptions
is undefined, and opts.skills at line ~545 throws. The handler assumes a Pi-specific event payload shape that omp
does not provide.

Expected behavior

• Either omp should populate systemPromptOptions on before_agent_start (aligning with Pi's event contract), or
• The extension should defensively handle a missing systemPromptOptions (e.g. opts?.skills, treat as "no rewrite
  applicable") so the rest of the extension (footer cache stats, prompt_cache_key fallback, Anthropic cache-control
  repair) keeps working.

Suggested fix (minimal, in extension)
Guard the payload access, e.g.:

const opts = event.systemPromptOptions ?? {};

Workaround (for users until fixed)
PI_CACHE_OPTIMIZER_NO_PROMPT_REWRITE=1 skips the failing code path; the remaining features stay active.

Notes

• Install/load path is fully working on omp (package.json#pi.extensions manifest fallback is honored; npm: install
  spec accepted). This is purely a runtime event-contract mismatch.
• Happy to test a patched version on omp if you want to add @oh-my-pi/pi-coding-agent to peerDependencies or ship a
  package.json#omp.extensions alias.
  （it’s from omp agnet）

[jiangge]

Thank you for the detailed report and root-cause analysis. I have reviewed the extension code and the before_agent_start contract exposed by OMP 17.2.7.

The runtime error is real, but the underlying problem is a host API contract mismatch rather than a defect that this extension can correctly fix on its own.

pi-cache-optimizer is a Pi extension and relies on Pi's before_agent_start event contract, including systemPromptOptions, to identify skills, prompt guidelines, context files, and other stable prompt components. OMP loads Pi extensions by rewriting the @earendil-works/pi-coding-agent import, but its event currently has a different shape: it omits systemPromptOptions, represents systemPrompt differently, and has different return semantics.

Adding a guard such as event.systemPromptOptions ?? {} would only suppress the exception. It would not restore the missing metadata, so skill compression and stable-prefix reordering would silently stop working. That would make the extension appear healthy while reducing its actual cache effectiveness, and would make the compatibility problem much harder for users to diagnose. For that reason, I do not want to treat silent feature degradation as the fix here.

If OMP intends to support Pi extensions, its compatibility layer should preserve Pi's extension API contract, or explicitly adapt OMP's event and result shapes to the Pi equivalents. In particular, the before_agent_start compatibility path needs to provide the metadata and semantics required by Pi extensions, not merely rewrite the package import.

Could you please open an issue with the OMP project and link it here? Please include the contract differences you identified, especially:

• missing event.systemPromptOptions;
• the different event.systemPrompt representation;
• the different systemPrompt result/handler chaining semantics;
• the fact that OMP presents the extension as loadable through Pi import rewriting.

I will leave this issue open for tracking for now. Once OMP has addressed the compatibility contract, we can verify the extension against the corrected host behavior.