feat(omp): add extension-based rewrite integration for Oh My Pi

[makoMakoGo]

Summary

Adds Oh My Pi (OMP) as a first-class RTK CLI integration via a TypeScript extension that intercepts tool_call events for the bash tool and delegates command rewrite decisions to rtk rewrite.

• New init flag: rtk init --omp / rtk init -g --omp
• Installs ./.omp/extensions/rtk.ts for project scope or ~/.omp/agent/extensions/rtk.ts for global scope
• Keeps rewrite logic in the Rust registry; the OMP extension is a thin runtime adapter
• Supports --show, --uninstall, --dry-run, project-scoped install, and global install
• Refuses to overwrite pre-existing non-stock OMP extension files

Closes #591.

Review cleanup

This version was rebased onto current develop to keep the PR focused on OMP only:

• Removed the previous docs noise and broad wording changes
• Kept Hermes and existing agent documentation intact
• Switched OMP from --agent omp to --omp because OMP is a CLI/runtime integration, closer to OpenCode/Gemini/Codex than IDE rules-file integrations

Test plan

• cargo fmt --all -- --check
• cargo clippy --all-targets
• cargo test
• bun --eval 'await import("./hooks/omp/rtk.ts")'
• cargo run -- init --help
• cargo run -- init --omp --dry-run
• cargo run -- init --omp --show

[CLAassistant]

All committers have signed the CLA.

[makoMakoGo]

I have used this pr for about 2 days on my omp.

[makoMakoGo]

@aeppling @KuSh @FlorianBruniaux this is now rebased onto current master, the PR description matches the current fail-closed OMP behavior, and the targeted checks were rerun:

• cargo test test_omp
• cargo test test_validate_init_target_selection
• cargo test test_npx_unknown_tool_passthrough
• bun --eval await import("./hooks/omp/rtk.ts")

This PR has been open since 2026-04-17. Could one of you review it when you have time? Thanks.

[makoMakoGo]

@pszymkowiak also pinging you here since you merge/review a lot of RTK work and this touches init/hook integration paths.

[tsubus]

this looks like a vibe coded mess, isn't this other one looking much better? https://github.com/beeemT/rtk/pull/2

[makoMakoGo]

this looks like a vibe coded mess, isn't this other one looking much better? beeemT#2

PR #2 is prompt-only, while OMP supports a cleaner command-rewrite path via tool_call. My personal opinion is that using event.input.command before the native BashTool runs, so RTK keeps transparent behavior without overriding the bash tool or relying on the model to remember rtk.

PR #2 describes Capability A(which I mentioned above), but the actual patch does not implement it; it ends up as Capability B (prompt-injection) only.

[KuSh]

Hi @makoMakoGo, thanks for your PR.

There's a lot of documentation changes that feels like nitpicks around terms (extensions/hooks/...). That seems uneeded and unwanted. Could you try to stay closer to what we already have?

Also OMP do have pre hooks, why not just use that? Why did you choose to use an extension?

[makoMakoGo]

Thanks for the review, @KuSh.

On the docs: Agreed — I'll strip the broad terminology changes and keep the diff to OMP-specific additions
only. The hook/plugin/extension wording updates aren't needed for this integration.

On extension vs pre hook: The goal is the same as a pre-execution rewrite: intercept the bash tool call before it runs and replace the command with the rtk rewrite result.

I chose the extension path because it's the actively maintained surface for tool interception in current OMP. Specifically:

• --hook is treated as an alias for an extension path in current OMP
• Extension modules are auto-discovered from .omp/extensions/ and ~/.omp/agent/extensions/
• OMP's authoring docs recommend ExtensionAPI for new integrations
• The hook subsystem's tool_call event can only block/allow — it cannot mutate tool input in-place, which is needed for command rewriting. In other words, the legacy hook result contract is block/allow-oriented and does not expose an explicit updated-input return shape for command rewriting.

This also aligns with RTK's existing transparent-rewrite integrations (OpenCode plugin, OpenClaw plugin) rather than the rules-file approach or hooks.

That said — if you'd prefer a pre-hook implementation, or would rather wait for another contributor's take, I'm happy to adjust or close. Just let me know which direction you'd prefer. 🤗

[KuSh]

On extension vs pre hook: The goal is the same as a pre-execution rewrite: intercept the bash tool call before it runs and replace the command with the rtk rewrite result.

I chose the extension path because it's the actively maintained surface for tool interception in current OMP. Specifically:

* `--hook` is treated as an alias for an extension path in current OMP

* Extension modules are auto-discovered from .omp/extensions/ and ~/.omp/agent/extensions/

* OMP's authoring docs recommend ExtensionAPI for new integrations

* The hook subsystem's tool_call event can only block/allow — it cannot mutate tool input in-place, which is needed for command rewriting. In other words, the legacy hook result contract is block/allow-oriented and does not expose an explicit updated-input return shape for command rewriting.

This also aligns with RTK's existing transparent-rewrite integrations (OpenCode plugin, OpenClaw plugin) rather than the rules-file approach or hooks.

That said — if you'd prefer a pre-hook implementation, or would rather wait for another contributor's take, I'm happy to adjust or close. Just let me know which direction you'd prefer. 🤗

No, I was just questioning the choice since, after a quick review of the OMP repo, I didn't find anything that prioritizes extensions over hooks. But after your explanation and a closer review of the documentation, extensions seem like the right choice.

So rebase, handle conflicts, and reduce documentation noise—the principles remain the same even if OMP chooses different wording.

[rtk-release-bot]

Automatic message from CI checks : It seems like this branch is targeting the wrong branch, any contribution should target develop branch.

See CONTRIBUTING.md for details.

[makoMakoGo]

@KuSh updated.

Changed:

• Kept docs to OMP-additive entries only; no broad terminology changes
• Aligned OMP extension with RTK's fail-open convention used by Hermes/OpenCode etc: missing rtk or rewrite
  failures leave the original command unchanged

Verified:

• cargo fmt --all -- --check ✓
• cargo clippy --all-targets ✓
• cargo test ✓
• bun --eval 'await import("./hooks/omp/rtk.ts")' ✓
• Local OMP simulation: tool_call rewrites supported bash commands through rtk
• Manual fail-open check: hid the rtk binary; command passed through unchanged, no block

Ready for re-review when you have time.