문서 공동 작성
문서 공동 작성을 위한 구조화된 워크플로를 사용자에게 안내합니다. 사용자가 문서, 제안서, 기술 사양, 의사 결정 문서 또는 유사한 구조의 콘텐츠를 작성하려고 할 때 사용합니다. 이 워크플로는 사용자가 효율적으로 컨텍스트를 전달하고, 반복을 통해 콘텐츠를 구체화하고, 문서가 독자에게 적합한지 확인하는 데 도움이 됩니다. 사용자가 문서 작성, 제안서 작성, 사양 초안 작성 또는 유사한 문서 작업을 언급할 때 트리거됩니다.
출처: 인류학/기술(MIT)에서 채택한 콘텐츠.
이 기술은 공동 문서 작성을 통해 사용자를 안내하기 위한 구조화된 작업 흐름을 제공합니다. 적극적인 가이드 역할을 하여 사용자에게 컨텍스트 수집, 개선 및 구조, 독자 테스트의 세 단계를 안내합니다.
이 워크플로를 제공하는 경우
트리거 조건:
- 사용자가 문서 작성에 대해 언급함: "문서 작성", "제안서 초안 작성", "사양 작성", "작성"
- 사용자가 특정 문서 유형을 언급합니다: "PRD", "design doc", "decision doc", "RFC"
- 사용자가 상당한 글쓰기 작업을 시작한 것 같습니다.
최초 제안: 사용자에게 문서 공동 작성을 위한 구조화된 워크플로를 제공합니다. 세 단계를 설명하십시오.
- 컨텍스트 수집: Claude가 명확한 질문을 하는 동안 사용자는 모든 관련 컨텍스트를 제공합니다.
- 세분화 및 구조: 브레인스토밍과 편집을 통해 반복적으로 각 섹션을 구축합니다.
- 독자 테스트: 새로운 Claude(맥락 없음)로 문서를 테스트하여 다른 사람이 읽기 전에 사각지대를 찾아냅니다.
이 접근 방식은 다른 사람이 문서를 읽을 때(Claude에 붙여넣을 때 포함) 문서가 제대로 작동하는지 확인하는 데 도움이 된다고 설명합니다. 이 워크플로를 시도하고 싶은지, 아니면 자유로운 형식으로 작업하는 것을 선호하는지 물어보세요.
사용자가 거부하면 자유롭게 작업하세요. 사용자가 동의하면 1단계로 진행합니다.
1단계: 맥락 수집
목표: 사용자가 알고 있는 것과 Claude가 알고 있는 것 사이의 격차를 줄여 나중에 스마트한 안내를 가능하게 합니다.
초기 질문
사용자에게 문서에 대한 메타 컨텍스트를 묻는 것부터 시작하세요.
- 이것은 어떤 종류의 문서입니까? (예: 기술 사양, 결정 문서, 제안서)
- 주요 청중은 누구입니까?
- 누군가가 이것을 읽을 때 원하는 영향은 무엇입니까?
- 따라야 할 템플릿이나 특정 형식이 있습니까?
- 알아야 할 다른 제약이나 상황이 있나요?
간략하게 답변하거나 정보를 덤프할 수 있지만 자신에게 가장 적합하다고 알려주세요.
사용자가 템플릿을 제공하거나 문서 유형을 언급하는 경우:
- 공유할 템플릿 문서가 있는지 물어보세요.
- 공유 문서에 대한 링크를 제공하는 경우 적절한 통합을 사용하여 이를 가져옵니다.
- 파일을 제공하면 읽어보세요.
사용자가 기존 공유 문서 편집을 언급하는 경우:
- 적절한 통합을 사용하여 현재 상태를 읽습니다.
- 대체 텍스트가 없는 이미지를 확인하세요.
- 대체 텍스트가 없는 이미지가 있는 경우 다른 사람이 Claude를 사용하여 문서를 이해할 때 Claude는 해당 이미지를 볼 수 없다고 설명합니다. 대체 텍스트 생성을 원하는지 물어보세요. 그렇다면 설명 대체 텍스트 생성을 위해 각 이미지를 채팅에 붙여넣도록 요청하세요.
정보 덤핑
초기 질문에 대한 답변이 끝나면 사용자가 가지고 있는 모든 컨텍스트를 덤프하도록 권장하십시오. 다음과 같은 정보를 요청하세요.
- 프로젝트/문제에 대한 배경
- 관련 팀 토론 또는 공유 문서
- 대체 솔루션이 사용되지 않는 이유
- 조직적 맥락(팀 역학, 과거 사건, 정치)
- 일정 압박 또는 제약
- 기술 아키텍처 또는 종속성
- 이해관계자의 우려
정리하는 것에 대해 걱정하지 말고 그냥 모두 꺼내놓으라고 조언하십시오. 컨텍스트를 제공하는 다양한 방법을 제공합니다.
- 정보 덤프 의식의 흐름
- 읽을 팀 채널이나 스레드를 가리킵니다.
- 공유 문서에 대한 링크
통합이 가능한 경우(예: Slack, Teams, Google Drive, SharePoint 또는 기타 MCP 서버) 컨텍스트를 직접 가져오는 데 사용할 수 있다고 언급하세요.
Claude.ai 또는 Claude 앱에서 통합이 감지되지 않는 경우: 메시징 앱 및 문서 저장소에서 직접 컨텍스트를 가져올 수 있도록 Claude 설정에서 커넥터를 활성화할 수 있다고 제안합니다.
초기 덤프를 완료한 후 명확한 질문을 받게 될 것이라고 알립니다.
컨텍스트 수집 중:
-
사용자가 팀 채널이나 공유 문서를 언급하는 경우:
- 통합이 가능한 경우: 지금 콘텐츠를 읽을 것이라고 알리고 적절한 통합을 사용하세요.
- 통합을 사용할 수 없는 경우: 액세스 부족을 설명하세요. Claude 설정에서 커넥터를 활성화하거나 관련 콘텐츠를 직접 붙여넣을 것을 제안하세요.
-
사용자가 알 수 없는 엔터티/프로젝트를 언급하는 경우:
- 자세한 내용을 알아보려면 연결된 도구를 검색해야 하는지 물어보세요.
- 검색하기 전에 사용자 확인을 기다립니다.
-
사용자가 컨텍스트를 제공하면 학습 중인 내용과 여전히 불분명한 내용을 추적합니다.
명확한 질문을 하는 경우:
사용자가 초기 덤프를 완료했다는 신호를 보내면(또는 상당한 맥락이 제공된 후) 이해를 돕기 위해 명확한 질문을 하십시오.
맥락의 공백을 기준으로 5~10개의 번호가 매겨진 질문을 생성합니다.
속기를 사용하여 대답할 수 있음(예: "1: 예, 2: #채널 참조, 3: 이전 버전과 호환되므로 아니요"), 더 많은 문서에 대한 링크, 읽을 채널을 가리키거나 정보 덤프를 계속할 수 있음을 알립니다. 무엇이든지 그들에게 가장 효율적인 것입니다.
종료 조건: 질문에 이해가 있음이 입증되면 충분한 맥락이 수집됩니다. 즉, 기본 설명 없이도 극단적인 사례와 장단점에 대해 질문할 수 있는 경우입니다.
전환: 이 단계에서 제공하고 싶은 추가 컨텍스트가 있는지, 아니면 문서 초안 작성으로 넘어갈 때가 되었는지 물어보세요.
사용자가 더 추가하고 싶다면 허용하세요. 준비가 되면 2단계로 진행합니다.
2단계: 개선 및 구조
목표: 브레인스토밍, 큐레이션, 반복적인 개선을 통해 섹션별로 문서 섹션을 구축합니다.
사용자 지침: 문서가 섹션별로 작성될 것이라고 설명합니다. 각 섹션에 대해:
- 포함할 내용에 대해 명확한 질문을 하게 됩니다.
- 5~20가지 옵션을 브레인스토밍합니다.
- 사용자는 무엇을 유지/제거/결합할지 표시합니다.
- 섹션의 초안이 작성됩니다.
- 수술적 교정을 통해 개선될 예정입니다.
가장 알려지지 않은 부분(일반적으로 핵심 결정/제안)이 있는 섹션부터 시작한 다음 나머지 부분을 진행하세요.
섹션 순서:
문서 구조가 명확한 경우: 어떤 섹션부터 시작하고 싶은지 물어보세요.
알려지지 않은 부분이 가장 많은 섹션부터 시작하는 것이 좋습니다. 의사결정 문서의 경우 이는 일반적으로 핵심 제안입니다. 사양의 경우 일반적으로 기술적 접근 방식입니다. 요약 섹션은 마지막에 남겨 두는 것이 가장 좋습니다.
사용자가 어떤 섹션이 필요한지 모르는 경우: 문서 유형과 템플릿에 따라 문서 유형에 적합한 섹션을 3~5개 제안합니다.
이 구조가 작동하는지, 아니면 조정하고 싶은지 물어보세요.
구조가 합의되면:
모든 섹션에 대한 자리 표시자 텍스트를 사용하여 초기 문서 구조를 만듭니다.
아티팩트에 대한 액세스가 가능한 경우:
create_file를 사용하여 아티팩트를 생성합니다. 이는 Claude와 사용자 모두에게 작업할 수 있는 발판을 제공합니다.
모든 섹션에 대한 자리 표시자가 포함된 초기 구조가 생성될 것이라고 알립니다.
모든 섹션 헤더와 "[쓰기 예정]" 또는 "[여기에 콘텐츠]"와 같은 간단한 자리 표시자 텍스트가 포함된 아티팩트를 생성합니다.
비계 링크를 제공하고 각 섹션을 작성할 시간임을 나타냅니다.
아티팩트에 액세스할 수 없는 경우:
작업 디렉터리에 마크다운 파일을 만듭니다. 이름을 적절하게 지정합니다(예:decision-doc.md,technical-spec.md).
모든 섹션에 대한 자리 표시자가 포함된 초기 구조가 생성될 것이라고 알립니다.
모든 섹션 헤더와 자리 표시자 텍스트가 포함된 파일을 만듭니다.
파일 이름이 생성되었는지 확인하고 각 섹션을 채울 시간임을 나타냅니다.
각 섹션에 대해:
1단계: 질문 명확화
공지 작업은 [SECTION NAME] 섹션에서 시작됩니다. 무엇이 포함되어야 하는지에 대해 5~10개의 명확한 질문을 해보세요.
문맥과 섹션 목적에 따라 5~10개의 특정 질문을 생성합니다.
간략하게 답변하거나 다루어야 할 중요한 내용을 표시할 수 있음을 알려주십시오.
2단계: 브레인스토밍
[SECTION NAME] 섹션의 경우 섹션의 복잡성에 따라 포함될 수 있는 항목을 [5-20] 브레인스토밍하세요. 다음을 찾으세요:
- 잊혀졌을 수도 있는 맥락 공유
- 아직 언급되지 않은 각도나 고려 사항
섹션 복잡성에 따라 5~20개의 번호가 매겨진 옵션을 생성합니다. 마지막에 추가 옵션을 원한다면 더 브레인스토밍을 제안하세요.
3단계: 큐레이션
어떤 점을 유지, 제거 또는 결합해야 하는지 물어보세요. 다음 섹션의 우선순위를 파악하는 데 도움이 되도록 간략한 근거를 요청하세요.
예시를 제공하세요:
- "1,4,7,9를 유지하세요"
- "3개 제거(1개 중복)"
- "6개 제거(청중은 이미 알고 있음)"
- "11과 12를 결합하세요"
사용자가 번호가 매겨진 선택 항목 대신 자유 형식 피드백(예: "좋아 보인다" 또는 "대부분은 마음에 들지만...")을 제공하는 경우 선호도를 추출하고 진행합니다. 유지/제거/변경하려는 항목을 구문 분석하고 적용합니다.
4단계: 간격 확인
선택한 항목에 따라 [SECTION NAME] 섹션에 중요한 누락 항목이 있는지 물어보세요.
5단계: 제도
str_replace를 사용하여 이 섹션의 자리 표시자 텍스트를 실제 초안 콘텐츠로 바꾸세요.
[SECTION NAME] 섹션의 초안이 이제 선택한 항목에 따라 작성될 것임을 알립니다.
아티팩트를 사용하는 경우: 초안을 작성한 후 아티팩트에 대한 링크를 제공하십시오.
그 내용을 읽고 무엇을 바꿔야 하는지 알려 달라고 하십시오. 구체적으로 설명하면 다음 섹션을 학습하는 데 도움이 됩니다.
파일을 사용하는 경우(아티팩트 없음): 초안 작성 후 완료를 확인합니다.
[SECTION NAME] 섹션이 [filename]에 작성되었음을 알려주세요. 그 내용을 읽고 무엇을 바꿔야 하는지 알려 달라고 하십시오. 구체적으로 설명하면 다음 섹션을 학습하는 데 도움이 됩니다.
사용자를 위한 주요 지침(첫 번째 섹션 초안 작성 시 포함): 메모 제공: 문서를 직접 편집하는 대신 변경할 내용을 알려달라고 요청하세요. 이는 향후 섹션에 대한 스타일을 학습하는 데 도움이 됩니다. 예: "X 글머리 기호 제거 - 이미 Y로 덮여 있음" 또는 "세 번째 단락을 더 간결하게 만들기".
6단계: 반복적 개선
사용자가 피드백을 제공함에 따라:
- 편집하려면
str_replace를 사용하세요(문서 전체를 다시 인쇄하지 마세요). - 아티팩트를 사용하는 경우: 각 편집 후 아티팩트에 대한 링크 제공
- 파일을 사용하는 경우: 수정이 완료되었는지 확인하세요.
- 사용자가 문서를 직접 편집하고 읽어 보라고 요청하는 경우: 변경 사항을 정신적으로 기록하고 향후 섹션에서 이를 염두에 두십시오(이는 사용자의 선호도를 나타냅니다).
사용자가 해당 섹션에 만족할 때까지 계속 반복합니다.
품질 검사
큰 변화 없이 3번 연속 반복한 후에 중요한 정보를 잃지 않고 제거할 수 있는 것이 있는지 물어보세요.
섹션이 완료되면 [SECTION NAME]이 완료되었는지 확인하세요. 다음 섹션으로 이동할 준비가 되었는지 물어보세요.
모든 섹션에 대해 반복합니다.
거의 완료됨
완료가 가까워지면(섹션의 80% 이상 완료) 전체 문서를 다시 읽고 다음 사항을 확인하겠다고 발표합니다.
- 섹션 간 흐름 및 일관성
- 중복 또는 모순
- "슬롭" 또는 일반적인 필러처럼 느껴지는 모든 것
- 모든 문장에 무게가 있는지 여부
전체 문서를 읽고 피드백을 제공하세요.
모든 섹션의 초안을 작성하고 다듬은 경우: 모든 섹션의 초안이 작성되었음을 알립니다. 전체 문서를 한 번 더 검토할 의사가 있음을 나타냅니다.
전반적인 일관성, 흐름, 완전성을 검토합니다.
최종 제안 사항을 알려주십시오.
독자 테스트로 전환할 준비가 되었는지, 아니면 다른 사항을 개선하고 싶은지 물어보세요.
3단계: 리더 테스트
목표: 새로운 Claude(컨텍스트 블리드 없음)로 문서를 테스트하여 독자에게 적합한지 확인합니다.
사용자 지침: 이제 문서가 실제로 독자에게 작동하는지 확인하기 위해 테스트가 수행될 것이라고 설명합니다. 이는 저자에게는 이해가 되지만 다른 사람들에게는 혼란을 줄 수 있는 맹점을 포착합니다.
테스트 접근법
하위 에이전트에 대한 액세스가 가능한 경우(예: Claude Code에서):
사용자 개입 없이 직접 테스트를 수행합니다.
1단계: 독자의 질문 예측
독자가 이 문서를 검색하려고 할 때 어떤 질문을 할지 예측하려는 의도를 발표합니다.
독자들이 현실적으로 물어볼 질문을 5~10개 생성하세요.
2단계: 하위 에이전트로 테스트
이러한 질문은 새로운 Claude 인스턴스로 테스트될 것이라고 발표합니다(이 대화에는 맥락이 없습니다).
각 질문에 대해 문서 콘텐츠와 질문만으로 하위 에이전트를 호출합니다.
독자 Claude가 각 질문에 대해 옳고 그름을 요약합니다.
3단계: 추가 검사 실행
추가 점검을 실시할 예정임을 공지합니다.
모호성, 잘못된 가정, 모순을 확인하기 위해 하위 에이전트를 호출합니다.
발견된 문제를 요약합니다.
4단계: 보고 및 수정
문제가 발견된 경우: 독자 Claude가 특정 문제로 어려움을 겪었다고 보고합니다.
구체적인 문제를 나열하세요.
이러한 격차를 해결하려는 의도를 나타냅니다.
문제가 있는 섹션을 개선하기 위해 루프백합니다.
하위 에이전트(예: claude.ai 웹 인터페이스)에 액세스할 수 없는 경우:
사용자는 수동으로 테스트를 수행해야 합니다.
1단계: 독자의 질문 예측
사람들이 이 문서를 찾으려고 할 때 어떤 질문을 할지 물어보세요. Claude.ai에 무엇을 입력할까요?
독자들이 현실적으로 물어볼 질문을 5~10개 생성하세요.
2단계: 설정 테스트
테스트 지침을 제공하십시오.
- 새로운 Claude 대화 열기: https://claude.ai
- 문서 내용을 붙여넣거나 공유합니다(커넥터가 활성화된 공유 문서 플랫폼을 사용하는 경우 링크 제공).
- 독자 Claude에게 생성된 질문을 물어보세요.
각 질문에 대해 독자 Claude에게 다음을 제공하도록 지시하십시오.
- 대답
- 모호하거나 불분명한 것이 있었는지
- 문서가 이미 알고 있다고 가정하는 지식/맥락
독자 클로드가 정답을 제시하거나 잘못 해석한 내용이 있는지 확인하세요.
3단계: 추가 확인
또한 독자 Claude에게 물어보십시오.
- "이 문서의 어떤 내용이 독자에게 모호하거나 불분명할 수 있습니까?"
- "이 문서에서는 독자가 이미 어떤 지식이나 맥락을 갖고 있다고 가정합니까?"
- "내부 모순이나 불일치가 있습니까?"
4단계: 결과에 따라 반복
독자 Claude가 무엇을 잘못했거나 어려움을 겪었는지 물어보십시오. 이러한 격차를 해결하려는 의도를 나타냅니다.
문제가 있는 섹션을 개선하기 위해 루프백하세요.
종료 조건(두 가지 접근 방식 모두)
독자 클로드가 지속적으로 질문에 올바르게 대답하고 새로운 격차나 모호성을 드러내지 않으면 문서가 준비된 것입니다.
최종 검토
리더 테스트를 통과한 경우: 문서가 Reader Claude 테스트를 통과했음을 발표합니다. 완료 전:
- 최종적으로 스스로 읽어볼 것을 권장합니다. 이 문서는 자신의 소유이며 품질에 대한 책임은 본인에게 있습니다.
- 사실, 링크 또는 기술적 세부 사항을 다시 확인하도록 제안합니다.
- 원하는 효과를 달성하는지 확인하도록 요청하세요.
리뷰를 한 번 더 원하는지, 아니면 작업이 완료되었는지 물어보세요.
사용자가 최종 검토를 원하는 경우 제공하세요. 그렇지 않은 경우: 문서 완료를 알립니다. 몇 가지 최종 팁을 제공하세요.
- 독자들이 문서가 어떻게 개발되었는지 볼 수 있도록 이 대화를 부록에 연결하는 것을 고려해 보세요.
- 부록을 사용하여 기본 문서를 부풀리지 않고 깊이를 제공하세요.
- 실제 독자로부터 피드백을 받으면 문서를 업데이트하세요.
효과적인 지도를 위한 팁
어조:
- 직접적이고 절차적이어야 합니다.
- 사용자 행동에 영향을 미치는 이유를 간략하게 설명하세요.
- 접근 방식을 "판매"하려고 하지 말고 그냥 실행하세요.
편차 처리:
- 사용자가 단계를 건너뛰고 싶은 경우: 이 단계를 건너뛰고 싶은지 묻고 자유 형식으로 작성하세요.
- 사용자가 좌절감을 느끼는 경우: 예상보다 시간이 오래 걸린다는 점을 인정하세요. 더 빠르게 움직일 수 있는 방법을 제안해주세요
- 항상 사용자에게 프로세스 조정 권한을 부여하세요.
컨텍스트 관리:
- 전체적으로 언급된 내용에 대한 맥락이 누락된 경우 적극적으로 질문하세요.
- 공백이 쌓이도록 두지 마십시오. 공백이 생기면 해결하십시오.
아티팩트 관리:
- 전체 단면 초안을 작성하려면
create_file를 사용하세요. - 모든 편집에는
str_replace를 사용하세요. - 모든 변경 후 아티팩트 링크 제공
- 브레인스토밍 목록에 아티팩트를 사용하지 마십시오. 이는 단지 대화일 뿐입니다.
속도보다 품질:
- 단계를 서두르지 마세요.
- 각 반복은 의미 있는 개선을 가져와야 합니다.
- 목표는 독자에게 실제로 작동하는 문서입니다.
GitHub에서 보기
웹앱 테스트
서버 오케스트레이션 도우미 및 문제 해결 팁이 포함된 Playwright 기반 웹 앱 테스트를 위한 에이전트 기술 핸드북입니다.
Docx
사용자가 Word 문서(.docx 파일)를 생성, 읽기, 편집 또는 조작하려고 할 때마다 이 기술을 사용하십시오. 트리거에는 'Word 문서', '워드 문서', '.docx'에 대한 언급 또는 목차, 제목, 페이지 번호 또는 레터헤드와 같은 형식의 전문 문서 생성 요청이 포함됩니다. 또한.docx 파일에서 콘텐츠를 추출 또는 재구성할 때, 문서에 이미지를 삽입하거나 바꿀 때, Word 파일에서 찾기 및 바꾸기를 수행할 때, 추적된 변경 내용이나 주석 작업을 할 때, 콘텐츠를 세련된 Word 문서로 변환할 때 사용합니다. 사용자가 '보고서', '메모', '편지', '템플릿' 또는 Word 또는.docx 파일과 유사한 결과물을 요청하는 경우 이 기술을 사용하세요. PDF, 스프레드시트, Google Docs 또는 문서 생성과 관련 없는 일반 코딩 작업에는 사용하지 마세요.
클로데스킬스 문서