testing-cycle
Skill9 starsChanged 3 months agoMITView on GitHub
Process a single user testing feedback item — classify, fix or log, verify, and report.
In this repository56 other files it gives its agents.
- .claude/agents/CLAUDE.mdCLAUDE.md
- .claude/hooks/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- .claude/prompts/CLAUDE.mdCLAUDE.md
- .claude/rules/CLAUDE.mdCLAUDE.md
- .claude/skills/CLAUDE.mdCLAUDE.md
- docs/CLAUDE.mdCLAUDE.md
- vision/CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- scaffold/llms.txtllms.txt
- architecture-checkSkill
- backlog-reviewSkill
- bootstrapSkill
- brainstormSkill
- buildSkill
- claude-sense-checkSkill
- code-qualitySkill
- commitSkill
- continueSkill
- custom-hooksSkill
- dashboardSkill
- debug-sessionSkill
- deploySkill
- discoverSkill
- doctorSkill
- fix-issueSkill
- framework-upgradeSkill
- handoffSkill
- help-meSkill
- ideateSkill
- lanesSkill
- manual-testSkill
- merge-downSkill
- merge-upSkill
- optimizeSkill
- parallel-workSkill
- performance-checkSkill
- phase-reviewSkill
- pr-statusSkill
- quality-checkSkill
- quickstartSkill
- refine-loopSkill
- researchSkill
- retrospectiveSkill
- security-auditSkill
- skill-createSkill
- skill-evalSkill
- sprint-endSkill
- sprint-startSkill
- story-cycleSkill
- test-validatorSkill
- UAT-cycleSkill
- undo-workSkill
- uninstallSkill
- weekly-maintenanceSkill
- wrap-upSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 16 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈16
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 40
Wait for user confirmation.
- Distinctive: line 47
Search for related files using the feedback keywords
- Distinctive: line 48
Read the relevant source files
- Distinctive: line 49
Check if there's an existing test covering this behavior
- Distinctive: line 51
If a test exists but tests the wrong thing → fix the test first (it should now fail)
- Distinctive: line 52
If no test exists → write a failing test that captures the bug
- Distinctive: line 53
Run the test to confirm it fails
- Distinctive: line 55
Verify tests pass: Run the project's test command (from CLAUDE.md)
- Distinctive: line 63
Add test: only if the behavior is non-trivial or regression-prone
- Distinctive: line 76
Add the story section (use next available story number)
- Distinctive: line 77
Update the summary table
- Very specific: line 97
If fixing now: implement, test, commit as feat(scope): or fix(scope):
- Distinctive: line 98
If deferring: log to backlog and report
- Distinctive: line 102
After any code change:
- Distinctive: line 104
Run the project's test command (from CLAUDE.md) to verify all tests pass
- Distinctive: line 105
If the app is running, ask the user: "Can you verify this in the running app?"
- Distinctive: line 106
If tests fail, fix the issue before proceeding
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

