loop-creator

> **Versioning.** Any change to this skill or `references/loop-engineering.md` > bumps `version` (patch=wording, minor=new guard, major=restructure) + a > `CHANGELOG.md` entry. Every per-loop journal entry stamps `skill vX.Y.Z` so > fire outcomes ↔ skill version stay correlatable. Re-evaluation triggers: > ~100 accumulated fires / new primary research / a repeated failure class > (contract §6). History: [`CHANGELOG.md`](CHANGELOG.md). # loop-creator — 원칙을 지키는 자율 루프를 생성하고 등록한다 ## Overview 한 번 호출하면 끝까지: **테마를 받아 → 계약을 채워 → 재귀 fire-프롬프트 생성 → cron 등록 → 멈추는 법 보고.** 계약 본체는 [`loop-engineering.md`](references/loop-engineering.md). 이 스킬은 그 계약의 *적용기*다 — 단일 슬라이스 빌드는 하지 않는다(그건 루프가 돌며 한다). v3.x의 설계 원칙(2026-07-18 재조사로 재확인, 계약 §5·§7): **결정론 검증이 1차, LLM은 절대 단독으로 "완료"를 판정하지 않는다 · maker≠judge fresh-context · 하드 예산/반복 상한 · 디스크가 상태(fire = fresh context, Ralph 패턴) · 오너의 강조가 우선순위를 지배한다.** 가드는 실측(489-fire 마이닝 + 검증된 공개 연구)이 지탱하는 것만 남긴다 — 가드 자체가 토큰 비용이므로. ## 입력 해석 - **테마**: 주어진 그대로. **오너-강조 우선(하드 룰)** — 진안이 강조한 주 트랙이 fire-프롬프트 ②의 1순위에 *그대로* 박히고, 보조 범주(인프라·신뢰성·주변 결함)는 "주 트랙을 직접 막거나 self-eval 회귀일 때만"으로 명시 격하된다. (실측 미스에서 각인: fire가 '가치 휴리스틱'으로 오너의 명시 강조를 이기면 안 된다 — v2.1.1.) - **간격**: 주어진 값, 없으면 20m. **티어**: 기본 Tier1(로컬 커밋). push 신호가 있으면 Tier2(브랜치+draft PR) 또는 Tier2+(main push — 진안의 명시 승인 문구를 프롬프트에 그대로 인용해 박는다). - 테마가 없으면 스킬의 1번 작업이 "무엇을 할지 알아내기"다(§1의 gap-scout). - 모호한 포크 1-질문은 **등록 단계에서만** 허용. 등록 후 무인 fire는 절대 질문하지 않는다. ## 파이프라인 ### §1 DECIDE — 기준선·연료·동시성 1. `pnpm self-eval` — non-ze...