📌 참고: 이 문서는 공식 Claude Code 문서의 원문 + 레퍼런스입니다.

• 원문 링크를 직접 사용하셔도 됩니다
• 이 파일을 .claude/skills/ 하위에 복사하여 스킬로 등록할 수도 있습니다

(2026.03.15 기준)

문서 공동 작성 워크플로

이 스킬은 사용자가 협업적으로 문서를 작성하는 과정을 안내하는 구조화된 워크플로를 제공합니다. 적극적인 가이드 역할을 하며, 사용자를 세 단계를 통해 안내합니다: 맥락 수집, 다듬기 및 구조화, 독자 테스트.

이 워크플로를 제안하는 시점

트리거 조건:

• 사용자가 문서 작성을 언급: "문서를 작성해 주세요", "제안서 초안", "스펙 작성", "정리해 주세요"
• 사용자가 특정 문서 유형을 언급: "PRD", "설계 문서", "의사결정 문서", "RFC"
• 사용자가 상당한 규모의 글쓰기 작업을 시작하려는 것처럼 보임

초기 제안:
문서 공동 작성을 위한 구조화된 워크플로를 사용자에게 제안합니다. 세 단계를 설명합니다:

1. 맥락 수집: 사용자가 모든 관련 맥락을 제공하고 Claude가 명확화 질문을 합니다
2. 다듬기 및 구조화: 브레인스토밍과 편집을 통해 각 섹션을 반복적으로 구축합니다
3. 독자 테스트: 다른 사람이 읽기 전에 사각지대를 잡기 위해 새로운 Claude(맥락 없음)로 문서를 테스트합니다

이 접근 방식이 다른 사람이 읽을 때(Claude에 붙여넣는 경우 포함) 문서가 잘 작동하도록 도움이 된다고 설명합니다. 이 워크플로를 시도할 것인지 아니면 자유 형식으로 작업하고 싶은지 물어봅니다.

사용자가 거부하면 자유 형식으로 작업합니다. 사용자가 수락하면 1단계로 진행합니다.

1단계: 맥락 수집

목표: 사용자가 알고 있는 것과 Claude가 알고 있는 것 사이의 격차를 좁혀, 나중에 현명한 안내를 가능하게 합니다.

초기 질문

문서에 대한 메타 맥락을 사용자에게 물어보는 것부터 시작합니다:

1. 어떤 유형의 문서인가요? (예: 기술 스펙, 의사결정 문서, 제안서)
2. 주요 독자는 누구인가요?
3. 누군가가 이것을 읽었을 때 원하는 영향은 무엇인가요?
4. 따를 템플릿이나 특정 형식이 있나요?
5. 알아야 할 다른 제약 조건이나 맥락이 있나요?

축약어로 답하거나 가장 편한 방식으로 정보를 쏟아내도 된다고 알립니다.

사용자가 템플릿을 제공하거나 문서 유형을 언급하는 경우:

• 공유할 템플릿 문서가 있는지 물어봅니다
• 공유 문서 링크를 제공하면, 적절한 통합을 사용하여 가져옵니다
• 파일을 제공하면 읽습니다

사용자가 기존 공유 문서 편집을 언급하는 경우:

• 적절한 통합을 사용하여 현재 상태를 읽습니다
• 대체 텍스트 없는 이미지를 확인합니다
• 대체 텍스트 없는 이미지가 있으면, 다른 사람이 Claude를 사용하여 문서를 이해할 때 Claude가 볼 수 없다고 설명합니다. 대체 텍스트를 생성할 것인지 물어봅니다. 그렇다면 각 이미지를 채팅에 붙여넣도록 요청하여 설명적 대체 텍스트를 생성합니다.

정보 쏟아내기

초기 질문에 답한 후, 사용자가 가진 모든 맥락을 쏟아내도록 독려합니다. 다음과 같은 정보를 요청합니다:

• 프로젝트/문제에 대한 배경
• 관련 팀 논의 또는 공유 문서
• 대안 솔루션을 사용하지 않는 이유
• 조직적 맥락 (팀 역학, 과거 사건, 정치)
• 일정 압박이나 제약
• 기술 아키텍처 또는 의존성
• 이해관계자 우려 사항

정리할 걱정 없이 그냥 다 꺼내라고 조언합니다. 맥락을 제공하는 여러 방법을 제시합니다:

• 의식의 흐름대로 정보 쏟아내기
• 팀 채널이나 스레드를 가리키기
• 공유 문서 링크하기

통합이 사용 가능한 경우 (예: Slack, Teams, Google Drive, SharePoint, 또는 기타 MCP 서버), 이를 사용하여 맥락을 직접 가져올 수 있다고 언급합니다.

통합이 감지되지 않고 Claude.ai 또는 Claude 앱인 경우: Claude 설정에서 커넥터를 활성화하여 메시징 앱과 문서 저장소에서 직접 맥락을 가져올 수 있다고 제안합니다.

초기 쏟아내기가 끝나면 명확화 질문을 할 것이라고 알립니다.

맥락 수집 중:

• 사용자가 팀 채널이나 공유 문서를 언급하는 경우:

  • 통합이 사용 가능하면: 지금 내용을 읽겠다고 알리고, 적절한 통합을 사용합니다
  • 통합이 사용 불가능하면: 접근 권한이 없다고 설명합니다. Claude 설정에서 커넥터를 활성화하거나, 관련 내용을 직접 붙여넣도록 제안합니다.

• 사용자가 알 수 없는 엔티티/프로젝트를 언급하는 경우:

  • 연결된 도구를 사용하여 더 알아볼지 물어봅니다
  • 검색 전에 사용자 확인을 기다립니다

• 사용자가 맥락을 제공하면서, 알게 된 것과 아직 불분명한 것을 추적합니다

명확화 질문하기:

사용자가 초기 쏟아내기를 마쳤다고 신호를 보내면(또는 상당한 맥락이 제공된 후), 이해를 확인하기 위해 명확화 질문을 합니다:

맥락의 빈틈에 기반하여 5-10개의 번호가 매겨진 질문을 생성합니다.

축약어로 답하거나(예: "1: 네, 2: #channel 참조, 3: 아니요 하위 호환성 때문에"), 더 많은 문서를 링크하거나, 채널을 가리키거나, 정보 쏟아내기를 계속해도 된다고 알립니다. 가장 효율적인 방법이면 됩니다.

종료 조건:
질문이 이해를 보여줄 때 충분한 맥락이 수집된 것입니다 - 기본적인 것을 설명할 필요 없이 엣지 케이스와 트레이드오프에 대해 물어볼 수 있을 때.

전환:
이 단계에서 더 제공하고 싶은 맥락이 있는지, 또는 문서 초안 작성으로 넘어갈 시간인지 물어봅니다.

사용자가 더 추가하고 싶으면 그렇게 합니다. 준비되면 2단계로 진행합니다.

2단계: 다듬기 및 구조화

목표: 브레인스토밍, 큐레이션, 반복적 다듬기를 통해 섹션별로 문서를 구축합니다.

사용자에게 안내:
섹션별로 문서를 구축할 것이라고 설명합니다. 각 섹션에 대해:

1. 무엇을 포함할지 명확화 질문을 합니다
2. 5-20개의 옵션을 브레인스토밍합니다
3. 사용자가 유지/제거/결합할 것을 표시합니다
4. 섹션 초안을 작성합니다
5. 정밀한 편집을 통해 다듬습니다

미지수가 가장 많은 섹션(보통 핵심 결정/제안)부터 시작하고, 나머지를 진행합니다.

섹션 순서:

문서 구조가 명확한 경우:
어떤 섹션부터 시작할지 물어봅니다.

미지수가 가장 많은 섹션부터 시작하는 것을 제안합니다. 의사결정 문서의 경우, 보통 핵심 제안입니다. 스펙의 경우, 일반적으로 기술적 접근 방식입니다. 요약 섹션은 마지막에 하는 것이 가장 좋습니다.

사용자가 어떤 섹션이 필요한지 모르는 경우:
문서 유형과 템플릿에 기반하여, 문서 유형에 적합한 3-5개 섹션을 제안합니다.

이 구조가 괜찮은지, 조정하고 싶은지 물어봅니다.

구조가 합의되면:

모든 섹션에 대한 자리표시자 텍스트가 있는 초기 문서 구조를 만듭니다.

아티팩트에 접근 가능한 경우:
create_file을 사용하여 아티팩트를 만듭니다. 이렇게 하면 Claude와 사용자 모두 작업할 스캐폴드를 갖게 됩니다.

모든 섹션의 자리표시자가 있는 초기 구조를 만들겠다고 알립니다.

모든 섹션 헤더와 "[작성 예정]" 또는 "[내용 입력]" 같은 간략한 자리표시자 텍스트로 아티팩트를 만듭니다.

스캐폴드 링크를 제공하고 각 섹션을 채울 시간이라고 표시합니다.

아티팩트에 접근 불가능한 경우:
작업 디렉토리에 마크다운 파일을 만듭니다. 적절하게 이름을 지정합니다(예: decision-doc.md, technical-spec.md).

모든 섹션의 자리표시자가 있는 초기 구조를 만들겠다고 알립니다.

모든 섹션 헤더와 자리표시자 텍스트로 파일을 만듭니다.

파일명이 생성되었음을 확인하고 각 섹션을 채울 시간이라고 표시합니다.

각 섹션에 대해:

1단계: 명확화 질문

[섹션 이름] 섹션 작업을 시작하겠다고 알립니다. 무엇을 포함해야 하는지에 대한 5-10개의 명확화 질문을 합니다:

맥락과 섹션 목적에 기반하여 5-10개의 구체적인 질문을 생성합니다.

축약어로 답하거나 무엇이 중요한지 표시하면 된다고 알립니다.

2단계: 브레인스토밍

[섹션 이름] 섹션에 대해, 섹션의 복잡도에 따라 포함될 수 있는 [5-20]개의 것을 브레인스토밍합니다. 다음을 찾습니다:

• 공유된 맥락 중 잊혀졌을 수 있는 것
• 아직 언급되지 않은 각도나 고려 사항

섹션 복잡도에 기반하여 5-20개의 번호가 매겨진 옵션을 생성합니다. 마지막에 추가 옵션을 원하면 더 브레인스토밍하겠다고 제안합니다.

3단계: 큐레이션

어떤 포인트를 유지, 제거 또는 결합할지 물어봅니다. 다음 섹션의 우선순위를 배우는 데 도움이 되도록 간략한 근거를 요청합니다.

예시를 제공합니다:

• "1,4,7,9 유지"
• "3 제거 (1과 중복)"
• "6 제거 (독자가 이미 알고 있음)"
• "11과 12 결합"

사용자가 자유 형식 피드백을 주는 경우 (예: "좋아 보여요" 또는 "대부분 마음에 들지만...") 번호 선택 대신, 선호도를 추출하고 진행합니다. 유지/제거/변경하고 싶은 것을 파악하고 적용합니다.

4단계: 빈틈 확인

선택한 것에 기반하여, [섹션 이름] 섹션에 빠진 중요한 것이 있는지 물어봅니다.

5단계: 초안 작성

str_replace를 사용하여 이 섹션의 자리표시자 텍스트를 실제 초안 내용으로 교체합니다.

선택한 것에 기반하여 [섹션 이름] 섹션을 지금 초안 작성하겠다고 알립니다.

아티팩트를 사용하는 경우:
초안 작성 후, 아티팩트 링크를 제공합니다.

한번 읽어보고 변경할 것을 표시해 달라고 요청합니다. 구체적일수록 다음 섹션을 위한 학습에 도움이 된다고 알립니다.

파일을 사용하는 경우 (아티팩트 없음):
초안 작성 후, 완료를 확인합니다.

[파일명]에 [섹션 이름] 섹션이 초안 작성되었다고 알립니다. 한번 읽어보고 변경할 것을 표시해 달라고 요청합니다. 구체적일수록 다음 섹션을 위한 학습에 도움이 된다고 알립니다.

사용자에게 주요 안내 (첫 섹션 초안 작성 시 포함):
참고 사항을 제공합니다: 문서를 직접 편집하는 대신, 변경할 것을 표시해 달라고 요청합니다. 이렇게 하면 향후 섹션을 위한 스타일 학습에 도움이 됩니다. 예: "X 항목 제거 - Y에서 이미 다룸" 또는 "세 번째 단락을 더 간결하게 만들어 주세요".

6단계: 반복적 다듬기

사용자가 피드백을 제공하면:

• str_replace를 사용하여 편집합니다 (전체 문서를 절대 다시 출력하지 않습니다)
• 아티팩트를 사용하는 경우: 각 편집 후 아티팩트 링크를 제공합니다
• 파일을 사용하는 경우: 편집 완료를 확인합니다
• 사용자가 문서를 직접 편집하고 읽어달라고 요청하면: 그들이 한 변경 사항을 정신적으로 기록하고 향후 섹션에 고려합니다 (이것은 선호도를 보여줍니다)

사용자가 섹션에 만족할 때까지 반복을 계속합니다.

품질 확인

실질적인 변경 없이 3회 연속 반복 후, 중요한 정보를 잃지 않고 제거할 수 있는 것이 있는지 물어봅니다.

섹션이 완료되면 [섹션 이름]이 완료되었음을 확인합니다. 다음 섹션으로 넘어갈 준비가 되었는지 물어봅니다.

모든 섹션에 대해 반복합니다.

완료 근접

완료에 근접하면(80% 이상의 섹션 완료), 전체 문서를 다시 읽고 다음을 확인하겠다고 알립니다:

• 섹션 간 흐름과 일관성
• 중복이나 모순
• "부실한" 내용이나 일반적인 채우기처럼 느껴지는 것
• 모든 문장이 가치를 갖는지

전체 문서를 읽고 피드백을 제공합니다.

모든 섹션이 초안 작성되고 다듬어지면:
모든 섹션이 초안 작성되었다고 알립니다. 완전한 문서를 한 번 더 검토하겠다고 알립니다.

전체적인 일관성, 흐름, 완전성을 검토합니다.

최종 제안을 제공합니다.

독자 테스트로 넘어갈 준비가 되었는지, 아니면 더 다듬고 싶은 것이 있는지 물어봅니다.

3단계: 독자 테스트

목표: 새로운 Claude(맥락 오염 없음)로 문서를 테스트하여 독자에게 작동하는지 확인합니다.

사용자에게 안내:
문서가 실제로 독자에게 작동하는지 테스트하겠다고 설명합니다. 이것은 사각지대를 잡습니다 - 저자에게는 이해가 되지만 다른 사람을 혼란스럽게 할 수 있는 것들.

테스트 접근 방식

서브에이전트에 접근 가능한 경우 (예: Claude Code에서):

사용자 개입 없이 직접 테스트를 수행합니다.

1단계: 독자 질문 예측

독자가 이 문서를 발견하려 할 때 어떤 질문을 할지 예측하겠다고 알립니다.

독자가 현실적으로 물어볼 5-10개의 질문을 생성합니다.

2단계: 서브에이전트로 테스트

이 질문들을 새로운 Claude 인스턴스(이 대화의 맥락 없음)로 테스트하겠다고 알립니다.

각 질문에 대해, 문서 내용과 질문만으로 서브에이전트를 호출합니다.

독자 Claude가 각 질문에 대해 맞은 것/틀린 것을 요약합니다.

3단계: 추가 검사 실행

추가 검사를 수행하겠다고 알립니다.

모호성, 잘못된 가정, 모순을 확인하기 위해 서브에이전트를 호출합니다.

발견된 문제를 요약합니다.

4단계: 보고 및 수정

문제가 발견된 경우:
독자 Claude가 특정 문제에서 어려움을 겪었다고 보고합니다.

구체적인 문제를 나열합니다.

이 빈틈을 수정하겠다고 알립니다.

문제가 있는 섹션에 대해 다듬기로 돌아갑니다.

---

서브에이전트에 접근 불가능한 경우 (예: Claude.ai 웹 인터페이스):

사용자가 수동으로 테스트를 해야 합니다.

1단계: 독자 질문 예측

사람들이 이 문서를 발견하려 할 때 어떤 질문을 할지 물어봅니다. Claude.ai에 무엇을 입력할 것인가요?

독자가 현실적으로 물어볼 5-10개의 질문을 생성합니다.

2단계: 테스트 설정

테스트 지침을 제공합니다:

1. 새 Claude 대화를 엽니다: https://claude.ai
2. 문서 내용을 붙여넣거나 공유합니다 (커넥터가 활성화된 공유 문서 플랫폼을 사용하는 경우 링크 제공)
3. 독자 Claude에게 생성된 질문을 합니다

각 질문에 대해, 독자 Claude에게 다음을 제공하도록 지시합니다:

• 답변
• 모호하거나 불분명한 것이 있었는지
• 문서가 이미 알고 있다고 가정하는 지식/맥락

독자 Claude가 올바른 답변을 주는지 아니면 잘못 해석하는 것이 있는지 확인합니다.

3단계: 추가 검사

또한 독자 Claude에게 다음을 물어봅니다:

• "이 문서에서 독자에게 모호하거나 불분명할 수 있는 것은 무엇인가요?"
• "이 문서가 독자에게 이미 알고 있다고 가정하는 지식이나 맥락은 무엇인가요?"
• "내부 모순이나 불일치가 있나요?"

4단계: 결과에 기반한 반복

독자 Claude가 무엇을 잘못했거나 어려워했는지 물어봅니다. 해당 빈틈을 수정하겠다고 알립니다.

문제가 있는 섹션에 대해 다듬기로 돌아갑니다.

---

종료 조건 (두 접근 방식 모두)

독자 Claude가 일관되게 질문에 올바르게 답하고 새로운 빈틈이나 모호성을 발견하지 않으면, 문서가 준비된 것입니다.

최종 검토

독자 테스트가 통과되면:
문서가 독자 Claude 테스트를 통과했다고 알립니다. 완료 전에:

1. 직접 최종 읽기를 권장합니다 - 이 문서의 소유자이며 품질에 책임이 있습니다
2. 사실, 링크 또는 기술적 세부 사항을 이중 확인하도록 제안합니다
3. 원했던 영향을 달성하는지 확인하도록 요청합니다

한 번 더 검토를 원하는지, 작업이 끝났는지 물어봅니다.

사용자가 최종 검토를 원하면 제공합니다. 그렇지 않으면:
문서 완성을 알립니다. 몇 가지 최종 팁을 제공합니다:

• 독자가 문서가 어떻게 개발되었는지 볼 수 있도록 부록에 이 대화를 링크하는 것을 고려합니다
• 본문을 부풀리지 않고 깊이를 제공하기 위해 부록을 사용합니다
• 실제 독자로부터 피드백을 받으면 문서를 업데이트합니다

효과적인 안내를 위한 팁

톤:

• 직접적이고 절차적으로
• 사용자 행동에 영향을 미치는 경우 간략히 이유를 설명합니다
• 접근 방식을 "판매"하려 하지 않습니다 - 그냥 실행합니다

이탈 처리:

• 사용자가 단계를 건너뛰고 싶어하면: 이것을 건너뛰고 자유 형식으로 작성하고 싶은지 물어봅니다
• 사용자가 답답해하는 것 같으면: 예상보다 오래 걸리고 있다는 것을 인정합니다. 더 빨리 진행할 수 있는 방법을 제안합니다
• 항상 사용자에게 프로세스를 조정할 주도권을 줍니다

맥락 관리:

• 전체적으로, 언급된 것에 대한 맥락이 부족하면 능동적으로 물어봅니다
• 빈틈이 쌓이지 않도록 합니다 - 발생하는 즉시 해결합니다

아티팩트 관리:

• 전체 섹션 초안 작성에 create_file을 사용합니다
• 모든 편집에 str_replace를 사용합니다
• 모든 변경 후 아티팩트 링크를 제공합니다
• 브레인스토밍 목록에는 아티팩트를 사용하지 않습니다 - 그것은 대화일 뿐입니다

속도보다 품질:

• 단계를 서두르지 않습니다
• 각 반복은 의미 있는 개선을 해야 합니다
• 목표는 실제로 독자에게 작동하는 문서입니다