testing-cycle

name	testing-cycle
version	2.4.0
description	Process a single user testing feedback item — classify, fix or log, verify, and report.
trigger	manual
depends-on	[]
references	[]
disable-model-invocation	true
user-invocable	true
allowed-tools	Read, Glob, Grep, Bash, Edit, Write
argument-hint	<feedback-description>

---

testing-cycle

Processing feedback: $ARGUMENTS

Phase 1: Classify Feedback

Analyze the feedback and assign a classification:

Type	Indicators	Effort
Bug (Critical)	Functionality broken, crash, data loss, core feature	High
Bug (Minor)	UI glitch, cosmetic, edge case, non-blocking	Low
Gap	Missing feature, expected capability not implemented	Backlog
Test Correction	Automated test tests wrong behavior, false positive	Medium
Enhancement	UX improvement, better wording, nice-to-have	Varies

Present the classification to the user for confirmation before proceeding.

Show:

• Feedback: (original, quoted)
• Classification: [type]
• Rationale: (why this classification)
• Proposed action: (what will be done)

Wait for user confirmation. They may reclassify.

Phase 2: Act by Type

Bug (Critical)

1. Investigate: Find relevant code, understand the root cause
   • Search for related files using the feedback keywords
   • Read the relevant source files
   • Check if there's an existing test covering this behavior
2. Test first:
   • If a test exists but tests the wrong thing → fix the test first (it should now fail)
   • If no test exists → write a failing test that captures the bug
   • Run the test to confirm it fails
3. Fix the code: Make the minimal change to fix the bug
4. Verify tests pass: Run the project's test command (from CLAUDE.md)
5. Ask user to verify: "Can you verify this fix in the running app?"
6. Commit: fix(scope): description

Bug (Minor)

1. Identify the issue in code
2. Fix the code (minimal change)
3. Add test only if the behavior is non-trivial or regression-prone