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.

Want to try it?

Ask your Strawberry companion: “Research this product problem, check the relevant team and code context, search our actual ticketing system for duplicates, and prepare or file a grounded issue within the current permission.”

Skill

Research and report a bug

Research unexpected behavior, find the relevant team and code context, search for duplicates, and prepare or file a grounded issue within scope.

Gather the context that could change the report

ContextWhat it can add
Slack or TeamsPrior reports, customer impact, workarounds, decisions, owners, and unresolved questions.
GitHub and recent changesAffected components, related pull requests, release timing, regression range, and code-owner context.
Logs, monitoring, console, and networkErrors, failed requests, timing, frequency, and environment-specific evidence.
The team's ticketing systemExisting 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.

Skill

Audit a product flow

Run a broader or proactive flow audit when the team needs passes, regressions, and browser evidence beyond one reported bug.

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.

Official Strawberry skill
Copy skill file Download skill file
name
research-and-report-a-bug
description
Research unexpected product behavior, reproduce it when safe, inspect approved Slack or Teams discussion, GitHub context, recent changes, logs, monitoring, existing issues, and the team's actual ticketing system, then prepare or file a grounded deduplicated issue according to current scoped permissions.

Research and Report a Bug

Turn a product problem into a grounded issue the team can act on. Research enough context to avoid a thin report or a duplicate, but do not require every possible system before producing useful work.

1. Understand the report and the desired action

Establish the symptom, expected behavior, user impact, environment, account or role, version when known, frequency, timing, affected scope, and any reproduction evidence already available. Infer details from screenshots, URLs, messages, recordings, logs, and product context when reliable instead of making the reporter repeat them.

Clarify whether the user wants research, a draft issue, issue creation, or research followed by a code fix. Find the team's actual ticketing system, project, issue type, template, severity scale, labels, and ownership conventions rather than assuming a particular vendor.

2. Research the context that can change the issue

Use approved sources selectively:

  • Slack or Teams discussion for customer impact, timing, prior investigation, and ownership;
  • GitHub for relevant repositories, code context, recent changes, pull requests, release history, and existing issues;
  • the team's ticketing system for duplicates, linked work, templates, severity, and current state;
  • logs, monitoring, analytics, support records, screenshots, or recordings for supporting evidence; and
  • the product itself for safe reproduction and environment details.

Match people, accounts, repositories, builds, and tickets carefully. Preserve source links or record identifiers. Keep secrets, tokens, private messages, and customer data out of the issue; summarize or redact sensitive evidence when the team still needs the finding.

3. Reproduce and narrow the behavior

Reproduce the problem end to end when practical and safe. Prefer staging, preview environments, or dedicated test accounts for authenticated or stateful paths. On a public live site, perform read-only inspection unless Strawberry has active scoped permission for the exact state-changing action, account, data, and conditions.

Record the smallest reliable steps, expected and observed result, environment, version, account role, test data, frequency, screenshots, and relevant console or network evidence. Recheck a failure when safe. Distinguish confirmed behavior, suspected regression range, likely component, and unverified root-cause hypothesis.

If reproduction is not possible, assemble the strongest evidence chain available and state the limitation rather than fabricating steps.

4. Search for the existing issue

Search the actual ticketing system and relevant GitHub issues using the symptom, error text, affected flow, component, version, and likely synonyms. Compare behavior, environment, scope, and status before declaring a duplicate.

If a matching issue exists, return the match and the new evidence worth adding. Updating, commenting on, or reopening that issue is a separate external action governed by the current scoped permission. Do not file a second issue merely to complete the workflow.

5. Prepare the report

Create a concise issue with the team's accepted format. Include what is useful:

  • a clear title and user impact;
  • environment, version, account role, scope, and frequency;
  • minimal reproduction steps;
  • expected and observed behavior;
  • screenshots, logs, console or network evidence, and source links;
  • severity or priority using the team's definitions;
  • duplicate search and related work;
  • suspected area or regression range, clearly labeled as inference;
  • acceptance or verification notes; and
  • uncertainty, privacy-safe evidence gaps, and cleanup state.

Keep solution ideas separate from confirmed cause. A good bug report is actionable without pretending the investigation is complete.

6. Draft or file within the current permission

Follow Strawberry's active scoped permission for the exact ticketing account, project, issue type, fields, destination, and action. If it covers creation under the current conditions, create the issue and verify its identifier, URL, fields, and attachments. If it does not, return a reviewable draft or ask for the missing approval.

Stop when identity, repository, environment, account, project, scope, impact, or sensitive-data handling changes. Batch findings remain a reviewable set until filing scope is clear.

This skill does not limit what a capable companion may do next. If the user also asks for a fix, the companion can continue through the available coding workflow under the normal repository, change, validation, and permission boundaries. Preserve the issue evidence so implementation and verification remain connected to the reported behavior.