xallindrome-labs/claude-code-ops

/runway

목표: 모든 질문은 지금 하고, 40번째 턴에 질문할 필요가 없도록 합니다. 그 후 사용자는 하나의 계획을 승인하고 자리를 비웁니다. 사용자의 휴대폰은 중단점에서만 알림을 받습니다.

기본 규칙 (사용자는 CLAUDE.md에 자신의 규칙을 가질 수 있으며, 사용자 규칙이 우선합니다):

• 로컬이고 되돌릴 수 있는 작업 (편집, 빌드, 테스트, 로컬 명령어, 브랜치 또는 워크트리에서의 커밋)은 묻지 않고 실행합니다.
• 다음 작업은 항상 중단합니다: 푸시 또는 배포, 메시지 보내기, 애플리케이션 제출, 비용 지출, 데이터 삭제, 공개 게시.
• 대량 작업 (검색, 테스트 실행, 로그 분류)에는 더 저렴한 서브 에이전트 모델을 사용하고, 고급 모델은 설계 및 어려운 디버깅에만 사용합니다.

0. 사전 점검 (자동, 질문 없음)

• 저장소 루트와 그 상태를 확인합니다: git status, 현재 브랜치, 기존 SPEC.md, 테스트 및 빌드 스크립트 (package.json, Makefile 등). 사실을 찾는 것은 사용자의 일이 아니라 당신의 일입니다.
• 휴대폰 승인이 활성화되어 있는지 확인합니다. ~/.claude/settings.json에 phone-approve.js를 실행하는 PermissionRequest 후크가 있거나 이 플러그인의 후크가 활성화되어 있고 그리고 ~/.claude/phone-approve.json이 존재하면 활성화된 것입니다. 그렇지 않으면 사용자에게 한 번 알리고 (설정: node "${CLAUDE_PLUGIN_ROOT}/hooks/phone-approve.js" --init을 실행한 다음, 해당 파일의 요청 토픽에 ntfy 앱을 구독) 계속 진행합니다. 중단점은 데스크톱 대화 상자로 대체됩니다.
• 중단점 명령어가 강제로 프롬프트를 표시하도록 설정되어 있는지 확인합니다. 자동 모드에서는 그렇지 않으면 알림 없이 승인할 수 있기 때문입니다. 사용자, 프로젝트 및 로컬 설정에서 git push, 이 저장소의 배포 명령어 (vercel, aws s3 sync, cdk deploy, npm publish, gh release, gh pr merge) 및 삭제 명령어 (rm -r, git clean, git branch -D)에 대한 permissions.ask (또는 deny) 규칙을 확인합니다. 규칙이 누락된 경우, 특정 규칙을 제안하고, 차이점(diff)을 보여주고, 사용자가 동의할 때만 추가합니다 (플러그인의 examples/permissions-ask.json이 시작점입니다). 전송, 게시 또는 배포 도구에 대해 allow 규칙을 추가하지 말고, Bash(*)에도 추가하지 마십시오.

1. 사양이 완료될 때까지 인터뷰

grilling 또는 grill-me 스킬이 설치되어 있으면, 그것을 호출하고 이 기능에 대해 실행합니다. 해당 규칙이 완전히 적용됩니다. 그렇지 않으면 다음과 같이 직접 인터뷰를 진행합니다: 라운드로 질문합니다; 각 라운드에는 이미 결정된 전제 조건이 있는 모든 질문이 포함되며, 각각 번호가 매겨지고, "예"라고 대답하면 수락되는 권장 답변이 포함됩니다. 답변을 기다리고, 이제 질문할 수 있는 것을 다시 계산하고, 반복합니다. 환경 정보는 직접 찾아보고 (대량 검색에는 서브 에이전트 사용), 스스로 찾을 수 있는 것을 사용자에게 묻지 마십시오. 결정은 사용자의 몫입니다.

사용자가 이미 대화 초반에 이 기능에 대해 그릴링 세션을 실행하고 공유된 이해를 확인했다면, 반복하지 마십시오: 답변을 재사용하고 아래 체크리스트 항목 중 열려 있는 항목에 대해서만 질문하십시오.

다음 모든 사항이 더 이상 열려 있지 않을 때까지 계속 진행하십시오:

1. 목표: 한두 문장, 사용자에게 보이는 결과.
2. 범위: 변경될 사항 (영역, 파일, 표면).
3. 범위 외: 건드리지 말아야 할 것.
4. 수락 기준: 각 항목이 명령어 출력으로 참(true)임을 증명할 수 있는 체크리스트.
5. 검증 명령어: 종료 코드 0이 완료를 의미하는 정확히 하나의 명령어 (예: npm run lint && npm test && npm run build). 없으면, 사양에 첫 번째 작업으로 이를 작성하는 것이 포함됩니다.
6. 중단점: 이 기능이 접촉할 푸시/배포/전송/제출/지출/삭제/게시 중 어떤 것이며, 각각에 대해 사용자가 기대하는 것 (예: "브랜치를 푸시하고, PR을 열고, 병합하지 마십시오").
7. 그렇지 않으면 작업 중간에 내리게 될 결정: 라이브러리, 명명, 데이터 형태, 카피, 경계 케이스 동작. 지금 권장 사항과 함께 물어보십시오.
8. 턴 제한 (기본값 60) 및 예산 관련 사항.

사용자가 공유된 이해를 확인할 때까지 넘어가지 마십시오.

2. SPEC.md를 작성하고 로컬에 커밋

저장소 루트에 SPEC.md를 작성합니다:

# <기능 이름>
## 목표
## 범위
## 범위 외
## 수락 기준
- [ ] ...
## 검증 명령어
`<하나의 명령어>`
## 중단점
| 작업 | 예상 처리 |
## 이미 내려진 결정
## 턴 제한
60

브랜치를 생성하고 (git switch -c runway/<슬러그>), 또는 다른 세션이 같은 폴더를 편집 중일 때는 워크트리를 사용한 다음, 오직 SPEC.md만 커밋합니다. 이는 로컬이고 되돌릴 수 있습니다. 묻지 마십시오. 절대 푸시하지 마십시오.

3. 단일 계획 승인

계획 모드로 진입하여 단일 계획을 제시합니다: 순서가 지정된 단계, 어떤 단계가 서브 에이전트로 가는지 (어떤 모델에서), 검증 명령어, 예상 처리와 함께 중단점. 이것은 실행 전 유일한 승인입니다. ExitPlanMode를 사용하고 사용자에게 **"예, 자동 모드를 사용하십시오"**를 선택하도록 요청하십시오. (휴대폰 후크는 의도적으로 계획 승인을 건너뛰므로, 사용자는 컴퓨터에서 이 작업을 수행합니다.)

승인 후 자동 모드가 활성화되지 않으면, 그렇게 말하고 사용자에게 전환하도록 요청하십시오. 수동 모드에서 루프를 실행하지 마십시오.

4. 턴 제한과 함께 /goal 하에서 실행

내장된 슬래시 명령어는 모델이 직접 호출할 수 없으므로, 이전 단계를 마무리하면서 사용자에게 한 줄을 붙여넣도록 제공합니다 (실제 명령어와 제한을 채워 넣으십시오):

/goal <검증 명령어>가 0으로 종료되고, SPEC.md의 모든 수락 기준이 기록에 증거와 함께 체크되었으며, SPEC.md의 범위 외 목록에 있는 것은 전혀 건드리지 않았거나, 60턴 후 중지

세션이 이미 goal을 실행 중이면 /goal이 이를 대체합니다. 평가자는 기록만 보므로, 작업 중: 검증 명령어를 자주 실행하고, 그 결과를 출력하고, 증거와 함께 SPEC.md 기준을 체크하십시오. 각 턴마다 턴 제한 대비 진행 상황을 보고하십시오.

실행 중:

• 질문하지 마십시오. 명시되지 않은 사항이 발생하면, 사양에 가장 가까운 옵션을 선택하여 "이미 내려진 결정"에 기록하고 계속 진행하십시오. 진행이 중단점에 도달하거나 사양과 모순되는 경우에만 질문을 위해 중단하십시오.
• 작은 커밋으로 runway 브랜치에 작업을 커밋하십시오. 중단점 승인 없이 푸시하지 마십시오.
• 중단점에서, 평소처럼 호출하십시오. 권한 프롬프트가 휴대폰으로 알림을 보냅니다. 거부되면 다른 방법으로 재시도하지 마십시오: 기록하고, 그것이 필요하지 않은 작업을 마치고, 보고하십시오.
• 3턴 연속으로 진행이 없으면, 중단하고 무엇이 막혔는지 보고하십시오.

5. 완료

검증이 통과되거나 (또는 제한에 도달하면), 다음 순서로 보고하십시오:

1. 결과: 완료 / 부분 완료 / 차단됨, 브랜치 및 PR 링크.
2. Diff 통계 (git diff --stat <기준>...HEAD).
3. 검증됨: 명령어와 결과로 증명된 기준.
4. 검증되지 않음: 완전히 또는 부분적으로 증명되지 않은 기준; 중단점에서 건너뛰거나 거부된 모든 것.
5. 사용된 서브 에이전트, 어떤 모델에서, 그리고 더 작은 모델이 더 나쁜 성능을 보인 곳.
6. 턴 및 제한 대비 대략적인 비용.