triage-issue-reports

Files (2)

• SKILL.md
• routing.example.md · references/

SKILL.md (first lines)

# 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.
- Every child prompt must forbid every Slack MCP write tool, `chat.postMessage`, and every other Slack write.
- If worker isolation cannot enforce those limits, do the work in the coordinator. 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.
- 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. 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.

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 posted by the triage identity.
3. Skip a message whose thread already has a reply from the triage identity.
4. Skip a message with any `triage` row in the ledger.
5. Select the oldest remaining message. If none remains, stop with no posts, no tracker writes, and no ledger row.
6. Append a `triage` row with status `claimed`. Read the ledger again. If an earlier `triage` row exists for the same thread, another run owns it. Stop.

Before making a work list or delegating:

1. Read `source_channel_id` from the selected message.
2. Require it to equal the configured source channel.
3. Set `SOURCE_THREAD_TS` to the selected message's `thread_ts` when present. Otherwise use its `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.

From rahmanramsi/bb-pstack-plugin, MIT.

More from rahmanramsi/bb-pstack-plugin