iterate-skill

name: iterate-skill description: Run the Logic-Lens skill-improvement loop end to end — baseline → diagnose failures → edit → sync cache → re-eval → verify net gain → iterate until clean. Use whenever the goal is to RAISE a skill's eval score or fix a failing eval mode: "improve logic-review", "the format compliance is failing, fix it", "iterate on this skill until the evals pass", "raise the score", "re-run the loop on the latest failures", "run another iteration", "tune the skill description / disambiguation table against the evals". Also use to RESUME a prior loop ("continue improving from where we left off", "do another pass", "iterate further"). Do NOT use for: a one-off question about a skill, shipping a release (use bump-version), or scaffolding a brand-new skill (use new-skill). disable-model-invocation: true

iterate-skill — the Logic-Lens improvement loop

This is the harness orchestrator. It coordinates three agents and two support skills into one deterministic loop that raises a skill's eval score without overfitting or grader-gaming.

Execution mode: sub-agent pipeline (generate → test → verify). Each step's output is the next step's input, handed off through the filesystem (skills-workspace/iteration-<TAG>/) and agent return values. There is no peer-to-peer team chatter, so agents are spawned via the Agent tool — always with model: "opus", and subagent_type set to the agent's own definition name (e.g. subagent_type: "skill-editor"), not "general-purpose" — passing general-purpose would discard the role/principles in .claude/agents/<name>.md, defeating the harness. Agents return results to this orchestrator, which owns state and the ship/rollback decisions.

Agents (who) — all in .claude/agents/, spawn by these exact subagent_type names:

Support skills (how): sync-skill-cache (mandatory pre-eval gate), run-iteration-eval (run + grade).

Phase 0 — context check (initial / resume / partial)

Determine the run mode before doing anything:

• ls -dt skills-workspace/iteration-*/ — if recent iterations exist and the user asks to "continue" or "another pass" → resume: use the latest as baseline, skip re-baselining.
• User provides a fresh target skill / new failure → initial: establish a baseline first (Phase 1).
• User asks to redo just one mode or one skill → partial: scope the eval to the affected case IDs.

Confirm the target skill (which of the six logic-*) and the failing mode with the user if ambiguous — do not guess which skill to mutate.

Phase 1 — baseline

If no usable baseline exists for the target: run the run-iteration-eval skill (sync cache, then a full or mode-scoped run) to get summary.json. This is the number every later iteration is judged against. Record its TAG.

Phase 2 — diagnose

Spawn eval-failure-analyzer (Agent, model: "opus") pointed at the baseline iteration dir. It returns the prioritized failure modes, the exact failing eval IDs, and concrete edit proposals. Pick the single highest (failure-count × ease-of-fix) mode for this iteration. One mode per iteration — batching edits makes the verify step unable to attribute a regression.

Phase 3 — edit

Spawn skill-editor (Agent, model: "opus") with the chosen proposal. It applies one minimal, generalized edit and reports what it touched + its risk note. If it refuses (the proposal needs a grader/assertion change), drop that proposal and pick another mode — never relax the grader.

Phase 4 — sync cache (gate)

Run sync-skill-cache. If it reports DRIFT or a missing cache, stop the loop and surface it — an unsynced eval grades stale content and wastes the run. Do not proceed to Phase 5 until it prints OK.

Phase 5 — re-eval

Run run-iteration-eval scoped to the affected mode's case IDs (cheap) for a fast read; widen to a full run before a final SHIP decision. New summary.json, new TAG.

Phase 6 — verify

Spawn iteration-guard (Agent, model: "opus") with the baseline and candidate iteration dirs + the editor's risk note. Act on its verdict:

• SHIP → keep the edit; the candidate becomes the new baseline.
• ROLLBACK → revert the edit (it named which one); baseline unchanged.
• RERUN → the move is inside variance; rerun the affected cases 2–3× (Phase 5) and re-verify before deciding.

Phase 7 — iterate or report

If SHIP and more modes remain and the score isn't at target → loop back to Phase 2 on the next mode. Otherwise produce the 迭代报告 (in 简体中文): baseline→final overall + logic/format subscores, the per-iteration Fix Log (mode, edit, verdict), and any mode left unresolved with why.

After reporting, offer Phase 7 evolution (harness skill): if the same failure mode recurs across loops, or the editor keeps refusing the same proposal, propose a harness change (a new disambiguation rule in the editor's principles, a new agent) and log it in CLAUDE.md's 변경 이력.

Data-passing protocol

• File-based (durable handoff): all run artifacts live in skills-workspace/iteration-<TAG>/; agents read these dirs directly. Never delete a prior iteration dir — it is the rollback reference and the audit trail.
• Return-value based (control flow): each agent returns its report to this orchestrator, which decides the next step. Agents do not call each other.

Error handling

1-retry then proceed-with-note. Specifically:

• Cache sync fails → hard stop (never eval stale content). Report and fix the cache, don't skip.
• An eval case errors (claude call fails) → the runner isolates it; re-run just that case once, then proceed and note the missing case in the report rather than blocking the whole loop.
• Guard says RERUN repeatedly (persistent variance) → report the move as "within noise floor, inconclusive" rather than forcing a SHIP/ROLLBACK; widen the case set instead of trusting one run.
• Conflicting signals (logic up, format down) → do not average them away; report both subscores with their sources and let the user weigh, per the project's "logic = primary / format = gate" split.

테스트 시나리오

정상 흐름: User: "logic-review 的 format compliance 一直挂，迭代修一下。" → Phase 0 initial → Phase 1 baseline (format subscore low) → analyzer flags the format-label mode + eval IDs → editor sharpens the literal label in the SKILL.md skeleton → sync OK → re-eval affected cases → guard: format up, logic flat, no collateral → SHIP → report with before/after subscores.

에러 흐름: Editor's proposed fix requires loosening a grader assertion → editor refuses in Phase 3 → orchestrator drops that proposal, picks the next mode from the analyzer's list, and continues — the grader is never touched. If instead the cache sync prints DRIFT in Phase 4, the loop halts and reports the drift before spending any eval tokens.