Menu
Produce clear, actionable, reproducible bug reports. Use whenever a test fails or unexpected behavior is discovered during verification.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Execute implementation plans through small, verified steps — fighting the complexity explosion that AI-assisted development naturally produces. Use throughout the entire implementation process, from first line to last commit.
Systematically verify your own implementation through layered testing. Use after completing implementation tasks, before considering the work done.
Identify unvalidated technical assumptions in a design, research them against external sources (docs, APIs, community), and produce a feasibility verdict. Use after receiving requirements and before implementation planning, whenever the design depends on technologies, APIs, or platform capabilities you haven't verified.
Execute acceptance tests against completed implementation, run the full test suite, and produce a structured verification report. Use after Developer notifies implementation is complete.
Review implemented code for architectural compliance, detect entropy (bloat, duplication, boundary violations), and propose corrections. Use after Developer completes implementation, or periodically to audit codebase health.
Read and understand a codebase's architecture, modules, boundaries, and conventions. Use when onboarding to a new project, before designing any implementation, or when the codebase has evolved significantly since last review.
| name | bug-reporting |
| description | Produce clear, actionable, reproducible bug reports. Use whenever a test fails or unexpected behavior is discovered during verification. |
Write bug reports that are precise, reproducible, and actionable — so Developer can fix the issue without asking clarifying questions.
A bug you can't reproduce isn't a bug report — it's noise. A bug without context is a puzzle that wastes Developer's time. Every minute Developer spends understanding your report is a minute they're not fixing the bug.
The goal: Developer reads the report and immediately knows what's wrong, where to look, and how to verify the fix.
## Bug: [Short descriptive title]
**ID**: BUG-[number]
**Severity**: Critical | Major | Minor
**Requirement**: [which PRD requirement this violates, if applicable]
**Found in**: [acceptance test name / manual exploration]
### Environment
- [relevant environment details: OS, runtime version, config]
### Steps to Reproduce
1. [Precise first step — include exact commands, inputs, clicks]
2. [Second step]
3. [Third step]
### Expected Behavior
[What should happen according to the requirement/acceptance criteria]
### Actual Behavior
[What actually happened — be specific]
### Evidence
[Error output, log snippet, or test output]
### Notes
[Any additional context: does it happen consistently? any patterns?]