create-colleague

create-colleague 스킬 개요

create-colleague 스킬이 하는 일

create-colleague 스킬은 실제 동료가 남긴 산출물을 재사용 가능한 AI 스킬로 바꿔 줍니다. 핵심은 일반적인 인물 소개를 쓰는 것이 아니라, 그 사람이 어떻게 일하고, 어떻게 소통하며, 어떤 기준으로 의사결정을 내리는지를 추출해 문서, 채팅, 스크린샷, 이메일, Feishu·DingTalk 같은 업무 플랫폼 자료로부터 실제로 쓸 수 있는 협업자 프로필을 재현하는 데 있습니다.

create-colleague를 설치하면 좋은 사람

이 스킬은 팀원이 퇴사하거나, 이동하거나, 업무를 인수인계한 뒤에도 운영 노하우를 보존하고 싶은 Skill Authoring 사용자에게 특히 잘 맞습니다. 팀의 근거 자료가 여러 업무 도구에 흩어져 있고, “이 사람 말투처럼 보이게 프롬프트 하나 써줘” 수준보다 더 구조화된 결과가 필요할 때 특히 유용합니다.

일반 프롬프트와 다른 점

일반 프롬프트는 말투를 흉내 내는 데는 도움이 될 수 있습니다. 하지만 create-colleague skill은 두 가지 출력을 분리해서 만드는 데 초점을 둡니다. 하나는 실제 업무 수행을 위한 work skill, 다른 하나는 커뮤니케이션 스타일을 위한 persona 레이어입니다. 여기에 Feishu, DingTalk, 이메일, 파일 기반 입력을 수집하는 경로까지 포함되어 있어, 채팅창에 단편적인 조각을 수동으로 붙여넣는 방식보다 훨씬 실무적입니다.

설치 전에 사용자가 확인하는 포인트

대부분의 도입 판단은 네 가지 질문으로 정리됩니다. 현재 가진 자료가 지원되는지, 설치가 특정 agent 환경에 묶여 있는지, 처음 생성한 결과를 나중에 수정할 수 있는지, 그리고 결과를 시간이 지나며 계속 발전시킬 수 있는지입니다. 이 기준으로 보면 create-colleague는 Claude Code 스타일의 스킬 워크플로우에서 가장 강점이 크고, 자동 수집과 수동 수집을 모두 지원하며, 수정 사항이나 새 파일을 반영하는 업데이트/진화 플로우도 명시적으로 제공합니다.

create-colleague가 잘 맞는 경우와 아닌 경우

create-colleague는 실제로 그 사람이 어떻게 일했는지 보여 주는 근거가 있을 때 쓰는 것이 맞습니다. 예를 들면 메시지 기록, 문서, 이메일, 스크린샷, 혹은 충분히 구체적인 서술형 설명이 있는 경우입니다. 반대로 가상의 페르소나가 필요하거나, 가볍게 한 번 말투만 흉내 내면 되거나, 일반적인 팀 역할 템플릿만 만들고 싶은 경우라면 굳이 이 스킬을 고를 필요가 없습니다. 이 스킬은 근거 있는 추출을 위한 것이지, 빈약한 입력으로 롤플레이를 만드는 도구가 아닙니다.

create-colleague 스킬 사용 방법

올바른 스킬 디렉터리에 create-colleague 설치하기

이 repo의 공식 설치 방식은 npx가 아니라 clone 기반입니다. Claude Code에서는 프로젝트 단위 또는 전역 skills 디렉터리 아래에 create-colleague라는 이름으로 설치해야 합니다.

# project-local
mkdir -p .claude/skills
git clone https://github.com/titanwings/colleague-skill .claude/skills/create-colleague

# or global
git clone https://github.com/titanwings/colleague-skill ~/.claude/skills/create-colleague

OpenClaw에서는 다음과 같습니다.

git clone https://github.com/titanwings/colleague-skill ~/.openclaw/workspace/skills/create-colleague

이 점이 중요한 이유는, 스킬 트리거와 생성 결과 경로가 지정된 설치 디렉터리 이름을 기준으로 동작하도록 가정하고 있기 때문입니다.

collector 테스트 전에 의존성부터 설치하기

실제 create-colleague install 경로는 어떤 소스를 수집할지에 따라 달라집니다. 기본 요구 사항은 Python 3.9+이며, 선택 패키지를 설치하면 더 나은 ingestion 경로를 사용할 수 있습니다.

pip3 install pypinyin
pip3 install playwright
playwright install chromium
npm install -g feishu-mcp
pip3 install python-docx openpyxl

이 단계를 건너뛰어도 수동 업로드나 텍스트 입력만으로 스킬을 돌리는 것은 가능합니다. 다만 자동 수집이나 일부 파일 변환 경로는 동작하지 않게 됩니다.

실제 트리거로 create-colleague 실행하기

지원되는 agent 환경에서는 /create-colleague로 실행합니다. repo에는 자연어 트리거 예시도 문서화되어 있고, /update-colleague {slug}, /list-colleagues 같은 업데이트 플로우도 포함되어 있습니다. 설치 후 “정상적으로 깨어나는지”를 확인하는 수준의 테스트라도, 가장 먼저 검증해야 할 것은 이 트리거 동작입니다.

create-colleague에 어떤 입력이 필요한지 이해하기

좋은 결과는 보통 두 종류의 입력을 함께 넣을 때 나옵니다.

1. 그 사람에 대한 구조화된 기본 정보
2. 실제 업무 방식을 보여 주는 근거 자료

워크플로우에서는 이름, 역할, 레벨, 회사 맥락, 성향 힌트, 사용자의 주관적 인상 같은 기본 정보를 먼저 묻습니다. 그리고 Feishu 메시지, DingTalk 문서, exported JSON, 이메일, 스크린샷, PDF, markdown, 붙여넣은 텍스트 같은 자료를 ingest합니다. 인구통계성 정보만 넣고 실제 업무 산출물을 주지 않으면, 결과도 얕아질 가능성이 높습니다.

대충 던진 요청을 강한 create-colleague 프롬프트로 바꾸기

약한 요청은 이런 식입니다. “Alice용 스킬 만들어줘.”

더 좋은 create-colleague usage 프롬프트는 아래 요소를 담습니다.

• 그 사람이 누구인지
• 어떤 종류의 일을 했는지
• 어떤 자료를 갖고 있는지
• 생성된 스킬이 무엇을 잘해야 하는지
• 신호가 가장 강한 자료가 무엇인지
• 무엇을 추론하면 안 되는지

예시:

/create-colleague

Name: Alice
Role: Staff backend engineer
Company context: B2B SaaS, billing platform
What I need: a skill that reproduces her incident response style, API review standards, and communication tone with PMs
Sources: 2 Feishu doc links, 1 exported message JSON, 6 screenshots of architecture notes, 3 handoff emails
Important: prioritize technical judgment and escalation habits over personality mimicry
Do not infer management style from jokes or casual chat

이런 방식의 프롬프트는 겉으로 드러난 말투에 과적합되는 위험을 줄이고, work/persona 분리도 더 잘 되게 만듭니다.

create-colleague에 맞는 수집 경로 선택하기

이 repo는 여러 소스 파이프라인을 제공하며, 어떤 경로를 고르느냐에 따라 준비 비용과 신뢰도가 달라집니다.

• tools/feishu_auto_collector.py: Feishu app credentials가 있을 때 가장 적합
• tools/feishu_browser.py: 브라우저 로그인 뒤에서만 접근 가능한 내부 문서에 유용
• tools/feishu_mcp_client.py: 토큰 기반 플로우로 Feishu 문서에 접근할 때 사용
• tools/dingtalk_auto_collector.py: DingTalk 수집 경로
• tools/email_parser.py: .eml 또는 .mbox
• tools/feishu_parser.py: exported Feishu JSON 파싱

팀에서 app credentials를 발급해 줄 수 없다면, 브라우저 기반 경로나 수동 파일 경로가 현실적인 출발점일 수 있습니다.

먼저 읽어야 할 파일

빠르게 적합성을 판단하려면 다음 순서로 보는 것이 좋습니다.

1. SKILL.md: 트리거 로직, 허용 도구, 전체 워크플로우
2. INSTALL.md: 실제 환경 설정과 의존성 선택
3. README_EN.md: 지원 소스와 사용자 관점 설명
4. docs/PRD.md: 의도한 출력 모델과 진화 플로우
5. prompts/ 파일들: 분석 동작을 수정할 계획이 있을 때

repo 트리를 무작정 둘러보는 것보다, 이 순서가 설치·도입 결정을 내리는 데 훨씬 빠르고 정확합니다.

create-colleague의 생성 결과 구조 이해하기

이 repo의 제품 설계는 출력을 다음처럼 분리합니다.

• Work Skill
• Persona
• 바로 사용할 수 있는 결합형 SKILL.md 스타일 결과

이 분리는 실제 도입 시 꽤 중요합니다. 정말 필요한 것이 “어떻게 일을 해결하는가”라면 persona 영향은 가볍게 유지하면 되고, 보다 실제 같은 커뮤니케이션이 중요하다면 persona 근거를 더 강하게 넣으면 됩니다. 이 스킬이 단일 혼합 프롬프트보다 유용한 이유는, 역량과 스타일을 서로 다른 신호로 다루기 때문입니다.

create-colleague는 반복 개선을 전제로 보기

좋은 create-colleague guide 관점은 첫 실행 결과를 초안으로 보는 것입니다. 이 스킬은 파일을 추가하거나, 잘못된 주장에 수정 패치를 넣거나, 리뷰 후 동작을 다듬는 “evolution mode”를 지원합니다. 첫날부터 완벽한 원샷 프롬프트를 만들려 하기보다, 실제 업무 맥락을 점진적으로 추출하는 쪽에 더 잘 맞습니다.

결과 품질을 높이는 실전 팁

신호가 강한 입력은 다음과 같습니다.

• 단순한 잡담보다 의사결정이 담긴 대화
• 명시적인 기준, 트레이드오프, 리뷰 코멘트가 있는 문서
• 하나의 고립된 산출물이 아니라 여러 업무에 걸친 예시
• “이 사람은 절대 이렇게 하지 않는다”는 사용자의 교정 정보

반대로 신호가 약한 입력은 다음과 같습니다.

• 맥락 없는 스크린샷만 있는 경우
• 칭찬 위주의 설명만 있는 경우
• 의사결정 방식의 흔적 없이 형식적인 문서만 있는 경우
• 라벨 없이 여러 사람 자료가 섞여 있는 경우

출력이 기록되는 위치와 왜 중요한지

설치 문서에 따르면 Claude Code 중심 사용에서는 생성된 colleague skill이 기본적으로 ./colleagues/ 아래에 저장됩니다. 운영 관점에서 이 점은 중요합니다. 실제 배포 전에, 생성된 스킬을 repo 안에 둘지, 공용 내부 워크스페이스에 둘지, 개인 환경에 둘지를 먼저 정해야 합니다. 많은 팀이 생성형 스킬의 유지보수 측면을 과소평가합니다.

create-colleague 스킬 FAQ

create-colleague는 Skill Authoring 입문자도 쓸 수 있나요?

네, repo 기반 스킬 설치를 할 수 있고 소스 자료를 준비할 수 있다면 가능합니다. 워크플로우 자체는 안내형이지만, 원클릭 소비자 앱은 아닙니다. 어떤 데이터를 넣을지 고르고, 생성 결과를 비판적으로 검토할 수 있을수록 결과는 더 좋아집니다.

create-colleague는 일반 프롬프트보다 더 낫나요?

대체로 그렇습니다. 특히 문제의 핵심이 단순히 말투를 흉내 내는 것이 아니라, 팀원의 실제 업무 패턴을 보존하는 데 있을 때 그렇습니다. 추가 가치가 생기는 지점은 구조화된 입력 수집, 지원되는 collector, 분리된 work/persona 생성, 그리고 명시적인 업데이트 경로입니다. 반대로 “직설적인 스타일로 써줘” 정도만 필요하다면 일반 프롬프트로도 충분할 수 있습니다.

어떤 소스 자료가 가장 잘 맞나요?

가장 좋은 조합은 실제 업무를 담은 자료입니다. 예를 들면 의사결정이 오간 메시지 스레드, 리뷰 코멘트, 내부 문서, 프로세스 노트, 인수인계 이메일, 트레이드오프 판단 사례 등이 있습니다. 생성된 스킬이 실제로 일을 잘하길 기대한다면, 성격 정보만으로는 부족합니다.

create-colleague를 쓰려면 Feishu나 DingTalk가 꼭 필요한가요?

아니요. 그것들은 중요한 수집 옵션이지 필수 요건은 아닙니다. PDF, markdown, 스크린샷, 이메일, 붙여넣은 텍스트, exported 파일도 사용할 수 있습니다. 그래서 Feishu 전용 워크플로우가 아닌 환경에서도 충분히 사용할 수 있습니다.

어떤 경우에는 create-colleague를 설치하지 않는 편이 좋나요?

단순한 스타일 프리셋이 필요하거나, 가상의 캐릭터를 만들고 싶거나, 빈약한 근거만으로도 실제 사람을 정확히 시뮬레이션해 주길 기대한다면 이 스킬은 맞지 않습니다. 또 필요한 스킬 툴링을 환경에서 실행할 수 없거나, 데이터 접근 정책상 필요한 자료를 export하거나 수집할 수 없다면 설치를 피하는 편이 낫습니다.

생성한 colleague를 첫 버전 이후에도 업데이트할 수 있나요?

네. 이 repo는 새 파일 추가, 잘못된 추론 수정, 기존 colleague의 점진적 진화를 명시적으로 지원합니다. create-colleague를 정적인 수제 프롬프트보다 선호할 만한 가장 강한 이유 중 하나가 바로 이 점입니다.

create-colleague 스킬을 더 잘 활용하는 방법

형용사보다 근거를 넣어 create-colleague 품질 높이기

create-colleague 결과를 가장 빨리 개선하는 방법은 “매우 꼼꼼함”, “조금 날카로움” 같은 라벨을 근거로 바꾸는 것입니다.

• 반복적으로 남긴 review comments
• 수용한 작업과 거절한 작업의 예시
• 기본 구조가 드러나는 문서
• 장애 대응 중 보낸 escalation 메시지
• 확신이 없을 때 자주 쓰는 표현

근거가 들어가면 생성된 work skill은 더 실행 가능해지고, persona는 과장된 캐리커처가 되지 않습니다.

스킬 신호와 성격 신호를 분리하기

사용자는 종종 “무엇을 아는가”와 “어떤 톤으로 말하는가”를 한데 섞습니다. 더 좋은 결과를 원한다면 입력을 명시적으로 나누는 편이 낫습니다.

• work inputs: specs, code review notes, runbooks, architecture comments
• persona inputs: chat tone, conflict style, humor, disagreement 방식

이렇게 해야 work/persona 결과가 분리된 채 유지되고, 막연한 흉내 내기로 흐르지 않습니다.

소스 신뢰도를 라벨링하기

모든 입력을 같은 비중으로 다뤄서는 안 됩니다. 어떤 자료가 기준 문서인지, 최신인지, 잡음이 많은지 스킬에 알려 주세요. 예를 들면:

• “These review comments reflect current standards”
• “These 2022 chats are outdated”
• “This screenshot is second-hand and may be inaccurate”

이렇게 하면 잘못된 추론을 줄이고, create-colleague가 더 나은 근거를 우선시하도록 도울 수 있습니다.

첫 초안은 구체적인 패치로 수정하기

첫 결과가 틀렸을 때 “뭔가 어색해요”라고만 말하지 마세요. 더 좋은 수정 방식은 다음과 같습니다.

• “He prefers rollback first, not hotfix-in-place”
• “She is concise with peers but much more explanatory with junior engineers”
• “Do not make him sound sarcastic in formal docs”
• “Her strongest skill is requirements clarification, not system design”

이런 구체적인 패치는 막연한 불만보다 다음 버전에 반영하기 훨씬 쉽습니다.

동작을 커스터마이즈할 계획이라면 prompt 파일 보기

분석 방식이나 근거 병합 방식을 바꾸고 싶다면 prompts/ 디렉터리를 꼭 읽어볼 가치가 있습니다. intake.md, work_analyzer.md, persona_analyzer.md, work_builder.md, persona_builder.md, merger.md, correction_handler.md 같은 파일에서 실제 출력 품질이 형성됩니다. 기본적인 work/persona 균형이 현재 용도와 맞지 않는다면, 바로 이 지점을 먼저 점검하는 것이 맞습니다.

create-colleague의 흔한 실패 패턴 주의하기

주요 품질 리스크는 다음과 같습니다.

• 말투에 과하게 치우치고 실제 업무 역량은 충분히 구축하지 못하는 경우
• 빈약하거나 편향된 자료에서 너무 많은 것을 추론하는 경우
• 여러 동료를 하나의 프로필로 섞어 버리는 경우
• 오래된 산출물을 현재 행동 패턴으로 오인하는 경우
• 회사의 프로세스를 개인 스타일로 착각하는 경우

이것들은 추상적인 AI 문제라기보다, 생성된 colleague가 가짜처럼 느껴지거나 실무에 도움이 되지 않는 직접적인 이유입니다.

할 일을 좁혀 create-colleague를 개선하기

첫 실행 결과가 너무 넓고 흐릿하게 느껴진다면 목표를 좁혀 보세요. 처음부터 한 사람 전체를 재현하려 하기보다, incident response, architecture review, customer escalation, PM communication 같은 한 영역에 최적화된 colleague skill을 먼저 요청하는 편이 더 설득력 있고 유용한 결과로 이어지는 경우가 많습니다.

팀 배포 전에 리뷰 루프 만들기

생성된 스킬을 다른 사람도 사용할 예정이라면, 원래 당사자와 실제로 긴밀하게 일했던 사람과 함께 검토하세요. 다음 항목을 확인하는 것이 좋습니다.

• 이 스킬이 반드시 해야 하는 것
• 절대 주장하면 안 되는 것
• 어떤 상황에서 escalation이 필요한지
• 커뮤니케이션 스타일이 실용적으로 충분히 정확한지

실제 팀 환경에서 create-colleague for Skill Authoring 품질을 높이는 가장 안전한 방법입니다.

설치 경로를 유지보수 가능하게 만들기

장기적으로 더 잘 쓰려면, 생성된 colleagues를 어디에 둘지, 업데이트 버전을 어떻게 관리할지, 어떤 선택적 collector를 팀 공식 지원 범위로 볼지를 표준화해 두세요. 특정 유지보수 담당자 한 사람의 노트북에서만 돌아가는 스킬은, 설치와 업데이트 정책이 명확한 스킬보다 신뢰받기 어렵습니다.

create-colleague usage를 개선하는 가장 단순한 원칙

실무적으로 한 가지 규칙만 기억하면 됩니다. 수는 적더라도 더 좋은 산출물을, 명확한 라벨과 함께 넣고, 이후에는 목표가 분명한 교정으로 반복 개선하세요. 이것이 생성 결과 자체와 전체적인 create-colleague usage 경험을 함께 끌어올리는 가장 효율적인 방법입니다.