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.