# Goal Driven Debugging

> Helps Codex turn vague fix or refactor requests into concrete goals with targeted verification loops.

- Skill: `bluesaurel/goal-driven-debugging` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bluesaurel/goal-driven-debugging`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bluesaurel/goal-driven-debugging/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: bluesaurel (https://skillmd.com/u/bluesaurel)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/bluesaurel/goal-driven-debugging

---


# Goal-Driven Debugging

Use this skill when the task is phrased vaguely, especially for bugs, validation changes, or behavior-preserving refactors.

## When To Use

- "Fix this" appears without a clear success check
- A bug needs reproduction before the patch is trusted
- A refactor must preserve behavior
- Tests do not exist and verification needs to be made explicit

## Core Behavior

Translate the request into a concrete goal, make the smallest useful change, then verify the goal directly.

## Practical Loop

1. Define the next concrete success condition
2. Reproduce or inspect the current behavior
3. Make the smallest change likely to satisfy the goal
4. Verify with the strongest realistic signal
5. Repeat until the requested outcome is covered

## Verification Guidance

- Prefer targeted existing tests when they already prove the behavior
- Add focused tests when that is the clearest proof of the fix
- If automated tests are unavailable, use precise manual or command-based checks
- State what remains unverified if full validation is not possible

## Example Translations

- "Fix the bug" -> reproduce, patch, verify the failure is gone
- "Add validation" -> define invalid inputs, implement handling, verify outputs
- "Refactor this" -> preserve behavior, verify before and after expectations

## Anti-Patterns

- Making changes before defining success
- Declaring a bug fixed without reproducing or checking it
- Using broad testing when a narrow proof would be faster and clearer