doc-coauthoring

name	doc-coauthoring
description	기술 스펙, 제안서, 결정 문서, PRD 등 구조화된 문서를 3단계로 공동 작성합니다. "문서 작성", "스펙 작성", "제안서", "RFC", "설계 문서", "PRD" 등 비코드 문서 작성 요청 시 반드시 사용. /doc-coauthoring으로 호출.
tier	T1
input_schema	{"topic":{"type":"string","required":false,"description":"Document topic or title"}}

문서 공동 작성

3단계 워크플로우로 구조화된 문서를 작성합니다.

워크플로우 소개

시작 시 사용자에게 3단계를 설명하고 이 방식으로 진행할지 확인합니다:

1. 컨텍스트 수집 — 사용자가 배경 정보를 제공, Claude가 보완 질문
2. 구조화 및 작성 — 섹션별 브레인스토밍 → 선택 → 초안 → 정제 반복
3. 독자 테스트 — 컨텍스트 없는 상태로 문서를 검증

거절하면 자유 형식으로 작성합니다.

---

Stage 1: 컨텍스트 수집

목표: Claude가 사용자와 동일한 배경 지식을 갖출 때까지 수집.

초기 질문 (5가지)

1. 문서 유형은? (기술 스펙, 결정 문서, 제안서, RFC 등)
2. 주요 독자는?
3. 독자가 읽은 후 기대하는 결과/액션은?
4. 따라야 할 템플릿이나 포맷이 있나?
5. 기타 제약 조건이나 컨텍스트는?

정보 수집

질문 답변 후, 관련 정보를 모두 쏟아내도록 요청합니다:

• 프로젝트/문제의 배경
• 왜 다른 대안을 선택하지 않았는지
• 팀 논의, 기술 아키텍처, 이해관계자 우려사항
• 타임라인 제약

정리하지 않고 스트림 형식으로 제공해도 됨을 안내합니다.

충분한 컨텍스트 기준: 엣지 케이스와 트레이드오프를 질문할 수 있을 때.

---

Stage 2: 구조화 및 작성

목표: 섹션별로 반복 작성.

문서 구조 결정

• 문서 유형에 맞는 3~5개 섹션 제안
• 사용자가 수정/승인
• 모든 섹션 헤더와 [작성 예정] 플레이스홀더로 초안 구조 생성

섹션별 반복 (불확실한 섹션부터)

각 섹션마다:

1. 해당 섹션에 포함할 내용 확인 질문
2. 5~20개 옵션 브레인스토밍
3. 사용자가 유지/제거/조합할 항목 선택
4. 섹션 초안 작성
5. 외과적 수정으로 정제

결정 문서는 핵심 제안부터, 기술 스펙은 기술 접근법부터 시작. 요약 섹션은 마지막.

---

Stage 3: 독자 테스트

목표: 문서가 컨텍스트 없이도 self-contained한지 검증.

완성된 문서를 배경 지식 없는 독자 관점으로 시뮬레이션합니다:

[독자 역할 시작]
다음 문서를 처음 보는 독자 입장에서 읽겠습니다:

<문서 전문>

검토 결과:
- 이해하기 어려운 부분: ...
- 암묵적 가정으로 보이는 것: ...
- 불분명한 결정 근거: ...
- 추가 설명이 필요한 부분: ...
[독자 역할 종료]

발견된 취약점을 사용자에게 보고하고 수정 여부 확인 후 Stage 2로 돌아가거나 완료합니다.

---

사용 예시

• naia-os 기술 스펙 (STT/TTS 프로바이더 설계 문서)
• docs-business 제안서/IR 문서
• docs-nextain 온보딩/설계 결정 기록
• GitHub Issue 기반 기능 설계 스펙