@shiwenbin1617/pstack 0.14.4

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.
+- Every child prompt must forbid `SendSlackMessage`, `PostToSlack`, `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 automation run output.
+
+## 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 `.claude/automations/benny/`, for example to `.claude/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,84 @@
+schema_version: 1
+
+automations:
+  triage_name: "benny-triage"
+  reproduce_name: "benny-reproduce"
+
+slack:
+  source_channel_id: "SOURCE_CHANNEL_ID"
+  operations_channel_id: ""
+  triage_identity_user_id: "TRIAGE_IDENTITY_USER_ID"
+  read_action: "configured-slack-read-action"
+  thread_post_action: "configured-slack-thread-post-action"
+  file_download_action: "configured-slack-file-download-action"
+  operations_edit_action: "configured-slack-edit-action"
+  prefer_cursor_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: "configured-draft-pull-request-action"
+  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: ".cursor/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: ".cursor/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
+
+models:
+  triage: "choose-an-available-public-model-slug"
+  reproduce: "choose-an-available-public-model-slug"
+  code: "choose-an-available-public-model-slug"
+  media_review: "choose-an-available-public-model-slug"

package/automations/benny/templates/reproduce-automation-prompt.md

@@ -0,0 +1,33 @@
+# Reproduce automation prompt
+
+> Source material for the copied setup workflow. Paraphrase this intent into a built-in `automate` draft after `automate` confirms that the copied pack is committed in the repository where the automation will run.
+
+Read and follow `.claude/automations/benny/skills/reproduce-and-fix-issues/SKILL.md` for this run.
+
+Configuration source. Include this repository-relative path only when it is committed in the same target repository. Otherwise paraphrase the configured values. Never use a plugin source or cache path:
+
+```text
+{{BENNY_CONFIG_PATH}}
+```
+
+Trigger:
+
+```json
+{
+	"source_channel_id": "{{SLACK_CHANNEL_ID}}",
+	"message_ts": "{{SLACK_MESSAGE_TS}}",
+	"thread_ts": "{{SLACK_THREAD_TS_OR_EMPTY}}"
+}
+```
+
+The creation intent should describe this as a new top-level report in the configured source Slack channel. It should include the configured repository, default branch, issue tracker, control adapter, feature map, and draft pull request capability.
+
+Treat the source channel and root thread timestamp as immutable. If either is missing or does not match configuration, stop without posting.
+
+Wait for a configured triage marker from the configured triage identity in this exact thread. Proceed only for `[benny:bug]` or `[benny:performance]`.
+
+Require the configured control-adapter skill before attempting a repro. Reproduce the exact discriminating symptom twice through the real UI. Verify existing pull requests or commits without authoring over them. Attempt a bounded fix only after a confirmed repro and the operational file's fix gate.
+
+The coordinator is the only Slack poster. Every child prompt must forbid `SendSlackMessage`, `PostToSlack`, `chat.postMessage`, and all other Slack writes. Children return findings only.
+
+Never post a root message in the source channel.

package/automations/benny/templates/triage-automation-prompt.md

@@ -0,0 +1,39 @@
+# Triage automation prompt
+
+> Source material for the copied setup workflow. Paraphrase this intent into a built-in `automate` draft after `automate` confirms that the copied pack is committed in the repository where the automation will run.
+
+Read and follow `.claude/automations/benny/skills/triage-issue-reports/SKILL.md` for this run.
+
+Configuration source. Include this repository-relative path only when it is committed in the same target repository. Otherwise paraphrase the configured values. Never use a plugin source or cache path:
+
+```text
+{{BENNY_CONFIG_PATH}}
+```
+
+Trigger:
+
+```json
+{
+	"source_channel_id": "{{SLACK_CHANNEL_ID}}",
+	"message_ts": "{{SLACK_MESSAGE_TS}}",
+	"thread_ts": "{{SLACK_THREAD_TS_OR_EMPTY}}"
+}
+```
+
+The creation intent should describe this as a new top-level report in the configured source Slack channel.
+
+Treat the source channel and root thread timestamp as immutable. If either is missing or does not match configuration, stop without posting or writing to the issue tracker.
+
+The committed operational file owns classification, attachment review, cause tracing, routing, dedupe, tracker writes, and the final verdict. Post no progress messages. Never post a root message in the source channel.
+
+The coordinator is the only Slack poster. Any delegated worker must be read-only, return findings only, and receive an explicit ban on every Slack write action.
+
+End the single verdict with exactly one configured marker:
+
+```text
+[benny:bug]
+[benny:performance]
+[benny:other]
+```
+
+A bug or performance marker may add `tracker=<URL>`.