rippletide-package

Rippletide's product package. It ships as one npm CLI — npx rippletide-package <feature-name> — while each feature lives in its own self-contained top-level folder.

Published on npm as rippletide-package, and the installed command is also rippletide-package. So: npx rippletide-package <feature-name>, or npm i -g rippletide-package then rippletide-package <feature-name>. Tide also installs a direct tide command for the policy workflow; it is the same implementation as rippletide-package tide.

Zero sharing between folders. Each feature folder is fully self-contained — its own code, dependencies, config, and docs. Nothing imports from or reaches into another feature's folder. The only place features meet is the root CLI, which routes a subcommand to the feature that owns it.

Features

Each feature is a subcommand of rippletide-package, implemented in its own top-level folder. A feature is explained in its own folder — see that folder's README.md (and any PRD.md/docs) for what it does and how to use it.

npx rippletide-package <feature-name> [flags]

Tide is the runtime policy surface for agents:

npx -y --package rippletide-package@latest tide run

Run it from the agent repo. The npm CLI creates a local .venv, installs tide-runtime inside it, scans risky tools, and opens the terminal flow to choose allow, log, escalate, or deny before writing wrappers and policy. Approvals and earned-use reports then run through tide approvals, tide approve, tide deny, and tide report from that same environment. Omit --pack for baseline; add --pack support-refunds for refund agents.

Reviewer is the first pre-ship workflow:

npx rippletide-package@latest review /path/to/agent

It produces up to 10 evidence-backed findings, opens the interactive fix flow, and writes a local HTML review workspace so builders can triage findings, keep notes, and track status outside the terminal.

Surface statically discovers the tools an agent exposes to the model and labels each safe / dangerous / unknown from its name, description, and annotations — a lockfile for what your agent can do. No execution, no traces, no LLM, no API key:

npx rippletide-package@latest surface /path/to/agent          # scan → .rippletide/policy.yaml + report
npx rippletide-package@latest surface check /path/to/agent    # CI drift gate (exit 1 on drift)

Codex Plugin

The package also ships a repo-local Codex plugin marketplace at .agents/plugins/marketplace.json. It exposes the tide skill from tide/plugin and the aim skill from aim/plugin, so Codex can guide Tide policy checks or AIM local tool-call guardrails from inside a thread.

For public Codex installation from any terminal, use:

npx -y rippletide-package@latest tide codex install

AIM can be installed from this repo marketplace:

codex plugin marketplace add rippletideco/rippletide-package --ref main
codex plugin add aim@rippletide-package

How it fits together

One product, one command, many features. The root bin/rippletide.js is a small, feature-agnostic dispatcher: it reads the first argument and hands off to the feature folder that owns that subcommand. Behavior within a feature is chosen with flags (e.g. rippletide-package <feature-name> --<flag>). Runtime code is not shared across feature folders until a shared contract is deliberately designed.

Adding a feature

Repeat this shape for every new feature:

1. Create a top-level folder; keep everything it needs inside it (code, deps, docs, tests) and explain it in that folder's README.md.
2. When it becomes user-facing, add one route in bin/rippletide.js, and its runtime files (plus any dependency it needs) to the root package.json.
3. Prefer a subcommand or a flag over a new npm package; create a separate package only if a single command would make the product worse.

Publishing: PUBLISHING.md.