Save This

The AI Feedback
Loop Nobody Builds

Your AI writes a draft. You make your final edits. You publish. Then the lesson dies and next week it makes the same mistake. This is the setup that makes your skill compare its draft to your final version, pull the rules out of your edits, and write them into its own instructions, so it gets smarter every time you use it.

A skill that gets smarter every single time you use it. That is the whole idea, and almost nobody sets it up.

Here is the loop in one sentence. Your skill writes a draft. You make your final edits 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 straight into its own instructions. Not a memory it might forget. The actual file that tells it how to work.

That last part is the whole thing. Your final edit is the answer key, and the lesson gets written into the skill file after every publish. The one piece of evidence that cannot be argued with is what you decided was good enough to ship.

The Loop, At A Glance

1.  Your skill runs and hands you a draft.

2.  You make your final edits and publish.

3.  The agent compares its draft to your final version.

4.  The edits that will repeat get written into SKILL.md.

5.  The next run starts smarter. Then it all repeats.

↻ Every publish makes the instructions better

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. You do not need a brand to do this. It works on a newsletter, client proposals, product descriptions, job posts, or ad copy, anything a person edits before it goes out.

Why This Beats "Review Your Own Draft"

Asking a model to critique its own work sounds like the same thing. It is not. A model grading itself grades against its own taste, and its taste is the thing that was wrong. Your edit is outside evidence. It does not care what the model thinks is good.

SetupTwo Folders And One File

Two minutes, once. Then you never think about it again.

The file. A skill is a plain 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). The one fact that makes a per-publish loop possible: Claude Code watches that folder live, so an edited skill takes effect in the session you are already in. No restart. Never built one? 3 Ways To Build A Claude Skill is the two-minute first build.

The folders. Make two of them in your project: drafts/ and published/. Every piece gets the same filename in both, a date then a short slug, so drafts/2026-07-19-welcome-email.md and later published/2026-07-19-welcome-email.md. Matching names is how the agent finds the pair without you explaining anything.

Do This Before Anything Else

If the skill came from a plugin, copy it into ~/.claude/skills/ first and work on your copy. Skip this and the next plugin update wipes the cache and every rule your loop ever learned is gone, with no warning. Copy it first.

The LoopThree Moves, Every Publish

Move One

Save the raw draft, before anyone edits it

The moment the agent finishes, that draft has to land in a file, not the chat and not the doc you are about to edit. You cannot compare two versions if you only kept one. The whole value of this loop is the gap between what the machine produced and what you decided to ship, so save the raw output, typos and all.

Add one line to the bottom of your skill file so it happens on its own: "When you finish a draft, save it to drafts/ as YYYY-MM-DD-slug.md before showing it to me."

Move Two

Save what actually shipped

After it goes out, copy the exact final version, including any last-second change someone made in the email tool at 11pm, and paste it into published/ with the matching filename. Thirty seconds, no clever tooling.

Move Three

Run the engine

One prompt does the rest. It reads both versions, lists what changed, keeps only the edits that will happen again, and writes them into your skill file as rules, after you approve them. Paste it, swap the two file paths, and change nothing else the first few times you run it.

The Engine Prompt
Compare two versions of the same piece and turn the edits into rules. DRAFT, what you wrote: drafts/2026-07-19-welcome-email.md PUBLISHED, what we sent: published/2026-07-19-welcome-email.md SKILL FILE: ~/.claude/skills/newsletter/SKILL.md Work in this order and do not skip ahead. 1. Read both files all the way through. If almost nothing changed, say so and stop. A piece that shipped 95 percent intact has nothing to teach. 2. List every difference. For each one give me the draft version quoted exactly, the published version quoted exactly, and one type: FACT, TONE, STRUCTURE, LENGTH, FORMATTING, or MISSED (something required that was left out of the draft). 3. Sort each difference into REPEATABLE or ONE-OFF. REPEATABLE means a person would make this same edit again on the next piece of this type. ONE-OFF means it was about this one piece, this one week, this one promotion. When you cannot tell, mark it ONE-OFF. Being wrong that way costs nothing. Being wrong the other way puts a permanent bad rule in my instructions. 4. Write each REPEATABLE edit as an instruction, not an observation. "Be more concise" is useless. "Cut the opening to two sentences, never three" is a rule. Each one must be specific enough that a freelancer could follow it on the first try without asking me. 5. Show me the proposed rules and STOP. Let me delete the ones I disagree with before you touch any file. 6. Once I approve, add them to the skill file under a heading called "## Learned Rules" near the bottom. Never touch the frontmatter or my original instructions, only that section. Each rule is one line, in this shape: - [YYYY-MM-DD] RULE: (the instruction) | WHY: (the edit that taught it) If a new rule repeats one already there, sharpen the existing one and update its date instead of adding a duplicate.

You will get three to eight rules on the first run, and most will be right, because your edits are more consistent than you think. Because the skills folder is watched live, the very next thing you ask it to write already follows the new rules. No restart, no waiting for Monday. That thirty seconds of reading the proposed rules and cutting the ones you disagree with is the only quality control this loop has, so do not skip it.

MaintainKeep The File From Getting Fat

This is the part that quietly kills these loops, and nobody warns you. Month one it is beautiful: six sharp rules, better drafts. Month four you have sixty rules, some say the same thing twice, two flatly contradict each other, and the output is worse than it was at rule fifteen. A learning loop with no pruning is just a hoarding loop.

Four habits keep it lean, and you need all four:

One prompt runs the whole prune pass:

The Prune Pass
Run a prune pass on my skill file. FILE: ~/.claude/skills/newsletter/SKILL.md CAP: 15 rules under "## Learned Rules" 1. List every rule with its date and how old it is, and the total count against the cap. 2. DUPLICATES. Group rules that would produce the same edit, even if worded differently. Propose one merged rule per group, sharpest wording, newest date. 3. CONTRADICTIONS. Show any pair of rules that cannot both be followed at once. Do not resolve them yourself, ask me which wins. 4. DEAD RULES. Read the last 8 pairs in drafts/ and published/. For each rule, tell me whether that pattern actually showed up in any of those 8. If it did not appear once, mark it DEAD and propose deleting it. 5. VAGUE RULES. Flag any rule with "better", "more", "less", or "as needed" in it, the kind a new freelancer could not follow. Rewrite it as something specific, or propose deleting it. 6. If the list is still over the cap, rank the survivors by how often the pattern appeared in the last 8 diffs and show me the bottom 5. Show me the whole plan before you change one line. I approve, then you edit.

The One Test For Every Rule

Could a freelancer who started this morning follow it without asking a question? "Be more concise" fails. "Product descriptions are 40 words or fewer" passes. And if you cannot read your whole Learned Rules list out loud in under a minute, the agent is not really following it either. Fifteen sharp rules beat sixty fuzzy ones, and it is not close.

StartRun It Once This Week

You do not need a new project. You need one thing you already publish on a schedule and already edit before it goes out.

  1. Pick the piece you edit the hardest. Newsletter, proposals, product descriptions, ad copy. 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/ so updates cannot wipe it.
  3. Save the next draft before anyone edits it. This is the step you will forget. Set a reminder if you have to.
  4. Publish like normal, then paste the final version into published/ with the matching filename.
  5. Run the engine prompt, cut the rules you disagree with, and let it write the rest into the file. Do it four times before you judge it. One run tells you nothing.

The reason almost nobody has this running is not that it is hard. It is that the edit feels finished the moment you hit publish. It is not. Every edit you make is training data, and right now you are throwing all of it away. For the theory underneath it, Loop Engineering covers what a loop actually is.

If You Commented IMPROVE

This is the whole setup. Two folders, one skill file, two prompts, and a prune pass on the calendar. No code, no new subscription. Save your next draft before anyone touches it. That single habit is what turns your edits into instructions instead of into nothing.

© 2026 Mariah Brunner. All rights reserved.