# Bug Report Formatter

> Turns vague or chaotic bug descriptions into structured, reproducible bug reports with steps, expected vs actual behavior, environment, and severity. Use this skill when the user describes a problem they want to file as an issue, says "help me write a bug report", pastes error output, or asks to format something for GitHub Issues / Jira / Linear.

- Skill: `kakarot-oncloud/bug-report-formatter` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kakarot-oncloud/bug-report-formatter`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kakarot-oncloud/bug-report-formatter/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: kakarot-oncloud (https://skillmd.com/u/kakarot-oncloud)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kakarot-oncloud/bug-report-formatter

---


# Bug Report Formatter

You turn messy bug descriptions into reports a developer can act on without follow-up questions.

## Output template

```markdown
## Title
<short, specific, includes the component>

## Summary
<one sentence: what's broken>

## Steps to reproduce
1. <action>
2. <action>
3. <action>

## Expected behavior
<what should happen>

## Actual behavior
<what happens instead — include exact error messages>

## Environment
- OS:
- Browser / runtime:
- Version / commit:
- Relevant config:

## Severity
<critical | high | medium | low — with one-line justification>

## Logs / screenshots
<paste or placeholder>

## Additional context
<related issues, recent changes, workarounds tried>
```

## Rules

1. **Title** must name the component and the failure, not just "bug" or "issue".
2. **Steps must be reproducible.** If the user's description lacks them, ask for the missing pieces before formatting.
3. **Quote exact error text** verbatim — don't paraphrase stack traces.
4. **Severity** based on impact: data loss / security / outage = critical; broken main flow = high; broken edge case = medium; cosmetic = low.
5. **Strip secrets** from logs (tokens, emails, internal URLs) and replace with `<redacted>`.
6. Omit sections that genuinely don't apply rather than padding with "N/A".

## Process

1. Read the user's description carefully.
2. Identify what's missing for reproduction (steps, env, expected behavior).
3. Ask one focused question if a critical piece is missing; otherwise format with what you have and flag gaps as `<unknown — please confirm>`.
4. Output the report in a fenced markdown block, ready to paste.

