micooz/batch-plan-execute

Batch Plan Execute (일괄 계획 수립 및 실행)

이 스킬은 요구사항 소스와 현재 plans/ 디렉토리 상태를 기반으로 모듈 계획 및 파생된 checklist.md를 생성, 수정, 폐기, 실행 또는 검사하는 작업에 사용됩니다.

이 스킬은 현재 다음과 같은 명시적 모드를 가지고 있습니다:

• plan: 구현 준비가 완료된 계획을 생성하거나 수정하고 checklist.md를 새로 고칩니다.
• execute: 이미 검토된 계획을 구현합니다.

이 스킬은 다음 작업을 수행할 수 있습니다:

• 채팅, 요구사항 파일(예: requirements.md), 기존 계획 파일 또는 plans/ 디렉토리로부터 요구사항 텍스트를 입력받습니다.
• 최신 요구사항 소스, 기존 계획 파일 및 숨겨진 상태 파일로부터 현재 계획 상태를 재구성합니다.
• 모듈별 혼합 변경 사항(신규 요구사항, 변경된 요구사항, 제거된 요구사항, 검토 노트)을 감지합니다.
• 병렬화 가능한 작업과 직렬 작업을 반영하는 의존성 인식 모듈 또는 작업 스트림 계획을 수립합니다.
• 최신 요구사항 소스와 권위 있는 검토 노트로부터 통합 checklist.md를 생성합니다.
• 사용자의 명시적 실행 명령이 있을 때만 구현 하위 에이전트를 통해 승인된 계획을 실행합니다.

입력 처리

다음 우선순위에 따라 기본 입력을 선택합니다:

1. 사용자가 언급한 명시적 계획 파일 경로 또는 plans/ 디렉토리 경로.
2. 사용자가 언급한 명시적 요구사항 파일 경로.
3. 작업 컨텍스트에 이미 첨부된 파일 또는 문서.
4. 채팅에 직접 작성된 요구사항 텍스트.

다음 규칙을 사용합니다:

• 계획 파일 경로가 제공된 경우, 해당 계열을 기본 시작점으로 처리하고 형제 plans/ 디렉토리를 검사합니다.
• plans/ 디렉토리 경로가 제공된 경우, 해당 디렉토리 내의 계획 파일과 상태 파일만 검사합니다.
• 요구사항 파일 경로가 제공된 경우, 직접 읽어 최신 요구사항 소스로 처리합니다.
• 입력이 원시 채팅 텍스트인 경우, 전체 사용자 텍스트를 최신 요구사항 소스로 처리합니다.
• 요구사항 소스와 plans/ 디렉토리가 모두 사용 가능한 경우, 항상 둘 다 사용합니다.

참조된 파일이나 디렉토리가 존재하지 않거나 읽을 수 없는 경우 즉시 실패합니다.

출력 언어

다음 규칙을 사용합니다:

• 모든 사용자 대상 출력 언어를 최신 요구사항 소스의 주요 언어와 일치시킵니다.
• 요구사항 소스가 없는 경우, 사용자의 현재 턴 입력의 주요 언어와 일치시킵니다.
• 사용자가 명시적으로 번역이나 특정 출력 언어를 요청한 경우, 그 요청을 따릅니다.

모드 선택

기본값은 plan 모드입니다.

사용자가 현재 턴에서 명시적으로 실행 명령을 내리는 경우에만 execute 모드로 전환합니다.

execute 모드로 해석되는 예시:

• 시작해
• 이 계획대로 구현해
• 코드로 옮겨
• 바로 실행
• implement now
• apply the plan

기본 plan 동작에서 모드를 변경하지 않는 예시:

• 좋아
• OK
• 계속해
• 이 방향으로
• 검토 완료
• 계획을 승인하지만 명시적으로 구현 시작을 요청하지 않는 모든 승인

다음 규칙을 사용합니다:

• 검토 승인은 실행 승인이 아닙니다.
• 사용자가 모호한 경우 plan 모드를 유지하고 실행 계획을 구체화하거나 더 명확한 실행 명령을 요청합니다.
• 분위기, 낙관론 또는 반대 의견 부재로 실행 의도를 추론하지 않습니다.

출력 위치 및 명명

계획 파일을 plans/ 디렉토리에 기록합니다:

• 소스가 요구사항 파일인 경우, 해당 파일 옆에 plans/ 폴더를 사용합니다.
• 소스가 계획 파일 또는 plans/ 디렉토리인 경우, 동일한 plans/ 디렉토리에 계속 기록합니다.
• 소스가 원시 채팅 텍스트인 경우, <cwd>/plans/를 사용합니다.

plans/ 디렉토리가 없으면 생성합니다.

기본 계획 파일 형식:

• <module-slug>.md

개정 계획 파일 형식:

• <module-slug>.rev-<n>.md

파생된 체크리스트 파일:

• checklist.md

숨겨진 상태 파일:

• .state.json

다음 명명 규칙을 사용합니다:

• new-plan은 모듈에 이전 계열이 없는 경우 기본 파일을 생성할 수 있습니다.
• revise-plan 및 obsolete-plan은 항상 새로운 rev 파일을 기록해야 합니다.
• no-op은 새 계획 파일을 기록하지 않아야 합니다.
• 기존 파일을 자동으로 덮어쓰지 않습니다.
• 계획 슬러그는 요구사항 제목 텍스트가 아닌, 구현 소유권을 따라야 합니다.
• 최신 요구사항 소스가 읽을 수 있는 파일인 경우, checklist.md를 plans/ 내부가 아닌 해당 요구사항 파일 옆에 기록합니다.
• 읽을 수 있는 요구사항 파일이 없는 경우, 활성 plans/ 디렉토리 내부에 checklist.md를 기록합니다.
• 결정된 checklist.md 경로를 안전하게 새로 고칠 수 있을 때 항상 제자리에 덮어씁니다.
• checklist.md는 파생된 스냅샷이며, 계획 계열 아티팩트나 실행 대상이 아닙니다.

상태 파일

plans/.state.json을 계획 기준선으로 유지 관리합니다.

상태 파일에는 최소한 다음이 포함되어야 합니다:

• requirement_source
• requirement_hash
• run_at
• modules

각 모듈 상태 객체에는 최소한 다음이 포함되어야 합니다:

• slug
• title
• status
• source_excerpt_hash
• body_hash_without_heading
• latest_plan_file
• latest_rev
• last_action

상태 값은 명시적이어야 합니다:

• active
• obsolete

다음 규칙을 사용합니다:

• 상태 파일은 계획 계열만 설명합니다.
• 상태 파일을 실행 권한으로 취급하지 않습니다.
• 상태 파일이 누락된 경우, 실패하지 않고 최신 요구사항 소스와 기존 계획 파일로부터 부트스트랩합니다.

계획 모드

상세한 계획 작성 지침은 docs/plan.md를 사용합니다.

모듈 추출

기본적으로 저장소 패키지 구조나 요구사항 제목에 의해 기계적으로 분할하지 않고, 구현 단위와 의존성 경계를 기준으로 분할합니다.

모듈을 추출하거나 요구사항 해시를 계산하기 전에, 펜스 처리된 코드 블록 외부의 HTML 주석을 제거하여 최신 요구사항 소스를 전처리합니다.

다음 규칙을 사용합니다:

• 주석 처리된 요구사항 내용은 존재하지 않는 것으로 취급합니다.
• 최종 모듈 경계가 아닌 추출 보조 수단으로만 요구사항 섹션부터 시작합니다.
• 배경, 목표, 범위, 비목표, 가정, 롤아웃, 수용 기준 및 비기능 요구사항과 같은 메타 섹션은 독립 모듈이 아닌 전역 제약 조건으로 취급합니다.
• 동일한 구현 경로, 공유 코드 표면 또는 동일한 소유자 수준의 인도물에 해당하는 요구사항 조각을 병합합니다.
• 기반 작업 후 기능 작업과 같은 엄격한 구현 순서나 독립적인 인도물을 명확히 설명하는 경우에만 섹션을 분할합니다.
• 기능 소유권, 공유 인터페이스 소유권, 마이그레이션 경계 또는 배포 경계와 일치하는 모듈 경계를 선호합니다.
• 동일한 공유 변경 사항을 모두 소유하는 중복 모듈을 생성하지 않습니다.
• 구현 가능한 모듈을 추출할 수 없거나 공유 소유권을 명확하게 할당할 수 없는 경우 명시적으로 실패합니다.

소스가 신뢰할 수 있는 제목이 없는 일반 텍스트인 경우:

• 요구사항 내용에서 간결한 모듈 목록을 도출합니다.
• 기능 경계, 워크플로우, 인도물 및 전제 조건 관계를 모듈 이름으로 사용합니다.
• misc, other, supporting-work와 같은 일반적인 모듈 이름은 피합니다.

의존성 및 병렬성 모델링

후보 모듈을 추출한 후, 분류 또는 하위 에이전트 생성 전에 명시적 의존성 그래프를 도출합니다.

다음 규칙을 사용합니다:

• 각 모듈을 foundation, feature 또는 follow-on으로 분류합니다.
• depends_on, blocks, parallelizable_with 및 shared_change_owner를 기록합니다.
• 동일한 단계에서 동일한 공유 코드 소유권이 필요하지 않은 경우에만 병렬 모듈을 선호합니다.
• 한 모듈이 다른 모듈이 사용하는 계약, 스키마, 마이그레이션 또는 공유 유틸리티를 변경하는 경우 직렬 순서를 선호합니다.
• 구현이 A then B인 경우, 두 모듈을 하나의 피어 목록에 강제로 넣지 않고 직접 모델링합니다.
• 가짜 병렬성을 추론하지 않습니다. 안전한 순서가 불확실한 경우 보수적으로 순서를 지정합니다.

검토 감지 및 계열

검토 감지는 plans/*.md 내에서만 의미가 있습니다.

다음 규칙을 사용합니다:

• 펜스 처리된 코드 블록 외부의 모든 HTML 주석을 검토 노트로 취급합니다.
• 사용자 댓글의 검토 내용이 원래 요구사항 문서와 충돌하는 경우, 검토 내용을 최신 권위 있는 지침으로 취급합니다.
• 최종 계획 출력에 HTML 주석을 보존하지 않습니다.
• 가장 높은 rev로 최신 계열 아티팩트를 결정하고, 그렇지 않으면 최신 기본 파일을 사용합니다.
• 먼저 슬러그 일치를 선호합니다.
• body_hash_without_heading에 대한 안전한 일대일 일치에 대해서만 이름 변경 일치를 허용합니다.
• 이름 변경 일치가 모호한 경우 추측하지 않습니다.

체크리스트 생성

모든 성공적인 plan 실행 중에 checklist.md를 생성하거나 새로 고칩니다.

다음 규칙을 사용합니다:

• 최신 요구사항 소스와 최신 계획 계열의 권위 있는 검토 노트로부터 체크리스트를 작성합니다.
• 체크리스트 항목을 도출하기 전에 모듈 추출에 사용된 동일한 요구사항 전처리를 적용합니다.
• 검토 댓글이 원래 요구사항 문서와 충돌하는 경우 권위 있는 것으로 취급합니다.
• checklist.md에 원시 HTML 주석을 절대 보존하지 않으며, 해결된 의도만 보존합니다.
• 원시 요구사항 제목 순서가 아닌 의존성 계층 및 모듈 순서별로 체크리스트 섹션을 구성합니다.
• 마크다운 제목과 함께 실행 가능한 미완료 항목(예: - [ ] ...)을 사용합니다.
• 서술 요약이 아닌 검증 가능한 구현 또는 수용 결과를 선호합니다.
• 최신 요구사항 소스가 읽을 수 있는 파일인 경우, 해당 요구사항 파일 옆에 checklist.md를 기록합니다.
• 읽을 수 있는 요구사항 파일이 없는 경우, 활성 plans/ 디렉토리 내부에 checklist.md를 기록합니다.
• 소스가 계획 파일 또는 plans/ 디렉토리인 경우, 체크리스트를 새로 고치기 전에 plans/.state.json에서 최신 읽을 수 있는 요구사항 소스를 확인합니다.
• 요구사항 소스를 안전하게 재구성할 수 없는 경우, 검토 기반 계획 수정을 진행하되 checklist.md를 새로 고칠 수 없음을 보고합니다.

혼합 모드 분류

전체 실행에 대해 한 번이 아닌 모듈별로 작업을 결정합니다.

각 모듈을 다음 작업 중 정확히 하나로 분류합니다:

• new-plan
• revise-plan
• obsolete-plan
• no-op

다음 기본값을 사용합니다:

• 요구사항 변경 사항과 검토 노트를 하나의 revise-plan으로 병합합니다.
• 제거된 모듈을 자동으로 삭제하지 않고 obsolete-plan 수정을 생성합니다.
• 요구사항 소스를 사용할 수 없는 경우, 검토 기반 수정만 허용합니다.
• 요구사항 소스의 주석 전용 편집은 revise-plan을 트리거하지 않아야 합니다.

계획 하위 에이전트

모듈 목록, 의존성 그래프 및 작업을 잠근 후 영향을 받는 모듈당 하나의 계획 하위 에이전트를 생성합니다.

다음 규칙을 사용합니다:

• 계획 작업을 위해 읽기 전용 분석 하위 에이전트를 선호합니다.
• 전용 읽기 전용 분석 역할을 사용할 수 없고 하위 에이전트가 계속 읽기 전용 상태를 유지할 수 있는 경우에만 범용 하위 에이전트를 사용합니다.
• 계획 하위 에이전트는 파일을 편집할 수 없습니다.
• 동일한 의존성 계층 내에서만 계획 하위 에이전트를 병렬로 실행합니다.
• 각 계획 하위 에이전트에게 영향을 받는 코드 영역, 인터페이스, 의존성, 병렬성 노트, 위험, 테스트 및 명시적 가정을 반환하도록 요청합니다.

계획 조립

메인 에이전트는 최종 계획 품질, 계획 파일 출력 및 상태 파일 업데이트를 담당합니다.

다음 규칙을 사용합니다:

• 용어와 공유 변경 사항이 일관되게 유지되도록 모듈 간 의존성을 해결합니다.
• 각 공유 인터페이스, 스키마, 마이그레이션 또는 인프라 변경에 대해 명확한 소유자를 한 명 확인합니다.
• 요구사항 제목 순서가 아닌 의존성 계층에 따라 최종 모듈 출력을 정렬합니다.
• 모듈이 다른 모듈에 의해 차단되었거나 전제 조건 이후에 병렬로 실행될 수 있는 경우 명시적으로 명시합니다.
• 모듈 계획이 조립된 후 상태 파일을 새로 고치기 전에 checklist.md를 새로 고칩니다.
• 영향을 받는 모든 모듈이 처리된 후에만 plans/.state.json을 새로 고칩니다.

실행 모드

상세한 실행 계약은 docs/execute.md를 사용합니다.

실행 전제 조건

다음 중 하나라도 해당되는 경우 즉시 실패합니다:

• 대상 계획 파일 또는 plans/ 디렉토리를 확인할 수 없음.
• 최신 대상 계획 아티팩트에 여전히 해결되지 않은 검토 댓글이 포함됨.
• 저장소가 쓰기 소유권을 안전하게 할당할 수 있을 만큼 충분히 근거되지 않음.
• 공유 변경 소유권이 모호함.
• 의존성 사이클이 병합된 모듈로 정당화될 수 없음.

실행 규칙

게이트 및 전제 조건이 충족된 후:

• 대상 확인, 근거 부여, 작업자 디스패치, 통합, 검증 및 완료를 위해 docs/execute.md를 사용합니다.
• 선택된 각 모듈 계열에 대해 최신 검토된 아티팩트를 실행합니다.
• 계획 모드에서 생성된 의존성 그래프를 존중하거나 디스패치 전에 최신 계획 세트에서 재구성합니다.

실패 규칙

다음 상황에서는 약한 출력을 생성하는 대신 중단하고 문제를 보고합니다:

• 요구사항 파일, 계획 파일 또는 plans 디렉토리가 누락되었거나 읽을 수 없는 경우.
• 필수 요구사항 소스에 대한 모듈 추출이 실패한 경우.
• 계획이 대부분 추측에 불과하고 의미 있는 코드베이스 연계가 없는 경우.
• 한 모듈에 대해 여러 최신 계열 후보가 있고 순서를 안전하게 결정할 수 없는 경우.
• 이름 변경 일치가 모호하고 안전한 일대일 매핑으로 축소될 수 없는 경우.
• 공유 변경 또는 의존성 소유권을 하나의 명확한 모듈 또는 작업 스트림에 할당할 수 없는 경우.
• 의존성 그래프에 단일 병합 모듈로 정당화될 수 없는 사이클이 포함된 경우.
• 상태 파일이 존재하지만 형식이 잘못되었고 가시적인 아티팩트에서 안전하게 재구성될 수 없는 경우.

작업에 모듈별 출력이 필요한 경우 빈 계획 파일, 요약 전용 파일 또는 단일 통합 계획을 생성하지 마십시오.