setup-benny

Files (1)

• SKILL.md

SKILL.md (first lines)

# Set up Benny

Benny ships as a dormant automation pack inside omp-pstack. The plugin manifest exposes only omp-pstack's normal skill root; this file and the two operational files are not slash skills. The native runner reads them directly.
`pstack` commands below run through the installed-root launcher `bun "$PSTACK_ROOT/src/cli.ts" ...`: resolve `PSTACK_ROOT` once with the install resolver in the omp-pstack README (`running the pstack CLI after install`; inside the package checkout, `PSTACK_ROOT="$(pwd)"`). A marketplace install does not put `pstack` on PATH.

Benny runs through the deterministic native runner: `bun "$PSTACK_ROOT/src/cli.ts" benny setup|check|run|canary|enable|disable`. The runner holds all Slack, tracker, GitHub, and model credentials; coordinator sessions receive only bound actions and a disposable container workspace.

Never put a secret value in pack files, prompts, or committed configuration. Enablement lives in workspace-namespaced private OMP profile state; repository-local state is never authority and the default is disabled.
Configuration keys shaped like credential carriers inside `runtime.control_config` or `runtime.environment` are rejected outright, as are raw secret values anywhere in the config; the typed `*_token_env` fields are the only credential references.

## 1. Install the pack and enable shared omp-pstack skills

Ask which repository will run the automations. The source pack is the `automations/benny/` directory of the installed omp-pstack package. The destination is `<target-repository>/.omp/automations/benny/`.

Run `bun "$PSTACK_ROOT/src/cli.ts" benny setup --target <repo>` from the omp-pstack checkout. Setup performs a conservative merge into the destination:

1. Creates the destination when it is absent.
2. Copies every source file to the same relative path; identical files are no-ops.
3. Preserves destination-only files. Never deletes unrelated files during install or refresh.
4. Leaves user-owned configuration, feature maps, and routing maps outside the destination untouched.
5. Reports differing source-managed files as conflicts for diff/merge review. Never blind-overwrites a local edit; if ownership is ambiguous, stop and ask before replacing it.
6. Adds the anchored `.omp/pstack/state/` rule to the repository's private `.git/info/exclude` through the authoritative git path — `git rev-parse --git-path info/exclude`, so linked worktrees resolve to their own exclude file — and proves the rule with `git check-ignore`. Setup fails instead of writing through an unsafe Git metadata path, and repository-local state is never the enablement authority.
7. Verifies that the destination contains `FOR_AGENTS.md`, this setup file, both operational files, their references, and the templates.

Setup also installs omp-pstack at project scope in the target so shared skills resolve in fresh target sessions. It runs `omp plugin marketplace add <this package>` and `omp plugin install --scope project omp-pstack@omp-pstack`, then verifies that the durable declarations `.omp/plugins/installed_plugins.json` and `.omp/plugins/omp-plugins.lock.json` contain the omp-pstack entry. If the target is not a git repository or the install fails, setup reports it; fix the cause and rerun. Preserve every unrelated project configuration file.

Verify from a fresh agent rooted in the target repository that these shared omp-pstack skills resolve at project scope:

- `how`
- `why`
- `tdd`
- `unslop`
- `principle-separate-before-serializing-shared-state`
- `principle-minimize-reader-load`
- `principle-guard-the-context-window`
- `principle-sequence-verifiable-units`
- `principle-fix-root-causes`
- `principle-prove-it-works`

Do not count a skill loaded from the current session or a user-scoped install. The check must show that a fresh agent in the target repository receives omp-pstack through the committed project-scoped installation.

If the project-scoped install is unavailable or any shared dependency does not resolve, stop and explain the failure.

The Benny files are read directly from `.omp/automations/benny/`. Do not add that directory to a plugin manifest or expect its `SKILL.md` files to appear in the slash-skill list.

Tell the user that `.omp/plugins/installed_plugins.json`, `.omp/plugins/omp-plugins.lock.json`, `.omp/automations/benny/`, the committed configuration, and any referenced secret-free configuration must be committed before either automation is enabled. `bun "$PSTACK_ROOT/src/cli.ts" benny check` enforces this. Do not commit anything unless the user asks.

Once this check passes, live automation runs receive the committed operational files directly by their stable repository-relative paths. They never embed a plugin cache path or a copied file body.

## 2. Adapt the configuration

Open these copied examples:

- `../../templates/configuration.example.yaml`
- `../reproduce-and-fix-issues/references/feature-map.example.md`

Create user-owned copies outside `.omp/automations/benny/`. The default locations match the example config paths:

- Project config: `.omp/benny/configuration.yaml`
- Project feature map: `.omp/benny/feature-map.md`
- Project routing map: `.omp/benny/routing.md`
- The operational configuration must be a regular non-symlink file committed inside the target repository. It may live outside the copied pack — `.omp/benny/` is the default location — but never outside the repository and never uncommitted: the runner refuses a symlinked, uncommitted, or out-of-repo configuration before any run, canary, or admission.

Fill one feature-map section for every user-facing feature the automation may reproduce. Keep it at the user point of view. Do not freeze implementation details or current code paths in the map.

Do not edit the copied examples. Pack refreshes may update source-managed files after conflict review, but they must never touch the user-owned copies.

- Configuration and every referenced map must be committed inside the target repository; uncommitted files can never pass `bun "$PSTACK_ROOT/src/cli.ts" benny check`. Reference a repository file only after that check confirms the committed-declarations gate passes for it.

Use stable repository-relative paths for committed pack and configuration files. Never reference the plugin source directory or a plugin cache path from a live run.

## 3. Fill the required choices

Ask for or confirm:

- Source Slack channel ID
- Optional operations or status channel ID
- Repository URL and default branch
- Triage identity or Slack user ID
- Issue tracker: team, project, labels, and intake status (bundled `linear` adapter)
- Routing map path (required): a committed same-repo path whose map may be empty for no owner routing
- Workspace boundary: `runtime.workspace_image`, trusted controller `runtime.control_command`, worker app bootstrap `runtime.control_config.worker_command`, and internal `runtime.control_config.app_url`
- Required user-facing feature-map path
- Status emoji strings
- Pull request URL format
- Polling and effort budgets
- Trigger transport: `runtime.trigger: "external"` or `"socket-mode"`, plus the Slack token environment-variable names
- Concrete OMP model selectors for triage, repro, code work, and media review

Use only concrete OMP model selectors that resolve in the runner's authenticated model registry. Validate the choices with `bun "$PSTACK_ROOT/src/cli.ts" benny check`; a selector the runner cannot resolve fails validation and blocks enabling. Do not guess a selector and do not carry over a private default.

The source channel, triage identity, repository, tracker (the bundled bounded Linear adapter), control adapter, and feature map must be explicit. Fail setup if any required value stays ambiguous.

Use omp-pstack's `unslop` skill on the final automation names, descriptions, and prompt text before committing them.

## 4. Check integration capabilities

The triage run needs:

- Read access to the configured source Slack channel and its threads, through the bundled Slack Web API transport with the token named by `runtime.slack_read_token_env`
- Thread-reply access in that channel, through the token named by `runtime.slack_write_token_env`
- Attachment metadata and file download access when reports include media
- Search, read, create, update, and compensation access through the bundled Linear tracker

The repro run needs:

- Read access to the source thread
- Thread-reply access in the source channel
- Optional post and edit access in the configured operations channel
- Repository read and history access
- A draft pull request action (the runner's `gh`-backed GitHub action, which always reads back `isDraft`, head, and base)
- The configured control adapter command inside the trusted workspace image

- Optional narrow gaps such as editing one operations status message or downloading an attachment may use the bot token named by `slack.optional_bot_token_env`. Store the value in the runner's environment, not in YAML. Only the bundled Slack Web API, Linear, and `gh`-backed GitHub transports execute: OMP supplies no narrow host broker for configured actions, so named MCP action mappings and `slack.prefer_configured_actions: true` are rejected outright at parse time and before admission. Do not configure them.

Do not use undocumented integration endpoints.

## 5. Prepare the routing map

From Jrecos/omp-pstack, MIT.

More from Jrecos/omp-pstack