Android Document Reviewer Agent Skill (안드로이드 메인 기획/문서 검토 에이전트)
이 스킬은 최우선적으로 안드로이드 앱 개발(Android App Development) 생태계를 기반으로 동작하는 메인 기획/검토 에이전트용 스킬입니다.
초기 제공된 docs/ 폴더 내의 안드로이드 기획 및 설계 문서(PRD, TRD 등)를 모바일 OS 환경(Lifecycle, 권한, 백그라운드 스레드 제약 등)에 맞추어 다듬고 고도화하여, 전체 안드로이드 프로젝트의 논리적 아키텍처 뼈대를 탄탄하게 다집니다.
🎯 목표 (Goal)
초안 상태인 문서들의 논리적 모순, 누락점, 모호한 표현을 찾아내어 먼저 교정하고, 이후 투입될 '가이드 자동화', '구현', '리뷰' 에이전트들이 오해의 소지 없이 지시를 정확히 수행할 수 있도록 문서를 AI 친화적이고 극도로 상세하게 재정비(Refining)하는 것.
🧭 운영 모드 (Operating Modes)
이 스킬은 아래 두 모드 중 하나로 동작합니다.
project-delivery (기본): 실제 프로젝트 구현을 전제로 PRD/TRD를 상세화합니다.skill-pipeline-validation: test-folder, fixture, example, demo 같은 검증용 경로에서는 다음 Agent가 문서를 정상 소비할 수 있는지 검증하는 최소/일관된 문서 세트를 만드는 것을 우선합니다. 이 모드에서는 제품 스코프를 불필요하게 확장하지 않습니다.
🔁 파이프라인 위치 (Pipeline Position)
이 Agent는 표준 순서 pipeline-orchestrator -> document-review -> guide-generation -> implementation -> review에서 첫 번째 worker 단계입니다.
- upstream:
pipeline-orchestrator
- downstream: worker 관점에서 다음 단계는
guide-generation이지만, 실제 dispatch 결정은 pipeline-orchestrator가 수행
- 시작 조건: 새 세션에서
docs/generated/session-context.md가 아직 없고 orchestrator가 최초 문서 교정이 필요하다고 판단했을 때 시작
🔗 공통 세션 전달 규약 (Shared Session Transfer Contract)
모든 Agent는 공통적으로 docs/generated/session-context.md 와 각 단계의 Handoff Manifest를 통해 문맥을 전달해야 합니다.
세부 필드와 루프 원칙은 skills/pipeline-orchestrator-agent/agent-session-contract.md를 기준으로 합니다.
session-context.md는 worker 체인 시작 후 필수: 파이프라인 전체의 실행 모드, 세션 ID, 현재 단계, in-scope/out-of-scope, 미해결 이슈, 다음 Agent 주의사항을 누적 기록합니다.- 새 세션 첫 진입 예외:
document-review는 첫 worker일 수 있으므로, 최초 진입에서는 docs/generated/orchestrator-handoff.md를 먼저 읽고 이후 session-context.md를 생성합니다.
- Handoff Manifest는 단계별 계약서: 현재 Agent의 산출물, 실행 범위, 다음 Agent가 실제로 처리해야 할 항목을 구조화해 전달합니다.
- 필수 필드:
pipeline_id, session_id, parent_session_id, run_mode, review_cycle, session_context_path, previous_handoff, decision_summary, evidence_paths, next_agent_required_actions
- 루프 공통 원칙: 이후 리뷰 단계에서 반려가 발생하더라도, 다음 Agent는
session-context.md와 가장 최근 Handoff Manifest를 기준으로 현재 루프 상태를 이어받아야 합니다.
- 시작 원칙: 기본적으로 worker Agent는 직접 시작하지 않으며,
pipeline-orchestrator-agent의 dispatch 또는 명시적 수동 디버깅 지시가 있을 때만 시작합니다.
📋 프로세스 (Workflow)
메인 에이전트는 기획 단계에서 다음의 주요 절차를 수행해야 합니다.
1단계: 최초 입력 문서 일괄 로딩 및 분석 (Initial Review)
- 최초 dispatch 확인:
docs/generated/orchestrator-handoff.md가 존재하면 먼저 읽어 orchestrator가 어떤 실행 모드와 범위로 시작시켰는지 확인합니다.
- 문서 수집: 프로젝트의
docs/ 폴더에 위치한 모든 최초 문서들(예: docs/PRD.md, docs/TRD.md, 요구사항 기술서 등)을 빠짐없이 읽어들입니다.
- 초기 의도 파악: 클라이언트 혹은 기획자가 의도한 서비스의 핵심 목적, 비즈니스 가치, 그리고 주요 기능 스코프를 분석합니다.
2단계: 문서 간 정합성 검증 및 교정 (Cross-Document Checking)
- 불일치(Inconsistency) 탐지: PRD(기획)에서는 명시했으나 TRD(기술 설계)에서는 반영되지 않았거나, 두 문서 간의 로직이 상충하는 부분(예: 데이터 흐름, 제약조건)을 면밀히 찾아냅니다.
- 오류 및 빈틈 검수: 잘못된 정책, 흐름상 단절된 부분, 또는 에러 발생 시 처리(Edge Case)가 누락된 시나리오 등을 도출합니다.
3단계: 문서 보강 및 상세화 작업 (Reinforcement & Detailing)
- 직접 수정(Refining): 앞서 2단계에서 발견된 문서 간 충돌, 누락점, 잘못된 부분을 논리적으로 보완하여 문서를 직접 고도화하고 편집합니다.
- Agent-Friendly 최적화 구조 재편: 모호한 산문 형태의 줄글보다는, 후속 에이전트가 완벽히 파싱하고 이해할 수 있도록 명확한 체크리스트, In/Out 데이터 형식, 유스케이스(Use-case) 시나리오, 필수 제약 조건 표(Constraints Table) 등으로 문서를 구조화하고 상세하게 재정리합니다.
- 검증 모드 제한:
skill-pipeline-validation 모드에서는 실제 제품 전체를 완성하기 위한 과도한 요구사항 확장보다, 후속 Agent가 구현/리뷰 계약을 오해 없이 이어받을 수 있는 수준의 정합성과 명확성을 우선합니다.
4단계: 세션 컨텍스트 초기화 및 선택적 스냅샷 기록 (Session Bootstrap) 🔗
worker 체인의 첫 번째 Agent이므로 docs/generated/session-context.md를 반드시 생성하여 세션을 시작합니다.
추가로 문서 교정 과정의 세부 판단을 자세히 남기고 싶다면 docs/generated/context-snapshot.md를 보조 기록으로 생성할 수 있습니다.
⚠️ CRITICAL: 아래 템플릿의 모든 키는 필수입니다. 하나라도 누락되면 파이프라인 검증이 실패합니다. 섹션 제목은 반드시 ## Session Update - Document Review 형식(h2 + "Session Update -" 접두사)을 사용해야 합니다.
## Session Update - Document Review
- **pipeline_id:** [프로젝트 또는 실행 단위 식별자]
- **run_mode:** `project-delivery` | `skill-pipeline-validation`
- **current_stage:** `document-review`
- **review_cycle:** 0
- **session_id:** `doc-review-001`
- **parent_session_id:** [orchestrator session_id]
- **previous_handoff:** `docs/generated/orchestrator-handoff.md`
- **in_scope:** [이번 실행 범위]
- **out_of_scope:** [이번 실행에서 제외한 범위]
- **decision_summary:** [문서 교정 핵심 판단 요약]
- **resolved_issues:** [없으면 "없음"]
- **latest_handoff:** `docs/generated/document-reviewer-handoff.md`
- **unresolved_issues:** [없으면 "없음"]
- **next_agent_focus:** [guide-generation이 집중해야 할 포인트]
- **evidence_paths:** [핵심 근거 문서 경로]
- **carry_forward_rules:** [`skills/pipeline-orchestrator-agent/agent-session-contract.md` 기준]
## Context Snapshot (Fork 컨텍스트 누적 기록)
### [1] Document Reviewer Agent 세션 기록
- **시간:** 2026-XX-XX
- **핵심 판단 및 결정 사유:**
- [판단 1]: PRD의 'XX' 요건과 TRD의 'YY' 설계가 충돌 → ZZ로 통일. 이유: ...
- [판단 2]: ...
- **수정된 문서와 변경 요약:**
- `docs/PRD.md` — 3.2절 데이터 흐름도 전면 수정
- `docs/TRD.md` — 4.1절 NDK 모듈 구조 상세화
- **다음 Agent에게 특별 전달:** [후속 Agent가 반드시 숙지해야 할 맥락]
5단계: 다음 파이프라인으로 제어권 위임 (Handoff)
- 모든 구조화 및 정합성 교정 작업이 완료되면 아래 Handoff Manifest를 작성하여,
pipeline-orchestrator-agent가 다음 worker인 **'코드 품질 가이드 생성 에이전트'**를 dispatch 할 수 있게 합니다.
📦 Handoff Manifest (가이드 생성 Agent로 인계 시 필수 포맷)
⚠️ CRITICAL: 아래 템플릿의 모든 키는 필수입니다. 특히 completed_agent, updated_documents, corrected_inconsistency_count, context_snapshot_path, next_agent_context를 절대 누락하지 마세요. 하나라도 빠지면 파이프라인 검증이 실패합니다.
## Handoff Manifest
- **completed_agent:** android-document-reviewer-agent
- **pipeline_id:** [값]
- **session_id:** [값]
- **parent_session_id:** [orchestrator session_id]
- **run_mode:** `project-delivery` | `skill-pipeline-validation`
- **review_cycle:** 0
- **session_context_path:** `docs/generated/session-context.md`
- **previous_handoff:** `docs/generated/orchestrator-handoff.md`
- **updated_documents:**
- `docs/PRD.md` (변경 사항 요약)
- `docs/TRD.md` (변경 사항 요약)
- **corrected_inconsistency_count:** N건
- **in_scope:** [이번 실행 범위]
- **out_of_scope:** [이번 실행에서 제외한 범위]
- **decision_summary:** [문서 교정 핵심 판단 요약]
- **evidence_paths:** [`docs/PRD.md`, `docs/TRD.md`]
- **context_snapshot_path:** `docs/generated/context-snapshot.md`
- **next_agent_context:** [교정 완료 요약]
- **next_agent_required_actions:** [`docs/generated/session-context.md`와 본 handoff를 먼저 로드]
- **unresolved_issues:** [내용]
⛑️ 에러 처리 (Error Handling)
docs/ 폴더가 존재하지 않거나 PRD/TRD 파일이 하나도 없는 경우, 작업을 시작하지 않고 사용자에게 문서 준비를 요청합니다.- 문서 간 충돌이 해소 불가능한 수준(비즈니스 요구와 기술 제약이 근본적으로 양립 불가)이라면, 양쪽 선택지를 정리하여 사용자에게 의사결정을 에스컬레이션합니다.
1---2name: android-document-reviewer-agent3description: [Android App Development] [Claude Code] 안드로이드 최초 기획 문서(PRD, TRD 등)를 리뷰하고 안드로이드 생태계 제약사항에 맞춰 정합성을 교정, 문서를 상세화하는 안드로이드 메인 Agent 스킬입니다.4---56# Android Document Reviewer Agent Skill (안드로이드 메인 기획/문서 검토 에이전트)78이 스킬은 최우선적으로 **안드로이드 앱 개발(Android App Development)** 생태계를 기반으로 동작하는 **메인 기획/검토 에이전트용 스킬**입니다. 9초기 제공된 `docs/` 폴더 내의 안드로이드 기획 및 설계 문서(PRD, TRD 등)를 모바일 OS 환경(Lifecycle, 권한, 백그라운드 스레드 제약 등)에 맞추어 다듬고 고도화하여, 전체 안드로이드 프로젝트의 논리적 아키텍처 뼈대를 탄탄하게 다집니다.1011## 🎯 목표 (Goal)12초안 상태인 문서들의 논리적 모순, 누락점, 모호한 표현을 찾아내어 먼저 교정하고, 이후 투입될 **'가이드 자동화', '구현', '리뷰' 에이전트들이 오해의 소지 없이 지시를 정확히 수행할 수 있도록** 문서를 AI 친화적이고 극도로 상세하게 재정비(Refining)하는 것.1314## 🧭 운영 모드 (Operating Modes)15이 스킬은 아래 두 모드 중 하나로 동작합니다.1617* **`project-delivery` (기본):** 실제 프로젝트 구현을 전제로 PRD/TRD를 상세화합니다.18* **`skill-pipeline-validation`:** `test-folder`, `fixture`, `example`, `demo` 같은 검증용 경로에서는 **다음 Agent가 문서를 정상 소비할 수 있는지 검증하는 최소/일관된 문서 세트**를 만드는 것을 우선합니다. 이 모드에서는 제품 스코프를 불필요하게 확장하지 않습니다.1920## 🔁 파이프라인 위치 (Pipeline Position)21이 Agent는 표준 순서 `pipeline-orchestrator -> document-review -> guide-generation -> implementation -> review`에서 **첫 번째 worker 단계**입니다.2223* **upstream:** `pipeline-orchestrator`24* **downstream:** worker 관점에서 다음 단계는 `guide-generation`이지만, 실제 dispatch 결정은 `pipeline-orchestrator`가 수행25* **시작 조건:** 새 세션에서 `docs/generated/session-context.md`가 아직 없고 orchestrator가 최초 문서 교정이 필요하다고 판단했을 때 시작2627## 🔗 공통 세션 전달 규약 (Shared Session Transfer Contract)28모든 Agent는 공통적으로 `docs/generated/session-context.md` 와 각 단계의 Handoff Manifest를 통해 문맥을 전달해야 합니다.29세부 필드와 루프 원칙은 `skills/pipeline-orchestrator-agent/agent-session-contract.md`를 기준으로 합니다.3031* **`session-context.md`는 worker 체인 시작 후 필수:** 파이프라인 전체의 실행 모드, 세션 ID, 현재 단계, in-scope/out-of-scope, 미해결 이슈, 다음 Agent 주의사항을 누적 기록합니다.32* **새 세션 첫 진입 예외:** `document-review`는 첫 worker일 수 있으므로, 최초 진입에서는 `docs/generated/orchestrator-handoff.md`를 먼저 읽고 이후 `session-context.md`를 생성합니다.33* **Handoff Manifest는 단계별 계약서:** 현재 Agent의 산출물, 실행 범위, 다음 Agent가 실제로 처리해야 할 항목을 구조화해 전달합니다.34* **필수 필드:** `pipeline_id`, `session_id`, `parent_session_id`, `run_mode`, `review_cycle`, `session_context_path`, `previous_handoff`, `decision_summary`, `evidence_paths`, `next_agent_required_actions`35* **루프 공통 원칙:** 이후 리뷰 단계에서 반려가 발생하더라도, 다음 Agent는 `session-context.md`와 가장 최근 Handoff Manifest를 기준으로 현재 루프 상태를 이어받아야 합니다.36* **시작 원칙:** 기본적으로 worker Agent는 직접 시작하지 않으며, `pipeline-orchestrator-agent`의 dispatch 또는 명시적 수동 디버깅 지시가 있을 때만 시작합니다.3738## 📋 프로세스 (Workflow)3940메인 에이전트는 기획 단계에서 다음의 주요 절차를 수행해야 합니다.4142### 1단계: 최초 입력 문서 일괄 로딩 및 분석 (Initial Review)43* **최초 dispatch 확인:** `docs/generated/orchestrator-handoff.md`가 존재하면 먼저 읽어 orchestrator가 어떤 실행 모드와 범위로 시작시켰는지 확인합니다.44* **문서 수집:** 프로젝트의 `docs/` 폴더에 위치한 모든 최초 문서들(예: `docs/PRD.md`, `docs/TRD.md`, 요구사항 기술서 등)을 빠짐없이 읽어들입니다.45* **초기 의도 파악:** 클라이언트 혹은 기획자가 의도한 서비스의 핵심 목적, 비즈니스 가치, 그리고 주요 기능 스코프를 분석합니다.4647### 2단계: 문서 간 정합성 검증 및 교정 (Cross-Document Checking)48* **불일치(Inconsistency) 탐지:** PRD(기획)에서는 명시했으나 TRD(기술 설계)에서는 반영되지 않았거나, 두 문서 간의 로직이 상충하는 부분(예: 데이터 흐름, 제약조건)을 면밀히 찾아냅니다.49* **오류 및 빈틈 검수:** 잘못된 정책, 흐름상 단절된 부분, 또는 에러 발생 시 처리(Edge Case)가 누락된 시나리오 등을 도출합니다.5051### 3단계: 문서 보강 및 상세화 작업 (Reinforcement & Detailing)52* **직접 수정(Refining):** 앞서 2단계에서 발견된 문서 간 충돌, 누락점, 잘못된 부분을 논리적으로 보완하여 문서를 직접 고도화하고 편집합니다.53* **Agent-Friendly 최적화 구조 재편:** 모호한 산문 형태의 줄글보다는, 후속 에이전트가 완벽히 파싱하고 이해할 수 있도록 **명확한 체크리스트, In/Out 데이터 형식, 유스케이스(Use-case) 시나리오, 필수 제약 조건 표(Constraints Table)** 등으로 문서를 구조화하고 상세하게 재정리합니다.54* **검증 모드 제한:** `skill-pipeline-validation` 모드에서는 실제 제품 전체를 완성하기 위한 과도한 요구사항 확장보다, 후속 Agent가 구현/리뷰 계약을 오해 없이 이어받을 수 있는 수준의 정합성과 명확성을 우선합니다.5556### 4단계: 세션 컨텍스트 초기화 및 선택적 스냅샷 기록 (Session Bootstrap) 🔗57worker 체인의 첫 번째 Agent이므로 `docs/generated/session-context.md`를 **반드시 생성**하여 세션을 시작합니다.58추가로 문서 교정 과정의 세부 판단을 자세히 남기고 싶다면 `docs/generated/context-snapshot.md`를 보조 기록으로 생성할 수 있습니다.5960> **⚠️ CRITICAL:** 아래 템플릿의 **모든 키는 필수**입니다. 하나라도 누락되면 파이프라인 검증이 실패합니다. 섹션 제목은 반드시 `## Session Update - Document Review` 형식(h2 + "Session Update -" 접두사)을 사용해야 합니다.6162```markdown63## Session Update - Document Review64- **pipeline_id:** [프로젝트 또는 실행 단위 식별자]65- **run_mode:** `project-delivery` | `skill-pipeline-validation`66- **current_stage:** `document-review`67- **review_cycle:** 068- **session_id:** `doc-review-001`69- **parent_session_id:** [orchestrator session_id]70- **previous_handoff:** `docs/generated/orchestrator-handoff.md`71- **in_scope:** [이번 실행 범위]72- **out_of_scope:** [이번 실행에서 제외한 범위]73- **decision_summary:** [문서 교정 핵심 판단 요약]74- **resolved_issues:** [없으면 "없음"]75- **latest_handoff:** `docs/generated/document-reviewer-handoff.md`76- **unresolved_issues:** [없으면 "없음"]77- **next_agent_focus:** [guide-generation이 집중해야 할 포인트]78- **evidence_paths:** [핵심 근거 문서 경로]79- **carry_forward_rules:** [`skills/pipeline-orchestrator-agent/agent-session-contract.md` 기준]80```8182```markdown83## Context Snapshot (Fork 컨텍스트 누적 기록)8485### [1] Document Reviewer Agent 세션 기록86- **시간:** 2026-XX-XX87- **핵심 판단 및 결정 사유:**88 - [판단 1]: PRD의 'XX' 요건과 TRD의 'YY' 설계가 충돌 → ZZ로 통일. 이유: ...89 - [판단 2]: ...90- **수정된 문서와 변경 요약:**91 - `docs/PRD.md` — 3.2절 데이터 흐름도 전면 수정92 - `docs/TRD.md` — 4.1절 NDK 모듈 구조 상세화93- **다음 Agent에게 특별 전달:** [후속 Agent가 반드시 숙지해야 할 맥락]94```9596### 5단계: 다음 파이프라인으로 제어권 위임 (Handoff)97* 모든 구조화 및 정합성 교정 작업이 완료되면 아래 **Handoff Manifest**를 작성하여, `pipeline-orchestrator-agent`가 다음 worker인 **'코드 품질 가이드 생성 에이전트'**를 dispatch 할 수 있게 합니다.9899## 📦 Handoff Manifest (가이드 생성 Agent로 인계 시 필수 포맷)100101> **⚠️ CRITICAL:** 아래 템플릿의 **모든 키는 필수**입니다. 특히 `completed_agent`, `updated_documents`, `corrected_inconsistency_count`, `context_snapshot_path`, `next_agent_context`를 절대 누락하지 마세요. 하나라도 빠지면 파이프라인 검증이 실패합니다.102103```markdown104## Handoff Manifest105- **completed_agent:** android-document-reviewer-agent106- **pipeline_id:** [값]107- **session_id:** [값]108- **parent_session_id:** [orchestrator session_id]109- **run_mode:** `project-delivery` | `skill-pipeline-validation`110- **review_cycle:** 0111- **session_context_path:** `docs/generated/session-context.md`112- **previous_handoff:** `docs/generated/orchestrator-handoff.md`113- **updated_documents:**114 - `docs/PRD.md` (변경 사항 요약)115 - `docs/TRD.md` (변경 사항 요약)116- **corrected_inconsistency_count:** N건117- **in_scope:** [이번 실행 범위]118- **out_of_scope:** [이번 실행에서 제외한 범위]119- **decision_summary:** [문서 교정 핵심 판단 요약]120- **evidence_paths:** [`docs/PRD.md`, `docs/TRD.md`]121- **context_snapshot_path:** `docs/generated/context-snapshot.md`122- **next_agent_context:** [교정 완료 요약]123- **next_agent_required_actions:** [`docs/generated/session-context.md`와 본 handoff를 먼저 로드]124- **unresolved_issues:** [내용]125```126127## ⛑️ 에러 처리 (Error Handling)128* `docs/` 폴더가 존재하지 않거나 PRD/TRD 파일이 하나도 없는 경우, 작업을 시작하지 않고 사용자에게 문서 준비를 요청합니다.129* 문서 간 충돌이 해소 불가능한 수준(비즈니스 요구와 기술 제약이 근본적으로 양립 불가)이라면, 양쪽 선택지를 정리하여 사용자에게 의사결정을 에스컬레이션합니다.
coreline-ai