The AI Feedback Loop Nobody Builds 🛠️

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.

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.

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.

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.

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:

• Cap it. Write the limit into the file itself: "Learned Rules never exceeds 15 items." When rule sixteen wants in, something has to leave. The cap is what forces the agent to decide what actually matters.
• Merge duplicates. "Keep the intro short" and "cut the opening to two sentences" are one rule wearing two outfits. Merge into the sharper wording and keep the newer date.
• Delete rules that stopped firing. If a pattern has not shown up in the last 8 diffs, it is done. Delete it. If it comes back, the loop catches it again. That is the whole point of a loop.
• Date every rule and prune on a schedule. Every 10 publishes, or monthly, whichever comes first. Nobody prunes voluntarily, so put it on the calendar.

One prompt runs the whole 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.

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.