역할

현재 대화에서 생성된 구현 계획을 직접 검토하고, 문제가 있으면 수정된 계획을 다시 Plan 모드로 제출한다.

이 스킬은 fork하지 않는다. 현재 에이전트가 자신이 만든 계획을 스스로 검토하고 수정한다.

Plan 검토 절차

0단계: 검토 대상 확인

현재 대화에서 가장 최근에 생성한 구현 계획을 검토 대상으로 삼는다. $ARGUMENTS가 있으면 해당 내용을 추가 검토 관점으로 반영한다.

1단계: 프로젝트 컨벤션 확인

Docs/ 폴더에서 계획과 관련된 문서를 읽고 현재 시스템 구조를 파악한다:

•Docs/코드베이스 구조.md - 파일/폴더 구조, 네이밍 패턴
•Docs/시스템 그룹 및 의존성.md - SystemGroup, 실행 순서
•계획 내용과 관련된 기능별 문서 (전투, 이동, 건설, 채집 등)

계획에서 언급된 기존 시스템/컴포넌트가 실제로 존재하는지 Grep/Glob으로 확인한다.

2단계: 검토 기준

다음 항목을 순서대로 검증한다:

A. 아키텍처 적합성

•새 시스템의 SystemGroup 배치가 올바른가? (실행 순서, UpdateAfter/UpdateBefore)
•Client/Server/Shared 분리가 올바른가?
•기존 패턴과 일관되는가? (DamageEvent 버퍼, Authoring 조합, Spatial Partitioning 등)

B. 중복/충돌 검사

•이미 존재하는 컴포넌트, 시스템, 유틸리티를 재구현하고 있지 않은가?
•기존 시스템과 Job 스케줄링 충돌 가능성은 없는가?
•싱글톤을 새로 만들기 전에 기존 싱글톤을 확장할 수 있는가?

C. DOTS 규칙 준수

•BurstCompile 적용 여부
•Health 직접 수정 대신 DamageEvent 버퍼 사용
•ECB를 통한 구조적 변경
•RefRO 선호, ReadOnly Lookup 사용
•Tag 컴포넌트 + Query 필터링

D. 네트워크 고려사항

•Server Authority 원칙을 따르는가?
•Ghost 동기화가 필요한 컴포넌트가 빠져있지 않은가?
•RPC 방향(Client→Server, Server→Client)이 올바른가?

E. 누락 사항

•필요한 Authoring 컴포넌트가 계획에 포함되어 있는가?
•관련 문서 업데이트 계획이 있는가?
•엣지 케이스 처리가 고려되어 있는가? (엔티티 파괴, 연결 끊김 등)

3단계: 검토 결과 출력

다음 형식으로 결과를 출력한다:

code

## Plan 검토 결과

### 적합 항목
- (문제 없는 부분 간략히)

### 수정 필요
| # | 항목 | 현재 계획 | 수정 제안 | 이유 |
|---|------|-----------|-----------|------|
| 1 | ...  | ...       | ...       | ...  |

### 누락 사항
- (계획에서 빠진 부분)

### 최종 판단
(승인 가능 / 재계획 필요)

검토는 사실 기반으로 수행하며, 코드베이스에서 근거를 확인한 항목만 지적한다. 추측이나 과잉 지적은 하지 않는다.

4단계: 판단별 후속 행동

•"승인 가능": 계획 구조가 올바른 경우. 검토 결과를 출력하고, 수정 항목이 있으면 플랜 파일에 직접 반영(Edit)한 뒤 종료한다. Plan 모드 재진입 없이 사용자가 계획을 승인할 수 있도록 한다.
•"재계획 필요": 시스템 배치/의존성/접근 방식 등 계획 구조 자체에 문제가 있는 경우. 검토 결과 출력 후, 수정 사항을 반영한 새로운 계획을 Plan 모드(EnterPlanMode → ExitPlanMode)로 다시 제출한다.