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)
- 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
- 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
- Fix the code: Make the minimal change to fix the bug
- Verify tests pass: Run the project's test command (from CLAUDE.md)
- Ask user to verify: "Can you verify this fix in the running app?"
- Commit:
fix(scope): description
Bug (Minor)
- Identify the issue in code
- Fix the code (minimal change)
- Add test only if the behavior is non-trivial or regression-prone
- Run the project's test command
- Commit:
fix(scope): description
Gap
- Document the gap clearly
- Write a user story with:
- Type, estimated effort
- Description explaining what's missing and why it matters
- INVEST-style acceptance criteria
- Technical notes if relevant
- Add to the appropriate backlog file in
docs/reference/backlog/:- Add the story section (use next available story number)
- Update the summary table
- Update
docs/reference/BACKLOG_INDEX.mdif a new story was added - Do NOT implement — this is scope control
- Report what was logged
Test Correction
- Find the problematic test
- Understand the correct behavior from user feedback
- Fix the test to match correct behavior
- Run the corrected test — if it now fails, also fix the code
- Run the project's test command
- Commit:
test(scope): correct [description](addfixprefix if code also changed)
Enhancement
- Evaluate scope:
- Trivial (< 10 lines, obvious improvement) → ask user if should fix now
- Larger → create backlog story (same process as Gap)
- Act accordingly:
- If fixing now: implement, test, commit as
feat(scope):orfix(scope): - If deferring: log to backlog and report
- If fixing now: implement, test, commit as
Phase 3: Verify
After any code change:
- Run the project's test command (from CLAUDE.md) to verify all tests pass
- If the app is running, ask the user: "Can you verify this in the running app?"
- If tests fail, fix the issue before proceeding
Phase 4: Report
Present a summary:
### Feedback Processed
**Feedback:** [original feedback]
**Classification:** [type]
**Action taken:** [what was done]
**Files modified:** [list of files]
**Tests:** [added/modified/none] — tests [pass/fail]
**Commit:** [hash and message] (or "logged to backlog as [story-ID]" for gaps)
Ready for next feedback item (`/testing-cycle <feedback>`) or finish testing.