Bug Report

# Bug Report

Take a messy text dump (Slack thread, support ticket, console log,
verbal complaint) and produce a structured bug report a developer can
actually triage.

## When to use

Use this skill when the user:
- Pastes a customer complaint and asks "file a bug for this"
- Says "structure this as a bug report"
- Has a thread of messages and needs a single ticket

## Inputs

A blob of text containing some subset of:
- Symptom description
- Steps the user took
- Error messages / stack traces / screenshots described in words
- Environment info (browser, OS, version)
- Severity hints

## Output format

```markdown
### Title

<5–10 words: <component>: <symptom>>

### Severity

<Critical | High | Medium | Low> — <one-line justification>

### Summary

<1–2 sentence description of the problem in user-visible terms>

### Steps to reproduce

1. <action>
2. <action>
3. <action>

### Expected behavior

<what should happen>

### Actual behavior

<what actually happens, with quoted error message if available>

### Environment

- App / version: <…>
- Browser / OS: <…>
- Account / org: <…> (if relevant)
- First seen: <date or "unknown">

### Additional context

- <log line, screenshot reference, or related ticket>
```

## Process

1. Read the dump. Identify the **symptom** — the one specific thing that
   breaks. Don't conflate two bugs into one.
2. Write the **title** as `<component>: <symptom>`. Examples:
   - "Login: 500 error when email contains '+'"
   - "Skills marketplace: detail page 404s for slugs with capital letters"
3. Pick **severity**:
   - **Critical**: production down, data loss, security
   - **High**: core feature broken, common path
   - **Medium**: feature broken on a sub-path or edge case
   - **Low**: cosmetic, rare, easy workaround
4. Extract **steps to reproduce**. If steps aren't in the input, say
   "Steps: not provided — needs reporter follow-up." Don't fabricate.
5. Quote the error message verbatim if present. Wrap in a code block.
6. Capture environment from the input or mark `unknown`.

## Disambiguation

- If the dump describes two bugs, file two reports. Note the linkage.
- If the input is "X is broken" with no detail, the structured report
  should reflect that — most fields will be `unknown` and the dev will
  push back. That's correct.

## Example

**Input:**
> Hey, I keep getting a 500 when I try to log in. It started yesterday I
> think. Email is sam+work@example.com. Chrome on Mac. Says something
> about "internal server error".

**Output:**
```markdown
### Title

Login: 500 error when email contains '+'

### Severity

High — blocks login for a known segment of users (anyone using "plus
addressing").

### Summary

Login attempts with an email containing a `+` character return a 500
Internal Server Error. Affects at least one user, possibly all users
with plus-addressed emails.

### Steps to reproduce

1. Go to /login
2. Enter email `sam+work@example.com` and a valid password
3. Submit

### Expected behavior

User is logged in (or sees a normal "wrong password" error if creds are bad).

### Actual behavior

Server returns 500 Internal Server Error.

> "internal server error"

### Environment

- Browser / OS: Chrome on macOS
- First seen: ~2025-03-09 (per reporter "yesterday")
- Account: sam+work@example.com

### Additional context

- Reporter is on the Pro plan (verify in admin)
- Suggests a URL-encoding or email-parsing bug; check the auth handler's
  email normalization step.
```

## Hard rules

- Never invent steps, environment info, or stack traces.
- Always assign severity. "TBD" is not an option — a dev will skip it.
- Never put a customer's name or PII in the title or summary unless the
  ticket explicitly requires it.
- Title must be ≤ 80 chars and start with the component.