iterative-refinement
Skill2 starsChanged 10 days agoMITView on GitHub
Execute iterative refinement workflows with validation loops until quality criteria are met. Use this skill when running test-fix cycles, code quality improvement, performance optimization, or any task requiring repeated action-validate-improve cycles — even if they just say "keep improving until it passes" or "iterate on this". Not for testing-strategy.
In this repository63 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .agents/skills/avoid-ai-writing/AGENTS.mdAGENTS.md
- .agents/skills/do-web-doc-resolver/AGENTS.mdAGENTS.md
- .agents/skills/skill-evaluator/AGENTS.mdAGENTS.md
- scripts/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms-full.txtllms.txt
- llms.txtllms.txt
- accessibility-auditorSkill
- agent-browserSkill
- agentic-abstentionSkill
- agents-mdSkill
- api-design-firstSkill
- architecture-diagramSkill
- avoid-ai-writingSkill
- cicd-pipelineSkill
- cloudflare-worker-apiSkill
- codacySkill
- codeberg-apiSkill
- code-review-assistantSkill
- css-render-performanceSkill
- database-devopsSkill
- debuggerSkill
- delegateSkill
- dependency-upgradesSkill
- dist-channel-selectionSkill
- docs-hookSkill
- document-rendering-and-locatorsSkill
- dogfoodSkill
- dora-reportSkill
- do-web-doc-resolverSkill
- durable-objectsSkill
- eu-ai-act-complianceSkill
- git-github-workflowSkill
- goap-agentSkill
- implementerSkill
- intent-classifierSkill
- jules-delegatorSkill
- learnSkill
- lifecycle-managementSkill
- local-context-sanitizationSkill
- memory-contextSkill
- migration-refactoringSkill
- nested-build-isolationSkill
- privacy-firstSkill
- progressive-deliverySkill
- pwa-offline-syncSkill
- reader-ui-uxSkill
- readme-best-practicesSkill
- secrets-managementSkill
- secure-invite-and-accessSkill
- security-code-auditorSkill
- shell-script-qualitySkill
- skill-creatorSkill
- skill-evaluatorSkill
- static-analysisSkill
- testing-strategySkill
- test-runnerSkill
- triz-solverSkill
- turso-dbSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Use for tasks requiring iterative refinement:
- Distinctive: line 16
Test-fix-validate cycles: Fix failures → retest → repeat until passing
- Distinctive: line 21
Don't use for single-pass tasks, purely parallel work, or simple linear workflows.
- Distinctive: line 25
Before starting iterations, consider researching current best practices, known issues, optimal configurations, or recent alternatives for …
- Distinctive: line 76
All criteria met? → SUCCESS
- Distinctive: line 93
If no progress for 2-3 iterations:
- Distinctive: line 97
Stop if truly stuck
- Distinctive: line 123
Prefer scripts/tools over manual inspection:
- Distinctive: line 124
Test frameworks over reading test code
≈ “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
Iterative Refinement
Execute workflows iteratively with systematic validation, progress tracking, and intelligent termination.
When to Use
Use for tasks requiring iterative refinement:
- Test-fix-validate cycles: Fix failures → retest → repeat until passing
- Code quality improvement: Review → fix → review until standards met
- Performance optimization: Profile → optimize → measure until targets achieved
- Progressive enhancement: Iterative improvements until diminishing returns
Don't use for single-pass tasks, purely parallel work, or simple linear workflows.
Pre-Usage Research (Optional)
Before starting iterations, consider researching current best practices, known issues, optimal configurations, or recent alternatives for your validation tools.
Research first when: unfamiliar tools, new tech stack, complex quality criteria, or high-stakes optimization.
Core Loop Pattern
Every iteration follows:
- Execute action (fix, optimize, improve)
- Validate result (test, measure, check)
- Assess progress (compare to criteria)
- Decide (continue or stop)
Instructions
Step 1: Define Configuration
Establish before starting:
Success Criteria (specific and measurable):
- Criterion 1: [Example: "All 50 tests passing"]
- Criterion 2: [Example: "Zero linter warnings"]
- Criterion 3: [Example: "Response time < 100ms"]
Loop Limits:
- Max iterations: 5-15 (justify if >20)
- Min iterations: (optional)
Termination Mode:
- Fixed: Run exactly N iterations
- Criteria: Stop when success criteria met
- Convergence: Stop when improvements < threshold (e.g., <10% over 3 iterations)
- Hybrid: Combine multiple conditions
Step 2: Execute Iteration
For each iteration:
- Take action - Apply fixes or implement changes
- Run validator - Execute tests, linters, or measurements
Record progress:
Iteration N: - Action: [what was done] - Results: [metrics/outcomes] - Issues remaining: [count/description] - Decision: [Continue/Success/Stop]- Assess termination:
- All criteria met? → SUCCESS
- Improvement < threshold? → CONVERGED
- Reached max iterations? → STOP
- Otherwise → CONTINUE
Step 3: Pass Context Between Iterations
Each iteration needs:
- Previous results
- Current metrics
- Remaining issues
- Progress trend
This prevents repeating failed approaches.
Step 4: Handle Stuck States
If no progress for 2-3 iterations:
- Analyze why progress stopped
- Try different approach
- Consider manual intervention
- Stop if truly stuck
Step 5: Report Results
Loop Summary:
- Iterations: N
- Termination: [Success/Converged/Max/Stuck]
- Initial state: [metrics]
- Final state: [metrics]
- Improvement: [percentage/delta]
- Remaining issues: [list if any]Validation Best Practices
Make Validators Specific
Bad: "Check if code is better" Good: "Run linter and count warnings"
Bad: "See if it's faster" Good: "Run benchmark: average response time over 100 requests"
Use Automated Validation
Prefer scripts/tools over manual inspection:
- Test frameworks over reading test code
- Linters over manual code review
- Benchmarks over estimated performance
- Coverage tools over counting tests
Capture Concrete Metrics
Track measurable progress:
- Test pass rate: 42/50 → 48/50 → 50/50
- Warning count: 23 → 8 → 2 → 0
- Response time: 320ms → 180ms → 95ms → 48ms
- Code coverage: 65% → 78% → 85% → 92%
Examples
Example 1: Test Fixing
Task: Fix all failing tests
Configuration:
- Success: 100% tests passing
- Max iterations: 8
Execution:
I1: 42/50 → Fix 8 failures → Continue
I2: 48/50 → Fix 2 failures → Continue
I3: 50/50 → SUCCESS ✓Example 2: Linter Cleanup
Task: Remove all linter warnings
Configuration:
- Success: 0 warnings
- Max iterations: 5
Execution:
I1: 15 warnings → Fix → 6 warnings
I2: 6 warnings → Fix → 1 warning
I3: 1 warning → Fix → 0 warnings ✓Example 3: Performance Loop
Task: Optimize response time
Configuration:
- Success: <50ms OR converged
- Max iterations: 15
- Convergence: <10% over 3 iterations
Execution:
I1: 320ms → Optimize → 180ms (44%)
I2: 180ms → Optimize → 95ms (47%)
I3: 95ms → Optimize → 48ms (49%)
SUCCESS (target met)Example 4: Coverage Improvement
Task: Increase test coverage to 90%
Configuration:
- Success: Coverage ≥ 90%
- Max iterations: 12
Execution:
I1: 65% → Write tests → 72%
I2: 72% → Write tests → 81%
I3: 81% → Write tests → 88%
I4: 88% → Write tests → 91% ✓Best Practices
DO:
✓ Define clear, measurable success criteria ✓ Set reasonable max limits (5-15) ✓ Use automated validators ✓ Pass context between iterations ✓ Track concrete metrics ✓ Stop early when criteria met ✓ Detect convergence ✓ Document changes
DON'T:
✗ Use loops for single-pass tasks ✗ Set high limits (>20) without justification ✗ Skip validation between iterations ✗ Lose context between iterations ✗ Continue after success/convergence ✗ Ignore stuck signals ✗ Use vague criteria ✗ Miss early termination
See Also
test-runner— Execute tests and diagnose failurestesting-strategy— Choose testing approaches
Rationalizations
| Rationalization | Reality |
| "I'll just keep iterating until it works" | Unbounded loops waste compute; define clear stop criteria before starting. |
| "The metrics are close enough" | Close enough is not passing; vague criteria hide incomplete work. |
| "Manual validation is faster than writing a test" | Manual checks don't repeat; automated validators catch regressions in future iterations. |
Red Flags
- Running more than 15 iterations without convergence or re-evaluation
- Skipping validator execution between iterations
- Losing context from previous iterations leading to repeated failed approaches
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.

