@justjoshn/pi-pstack 0.0.0-stage → 0.15.36-pi.1

package/automations/benny/skills/setup-benny/SKILL.md

@@ -0,0 +1,253 @@
+---
+name: setup-benny
+description: Configure Benny and prepare its triage and repro automations. Use when installing Benny or changing its Slack, tracker, repository, routing, control, model, trigger, memory, or budget settings.
+disable-model-invocation: true
+---
+
+# Set up Benny
+
+Benny ships as a dormant automation pack inside pi-pstack. Pi discovers only pi-pstack's normal skill root; this file and the two operational files are not slash skills.
+
+The human enters setup by pointing Pi at the pack's `FOR_AGENTS.md`. The bootstrap flow copies the whole pack into the target repository, then reads this file directly at `.pi/automations/benny/skills/setup-benny/SKILL.md`.
+
+Benny needs external configuration and two live automations. Each automation is a pi-pstack subscription owned by a long-running Pi session rooted in the target repository:
+
+- Timer mode (default): `subscribe_timer` with a 5-field `cron`. Each fire wakes the owning session, which sweeps the source channel, claims one report, and hands it to one background `Task` on the automation's configured model. The run's result arrives as a Task notification.
+- Webhook mode: `subscribe_webhook`. Each POST to the local routine URL wakes the owning session with a `[routine]` turn, and the prompt hands the event to one background `Task` on the automation's configured model.
+
+Subscriptions live in the Pi process. They stop when that session exits, return when it is resumed, and expire (default seven days). Tell the user this before creating anything.
+
+Do not create or update a subscription until the user explicitly asks. Never put a secret value in pack files, prompts, memory, or committed configuration.
+
+## 1. Copy the pack and check shared pi-pstack skills
+
+Do this before asking for Benny configuration and before creating any subscription.
+
+Ask which repository will run the automations. The source pack is the directory containing `FOR_AGENTS.md`. The destination is `<target-repository>/.pi/automations/benny/`.
+
+Merge the entire source pack into the destination:
+
+1. Create the destination when it is absent.
+2. Copy every source file to the same relative path.
+3. Preserve destination-only files. Never delete unrelated files during install or refresh.
+4. Keep user-owned configuration, feature maps, routing maps, and memory outside the destination. Never overwrite them.
+5. When an existing source-managed file differs, inspect the diff and merge without discarding local edits. If ownership is ambiguous, stop and ask before replacing it.
+6. Verify that the destination contains `FOR_AGENTS.md`, this setup file, both operational files, their references, and the templates.
+
+If this file is already being read from the target destination, treat the copy as complete and run the same verification before continuing.
+
+Confirm that pi-pstack is installed in Pi. A personal install (`pi install <path-to-pi-pstack>`) serves every repository on this machine. A project install (`pi install -l <path-to-pi-pstack>`) writes the target repository's `.pi/settings.json`; preserve every unrelated setting and package entry when that file exists, and validate it after editing.
+
+This setup session must run in the target repository, because a `Task` subagent starts in its parent's working directory. If it does not, stop and tell the user to start Pi in the target repository and point it at `FOR_AGENTS.md` again. Start a fresh `Task` subagent with `readonly: true`. Ask it which of these skills its system prompt lists as installed:
+
+- `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 this session read by hand. The check must show that a fresh subagent in the target repository receives pi-pstack.
+
+If pi-pstack or any shared dependency does not resolve, stop and explain the failure.
+
+Confirm that `pi mcp list` shows the Slack MCP server the user names, and that it exposes thread read, thread reply, and, when needed, file download and message edit tools. If it does not, stop and explain what is missing.
+
+The Benny files are read directly from `<target-repository>/.pi/automations/benny/`. Do not move that directory into `.pi/skills/` or expect its `SKILL.md` files to appear in the slash-skill list.
+
+Tell the user to commit `.pi/automations/benny/` and any referenced secret-free configuration, so pack refreshes stay reviewable. Do not commit them unless the user asks.
+
+Once this check passes, subscription prompts read the operational files by their absolute paths in the target checkout. They must not embed a pi-pstack package path or copy the file contents.
+
+## 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 `.pi/automations/benny/`. These are configuration files, not pack files. Example locations:
+
+- Project config, such as `.pi/benny/configuration.yaml`
+- Project feature map, such as `.pi/benny/feature-map.md`
+- Project routing map, such as `.pi/benny/routing.md`
+- User config, such as `~/.config/benny/configuration.yaml`
+- User feature map, such as `~/.config/benny/feature-map.md`
+
+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.
+
+Create the memory directory named by `memory.directory`, such as `<pstack dir>/automations/benny/memories/`, where `<pstack dir>` is the directory of the model rule the system prompt names (`~/.pi/agent/pstack` by default), with an empty `ledger.tsv` and a `MEMORIES.md`. Write into `MEMORIES.md` only operating notes a run needs: the target repository path, the configuration path, the subscription names, and, in webhook mode, each routine's URL and credential file path. Never write a key, a token, or report text into memory. Keep the directory out of the repository.
+
+Use absolute paths for the pack, configuration, and memory in subscription prompts. Never reference the pi-pstack package directory from a subscription prompt.
+
+## 3. Fill the required choices
+
+Ask for or confirm:
+
+- Source Slack channel ID
+- Optional operations or status channel ID
+- Repository URL and default branch
+- Absolute path of the target repository checkout
+- Triage identity or Slack user ID
+- Slack MCP server name and the exact tool for each Slack action
+- Issue tracker type, team, project, labels, and intake status
+- Tracker adapter skill or MCP actions
+- Optional routing map path
+- Required control skill name
+- Required user-facing feature-map path
+- Status emoji strings
+- Pull request URL format
+- Trigger mode, and the cron schedules for timer mode
+- Memory directory
+- Polling and effort budgets
+- Model for triage, repro, code work, and media review
+
+Use only model specs that `pi --list-models` shows, with a thinking level that model lists, such as `provider/model:high`. Do not guess a model and do not carry over a private default.
+
+The source channel, triage identity, repository, Slack MCP tools, tracker adapter, control skill, and feature map must be explicit. Fail setup if any required value stays ambiguous.
+
+Use pi-pstack's `unslop` skill on the final subscription names and prompts before creating 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
+- `gh` authenticated for the repository, so `gh pr create --draft` can open a draft pull request
+- The configured control-adapter skill
+
+Prefer the configured Slack MCP tools for reads and posts. The optional `BENNY_SLACK_BOT_TOKEN` may fill a narrow gap such as editing one operations status message or downloading an attachment. Store the value in a secret manager or the owning session's environment, not in YAML. A writable subagent inherits that environment, which is one reason Benny's workers run readonly.
+
+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` outside `.pi/automations/benny/`.
+2. Replace every placeholder with public or organization-local values.
+3. Keep owner pings off by default.
+4. Allow a ping only for a configured feature owner or a confirmed likely regression author.
+
+If no routing map is configured, triage may classify a report but must not guess a destination or owner.
+
+## 6. Verify the control adapter
+
+Read `../reproduce-and-fix-issues/references/control-adapter.md` and the user's completed feature map.
+
+Confirm that the named skill can:
+
+- Bring up the target app
+- Navigate every mapped feature through the real UI
+- Exercise mapped states through declared adapter actions
+- Inspect state without forcing the result
+- Capture screenshots
+- Start and stop a recording
+- Clean up its processes and temporary data
+
+If any capability is missing, do not create the repro subscription. It must fail closed rather than claim a reproduction it did not perform.
+
+## 7. Prepare the live automations
+
+Ask whether this is first-time creation or configuration of existing subscriptions.
+
+Read `../../FOR_AGENTS.md` from the copied pack as the primary user-intent source for either path. Use it to understand the two triggers, tools, instructions, outcomes, and shared rules.
+
+The owning session must be interactive or RPC, rooted in the target repository, and expected to keep running. A print or JSON run cannot own a subscription. Suggest a dedicated tmux window, such as `tmux new -s benny 'cd <target-repository> && pi'`. In both trigger modes, each fire hands its report to one background `Task` with the automation's configured `model`, so one owning session serves both automations, whatever model that session runs on.
+
+### First-time creation
+
+Create one subscription at a time.
+
+For each automation:
+
+1. Read the matching copied prompt template.
+2. Fill every `{{...}}` value from the finished configuration. Keep only the trigger block for the chosen mode.
+3. Check that the prompt reads its exact operational file under `<target-repository>/.pi/automations/benny/`, by absolute path. Do not copy the operational file contents into the prompt.
+4. Show the user the subscription name, mode, schedule, and full prompt, and get approval.
+5. Create the subscription:
+   - Timer mode: `subscribe_timer` with `name`, `prompt`, and `cron`. Keep the default `sessionStrategy`, `wake_self`, so each fire reaches the owning session, which starts the `Task` on the configured model.
+   - Webhook mode: `subscribe_webhook` with `name` and `prompt`. It returns the local URL (`http://127.0.0.1:<port>/routines/<slug>`, where the slug is the kebab-case form of the name) and the credential file path. The key stays in that file. Never print it, paste it into chat, or copy it into the configuration.
+6. Run `list_subscriptions`. Confirm the subscription appears with the expected name, schedule or URL, and `expiresAt`. A result of `created: false` means a subscription with that name already exists and kept its old prompt; follow the existing-subscription path instead.
+7. Finish the thread-safety checks that apply to this automation before creating the next one.
+
+The triage subscription must:
+
+- Be named `benny-triage`.
+- Read and follow `<target-repository>/.pi/automations/benny/skills/triage-issue-reports/SKILL.md` for every run.
+- Start on each new top-level report in the configured source Slack channel, one report per run, claimed in the ledger.
+- Read the triggering thread and reply only inside it.
+- Use the configured issue-tracker integration.
+- Classify, inspect evidence, trace cause, dedupe, and create only clear new bugs.
+- End one thread-only verdict with the configured `[benny:bug]`, `[benny:performance]`, or `[benny:other]` marker and optional tracker URL.
+- Never post a source-channel root message.
+
+After the triage subscription passes its checks, the repro subscription must:
+
+- Be named `benny-reproduce`.
+- Read and follow `<target-repository>/.pi/automations/benny/skills/reproduce-and-fix-issues/SKILL.md` for every run.
+- Start on the same new top-level reports in the configured source Slack channel, one report per run, claimed in the ledger.
+- Use the configured repository and default branch, in a fresh worktree from the default branch.
+- Read the source thread and reply only inside it.
+- Include draft pull request creation and the configured tracker, control-adapter, and feature-map requirements.
+- Wait for a trusted triage marker before acting.
+- Reproduce the exact symptom twice through the mapped real UI and capture evidence.
+- Verify an existing fix without authoring over it.
+- Attempt an optional bounded fix only after confirmed repro, then open a draft pull request when proof and checks pass.
+- Never post a source-channel root message.
+
+In webhook mode, Benny ships no relay. Slack cannot reach `127.0.0.1`, so the user runs a Slack app or relay that receives Slack events, verifies them, keeps only new top-level messages in the source channel, and POSTs `{"source_channel_id", "message_ts", "thread_ts"}` as JSON to both routine URLs, with `Authorization: Bearer <key>` read from each credential file. `/routines` lists each routine with its URL, credential file, and status.
+
+### Existing subscriptions
+
+Run `list_subscriptions` to find them. Subscribing again with an existing name does not update it.
+
+Finish configuration, routing, control-adapter, and feature-map validation. Then, for each subscription that must change:
+
+1. Fill the new prompt from the template, as in first-time creation, and get approval.
+2. `unsubscribe` the old subscription.
+3. Create it again with the same name and the new prompt. A webhook routine keeps its slug, so check whether its URL or credential file changed and tell the user to update the relay.
+4. Run `list_subscriptions` and confirm exactly one subscription per name.
+
+To renew an expiring subscription, do the same with the unchanged prompt. Do not create replacements under new names.
+
+### Creation boundary
+
+Create Benny's automations only with pi-pstack's `subscribe_timer` and `subscribe_webhook` tools in the owning session. Never start a scheduler outside Pi, such as `cron` or `launchd`, and never expose the routine listener beyond `127.0.0.1` from this setup.
+
+Do not let either automation handle normal traffic until the thread-safety test passes.
+
+## 8. Test thread safety
+
+Create both subscriptions with a test channel as the source channel, or test with a harmless report.
+
+Before testing, confirm that both subscription prompts point at their exact operational files in the target checkout, that the memory directory exists, and that `list_subscriptions` shows both subscriptions. If any check fails, stop. Tell the user that the automation cannot handle traffic yet.
+
+Verify:
+
+1. Triage stores the root `thread_ts` and posts exactly one verdict as a reply.
+2. The verdict contains one configured marker.
+3. Repro accepts the marker only from the configured triage identity.
+4. Repro keeps the same immutable source coordinates.
+5. No source-channel root message appears.
+6. A delegated worker cannot use any Slack write action: it runs as a `readonly` `Task`, so it has no MCP tools.
+7. Missing coordinates, a deleted parent, or a failed preflight produces no post and no tracker issue.
+8. A second fire, or a repeated webhook POST, for the same report does no work, because the ledger already lists it.
+
+Handle normal traffic only after all eight checks pass. If the checks ran against a test channel, set the real source channel in the configuration and recreate both subscriptions through the existing-subscription path.

package/automations/benny/skills/triage-issue-reports/SKILL.md

@@ -0,0 +1,240 @@
+---
+name: triage-issue-reports
+description: Triage Slack issue reports with one thread-only verdict, evidence review, cause-aware routing, tracker dedupe, and fail-closed ticket creation. Use only from the configured Benny triage automation.
+disable-model-invocation: true
+---
+
+# Triage issue reports
+
+Classify one Slack report and post one useful verdict in its source thread. Create a tracker issue only for a clear, new bug. Do not reproduce or fix it here.
+
+Load the external Benny configuration supplied by the automation. If the config is missing, malformed, or incomplete, stop without posting or writing to the tracker.
+
+## Hard safety rules
+
+- The source channel and root thread coordinates are immutable.
+- Never post a root message in the source channel.
+- Never post to another channel, broadcast a reply, send a DM, or start a replacement thread.
+- Preflight the source parent before any tracker write and immediately before the verdict post.
+- If the parent is missing, deleted, inaccessible, or uncertain, stop with no writes.
+- Post one substantive verdict. Do not narrate progress.
+- The coordinator is the only Slack poster.
+- Delegated workers return findings only. They must be read-only and receive no Slack credentials or write actions. In Pi, start each one with `Task` and `readonly: true`: a readonly subagent gets no MCP servers, and its shell can neither write files nor reach the network.
+- Every child prompt must forbid every Slack MCP write tool (`mcp__<slack-server>__*` tools that post, edit, react, or upload), `chat.postMessage`, and every other Slack write.
+- If worker isolation cannot enforce those limits, do the work in the coordinator.
+- Never create an issue that cannot link back to the source thread.
+- Prefer no ticket over a guessed or duplicate ticket.
+- Apply pstack's `principle-separate-before-serializing-shared-state` to source coordinates.
+- Apply pstack's `principle-minimize-reader-load` and `unslop` skills to the final verdict.
+
+## 1. Freeze source coordinates
+
+Before making a work list or delegating:
+
+1. Read `source_channel_id` from the trigger.
+2. Require it to equal the configured source channel.
+3. Set `SOURCE_THREAD_TS` to `trigger.thread_ts` when present. Otherwise use `trigger.ts`.
+4. Require a nonempty `SOURCE_THREAD_TS`.
+5. Store `SOURCE_CHANNEL_ID` and `SOURCE_THREAD_TS` as immutable values.
+6. Read the thread and verify that its root has exactly those coordinates.
+7. Fetch a stable source permalink.
+
+Every later source read and post must use those stored values. Never replace them with a reply timestamp or an operations-thread timestamp.
+
+## 2. Read the whole report
+
+Read the root and current replies before deciding.
+
+Capture:
+
+- Reporter wording
+- Product version, app build, environment, and platform when present
+- Expected behavior
+- Observed behavior
+- Frequency and trigger
+- Error text or stack signature
+- Existing issue, commit, or pull request links
+- Any explicit statement that someone is already fixing it
+
+Inspect every relevant attachment.
+
+- Read screenshots at full useful resolution.
+- Review video for the state transition that separates correct and broken behavior.
+- Read logs, traces, and crash text for concrete signatures.
+- If media needs specialist review, use a read-only media worker and ask a narrow question. The worker returns findings only.
+- If an attachment cannot be read, say so in the verdict. Do not invent what it shows.
+
+Use evidence already in the thread before asking the reporter for more.
+
+## 3. Trace cause before routing
+
+Do a bounded source and history pass before choosing an owner or destination. Use pstack's `how` skill to trace the path from the reported action to the observed result. Use `why` when the report looks like a regression or touches defensive code.
+
+1. Identify the likely code path from the reported action to the observed result.
+2. Check whether the visible symptom belongs to that code path or a dependency below it.
+3. Check recent changes when the report looks like a regression.
+4. Check whether a merged commit or open pull request already addresses the same symptom.
+5. Separate confirmed facts from hypotheses.
+
+This pass does not need a complete root cause. It must be strong enough to avoid routing a visible symptom to the wrong owner.
+
+If the repository cannot be read, do not guess a code owner. Continue with a conservative classification and say that cause tracing was unavailable.
+
+## 4. Classify
+
+Choose one category.
+
+### Bug
+
+Something violates intended behavior. Examples include wrong output, broken state, an error, a crash, a hang, a silent no-op, or a regression.
+
+### Performance
+
+The report describes measurable slowness, excess memory, battery drain, jank, or another resource problem. Treat it as a bug, but preserve measurements and profiles.
+
+### Feature request
+
+The current behavior appears intentional and the reporter wants a different behavior or affordance.
+
+### Question or feedback
+
+The report asks how something works, expresses a preference without a concrete defect, or gives general feedback.
+
+### Reroute
+
+Cause tracing shows that another configured destination owns the issue.
+
+When the bug versus feature line is unclear, do not file. The one verdict may ask one focused question and use the `other` marker.
+
+## 5. Apply configured routing
+
+Read the optional routing map from `routing.map_path`.
+
+- Match on confirmed product area, code path, or error signature.
+- A visible symptom alone is not enough when cause tracing points elsewhere.
+- If no route matches, say the owner is unclear. Do not guess.
+- Do not cross-post. Tell the reporter where to take the issue in the source thread.
+
+Owner pings are off by default. A ping is allowed only when all of these hold:
+
+1. The routing map explicitly names the owner.
+2. The config allows that ping type.
+3. The item is a feature request that needs owner input, or recent history identifies a likely regression author with strong evidence.
+4. The owner is not a broad on-call group.
+
+No other case gets a ping.
+
+## 6. Use the issue-tracker adapter
+
+The tracker is an adapter, not a required vendor. A Linear adapter is one valid example. A GitHub Issues adapter or another tracker may implement the same contract.
+
+The configured adapter must provide:
+
+- Search issues by text, state, label, source URL, and date range
+- Read one issue and its links
+- Create an issue with title, body, status, labels, and source URL
+- Update an existing issue without replacing unrelated fields
+- Add a source link and recurrence note
+- Cancel, close, or delete an issue created by this run if the Slack handoff fails
+
+If a required operation is unavailable, fail closed for that write.
+
+Resolve configured team, project, status, and labels at runtime. Do not invent IDs, create labels, assign owners, or set priority unless the config explicitly requires it.
+
+## 7. Dedupe
+
+Always check whether this source permalink is already linked to a tracker issue or a prior triage reply. If so, do not post or create a duplicate.
+
+For bugs and performance reports, search the tracker using:
+
+- Exact error or crash signature
+- Product area
+- Trigger
+- Symptom
+- Version or date window
+- Suspected regression commit
+- Source permalink
+
+Choose one outcome:
+
+- Confident duplicate: same signature, or the same area, trigger, and symptom, or a confirmed shared cause.
+- Possibly related: a shared cause is plausible but not proven.
+- Weak resemblance: similarity is superficial.
+- No match.
+
+For a confident duplicate, update the existing issue with the source permalink and one short recurrence note. Do not reopen, relabel, or reassign it unless the config says to.
+
+For a possible match, link it in the verdict as uncertain and create nothing.
+
+A long-closed issue is a regression lead, not automatically a live duplicate.
+
+## 8. Decide whether to create
+
+Create only when all of these are true:
+
+1. The classification is bug or performance.
+2. The behavior is clearly broken.
+3. The issue is still live or not known to be fixed.
+4. Dedupe found no confident or plausible live match.
+5. The source parent and permalink passed preflight.
+6. The tracker target fields resolved.
+7. The adapter can compensate if the verdict post fails.
+
+Never create for a feature request, question, feedback item, reroute, possible duplicate, confident duplicate, or already-fixed issue.
+
+The new issue must be self-contained:
+
+- Plain title that names the area and symptom
+- Reporter quote
+- Expected and observed behavior
+- Version and environment, or `unknown`
+- Trigger and frequency
+- Source thread permalink
+- Short cause-tracing findings with hypotheses labeled as hypotheses
+- Inline screenshot or representative video frame when supported
+- Links to remaining artifacts
+- Configured intake status and labels
+
+Do not put a guessed root cause in the title.
+
+## 9. Post one verdict
+
+Run a fresh source-parent preflight. Then post exactly one reply with `channel=SOURCE_CHANNEL_ID` and `thread_ts=SOURCE_THREAD_TS`.
+
+Never call a source-channel posting action without a nonempty `thread_ts`.
+
+Keep the reply short:
+
+- Lead with the outcome.
+- Link the existing or new tracker issue when there is one.
+- Mention a reroute or one missing fact when needed.
+- Include at most one allowed owner ping.
+- End with exactly one marker line.
+
+Marker contract:
+
+```text
+[benny:bug]
+[benny:bug] tracker=https://tracker.example/issue/123
+[benny:performance]
+[benny:performance] tracker=https://tracker.example/issue/123
+[benny:other]
+```
+
+Use only the configured marker strings. The repro automation trusts the marker only when it comes from the configured triage identity in this source thread.
+
+After posting, read the same source thread and verify the verdict appears under `SOURCE_THREAD_TS`. If it does not, never retry at the root.
+
+If this run created a tracker issue and the verdict did not land, use the adapter's compensation action. Verify that the issue is canceled, closed, or deleted. If compensation cannot be verified, report the failure only in the run's final message (its Task notification).
+
+## 10. Watch one follow-up window
+
+Watch the source thread for the configured follow-up window, then stop.
+
+- Answer only a direct question to the triage identity.
+- Apply a concrete correction to the tracker issue when safe.
+- Do not emit a second marker in the same run.
+- Stay out of human coordination and side chatter.
+- Stop early if someone asks the automation to stop.
+
+Do not extend the window more than once. A new report should start a new run.

package/automations/benny/skills/triage-issue-reports/references/routing.example.md

@@ -0,0 +1,61 @@
+# Routing map example
+
+Copy this file outside `.pi/automations/benny/`, for example to `.pi/benny/routing.md`, and replace every placeholder. Point `routing.map_path` at the copy. Pack refreshes must not overwrite it.
+
+The triage skill treats this as data. A route needs evidence from the report or cause trace. A keyword match alone is not enough.
+
+```yaml
+routes:
+  - name: "billing-example"
+    match:
+      product_areas:
+        - "billing-area-placeholder"
+      code_paths:
+        - "billing-code-path-placeholder"
+      error_signatures:
+        - "billing-error-placeholder"
+    destination:
+      slack_channel: "billing-channel-placeholder"
+      tracker_team: "billing-team-placeholder"
+    owners:
+      - "billing-owner-placeholder"
+    allow_feature_owner_ping: false
+
+  - name: "desktop-example"
+    match:
+      product_areas:
+        - "desktop-area-placeholder"
+      code_paths:
+        - "desktop-code-path-placeholder"
+      error_signatures:
+        - "desktop-error-placeholder"
+    destination:
+      slack_channel: "desktop-channel-placeholder"
+      tracker_team: "desktop-team-placeholder"
+    owners:
+      - "desktop-owner-placeholder"
+    allow_feature_owner_ping: false
+
+fallback:
+  destination: ""
+  owners: []
+  allow_feature_owner_ping: false
+
+ping_policy:
+  default: "off"
+  allow:
+    - "configured-feature-owner"
+    - "confirmed-regression-author"
+  deny:
+    - "broad-on-call-group"
+    - "unverified-owner"
+```
+
+## Rules
+
+- Leave `fallback.destination` empty unless one team accepts all unmatched reports.
+- Use stable product areas, code paths, and error signatures.
+- Do not include private data in a public copy.
+- Do not paste raw user or channel IDs into an example that will be published.
+- Keep feature-owner pings off until the target team agrees to them.
+- A reroute tells the reporter where to go. The automation never cross-posts.

package/automations/benny/templates/configuration.example.yaml

@@ -0,0 +1,113 @@
+schema_version: 1
+
+# Each Benny automation is a pi-pstack subscription in a long-running Pi session rooted in the target repository.
+automations:
+  # The `name` of each subscription (subscribe_timer or subscribe_webhook). A webhook routine's URL slug is the kebab-case form of this name.
+  triage_name: "benny-triage"
+  reproduce_name: "benny-reproduce"
+  # Absolute path of the target repository checkout. The owning Pi session runs here, and prompts read the pack from
+  # <target_repository_path>/.pi/automations/benny/.
+  target_repository_path: "/path/to/target-repository"
+
+# How runs start for each new top-level report in the source channel.
+trigger:
+  # timer: subscribe_timer with `cron`. Each fire wakes the owning session, which sweeps the source channel, claims at
+  #        most one report, and hands it to a background Task on the automation's model below.
+  # webhook: subscribe_webhook. A Slack app or relay you run POSTs each new top-level report to the local routine URL.
+  mode: "timer"
+  triage_cron: "*/2 * * * *"
+  reproduce_cron: "*/5 * * * *"
+  # How far back a sweep reads the source channel for reports that the ledger has not claimed.
+  sweep_lookback_minutes: 180
+
+# Durable memory. Plain files that every run reads and writes. Never commit them.
+memory:
+  directory: "~/.pi/agent/pstack/automations/benny/memories"
+  # One tab-separated line per claim: automation, channel, root ts, state (claimed | done | skipped), time, note.
+  ledger_file: "ledger.tsv"
+  # Operating notes from setup and verified lessons from runs. Never copy report text into it.
+  notes_file: "MEMORIES.md"
+
+slack:
+  source_channel_id: "SOURCE_CHANNEL_ID"
+  operations_channel_id: ""
+  triage_identity_user_id: "TRIAGE_IDENTITY_USER_ID"
+  # Server name from `pi mcp list`. Each action below is an exact Pi MCP tool name, mcp__<server>__<tool>.
+  mcp_server: "slack"
+  read_action: "mcp__slack__read-tool-placeholder"
+  thread_post_action: "mcp__slack__thread-post-tool-placeholder"
+  file_download_action: "mcp__slack__file-download-tool-placeholder"
+  operations_edit_action: "mcp__slack__edit-tool-placeholder"
+  # Use the Slack MCP tools before the optional bot token.
+  prefer_mcp_actions: true
+  optional_bot_token_env: "BENNY_SLACK_BOT_TOKEN"
+  allow_source_root_posts: false
+  allow_worker_slack_writes: false
+
+repository:
+  url: "https://github.com/example-org/example-repo"
+  default_branch: "main"
+  pull_request_action: "gh pr create --draft"
+  pull_request_url_format: "https://github.com/{owner}/{repo}/pull/{number}"
+  draft_only: true
+
+tracker:
+  type: "linear"
+  adapter_skill_name: "issue-tracker-adapter-placeholder"
+  team: "team-placeholder"
+  project: "project-placeholder"
+  labels:
+    bug: "bug-label-placeholder"
+    performance: "performance-label-placeholder"
+    intake: "intake-label-placeholder"
+    needs_repro: "needs-repro-label-placeholder"
+  status: "intake-status-placeholder"
+  source_link_title: "Slack report"
+  require_compensation_action: true
+
+routing:
+  map_path: ".pi/benny/routing.md"
+  owner_pings_default: false
+  allow_feature_owner_ping: false
+  allow_confirmed_regression_author_ping: false
+
+control:
+  skill_name: "control-target-app"
+  feature_map_path: ".pi/benny/feature-map.md"
+  environment: "safe-test-environment-placeholder"
+  artifact_directory: "/tmp/benny-artifacts"
+  artifact_retention_hours: 24
+
+verdict_markers:
+  bug: "[benny:bug]"
+  performance: "[benny:performance]"
+  other: "[benny:other]"
+  tracker_attribute: "tracker"
+
+status_emoji:
+  seen: "👀"
+  reproducing: "🔎"
+  reproduced: "✅"
+  could_not_reproduce: "⚪"
+  blocked: "⛔"
+  fixing: "🛠️"
+  fix_failed: "❌"
+  pull_request_opened: "🔗"
+
+budgets:
+  poll_seconds: 45
+  verdict_wait_minutes: 45
+  triage_follow_up_minutes: 10
+  triage_total_minutes: 30
+  repro_minutes: 60
+  rejection_window_minutes: 10
+  fix_minutes: 90
+  operations_follow_up_minutes: 45
+
+# Pi model specs from `pi --list-models`, such as provider/model:level. In both trigger modes, each fire's Task runs on
+# its automation's model: triage for benny-triage, reproduce for benny-reproduce.
+models:
+  triage: "choose-a-model-from-pi-list-models"
+  reproduce: "choose-a-model-from-pi-list-models"
+  code: "choose-a-model-from-pi-list-models"
+  media_review: "choose-a-model-from-pi-list-models"