setup-benny

Files (1)

• SKILL.md

SKILL.md (first lines)

# Set up Benny

Follow the [portable runtime contract](../pstack-pi/references/runtime.md) for skill paths, host capability discovery, questions, roles, models, and durable automation facilities.

Benny is a dormant pair of automation workflows backed by the sibling **triage-issue-reports** and **reproduce-and-fix-issues** skills. Benny needs external configuration and two live host automations or durable loops. Do not assume a particular editor, cloud checkout, plugin cache, protocol link, or automation backend.

Do not create or update an automation until the user explicitly asks. Never put a secret value in skill files, prompts, or committed configuration.

## 1. Install the operational skills and shared dependencies

Do this before asking for Benny configuration and before using the host's automation facility.

Ask which repository will run the automations. Use the current package's `skills/` directory as the source. The target must expose these project-local paths, either through the host's package installation mechanism or as committed files:

- `skills/setup-benny/SKILL.md`
- `skills/triage-issue-reports/SKILL.md` and its references
- `skills/reproduce-and-fix-issues/SKILL.md` and its references
- `skills/pstack-pi/references/runtime.md`
- the shared pstack skills named by the two operational skills

When copying is required:

1. Copy every file from each required skill directory to the same project-relative path.
2. Preserve destination-only files. Never delete unrelated files during install or refresh.
3. Keep user-owned configuration, feature maps, and routing maps outside the imported skill directories. Never overwrite them.
4. Inspect differences in source-managed files and merge without discarding local edits. If ownership is ambiguous, stop and ask before replacing anything.
5. Verify that both operational skills, every imported reference, and the runtime contract resolve from the target repository.

If this file is already running from the target repository, treat installation as complete only after the same verification.

Start a fresh agent rooted in the target repository and verify that these sibling skills resolve from 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 visible only through the current session or a user-global installation. The check must show that a fresh agent in the target repository receives the dependencies through project scope.

If project-scoped skill installation is unavailable or any shared dependency does not resolve, stop and explain the limit.

Tell the user that the operational skills and any referenced secret-free configuration must be committed on the branch used by the automation checkout before either automation is enabled. Do not commit them unless the user asks.

Once this check passes, live automation prompts may read the committed operational skills by stable repository-relative paths. They must not embed an installation cache path or copy the skill contents.

## 2. Create user-owned configuration

Create configuration outside the imported skill directories. Recommended project-local locations:

- `.benny/configuration.yaml`
- `.benny/feature-map.md`
- `.benny/routing.md`

A user-level path such as `~/.config/benny/configuration.yaml` or `~/.config/benny/feature-map.md` is valid only when the live automation can access it. Prefer committed, secret-free project files when an isolated checkout must read them. Otherwise paraphrase the required values into the live prompt. Reference a repository file only after the host automation facility confirms that it is committed in the repository where the automation runs. Store secrets in the host's secret manager or environment.

Start the feature map from [`../reproduce-and-fix-issues/references/feature-map.example.md`](../reproduce-and-fix-issues/references/feature-map.example.md). Fill one 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.

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

Use stable repository-relative paths in live automation prompts. Never reference an installation cache or a vendor-global path.

## 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 type, team, project, labels, and intake status
- Tracker adapter skill or host actions
- Optional routing map path
- Required control skill name
- Required user-facing feature-map path
- Status emoji strings
- Pull request URL format
- Polling and effort budgets
- Role or model choice for triage, repro, code work, and media review

Use canonical runtime roles or only model choices confirmed by the live host inventory. Do not guess a slug or carry over a private default.

The source channel, triage identity, repository, tracker adapter, control skill, and feature map must be explicit. Fail setup if any required value stays ambiguous.

Invoke the sibling **unslop** skill on final automation names, descriptions, and prompt shims before saving them.

## 4. Check integration capabilities

The triage automation needs:

- Read access to the configured source Slack channel and its threads
- Thread-reply access in that channel
- Attachment metadata and file download access when reports include media
- Search, read, create, and update access through the configured issue-tracker adapter

The repro automation 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 pull request action that can open a draft pull request
- The configured control-adapter skill

Prefer Slack actions exposed by the current host. The optional `BENNY_SLACK_BOT_TOKEN` may fill a narrow missing capability such as editing one operations status message or downloading an attachment. Store it in a secret manager or environment, never YAML, and never expose it to a child.

Do not use undocumented integration endpoints.

## 5. Prepare the routing map

If the user wants reroutes or owner pings:

1. Copy [`../triage-issue-reports/references/routing.example.md`](../triage-issue-reports/references/routing.example.md) to a user-owned path such as `.benny/routing.md`.
2. Replace every placeholder with public or organization-local values.

From shrimpwtf/oh-my-pstack, MIT.

More from shrimpwtf/oh-my-pstack