Skip to content
rippy

Packages

A package is a preconfigured safety profile you can pick as a starting point instead of hand-writing rules. rippy ships three packages out of the box, each targeting a different level of AI autonomy:

  review      [===]     Full supervision. Every command asks.
  develop     [==.]     Auto-approves builds, tests, VCS. Asks for destructive ops.
  autopilot   [=..]     Maximum AI autonomy. Only catastrophic ops are blocked.

Packages are a starting point — once you pick one, you layer your own allow / ask / deny rules on top in your .rippy.toml. The package supplies the defaults; your config has the final word.

Pick one interactively

Section titled “Pick one interactively”
Terminal window
rippy init

walks you through package selection and writes ~/.rippy/config.toml with package = "…" set to your choice.

Or pick one directly

Section titled “Or pick one directly”
Terminal window
rippy init --package develop

Replace develop with review or autopilot depending on how much friction you want.

Manage packages later

Section titled “Manage packages later”
Terminal window
rippy profile list              # see all packages
rippy profile show develop      # see what a package auto-approves, asks, and blocks
rippy profile set autopilot     # switch packages without rewriting your config

The active package is stored in your config’s [settings] block as package = "<name>". You can also edit that line directly.

How packages compose with rules

Section titled “How packages compose with rules”

When rippy evaluates a command, your explicit rules win over the package. That means you can run under autopilot but still deny git push --force for peace of mind, or run under review but allow git status so you don’t get asked about read-only commands.

See Configuration overview for the full ordering and Example configs for ready-to-copy starters for each package.

Custom packages

Section titled “Custom packages”

If the three built-ins don’t fit your workflow, you can define your own package in ~/.rippy/packages/<name>.toml. The format is the same as any other rippy TOML config, plus a [meta] block for display metadata.

Extend a built-in

Section titled “Extend a built-in”

The fastest way to build a custom package is to inherit from a built-in and layer extra rules on top:

~/.rippy/packages/backend-dev.toml
[meta]
name = "backend-dev"
tagline = "Go + Postgres + K8s workflow"
shield = "==."
extends = "develop"


[[rules]]
action = "allow"
command = "kubectl"
subcommands = ["get", "describe", "logs"]


[[rules]]
action = "deny"
pattern = "kubectl delete"
message = "destructive — run manually"

extends = "develop" pulls in every rule from the develop package first; your own rules are applied afterwards so they win under last-match-wins. Only built-in packages (review, develop, autopilot) can be extended in v1 — this prevents cycles and keeps the resolution order predictable.

If you omit extends, your custom package starts from an empty rule set and only the stdlib defaults apply underneath.

Activate a custom package

Section titled “Activate a custom package”

Custom packages are discovered automatically. Use the same CLI as built-ins:

Terminal window
rippy profile list              # your custom package appears under "Custom packages:"
rippy profile show backend-dev  # shows inherited + your own rules
rippy profile set backend-dev   # writes package = "backend-dev" to your config

Or put package = "backend-dev" directly in your global or project [settings] block.

Naming and priority

Section titled “Naming and priority”
  • The filename (minus .toml) is the authoritative package name — what you type after package = "…" and in rippy profile. The [meta] name field is informational; if it disagrees with the filename you’ll see a warning and the filename wins.
  • Built-in names always take priority. If you create ~/.rippy/packages/develop.toml, rippy will use the built-in develop and print a warning telling you your file is shadowed.
  • Malformed files don’t break profile list — rippy skips them with a stderr warning so one bad file can’t hide the rest. profile show on a malformed file returns a clear error with the file path.

Sharing

Section titled “Sharing”

Custom packages are plain TOML files. You can share them by copying to a teammate’s ~/.rippy/packages/, committing to a shared repo and symlinking in, or distributing via your own tooling.

Where to go from here

Section titled “Where to go from here”