openwork
DocsDownloadEnterprise
GitHub 15.3K
Open in OpenWork
Bug Reporter Fbkb43re1
bug-reporter-fbkb43re1.md
---
name: bug-reporter-fbkb43re1
description: 'Turn a bug into a short, evidence-backed report with exact repro
  steps, clear expected vs actual behavior, and optional GitHub filing. Triggers
  when user mentions: - "report a bug" - "write a bug report" - "open a GitHub
  issue for this bug"'
---
## Goal

Write bug reports that are short, specific, and easy to fix.
Prioritize exact symptoms, exact repro steps, exact expected vs actual behavior, and direct evidence.
Do not add filler, long background, or speculative root cause.

## Required Fields

Always collect or confirm:
- title
- summary
- steps to reproduce
- expected behavior
- actual behavior

Optional fields:
- assignee: Ask the user if they want to assign themselves or someone else in the team to fix it.
- project: default to `https://github.com/orgs/different-ai/projects/3` unless the user says otherwise

## Process

1. Intake the bug.
   - Ask only for missing fields.
   - If the bug is visible in UI or terminal output, ask for a screenshot or other direct evidence.
   - If evidence is unavailable, continue and note that it was not provided.

2. Tighten the wording.
   - Use exact UI labels, error strings, status names, and messages when available.
   - Make `Expected behavior` and `Actual behavior` clearly different.
   - Keep the summary to one or two sentences.

3. Find likely code touchpoints.
   - Search the workspace for the likely components, handlers, commands, or services.
   - Identify 1-5 likely affected functions or entry points.
   - Keep file references precise.
   - Include only tiny snippets when they materially clarify the bug.

4. Gather evidence across the factory.
   - Check submodules or nearby repos when relevant.
   - Check `openwork` explicitly when present.
   - If `FACTORY_ROOT` is configured, use it to look for related repos.
   - Keep only the strongest evidence.

5. Confirm a compact draft.
   - Show the issue title and body.
   - Note screenshot/evidence status.
   - Note assignee and project.
   - Do not open the issue until the user confirms or asks.

## Intake Prompt

Use this only when core fields are missing:

```text
Please help me pin this down:
1. Summary
2. Steps to reproduce
3. Expected behavior
4. Actual behavior
```

## Confirmation Draft

Confirm the report in this format:

```markdown
**Title:** [Bug]: <title>

**Summary:** *
<What went wrong?>

**Steps to reproduce:** *
1. ...
2. ...
3. ...

**Expected behavior:** *
<description>

**Actual behavior:** *
<description>

---
Label: bug
```

## Filing Rules

After the user confirms they are aligned with the bug report.

When filing:
- set the GitHub issue title to `[Bug]: <title>`
- use the template body exactly
- add the `bug` label if possible

If the repo is unclear, infer it from the current git remote or ask one targeted question.

## Rules

- Be precise.
- Be brief.
- Prefer exact strings over paraphrases.
- Do not claim root cause unless the code strongly supports it.
- Do not paste large code blocks into the issue.
- Skip extra sections unless they help someone fix the bug faster.
3096 characters