
After studying this material, you should be able to:
Imagine a team where an expert writes a brilliant code review comment. That comment helps one person. Then it disappears forever.
The next contributor makes the exact same mistake. Another expert writes the exact same comment. This repeats indefinitely.
Contributor A → Makes mistake → Expert reviews → Wisdom evaporates
Contributor B → Makes same mistake → Expert reviews → Wisdom evaporates
Contributor C → Makes same mistake → Expert reviews → Wisdom evaporates
The key insight from the article:
Repeated review comments are not really comments anymore — they are undocumented requirements
When the same guidance appears frequently enough, it no longer belongs in a human review. It belongs inside the system itself.
Why this is architectural, not a tooling problem:
The article describes a repeatable architecture built on three moves. Think of it as a cycle:
┌─────────────────────────────────────────────────────┐
│ │
│ GENERATE → REVIEW → COLLECT SIGNAL → IMPROVE │
│ ↑ │ │
│ └────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────┘
Move 1: Build a generator
Create an AI that produces structured, verifiable output. In the article's example, this was creating-sf-skill — a meta-skill that generates complete skill directories with consistent formatting, naming conventions, and file structure.
Move 2: Measure quality with a layered evaluation framework You need to prove the system is improving before you can improve it.
Move 3: Feed review signal back automatically Close the loop by mining human feedback and updating the generator's instructions.
This is the measurement engine. Each tier catches failures the others cannot.
| What it tests | Does the generated artifact activate correctly in a realistic environment? |
|---|---|
| Method | 20 queries tested: 10 that should trigger, 10 that should not |
| Environment | 80+ competing skills active simultaneously |
| Graded by | Independent AI subagents |
| Catches | "Looks great on paper, never works in practice" |
Why this matters first: If the output doesn't function correctly in a crowded real environment, nothing else matters. You cannot skip to quality if the basics fail.
| What it tests | Mechanical, objective correctness |
|---|---|
| Method | Same CI validation script used in production (21 rules) |
| Examples | Kebab-case naming, frontmatter format, description length, version format |
| Result | Binary pass/fail — no ambiguity |
| Catches | Structural violations that would block a real pull request |
Key principle: Use scripts for everything that has an objectively correct answer. This is pure determinism — no judgment required.
| What it tests | Meaning, clarity, and contextual quality |
|---|---|
| Method | LLM agents grade output on multiple dimensions |
| Examples | Clarity of constraints, quality of instructions, appropriate scope |
| Catches | Technically valid but semantically poor output |
The holistic principle the article establishes:
Deterministic validation → measures what is objectively verifiable
LLM judgment → measures what requires context and understanding
Neither replaces the other — they answer different questions
Now you can measure quality. But how do you actually improve the generator automatically?
Gate conditions (must both be true before running):
Why 15 PRs minimum? Fewer than that risks overfitting to one reviewer's personal style rather than community consensus.
Step 1: SCAN
Collect all review comments from merged PRs in the window
Step 2: SYNTHESIZE
Identify patterns — which comments appeared repeatedly?
(A comment appearing once = personal preference)
(A comment appearing 5+ times = undocumented requirement)
Step 3: ISOLATE GAPS
Separate patterns into: structural gaps vs. semantic gaps
Step 4: UPDATE
Rewrite the generator's instructions to encode the pattern
Step 5: VALIDATE
Run the three-tier framework on new output
Only merge if all tiers pass
How do you know the loop is working?
Track frequency of repeated comment patterns across cycles:
Cycle 1: Pattern X appears in 5 PRs → Loop encodes it
Cycle 2: Pattern X appears in 0 PRs → Loop worked ✓
The decline in repeat comments is the measurement of success.
This is the most counterintuitive part. Most people assume self-improving systems mutate forever. This one does not.
Generator improves
→ Produces fewer mistakes
→ Reviewers write fewer comments
→ Less signal per cycle
→ Smaller changes applied
→ System stabilizes
This is not a bug. It is the designed behavior.
| Cycle | What happened | Significance |
|---|---|---|
| Cycle 1 | 3 high-frequency patterns fixed — missing scope rules, hardcoded names, tool-specific language | Core structural gaps |
| Cycles 2–5 | Mix of improvements and aborted runs | Progressively smaller changes |
| Cycle 6 | Only peripheral files edited (best_practices.md, pr_checklist.md) — SKILL.md untouched | Core had stabilized |
| 3 of 6 cycles | Aborted — insufficient new signal | Convergence achieved |
The system literally ran out of things to fix. That is what success looks like.
Convergence is conditional, not permanent.
Standards change
→ Generator's instructions become stale
→ Reviewers flag the same new issue repeatedly
→ Frequency spike crosses threshold
→ Loop restarts automatically
→ System re-converges at new equilibrium
The article demonstrates this with a real example: frontmatter conventions changed, 5 PRs flagged the same stale guidance in one window, the loop corrected itself without human intervention.
The architecture is domain-agnostic. The article demonstrates this by applying it to an automated code reviewer bot.
Same three moves, different signal source:
| Element | Skill Generator | Code Reviewer Bot |
|---|---|---|
| Generator | Creates skill directories | Reviews pull requests |
| Signal source | Human comments on generated skills | Human reactions to bot suggestions |
| What gets mined | Repeated structural/semantic gaps | Which suggestions were accepted vs. disputed |
| What improves | Generator's instructions | Bot's best practices and severity calibration |
The pattern held. First cycle produced four improvements to the bot's reference files and severity calibration.
Before implementing this, verify all three conditions hold:
PREREQUISITE CHECK
├── Enough review volume? (15+ per cycle)
├── Structured output? (mechanical + semantic dimensions)
└── Real review culture? (genuine feedback, not rubber stamps)
IF YES → BUILD THE LOOP
GENERATOR produces structured artifacts
↓
REVIEWERS provide feedback (signal)
↓
LOOP (weekly, gated):
Scan → Synthesize → Isolate gaps → Update → Validate
↓
THREE-TIER EVALUATION confirms improvement:
Tier 1: Activation (does it work?)
Tier 2: Deterministic (does it follow rules?)
Tier 3: Semantic (is it actually good?)
↓
CONVERGENCE: fewer comments → smaller changes → stability
↓
RESTART when standards shift (frequency spike = new signal)
The end state: Reviewer wisdom stops evaporating into forgotten comments. It accumulates automatically into the system that produces the next artifact. Every participant in the review process makes the system better — without anyone doing extra work.