reproduce-and-fix-issues

Files (4)

• SKILL.md
• control-adapter.md · references/
• feature-map.example.md · references/
• verify-existing-fix.md · references/

SKILL.md (first lines)

# Reproduce and fix issues

Wait for a trusted triage marker in the source thread. Reproduce the exact symptom through the target app's real UI. Verify an existing fix when one exists. Attempt a bounded fix only after a confirmed repro.

Load the external Benny configuration supplied by the automation. If the config, required actions, control adapter, or completed feature map is missing, fail closed.

## Hard safety rules

- Freeze the source channel and root thread coordinates before doing any work.
- Never post a root message in the source channel.
- Preflight the source parent before every source-thread post.
- The coordinator is the only Slack poster.
- Delegated analysis workers are read-only and return findings or media notes.
- A fix-phase code worker may edit only when its environment provably excludes Slack credentials and every Slack write action. Otherwise the coordinator edits. A child bb thread on the same provider normally has the same Slack MCP tools, so treat its isolation as unproven unless setup verified otherwise.
- Every child prompt must explicitly forbid every Slack MCP write tool, `chat.postMessage`, and all other Slack writes.
- Never give a child a Slack token, posting instructions, source coordinates for posting, or permission to report externally.
- If a child needs Slack write access to run, do not launch it.
- Utility bots are evidence sources. They do not own the fix unless a person explicitly delegated the fix to them.
- The exact discriminating symptom must appear twice through real UI interaction.
- State inspection may confirm an observation. It must not inject or force the symptom.
- No confirmed repro means no authored fix.
- Existing pull requests or commits switch the run to verify mode. Do not author over them.
- Use `github.com` pull request links.
- Keep captures, recordings, logs, and tokens out of source control.
- Use pstack's `principle-guard-the-context-window` for delegated analysis.
- Apply pstack's `principle-sequence-verifiable-units`, `principle-fix-root-causes`, and `principle-prove-it-works` through repro, fix, and verification.

## 1. Select one report and freeze source coordinates

A bb automation starts this run on a schedule. There is no Slack event payload. Select the report yourself, and handle exactly one per run. Stay silent during selection.

The ledger at `state.ledger_path` is a tab-separated file with one row per event: UTC time, automation (`triage` or `reproduce`), source channel ID, root thread timestamp, and status. Never rewrite or delete rows. Create the file with no rows when it is missing.

1. Through the configured Slack read action, list top-level messages in the configured source channel posted within `schedule.lookback_hours`, oldest first.
2. Skip a message with any `reproduce` row in the ledger.
3. Read each remaining thread and look for a triage verdict that passes the checks in step 2 below.
4. No verdict yet: if the root is younger than `budgets.verdict_wait_minutes`, leave it for a later run. Otherwise append a `reproduce` row with status `no-verdict`.
5. An `other` marker, an untrusted author, or conflicting markers: append a `reproduce` row with status `skipped`.
6. Select the oldest message with a trusted `bug` or `performance` verdict. If none remains, stop with no posts.
7. Append a `reproduce` row with status `claimed`. Read the ledger again. If an earlier `reproduce` row exists for the same thread, another run owns it. Stop.

Before making a work list or delegating:

1. Require the selected message's channel to equal the configured source channel.
2. Set `SOURCE_THREAD_TS` to the selected message's `thread_ts` when present. Otherwise use its `ts`.
3. Require a nonempty `SOURCE_THREAD_TS`.
4. Store `SOURCE_CHANNEL_ID` and `SOURCE_THREAD_TS` as immutable values.
5. Read the source thread and verify its root has those exact coordinates.
6. Fetch the source permalink.

Never replace these values with a reply timestamp, operations timestamp, or status-message timestamp.

Before every source-channel post:

1. Read the thread by the immutable coordinates.
2. Confirm the parent exists, is not deleted, and still belongs to the source channel.
3. Send only with `channel=SOURCE_CHANNEL_ID` and `thread_ts=SOURCE_THREAD_TS`.
4. Read the thread again and verify the new message is a reply.

If any check fails, post nothing. Never retry at the root or in a fallback channel.

## 2. Check the triage contract

Waiting for the verdict happens across scheduled runs: step 1 leaves a report without a verdict for a later run until `budgets.verdict_wait_minutes` passes. Re-read the selected thread now and stay silent.

Accept a verdict only when:

- Its author matches `slack.triage_identity_user_id`.
- It is a reply under `SOURCE_THREAD_TS`.
- It contains exactly one configured marker.

Public marker forms:

```text
[benny:bug]
[benny:bug] tracker=https://tracker.example/issue/123
[benny:performance]
[benny:performance] tracker=https://tracker.example/issue/123
[benny:other]
```

Proceed only for `bug` or `performance`. Capture the optional tracker URL. Stop silently for `other`, a missing verdict, an untrusted author, conflicting markers, or a timeout, and record the reason in the ledger.

This marker replaces private bot identities and free-form verdict matching.

## 3. Apply ownership and fix-artifact gates

Re-read the thread immediately before starting work.

### Someone is explicitly fixing it

Stop when a person clearly claims the fix, gives a concrete implementation plan, or asks another agent to implement, patch, fix, or open a pull request.

Do not treat these as fix ownership:

- A bot summarizes evidence.
- A tool looks up logs or tickets.
- Someone asks a bot to diagnose, explain, inspect, or reproduce.
- A bot posts a cause hypothesis without agreeing to implement it.

Judge the requested action, not the presence of a bot.

### A fix artifact already exists

If an open pull request or merged commit plausibly fixes this report, switch to `references/verify-existing-fix.md`.

An artifact may come from the thread, tracker issue, repository history, or pull request search. A claim without a commit or pull request is not a fix artifact.

If a person owns the work but has not produced an artifact, stop. Do not race them.

## 4. Open an optional operations thread

If `slack.operations_channel_id` is configured, the coordinator may create one root status message there. This is the only allowed root post in the repro workflow.

Store its coordinates as `OPERATIONS_CHANNEL_ID` and `OPERATIONS_THREAD_TS`. Never confuse them with the source coordinates.

Use the configured plain Unicode status strings. Keep status text short:

- Reproducing

From rahmanramsi/bb-pstack-plugin, MIT.

More from rahmanramsi/bb-pstack-plugin