agent-plan

name	agent-plan
description	작업 전 독립 서브에이전트(Opus)와 협업하여 구현 계획을 수립. 작업 계획, 설계 논의, 접근 방식 검토 시 사용.
disable-model-invocation	false
argument-hint	[작업 설명]

작업 계획 수립 - 독립 서브에이전트(Opus) 검증

Claude(메인)가 코드를 분석하고 초안 계획을 작성한 뒤, 독립 서브에이전트에게 검증/보완을 받습니다. 대규모 아키텍처 변경이나 고위험 작업은 병렬 분석 모드로 전환합니다.

모드 선택

기본 모드 (순차 협업)

대부분의 작업에 사용합니다.

1. 메인이 codebase-memory-mcp 그래프 도구를 우선 사용하여 관련 코드를 분석합니다.
   • search_graph로 관련 함수/클래스/모듈 탐색
   • trace_call_path로 콜체인 및 영향 범위 추적
   • get_architecture로 구조 파악
   • 그래프에 없는 정보(문자열 리터럴, 설정값 등)만 Read/Grep/Glob으로 보완
2. 코드 구조, 영향 범위, 초안 계획을 정리합니다.
3. 서브에이전트에게 사실 정보만 전달하여 독립 검증을 요청합니다.
4. 서브에이전트 피드백을 반영하여 최종 계획을 확정합니다.

병렬 모드 (독립 분석)

다음 조건에 해당하면 병렬 모드를 사용합니다:

• 변경 범위가 크고 아키텍처 영향이 넓을 때
• Rust 백엔드와 React 프론트가 강하게 얽혀 있을 때
• 실패 비용이 큰 리팩토링/마이그레이션일 때

메인 분석과 서브에이전트 분석을 동시에 진행합니다:

• 메인: 그래프 도구 우선, 필요시 Read/Grep 보완
• 서브에이전트: 백그라운드로 독립 분석 (run_in_background 기본값)
• 두 분석 결과를 종합하여 최종 계획을 작성합니다.

서브에이전트 호출 방법

Agent 도구를 사용합니다:

• subagent_type: "general-purpose", model: "opus" (기본)
• 에스컬레이션: 아키텍처 전면 개편, 데이터 모델/영속성 설계 등 실패 비용이 큰 계획 검증은 model 지정을 생략하여 메인 모델(상위 티어)을 상속시킵니다.
• 백그라운드 실행이 기본 — 완료 시 task-notification으로 자동 수신. 대기 중에는 메인 선분석 등 병렬 가능한 작업만 수행합니다.
• 결과가 즉시 필요하면 run_in_background: false로 동기 실행합니다.
• 사실 수집(파일 목록·콜체인 정찰)만 필요한 보조 탐색은 Explore 에이전트 + model: "sonnet"으로 저비용 병렬 처리할 수 있습니다.

프롬프트 구성 (기본 모드)

사실 정보(파일 목록, 코드 구조, 영향 범위)만 전달하고, 메인의 판단/결론은 포함하지 않습니다 (anchoring bias 방지).

당신은 DmNote 프로젝트(Tauri: Rust + React)의 독립 설계 검증자입니다.
다음 작업의 구현 계획을 독립적으로 수립/검증하세요. 파일은 직접 읽어서 확인하세요.
코드를 수정하지 마세요 — 분석과 계획만 보고합니다.

기술 스택: Tauri(Rust + React), Zustand, Preact Signals, Tailwind CSS, Vite + React Compiler

작업 내용: (사용자 요청)

관련 코드 정보:
- 관련 파일: (파일 경로 목록)
- 코드 구조: (함수/모듈 관계, 콜체인 등 사실 정보)
- 영향 범위: (변경 시 영향받는 파일/함수 목록)

요청:
- 구현 계획을 단계별로 수립
- 누락된 영향 범위나 리스크 지적
- 더 나은 접근 방식이 있으면 제안

출력 형식 (반드시 준수):
## 구현 계획
1. (단계별 작업 - 파일명과 변경 내용)
## 리스크
- (잠재적 문제점과 근거)
## 대안
- (고려한 다른 접근 방식이 있다면)

병렬 모드 프롬프트

초안 없이 작업 내용과 기술 스택만 전달하고, 서브에이전트가 스스로 코드를 읽고 독립 분석하도록 지시합니다.

후속 질문 (멀티턴)

같은 에이전트에 SendMessage(에이전트 ID/이름)로 컨텍스트를 유지한 채 추가 질문합니다.

실패 처리

• 서브에이전트가 종료 에러로 실패(결과 null)하면: → "서브에이전트 실패: [원인]. 메인 단독으로 계획을 수립합니다."를 명시하고 단독 진행합니다.
• 응답이 불충분하면 SendMessage로 1회 보완 요청, 그래도 불충분하면 단독 진행합니다.

피드백 필터링

서브에이전트 피드백을 반영할 때 메인이 자체 판단으로 필터링합니다:

• 방어적 코딩 수준의 제안 (에러 핸들링 강화, 옵셔널 체크 추가 등)이 실질적 버그가 아니라 오버엔지니어링에 해당하면 반영하지 않고 생략합니다.
• 프로젝트 컨벤션(예: let _ = store.update(...) 패턴)에 부합하는 코드에 대한 지적은 무시합니다.

출력 형식

메인 분석

(코드 구조, 영향 범위, 기존 패턴)

서브에이전트 피드백

(검증 결과 및 보완 사항. fallback인 경우 "[서브에이전트 미사용: 사유]" 명시)

최종 실행 계획

1. (구체적 단계별 작업 - 파일명과 변경 내용 포함)

제약사항 및 리스크

(양쪽에서 지적된 주의점)