How do you use caveman with the Oh My Pi (omp) coding agent?

[avinashkanaujiya]

Question

How do you use Caveman with the Oh My Pi (omp) coding agent (a fork of pi)?

Specifically:

1. How do you use this? The repo targets Claude Code, Codex, Gemini, etc., and the compatibility matrix has no omp/pi entry. Do you wire the plain markdown artifacts (commands, skills, rules) into the agent config manually?
2. Does it get enabled automatically, or does it have to be invoked every time? I installed it on omp by placing the SKILL.md under .agents/skills/ and the commands under .agents/commands/. The skill's description says it "auto-triggers when token efficiency is requested," but is there a persistent/always-on mode, or must caveman (or a level like /caveman ultra) be invoked each session?

Context: there are open feature-request issues for native omp/pi support (#16, #161, #743) — asking here for the current recommended way to use it meanwhile, and whether an always-on mode exists.

[Mustaqeem66]

Yes — there is a persistent always-on mode on OMP, and it is not the skill. That is also the reason for the behaviour in #16 ("works in omp but only once, next prompt reverts to verbose").

Why the skill install stops sticking

Your .agents/skills/caveman/SKILL.md placement is valid — OMP's agents discovery provider reads .agent[s]/skills and the docs call it "the canonical OMP-native location" (priority 70, with its own enableAgentsUser / enableAgentsProject toggles, so disabling Claude/Codex/Pi discovery does not switch it off).

But a skill is only ever exposed as name + description metadata in the system prompt, with its body pulled on demand via read against skill://<name>. Nothing re-attaches it. Once the conversation grows, the opening context drifts up the transcript and the style instruction loses its hold — exactly the "first prompt caveman, second prompt verbose" symptom.

The always-on mechanism: RULES.md

OMP has a dedicated sticky-rule file, and its whole purpose is surviving long sessions. From docs/context-files.md, RULES.md is:

• loaded as an always-apply rule, not a context file, so it is re-attached near the current turn;
• always sticky — frontmatter cannot make it non-sticky.

That is precisely caveman's "always-on rules" story for hookless agents, and the rule body already exists in this repo as a single source: src/rules/caveman-activate.md.

Global (every session, every repo):

mkdir -p ~/.omp/agent
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/src/rules/caveman-activate.md \
  > ~/.omp/agent/RULES.md

Per-repo:

mkdir -p .omp
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/src/rules/caveman-activate.md \
  > .omp/RULES.md

Four gotchas that will otherwise cost an hour:

1. RULES.md is read only at native locations — the active user agent directory, and the nearest non-empty .omp/ directory found walking cwd → repo root. A RULES.md anywhere else is not a recognised convention.
2. If a nearer non-empty .omp/ exists without a RULES.md, OMP does not fall back to a farther one.
3. Both candidates are synthesised under the rule name RULES and dedup is name-based, so a user-level RULES.md shadows the project one — they are not concatenated. Pick one scope.
4. Do not name a file RULES.md inside .omp/rules/; native regular rules load earlier and can shadow both sticky candidates.

Under a named profile (omp --profile work) the path becomes ~/.omp/profiles/work/agent/RULES.md. PI_CODING_AGENT_DIR relocates the native agent dir.

Second option: APPEND_SYSTEM.md

If you would rather have it in the system prompt than as a rule:

curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/src/rules/caveman-activate.md \
  > ~/.omp/agent/APPEND_SYSTEM.md

This appends to the complete default prompt and keeps every tool and workflow instruction. Use APPEND_SYSTEM.md, not SYSTEM.md — SYSTEM.md swaps the whole default instruction template and drops the built-in tool inventory, tool policy, exploration/delegation rules and xd:// guidance, which is not a trade you want for a style tweak. Note APPEND_SYSTEM.md discovery does not walk ancestors, so a project-level one only resolves from the directory you launched omp in.

Keep it short either way — sticky content is re-sent, so it is paid for repeatedly. The 12-line rule file is already about the right size.

Recommended combination

• ~/.omp/agent/RULES.md → always-on, survives long sessions.
• .agents/skills/caveman/SKILL.md (or .omp/skills/caveman/SKILL.md) → keeps /skill:caveman and level switching (/caveman lite|full|ultra) available when skills.enableSkillCommands is on.

If you prefer .omp/skills/, that is the native provider at priority 100 and it requires a description in frontmatter (requireDescription: true); the agents provider does not. Either way, layout must be exactly <skills-root>/<skill-name>/SKILL.md — nested group/skill/SKILL.md is not discovered.

Also relevant

There is already a Pi-native port by @v2nic, linked from #16: https://github.com/v2nic/pi-caveman — pi install git:github.com/v2nic/pi-caveman, giving /caveman, /caveman lite|full|ultra as a real extension.

For native support (#743 / #161 / #16)

Detection and install for OMP look cheap, since it needs no hook system:

• Detect: omp on PATH, or an existing ~/.omp/agent/ directory.
• Install: write the rule to ~/.omp/agent/RULES.md (or .omp/RULES.md under --with-init) and drop the skill dirs into .omp/skills/. Honour PI_CODING_AGENT_DIR and OMP_PROFILE / PI_PROFILE when resolving the agent dir.
• Uninstall: same two paths, marker-fenced like the existing OpenClaw SOUL.md block so a hand-edited RULES.md is not clobbered.

That would make the INSTALL.md row read "Yes" under Auto-activates? rather than per-session, which is the actual ask in this thread. I am happy to send that as a PR against cli/install.js if you would take it.