driangle/ai-powers/fix-feedback

Fix Feedback

Address user feedback about a bug or feature issue using a test-first approach: first prove the problem exists with a failing test at the appropriate level, then fix it.

Input

Requires feedback in $ARGUMENTS — a bug report, user complaint, or description of unexpected behavior. Examples:

• /fix-feedback "clicking save twice creates duplicate entries"
• /fix-feedback "the CSV export drops rows with unicode characters"
• /fix-feedback "timeout option is ignored when retry is enabled"

Steps

Step 1: Understand the feedback

Read $ARGUMENTS and identify:

• What the reported behavior is
• Where in the codebase it likely originates
• What the expected behavior should be

Use Glob and Grep to locate the relevant code. Read the files to understand the current implementation.

Step 2: Find the existing test setup

Locate the project's test framework and existing tests for the affected code:

• Find test files near the relevant source files (e.g., *.test.ts, *_test.go, test_*.py, *_spec.rb)
• Identify the test runner, assertion style, and patterns used in the project
• Note how fixtures, mocks, and setup/teardown are handled

Match whatever conventions the project already uses.

Step 3: Write a failing test

Write a test that reproduces the reported issue at the appropriate level (unit, integration, or end-to-end — whichever best captures the problem):

• The test should encode the expected (correct) behavior described in the feedback
• It must fail against the current code — proving the bug exists
• Keep the test focused: one test, one assertion, targeting the specific issue
• Name the test descriptively so the feedback is obvious from the test name
• Choose the test level based on where the bug lives — a logic error in a pure function warrants a unit test; a broken interaction between components warrants an integration test

Step 4: Run the test — confirm it fails

Run the new test in isolation. It must fail.

• If it passes: the feedback may not be reproducible with the current code, or your test doesn't capture the issue correctly. Investigate further — re-read the feedback, check your assumptions, and adjust the test. Do not proceed until you have a genuinely failing test or have confirmed the issue is not reproducible.
• If it fails: proceed to the fix.

Step 5: Fix the issue

Make the minimal change needed to address the feedback:

• Fix the root cause, not just the symptom
• Avoid unrelated changes — keep the diff focused
• Preserve existing behavior for cases not described in the feedback

Step 6: Run the test — confirm it passes

Run the new test again. It must pass now.

If it still fails, revisit your fix and iterate until the test goes green.

Step 7: Run the full test suite

Run the project's full test suite (or the relevant subset) to check for regressions.

• If other tests break, fix them — your change should not degrade existing behavior
• If the suite was already broken before your change, note which failures are pre-existing

Step 8: Report

Summarize what you did:

• Feedback: one-line restatement of the issue
• Root cause: what was wrong and why
• Test added: file path and test name
• Fix: what you changed
• Regressions: none, or list any pre-existing failures