The AI Feedback
Loop Nobody Builds

A skill that gets smarter every time you use it. Almost nobody sets this up.

Here’s the loop. Your skill writes a draft. You edit and publish. Then you hand the published version back and make it compare the two, pull out the edits that will happen again, and write those rules into its own instructions. The actual file that tells it how to work, not a memory it might forget.

Your final edit is the answer key. What you decided was good enough to ship is the one piece of evidence that can’t be argued with.

I run this on the email agent for my clothing brand. It drafts, my team edits, we send, then the agent reads the sent version against its draft. Two months in, the drafts need a lot less work. It works on anything a person edits before it goes out, like a newsletter, proposals, product descriptions, job posts or ad copy.

Two minutes, once. This runs in Claude Code, because the agent needs to read your files and edit its own skill.

The file. A skill is a text file named SKILL.md in its own folder, either personal (~/.claude/skills/newsletter/SKILL.md, available everywhere) or in the project (.claude/skills/newsletter/SKILL.md, shared with your team). Claude Code watches those folders, so an edited skill takes effect in the session you’re already in. One catch: if the skills folder didn’t exist when you started the session, run /reload-skills once. (Claude Code docs) Never built a skill? Start with 3 Ways To Build A Claude Skill.

The folders. Make drafts/ and published/ in your project. Every piece gets the same filename in both, a date then a short slug, like drafts/2026-11-01-welcome-email.md and published/2026-11-01-welcome-email.md. Matching names is how the agent finds the pair.

Expect three to eight rules on the first run, and most will be right, because your edits are more consistent than you think. The next thing you ask it to write already follows the new rules. Reading the proposed rules and cutting the bad ones takes thirty seconds and is the only quality control this loop has, so don’t skip it.

This quietly kills these loops. Month one you have six sharp rules and better drafts. Month four you have sixty, some repeat, two contradict each other, and the output is worse than it was at rule fifteen. A learning loop with no pruning is a hoarding loop.

• Cap it. Write the limit into the file: "Learned Rules never exceeds 15 items." When rule sixteen wants in, something has to leave.
• Merge duplicates. "Keep the intro short" and "cut the opening to two sentences" are one rule. Keep the sharper wording and the newer date.
• Delete rules that stopped firing. If a pattern hasn’t shown up in the last 8 pairs, delete it. If it comes back, the loop catches it again.
• Prune on a schedule. Every 10 publishes or monthly, whichever comes first. Put it on the calendar.

One prompt runs the whole prune pass:

1. Pick the piece you edit the hardest. Whatever you rewrite the most is where the most learning is sitting.
2. Make drafts/ and published/, and copy the skill out of any plugin into ~/.claude/skills/.
3. Save the next draft before anyone edits it. This is the step you’ll forget, so set a reminder.
4. Publish like normal, then paste the final version into published/ with the matching filename.
5. Run the engine prompt and cut the rules you disagree with. Do it four times before you judge it.

Almost nobody has this running because the edit feels finished the moment you hit publish. Every edit you make is training data, and right now you’re throwing it away. For the theory underneath, Loop Engineering covers what a loop actually is.