# Recursive Improvement

> 재귀개선: N rounds of parallel critics → apply → verify.

- Skill: `wcpaka-lgtm/recursive-improvement` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add wcpaka-lgtm/recursive-improvement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wcpaka-lgtm/recursive-improvement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wcpaka-lgtm (https://skillmd.com/u/wcpaka-lgtm)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/wcpaka-lgtm/recursive-improvement

---


# Recursive Improvement (재귀개선)

Iterative self-improvement loop for a finished artifact (blog post, code, document). The user dictates the round count; each round runs 3 parallel critics, a cross-validation pass, an apply pass, and a playtest verification.

## When to Use
User says "재귀개선" / "재귀개선 시작해" / "한번돌려" / "N번돌려" — typically right after an artifact was produced (e.g. a blog post was published). Target = the artifact just produced; confirm if ambiguous.

## Protocol (user rules — do not skip)
- **Ask the loop count first** if not given: "몇 번 루프?" The user answers ("한번돌려" = 1 round, "3번" = 3 rounds). Never start without explicit instruction — this is a hard user rule.
- Run exactly N rounds, then stop. Offering "한 번 더 돌릴까?" at the end is fine; running extra rounds is not.
- Between phases, report in one concise line. Do not ask permission mid-round.
- Backup the original artifact before applying changes (user convention: `G:\...\NASfolder\Hermes\<task-subfolder>\`).

## One Round

### 1. Dispatch 3 parallel reviewers (delegate_task batch — 3 tasks, one per role)
Roles (rename per artifact class, keep the three axes):
1. **Fact/accuracy** — every number, date, name, quote, attribution vs a research brief; severity CRITICAL/MAJOR/MINOR; each issue = exact artifact quote + what's wrong/unsupported + precise fix.
2. **Style/tone** — against the user's voice rules (for blog posts: conversational blogger voice, NO AI patterns — no recap/TL;DR cards, no emoji ticker stat blocks, no corporate phrasing; honest caveats; restrained ending); concrete rewrites, never generic advice.
3. **Technical/platform** — the delivery constraints (for Blogger posts: zero `<script>`, self-contained card w/ own background, table cell borders, mobile overflow, well-formed HTML, escaped `<`/`&`).

Output contract for ALL reviewers: numbered list ordered by severity, each item = exact quote + problem + concrete fix. Explicitly forbid whole-artifact rewrites and out-of-role comments. Give each reviewer the file path, its criteria, the constraint list, and (for the fact role) the **fullest primary-source extracts you have** — see cross-validation.

Copy-paste prompt templates: `references/reviewer-prompts.md`.

### 2. Cross-validate (MANDATORY)
Reviewers working from condensed briefs produce false positives. In the first real run, **7 of 23 flagged items were false** — the claims were verbatim in primary sources the reviewer never saw (vendor press releases, official posts). For every flagged item:
- Claim exists in a primary source → **reject the flag with evidence** (quote the source line), keep the artifact as-is.
- Genuinely wrong/unsupported → apply the fix.
- Then reconcile the three reviews against each other (a tone reviewer may "fix" an accurate claim; a fact fix may break tone).

### 3. Apply
Rewrite the artifact file with all accepted fixes in one pass (cleaner than 15 small patches). Keep the rejected items intact.

### 4. Playtest verify
- **Structural**: parse the artifact programmatically (tag balance, no banned elements, image count, no raw unescaped `&`/`<` in text).
- **Assets**: every referenced URL returns 200 (GitHub raw URLs lag seconds after upload — verify via API first, retry the raw URL).
- **Live artifact**: after publishing/updating, confirm the changes actually landed — GET the live post and check marker strings from the new content (e.g. `"My read of the numbers" in content → True`) and the asset count. A green local file means nothing until the remote update is confirmed.

### 5. Report
Concise summary: reviewers run, fixes applied (grouped by area), false positives rejected with the reason, verification results, live link. A short table is fine.

## Pitfalls
- **False positives are the norm, not the exception.** The narrower the brief, the more primary-source-accurate claims get flagged. Cross-validation against the real source text is the step that makes the loop trustworthy — never apply reviewer output blindly.
- Tone reviewers will "smooth out" accurate technical claims; check their rewrites against facts before adopting.
- Don't merge reviewer text wholesale. Example: a tone reviewer wants a recap card removed — it may contain facts the fact-checker verified; preserve the facts, change only the form.
- Verify the LIVE artifact, not just the local file. Blogger PUTs silently clear fields (labels) when omitted — after any update, GET and confirm everything survived.
- Ask the loop count up front; one clarifying question at the start beats a wrong-size run.

## Related
- `subagent-driven-development` — same parallel-subagent family, but for executing implementation plans (implementer + spec/quality review); this skill is for improving an already-finished artifact in N rounds. Overlap noted for the curator; both can coexist.