bereniketech/iterative-refinement

Iterative Refinement

1. The Loop

Output received
    ↓
Is it good enough? ──Yes──→ Lock it in (update skill / CLAUDE.md)
    ↓ No
Specify exactly what's wrong (don't just say "bad")
    ↓
Request a different approach (not just "try again")
    ↓
Repeat

Rule: Never accept "okay." Push for dramatically better. Claude often produces its best output on the second or third attempt when given a precise critique.

2. Rejection Prompts That Work

Instead of: "That's not quite right, try again."

Use targeted critiques:

• "Scrap that. The structure is too verbose — do a version that's 50% shorter with the same coverage."
• "This isn't good enough. The naming is inconsistent with the rest of the codebase. Redo it following the pattern in src/utils/."
• "Wrong approach entirely. Instead of X, try Y. Show me a version that uses that pattern."
• "The logic is correct but it'll confuse any reader. Rewrite it so the intent is obvious without comments."

3. Specifying What's Wrong

A good critique names:

1. The specific flaw — not "bad" but "the function does too much"
2. The standard it should meet — "each function should have one responsibility"
3. A concrete direction — "split it into 3 functions: validate, transform, persist"

4. Locking In the Improvement

Once you get an output that clears the bar:

1. If it revealed a pattern Claude was missing → update the relevant SKILL.md
2. If it corrected a recurring mistake → add a Rule: line to the skill
3. If it was a project-specific discovery → note it in CLAUDE.md or a context file

Rule: Improvements only compound if they're persisted. An iterative win that isn't written down gets repeated next session.

5. Stopping Point

Stop iterating when:

• The output meets the stated requirement with no obvious gaps
• Further changes would be diminishing returns (style preferences, not correctness)
• You've done 3+ rounds and the flaw is ambiguous — at that point, clarify the requirement instead of re-prompting