goal-loop

name

goal-loop

description

목표(goal)를 프롬프트로 받으면, 매 루프마다 최신 기술 동향을 web_search/web_fetch로 조사하고 그 결과로 작업 프롬프트를 스스로 개선하면서 목표가 달성될 때까지 자율적으로 반복 실행하는 KernForge 내장 스킬. 사용자가 "이 목표 달성될 때까지 알아서 반복해줘", "스스로 프롬프트 개선하면서 끝까지 해줘", "자가 개선 루프 돌려줘", "목표 달성할 때까지 자율로 진행", "self-improving loop", "iterate until it works", "keep improving the prompt until the goal is met" 같이 말하거나, 한 번에 끝나지 않고 조사-개선-재시도를 반복해야 하는 열린(open-ended) 목표를 줄 때 사용한다. 단발성 질문이나 단순 1회 작업에는 쓰지 않는다.

goal-loop — 자가 개선 목표 달성 루프 (KernForge 내장)

사용자가 준 목표를, "웹 조사 → 프롬프트 개선 → 실행 → 평가"를 목표 달성까지 반복하며 스스로 몰아붙여 끝내는 내장 스킬이다.

핵심 철학: 첫 프롬프트는 거의 항상 최적이 아니다. 매 루프마다 최신 동향을 조사해 프롬프트를 다시 쓰고, 직전 실패에서 배운 것을 반영해 수렴시킨다. 사용자는 루프를 감독하지 않는다 — 안전한 결정은 스스로 내리고, 위험한 결정에서만 멈춘다.

KernForge 도구 매핑

이 스킬은 KernForge 네이티브 도구만 쓴다.

• 웹 조사: web_search(쿼리 검색), web_fetch(URL 본문 읽기).
• 분리 조사: spawn_task(경계가 있는 read-only 조사 서브태스크; read_file/grep/list_files/lsp_nav만 가능), 상태/결과 회수는 get_task, 열거는 list_tasks, 취소는 cancel_task. 서브태스크는 파일을 편집하거나 셸을 실행할 수 없다 — 조사·분석 전용이다.
• 실행 산출물: read_file/write_file/replace_in_file/apply_patch로 코드·문서를 만든다. 빌드·테스트 검증은 run_shell(장기 작업은 run_shell_background).
• 상태 파일: 워크스페이스의 .kernforge/goal-loop/state.md에 기록한다(아래 "상태 추적").

이미 /goal 명령이 durable-state 자율 루프 러너를 제공한다. 이 스킬은 그 위에서 "매 루프 웹 조사로 프롬프트를 재작성한다"는 방법론을 얹는 것이다. 사용자가 지속 추적을 원하면 /goal --run으로 목표를 등록해 병행할 수 있다.

언제 이 루프를 쓰나

• 목표가 열려 있고(open-ended) 한 번에 끝나지 않는다: "탐지율을 최대한 끌어올려", "이 우회 기법에 대응하는 방어를 완성해줘".
• 최신 기술 동향이 결과 품질을 좌우한다: 안티치트 우회/방어, 커널 텔레메트리, TPM 검증 등 빠르게 변하는 영역.
• 사용자가 반복적 자율 실행을 명시적으로 요청했다.

단순 1회 질의응답, 이미 정답이 정해진 기계적 작업에는 쓰지 않는다.

전체 흐름

[0] 목표 파싱 + 성공 기준 확정        (첫 루프에서 1회)
        |
        v
[1] 웹 조사 (매 루프 필수)  --->  [2] 프롬프트 개선  --->  [3] 실행  --->  [4] 평가
        ^                                                                     |
        |___________________ 목표 미달 & 진전 있음 __________________________|
        |
        v
[5] 종료 (목표 달성 / 정체 / 상한 도달) --> 최종 보고

[0] 목표 파싱과 성공 기준 확정 (첫 루프에서 1회)

루프를 돌리기 전에 "무엇이 달성이냐"를 먼저 못 박는다. 이게 없으면 루프가 영원히 끝나지 않거나, 애매하게 끝난다.

1. 사용자 프롬프트에서 **목표(goal)**를 뽑는다.
2. 목표를 **측정 가능한 성공 기준(success criteria)**으로 번역한다. 가능하면 정량으로.
   • 나쁨: "탐지를 잘하게" → 좋음: "샘플 우회 기법 N종 중 M종 이상 탐지, 오탐 X% 이하, 빌드/테스트 통과".
   • 정량이 불가능하면 검증 가능한 체크리스트로: "재현 코드가 컴파일된다 / 문서화된 방어가 실제 API에 매핑된다 / 근거 출처가 6개월 이내".
3. 제약과 종료 조건을 명시한다: 최대 루프 수(기본 8), 정체 판정 기준(연속 2루프 진전 없음), 명백한 안전 경계.
4. 이 내용을 상태 파일에 기록한다(아래 "상태 추적" 참고).

성공 기준이 사용자 프롬프트만으로 확정 불가능하고, 그 모호함이 결과를 크게 바꾼다면 — 그때만 한 번 질문한다. 그 외에는 합리적 기준을 스스로 정하고 상태 파일에 "가정(assumption)"으로 남긴 뒤 진행한다.

[1] 웹 조사 — 매 루프 필수, 생략 금지

이 스킬의 심장이다. 모든 루프는 반드시 새로운 웹 조사로 시작한다. 조사 없이 프롬프트를 바꾸지 않는다.

• web_search로 목표와 **현재 막힌 지점(직전 루프의 gap)**에 대한 최신 자료를 찾는다. 검색어는 매 루프 달라야 한다 — 직전 평가에서 드러난 구체적 실패를 검색어에 반영한다.
• 유망한 출처는 web_fetch로 실제 내용을 읽는다. 제목/스니펫만 믿지 않는다.
• 최신성을 우선한다: 가능하면 최근 자료, 버전·빌드 번호·CVE·API 변경 등 날짜가 박힌 사실을 수집한다. 오래된 기법이면 "현재도 유효한가"를 확인한다.
• 조사 결과를 3~6개의 실행 가능한 인사이트로 압축한다. 각 인사이트에 출처와 날짜를 붙인다. "흥미롭다"가 아니라 "다음 프롬프트를 이렇게 바꿔야 한다"로 적는다.

조사 폭이 넓으면 spawn_task로 read-only 조사 서브태스크를 여러 각도(기법별/방어별/시간순)로 나눠 띄우고 get_task로 결론만 회수한다. 서브태스크는 코드를 편집할 수 없으니 조사·분석에만 쓰고, 실제 웹 검색이 필요하면 메인 루프에서 web_search를 직접 돌린다.

[2] 프롬프트 개선

조사 인사이트 + 직전 루프의 실패를 반영해 다음 루프에서 실제로 실행할 작업 프롬프트를 다시 쓴다.

• 직전 프롬프트를 그대로 두고 덧붙이지 말고, 필요하면 재구조화한다. 프롬프트는 누적 팽창이 아니라 수렴이 목표다.
• 개선의 근거를 명시한다: "루프 N에서 X가 실패 → 조사에서 Y 발견 → 프롬프트에 Z 추가/제거".
• 개선된 프롬프트와 직전 버전의 diff 요약을 상태 파일에 남긴다. 무엇이 왜 바뀌었는지 추적 가능해야 한다.

[3] 실행

개선된 프롬프트로 실제 작업을 수행한다.

• 독립적이고 무거운 조사는 spawn_task로 컨텍스트를 분리한다. 코드 편집·빌드·테스트 같은 쓰기 작업은 메인 루프에서 직접 한다(서브태스크는 read-only이므로 편집이 불가능하다).
• 코드 산출물은 사용자의 코드 스타일 규칙을 따른다(여는 중괄호 다음 줄, 항상 중괄호, ASCII 주석/로그, do-while(false) 단일 종료 등).
• 실행 산출물(코드/문서/결과)을 상태 파일 또는 작업 디렉터리에 보존한다.

[4] 평가

산출물을 [0]의 성공 기준에 대고 채점한다.

• 각 성공 기준을 통과/실패로 판정하고, 실패는 구체적 gap으로 적는다("탐지 3/5, 실패한 2종은 ~기법 계열"). 이 gap이 다음 루프 [1]의 검색어가 된다.
• 가능하면 실제로 검증한다: 코드는 run_shell로 빌드/실행, 문서 주장은 API/출처 대조. 눈대중 대신 실행.
• 이번 루프 점수를 직전 루프와 비교해 진전 여부를 기록한다.

[5] 종료 판정과 반복

매 루프 [4] 후 종료 조건을 확인한다:

• 달성: 모든 성공 기준 통과 → 루프 종료, 최종 보고로 이동.
• 정체(plateau): 연속 2루프 측정 가능한 진전 없음 → 접근을 근본적으로 바꿔 1회 더 시도(다른 메타포/다른 기법 계열). 그래도 진전 없으면 종료하고 사용자에게 현황과 막힌 원인을 보고.
• 상한 도달: 최대 루프 수 도달 → 종료하고 현재까지 최선의 결과와 남은 gap 보고.

그 외에는 [1]로 돌아가 반복한다. 매 루프 시작 시 한 줄로 진행 상황을 알린다: "루프 3/8 — 직전 gap: X. 이번 조사 초점: Y."

의사 결정 정책 — 안전하면 묻지 말고 진행

루프 중 결정이 필요할 때, 아래 기준으로 스스로 판단한다.

묻지 말고 추천 방향으로 진행 (안전·가역):

• 로컬 파일 읽기/생성/수정, 코드 작성·리팩터링, 테스트 실행
• 조사 방향·기법 선택, 프롬프트 구조 변경, 라이브러리/접근법 선택
• 되돌릴 수 있고 외부에 영향 없는 모든 작업

이럴 때는 추천안을 고르고, 선택과 근거를 상태 파일/보고에 한 줄로 남긴 뒤 계속 진행한다. "~할까요?"로 멈추지 않는다.

멈추고 사용자에게 확인 (위험·비가역·외부):

• 파일/데이터 삭제·덮어쓰기(사용자가 만들지 않은 것), 시스템 상태 변경(서비스 재시작, 레지스트리·드라이버 변경, 프로세스 종료)
• 외부 전송/게시(네트워크로 데이터 송출, 커밋 푸시, 배포, 티켓 생성)
• 자격증명·비밀 취급, 프로덕션 영향
• 성공 기준 자체를 바꿔야 할 만큼 목표가 근본적으로 모호해진 경우

애매하면 위험 쪽으로 분류해 멈춘다.

상태 추적

루프 상태를 파일 하나로 관리한다. 경로: 워크스페이스의 .kernforge/goal-loop/state.md. write_file로 만들고 매 루프 갱신한다.

# goal-loop 상태

## 목표
<원문 목표>

## 성공 기준
- [ ] 기준 1 (측정 방법)
- [ ] 기준 2
## 가정 / 제약
- 최대 루프: 8, 정체 판정: 연속 2루프 진전 없음
- <스스로 정한 가정들>

## 루프 로그
### 루프 1
- 조사 인사이트: (출처+날짜)
- 프롬프트 diff: (무엇이 왜 바뀌었나)
- 실행 산출물: (경로/요약)
- 평가: 기준별 통과/실패, gap
- 진전: (직전 대비)
- 결정: (스스로 내린 안전 결정 + 근거)
### 루프 2
...

이 파일은 루프가 길어져 컨텍스트가 요약돼도 상태를 잃지 않게 하는 앵커다. 새 루프 시작 시 항상 먼저 read_file로 읽는다.

최종 보고 (종료 시)

턴 마지막 메시지에 다음을 담는다. 이게 사용자가 실제로 읽는 결과물이다.

1. 결과 한 줄 요약: 달성 여부와 최종 상태.
2. 성공 기준 체크리스트: 각 기준 통과/실패.
3. 핵심 산출물: 파일 경로, 최종 프롬프트, 주요 코드/문서.
4. 루프 요약: 몇 루프 돌았고, 프롬프트가 어떻게 진화했나(핵심 전환점 위주).
5. 미달 gap과 다음 수(있으면): 상한/정체로 끝났다면 무엇이 남았고 어떻게 이어갈지.

흔한 실패 모드와 회피

• 조사 생략: 바쁘다고 웹 조사를 건너뛰고 프롬프트만 만지면 이 스킬의 의미가 없다. 매 루프 조사는 타협 불가.
• 프롬프트 팽창: 매 루프 문장만 덧붙여 프롬프트가 비대해지고 초점을 잃음. 개선은 재작성이지 누적이 아니다.
• 무한 루프: 성공 기준·상한·정체 판정을 안 정해서 못 끝냄. [0]에서 반드시 확정.
• 가짜 진전: 평가를 눈대중으로 해서 실제로 안 되는데 됐다고 판정. run_shell 실행/출처 대조로 검증.
• 과잉 질문: 안전한 결정마다 멈춰 물어봄. 정책상 안전하면 진행하고 근거만 남긴다.