스무고개식 계획 수립

$ARGUMENTS를 이슈 URL, 이슈 번호, 또는 작업 설명으로 수신한다. 이슈 URL 또는 이슈 번호가 제공되면 gh issue view로 내용을 가져오고, 작업 설명이 텍스트로 제공되면 그대로 분석 대상으로 삼는다.

빠른 참조

주의: 즉시 계획 모드 진입 금지

이 스킬을 호출했다고 해서 즉시 EnterPlanMode를 호출하지 않는다. 계획 모드에서는 write 작업(빌드, 명령 실행, 로컬 재현)이 제한되어, 검증 없는 추측 기반 계획이 만들어지고 hallucination이 크게 증가한다. 반드시 Step 1-6을 일반 모드에서 완료한 뒤, Step 7에서 EnterPlanMode를 호출한다.

절차

Step 1: 이슈 유효성 판단 [일반 모드]

계획 수립에 앞서, 대상 이슈/작업이 실제로 수행할 가치가 있는지 먼저 판단한다.

• 이미 해결되었는가? — 관련 코드, 최근 커밋, closed PR을 탐색하여 이미 해결된 문제가 아닌지 확인한다.
• YAGNI인가? — 현재 시점에서 실제로 필요한 변경인지 판단한다. "나중에 필요할 수도 있으니까"는 충분한 근거가 아니다.
• NGMI인가? — 현재 아키텍처/기술 제약 상 실현 불가능한 요구인지 확인한다.

유효하지 않다고 판단되면 사용자에게 근거를 제시하고, 계획을 중단할지 여부를 확인한다. 사용자가 그래도 진행하겠다고 하면 계속한다.

Scope 분해 판단: 요청이 독립적인 서브시스템(서비스/플랫폼/독립 모듈 단위) 2개 이상을 포함하는 경우, 계획 파일 내 별도 Phase/섹션으로 구분하여 다룬다. 출력은 여전히 단일 계획 파일이며, 별도의 plan-with-questions 사이클로 분리하지 않는다. 분해 여부가 불분명하면 Step 2 코드베이스 탐색 후 판단한다.

Step 2: 코드베이스 탐색 + 로컬 재현 [일반 모드]

대상 이슈 또는 작업 설명을 정독하고, 관련 코드베이스를 탐색한다.

• 이슈에 언급된 파일, 모듈, 설정을 코드베이스에서 찾아 현재 상태를 파악한다.
• 관련된 기존 구현, 의존성, 설정 패턴을 확인한다.
• 이슈에 링크된 PR, 커밋, 다른 이슈가 있으면 함께 확인한다.

로컬 검증 의무:

• 이슈/작업에서 언급된 문제를 로컬에서 직접 재현한다.
• 관련 명령어 실행, 빌드 시도, 설정 확인 등을 수행한다.
• API/플래그/경로의 존재 여부를 grep/which/--help로 확인한다.
• "~일 것이다", "~로 추정된다" 등 추측 기반 분석을 금지한다.
• 코드베이스를 직접 읽어 확인하지 않은 내용은 이후 단계에서 사용하지 않는다.

Step 3: 질문 수집 [일반 모드]

분석 과정에서 발견한 모든 불명확점을 수집한다. 다음 관점에서 빠짐없이 점검한다:

• 요구사항 불명확점: 이슈/작업 설명에서 해석이 여러 가지 가능한 부분
• 판단 기준: 사용자의 선호도나 우선순위가 필요한 결정 사항
• 사이드이펙트: 변경이 다른 기능/모듈/플랫폼에 미치는 영향
• 트레이드오프/접근법 비교: 실행 가능한 접근법이 2개 이상이면, 각 접근법의 장단점을 정리하고 추천안을 준비한다. 접근법이 1개뿐이면 건너뛴다.
• 인지 상태 확인: 사용자가 특정 제약이나 영향을 알고 있는지 여부
• XY Problem 검증: 사용자가 실제 문제(X)가 아닌 자신이 시도한 해결책(Y)에 대해 요청하고 있지는 않은지 점검한다. 의심되면 "해결하려는 근본 문제가 무엇인가요?"를 질문한다.

하나도 빠짐없이 전부 수집한다. "이 정도면 됐겠지"는 금지한다.

Step 4: 사용자에게 질문 [일반 모드]

사용자에게 질문할 때는 반드시 AskUserQuestion 도구를 사용한다. 일반 텍스트로 질문하지 않는다. 이 규칙은 예외 없이 적용된다.

수집한 질문을 AskUserQuestion으로 한번에 모아서 사용자에게 제시한다. 질문이 많으면 카테고리별로 묶어서 번호를 매긴다.

사용자의 답변에 따라 추가 질문이 생기면, 다시 AskUserQuestion으로 한번에 질문한다. 모든 불명확점이 해소될 때까지 이 과정을 반복한다.

질문 시 다음 패턴을 활용한다:

• 사이드이펙트 인지 확인: "이렇게 변경하면 ...에도 영향이 갑니다. 인지하고 계셨나요?"
• 트레이드오프 선택: "A 방식은 ...이 장점이고, B 방식은 ...이 장점입니다. 어느 쪽을 선호하시나요?"
• 판단 기준 요청: "이 부분은 판단 기준이 필요합니다: ..."
• 범위 확인: "이 이슈의 범위에 ...도 포함되나요, 아니면 별도 이슈로 분리할까요?"

Step 5: DA for_plan 실행 [일반 모드]

모든 질문이 해소되면, EnterPlanMode 전에 /run-da for_plan 스킬을 실행한다. DA 에이전트가 일반 모드에서 full tool access로 PoC 검증을 수행할 수 있도록 반드시 계획 모드 진입 전에 이 단계를 완료한다.

Step 6: DA 결과 반영 [일반 모드]

DA for_plan 결과에서 유효한 지적을 반영한다. 기각하는 지적에는 반드시 기술적 근거를 명시한다.

Step 7: EnterPlanMode 호출 [전환점]

모든 분석, 질문, DA 검토가 완료되었으므로 EnterPlanMode 도구를 호출하여 계획 모드로 진입한다.

Step 8: 계획 파일 작성 [계획 모드]

상세 실행 계획을 계획 파일에 작성한다.

계획에 포함할 내용:

• 변경 대상 파일 목록: 수정/추가/삭제할 파일과 각 파일에서의 변경 내용
• 실행 순서: 의존 관계를 고려한 작업 순서
• 검증 방법: 변경이 올바르게 적용되었는지 확인하는 방법 (빌드, 테스트, 수동 검증 등)
• 사이드이펙트 대응: Step 4에서 확인된 사이드이펙트에 대한 처리 방법
• 롤백 가능성: 문제 발생 시 되돌리는 방법

Hallucination 방지 원칙:

• 계획 파일에는 Step 1-6에서 직접 확인한 사실만 포함한다.
• "~일 것이다", "~로 추정된다" 등 추측 표현을 금지한다.
• "추후 결정", "별도 검토 필요", "적절히 처리", "필요에 따라" 등 미결정 표현을 금지한다. 계획의 모든 항목은 구체적 행동으로 서술한다 ("에러 핸들링 추가"가 아니라 "X 함수에서 Y 예외를 catch하여 Z로 처리"). 단, "미검증: ..." 주석처럼 검증 상태를 명시하는 표기는 허용한다.
• 확인하지 못한 사항이 있으면 계획에 포함하지 않거나, "미검증: ..." 주석으로 명시한다.
• 계획 모드 진입 후 새로운 가정이 필요해지면, 먼저 Read/Grep/Glob으로 확인한다 (계획 모드에서도 가능). 그래도 확인 불가하면 ExitPlanMode → 검증 → 재진입한다. 확인 없이 가정을 계획에 추가하지 않는다.

승인 요청 전 자체 점검:

• 이슈 커버리지: 원본 이슈/작업 설명의 모든 요구사항이 계획에 매핑되는가?
• 내부 일관성: 실행 순서와 파일 간 의존 관계가 모순되지 않는가?

누락이나 모순이 발견되면 계획 모드에서 즉시 수정한다. 추가 확인이 필요하면 ExitPlanMode → 검증 → 재진입한다.

Step 9: ExitPlanMode [승인 요청]

계획이 완성되면 ExitPlanMode 도구를 호출하여 사용자에게 계획 승인을 요청한다. 사용자가 수정을 요청하면 EnterPlanMode로 다시 진입해 계획 파일을 수정한 뒤 ExitPlanMode를 다시 호출한다.

Post-Implementation (승인 후 자동 수행)

사용자가 계획을 승인하고 구현을 명시적으로 지시하면, 구현 완료 후 다음을 순차 수행한다:

1. 변경사항 커밋
2. /run-da for_pr — 코드 DA 피드백 루프
3. /parallel-audit 10 — 전수조사
4. /create-pr — main 브랜치 대상 PR 생성

사용자가 명시적으로 특정 단계를 생략하라고 지시한 경우에만 해당 단계를 건너뛴다.

주의사항

• AskUserQuestion 의무: 사용자에게 질문할 때는 반드시 AskUserQuestion 도구를 사용한다. 일반 텍스트로 질문하지 않는다. 이 규칙은 예외 없이 적용된다.
• 블랙박스 제로 원칙: 계획에 모호한 부분이 남아 있으면 완성이 아니다. 사용자에게 물어보기 전에 코드베이스를 충분히 탐색하여 스스로 답할 수 있는 질문은 걸러낸다.
• YAGNI/NGMI를 제1원칙으로: 계획의 각 단계에서 "이게 정말 필요한가?"를 반복 검증한다. 불필요한 추가 작업을 계획에 포함하지 않는다.
• 질문은 빠짐없이: "사용자가 귀찮아하지 않을까" 걱정하지 않는다. 불명확한 채로 진행하면 나중에 더 큰 비용이 발생한다. 다만 한번에 모아서 질문하여 왕복 횟수는 최소화한다.
• 기존 패턴 존중: 코드베이스에 이미 확립된 패턴(디렉토리 구조, 네이밍 컨벤션, 설정 방식)을 파악하고, 계획이 기존 패턴과 일관되도록 한다.
• 지연 Plan Mode: Step 1-6은 일반 모드에서 수행한다. 로컬 재현, 빌드, 명령 실행 등이 필요하기 때문이다. EnterPlanMode는 모든 분석과 질문이 완료된 Step 7에서만 호출한다.