/loopeng

name: loopeng
description: 요청 하나를 의도부터 PR·학습까지 AI SDLC 루프로 끝까지 돌릴 때, 멈춘 루프를 이어 갈 때, 루프가 지금 어디인지 볼 때 사용. /loopeng [요청|status]. Triggers - loopeng, 루프로 돌려, SDLC 루프, 처음부터 끝까지, 이어서 해, 루프 상태.

Loopeng: AI SDLC 루프

요청 하나를 **의도 → 설계 → 계획 → 구현 → 검증 → 리뷰 → 출시 → 학습**으로 돌리고, 남은 문제는 다음 루프의 의도로 넘긴다. 단계마다 산출물을 커밋하고, 다음 단계는 그 산출물을 읽고 시작한다. 사람은 게이트에서만 판단하고, 그 사이는 멈추지 않고 이어 간다.

부르는 법

| 입력 | 하는 일 | |---|---| | `/loopeng <요청>` | 새 루프를 연다 | | `/loopeng` | 진행 중인 루프를 상태에서 이어 간다. 없으면 무엇을 할지 묻는다 | | `/loopeng status` | 현재 상태만 보여 주고 멈춘다 |

Claude Code에서 다른 플러그인과 이름이 겹치면 `/adlc-harness:loopeng`. Codex는 `$loopeng`, 다른 호스트는 "loopeng으로 돌려"라고 요청한다.

단계

1 의도(`brainstorming` → `intent.md`) · 2 설계(`brainstorming` → `spec.md`, 화면이면 `design-md` → `design.md`) · 3 계획(`writing-plans` → `plan.md`) · 4 구현(`test-driven-development`, 독립 Task가 여럿이면 `memorybox`) · 5 검증(전체 검사 + `evaluator`) · 6 리뷰(`review`) · 7 출시(`commit-push-pr`) · 8 학습(`memory`). 게이트는 1·2·3·7이다.

단계별 산출물과 문서 규칙, 서브에이전트 띄우는 법, 메모리 쓰는 법은 `harness-guide`에 있다. 루프를 열 때 한 번 읽고, 흐름이 헷갈리면 다시 읽는다.

**각 단계는 그 단계의 스킬을 실제로 불러서 한다**(Claude Code는 Skill 도구, 다른 호스트는 그 스킬). `harness-guide`는 지도일 뿐이다. 질문하는 법(`brainstorming`), plan의 구성(`writing-plans`), 테스트 먼저(`test-driven-development`)는 그 스킬에만 있으니 요약을 보고 대신하지 않는다.

0. 상태 읽기 (매 단계를 시작할 때)

1. 작업 폴더를 찾는다: 인계(handoff.md)의 `지금:`, 없으면 `docs/work/*/` 중 `loop.md` 마지막 줄이 `done`이 아닌 최신 폴더. 2. 파일과 `승인:` 줄로 단계를 정한다. 기억이나 대화가 아니라 파일이 기준이다(압축·재시작·다른 호스트에서도 같은 답이 나온다).

| 상태 | 다음 | |---|---| | 작업 폴더 없음 | 크기 판정 | | `intent.md` 없음, 또는 `승인:` 날짜 없음 | 1 | | `spec.md`(화면이면 `design.md`도) 없음, 또는 승인 없음 | 2 | | `plan.md` 없음, 또는 승인 없음 | 3 | | plan에 미체크 단계 있음 | 4 (`재개:` 줄대로 첫 미체크 단계부터) | | 모두 체크, 이번 커밋에 대한 PASS 기록 없음 | 5 | | PASS, 리뷰 전이거나 지적이 남음 | 6 | | 리뷰 통과 | 7 | | PR 있음, 또는 7을 건너뜀(원격 없음, 사용자가 미룸) | 8 |

3. `loop.md`에 단계를 넘길 때마다 한 줄을 붙이고 그 단계의 커밋에 넣는다: `- YYYY-MM-DD HH:MM | <단계> | <결과: 승인·PASS·FAIL·지적 n건·PR #n> | 다음: <단계>` 시각은 `date '+%F %R'` 출력을 쓴다. 지어내지 않는다. 이 파일이 루프의 상태 기록이자 감사 기록이다. 고쳐 쓰지 않고 붙이기만 한다.

크기 판정

• **바로 끝나는 일**: 루프를 열지 않는다. 바로 하고 검증 출력으로 보고한다.
• **작은 변경**: 채팅에서 짧은 설계(수용 기준 한두 줄)를 승인받고 4 → 5(전체 검사) → 6 → 7 → 8. 6은 `review` 스킬의 Quick(서브에이전트 2개)으로 하고, 직접 훑어보는 것으로 대신하지 않는다. 작업 폴더와 `loop.md`는 만들지 않는다.
• **큰 작업**: 1부터 모든 단계.

판정은 한 줄로 알리고 시작한다: "큰 작업으로 루프를 돈다. 1 의도부터." 사용자가 크기를 바꾸라고 하면 따른다.

루프 규칙

• **게이트(1·2·3·7)**: 멈추고 산출물 경로와 결정할 것만 묻는다. 승인을 받으면 `승인: YYYY-MM-DD`를 적고 커밋한 뒤, 다시 묻지 않고 다음 단계로 넘어간다.
• **자동 단계(4·5·6)**: 멈추지 않는다. Task를 끝낼 때마다 plan을 체크하고 커밋하며, 인계의 `지금:`에 작업 폴더와 Task를 적는다. "계속할까요?"라고 묻지 않는다.
• **되돌아가기**: 5나 6에서 실패하면 지적을 들고 4로 간다. 같은 원인으로 세 번 되돌아가면 멈추고, 무엇이 왜 계속 실패하는지와 바꿀 접근을 보고한다. 요구 자체가 틀렸다는 증거가 나오면 그 문서(intent·spec)로 돌아가 `승인:` 줄을 지우고 다시 승인받는다.
• **요구 변경**: 사용자가 중간에 요구를 바꾸면 영향받는 가장 앞 문서부터 고치고 뒤 문서는 다시 승인받는다.
• **커밋이 막히면**: Codex 샌드박스처럼 `.git`에 쓸 수 없으면 사용자에게 한 번 알리고(`harness-guide` 7절), 승인 줄은 파일에 남긴 채 `loop.md`에 "커밋 보류"로 적고 이어 간다.
• **경계**: 루프는 PR까지다. 푸시·PR은 묻고 한다. 병합·배포·운영은 사람이 한다. 사용자가 "병합해"라고 분명히 말할 때만 병합하고, "알아서 해"·"추천대로"는 병합 승인이 아니다. 7을 건너뛰어도 8은 한다.
• **작업 폴더**: 끝난 `docs/work/*/`는 지우지 않는다(무엇을 왜 했는지의 기록이다). 스무 개가 넘으면 1년 지난 것부터 `docs/work/archive/YYYY/`로 옮기자고 제안한다.
• **다음 루프**: 8에서 나온 후속 일을 목록으로 보여 준다. 사용자가 고르면 그것으로 `/loopeng <요청>`을 연다. 고르지 않으면 끝낸다.
• **컨텍스트**: 단계가 바뀌면 그 단계에 필요한 산출물만 다시 읽는다. 대화 기억에 기대지 않는다.

status 출력

루프: docs/work/2026-10-28-마감일/   단계: 4 구현 (Task 3/5)
마지막 기록: 2026-10-28 14:02 | 계획 | 승인 | 다음: 구현
다음 할 일: Task 3 — overdue(list, today) (R2)
남은 게이트: 7 출시(푸시·PR 승인)

진행 중인 루프가 없으면 "`/loopeng <요청>`으로 시작, 흐름은 `harness-guide`"만 보여 준다.