bug-fix-planner
Bug Fix Planner
Plan the smallest credible fix for one specific defect.
Plan only. Do not edit files, apply patches, commit, or implement unless the user explicitly asks.
Goal
Give another engineer enough evidence and direction to fix the bug without rereading the conversation.
Success Criteria
- The broken behavior, expected behavior, impact, and affected area are clear.
- Important claims are classified as Confirmed, Likely, or Unknown.
- The plan traces the failing path in real code when repository access exists.
- The recommendation names one primary fix path, not a loose option list.
- Validation and acceptance criteria prove the original defect is gone.
Constraints
More from marcellocurto/skills
github-issue-create
Draft and create GitHub issues with `gh`. Use for bugs, tasks, features, PRDs, specs, epics, sub-issues, blockers, and tracer-bullet vertical issue breakdowns. Draft first. After approval, create issues and approved native GitHub relationships in the same turn.
11wild-frontend
Explicit-only skill for unconstrained, highly creative frontend design. Use only when the user explicitly says to use wild-frontend or asks to invoke this exact skill. Do not trigger automatically for normal frontend, styling, beautification, product UI, design-system, or production polish requests.
8design-system-ui
Design and implement polished frontend UI that feels native to the existing product, codebase, component library, and design system. Use for normal production frontend work where the result should extend real project patterns rather than invent a disconnected visual direction.
7relentless-review
Relentlessly stress-test proposals, plans, implementations, designs, strategies, or answers. Use when the user asks "is this actually the best we can do?", wants assumptions challenged, edge cases explored, failure modes examined, or asks to push harder, red-team, find holes, or be relentless. The answer may be that the current work is already the best path and should not change. Do not use for proofreading, encouragement-only feedback, minor style review, or requests where the user only wants implementation.
7test-quality-audit
Audit tests for real bug-finding value. Use when the user asks whether tests are useful, trivial, redundant, over-mocked, implementation-coupled, snapshot-heavy, coverage-padding, only passing because the test controls both sides, or whether tests should be kept, fixed, cut, or added. Also use when reviewing test changes in a PR and the user wants honest judgment about whether the tests earn their place.
7simplify-code-solution
Simplify code fixes and feature proposals by grounding them in real requirements and existing code. Use when a coding plan feels overbuilt, speculative, too abstract, or needs assumptions challenged before implementation.
6