Try this skill in Strawberry
A useful bug report connects what the user saw to the environment, expected behavior, reproduction, impact, recent changes, related discussion, and the team's existing issue history. Without that chain, the ticket often sends Engineering back to repeat the investigation.
Strawberry can reproduce the behavior in the browser and, when approved, inspect Slack or Teams discussion, GitHub context and recent changes, logs, existing issues, and the team's actual ticketing system. Your companion can search for duplicates and preserve uncertainty without inventing a root cause.
Start with the observed behavior
Capture what happened, what was expected, the user impact, environment, version, account role, frequency, scope, time, and evidence already available. Establish expected behavior from an accepted product source when possible; otherwise label the requirement gap.
Gather the context that could change the report
| Context | What it can add |
|---|---|
| Slack or Teams | Prior reports, customer impact, workarounds, decisions, owners, and unresolved questions. |
| GitHub and recent changes | Affected components, related pull requests, release timing, regression range, and code-owner context. |
| Logs, monitoring, console, and network | Errors, failed requests, timing, frequency, and environment-specific evidence. |
| The team's ticketing system | Existing issues, current status, accepted fields, severity definitions, and the real project or destination. |
Use only approved sources that could materially improve the report. Keep private customer data, secrets, internal discussion, and repository context within their permitted boundaries; redact evidence when the ticket has a wider audience.
Reproduce and narrow the behavior
Reproduce the smallest safe path in the appropriate environment. Record exact steps, starting state, expected and observed behavior, evidence, frequency, and cleanup. Compare a nearby control path or prior version when that can isolate the changed condition.
Distinguish a confirmed behavior, likely affected component, suspected regression range, and unverified root-cause hypothesis. If reproduction is not possible, provide the strongest evidence chain available and say what is missing.
/audit-a-product-flow Search before filing
Search the actual ticketing system and relevant GitHub issues using the symptom, error text, flow, component, version, and likely synonyms. Compare behavior, environment, scope, and status before declaring a duplicate.
When a matching issue exists, return the match and the new evidence worth adding. Commenting, updating, reopening, or changing priority is a separate action; do not create a second issue merely to complete the workflow.
Prepare or file the grounded issue
- A clear title and user impact.
- Environment, version, account role, scope, and frequency.
- Minimal reproduction steps and starting state.
- Expected and observed behavior.
- Privacy-safe screenshots, logs, browser evidence, and source links.
- Severity or priority using the team's definitions.
- Duplicate search, related work, suspected area, and regression range, with inference labeled.
- Acceptance or verification notes, evidence gaps, uncertainty, and cleanup state.
Create the issue only when active permission covers the exact ticketing account, project, issue type, fields, destination, and action. Otherwise return a reviewable draft or ask. Verify the identifier, URL, fields, and attachments after filing.
The report does not end the work. If the user also requests a fix, the companion can continue through the available coding workflow under the normal repository, change, review, validation, and permission boundaries while preserving the original issue evidence.