create-colleague

create-colleague skill 概覽

create-colleague skill 的用途

create-colleague skill 會把真實同事留下的各種工作產物，整理成可重複使用的 AI skill。它的核心任務不是泛泛地寫人物介紹，而是萃取一個人如何工作、如何溝通、以及如何做決策，讓你能根據文件、聊天紀錄、截圖、電子郵件，以及 Feishu、DingTalk 這類工作平台資料，重建出一個可用的協作型人物設定。

哪些人適合安裝 create-colleague

如果你是 Skill Authoring 使用者，想在同事離職、轉調或交接之後，保留他們的實務做事方式，這個 skill 特別適合你。尤其當團隊的資訊早已散落在各種工作工具裡，而你需要的不只是「幫我寫一段像這個人的 prompt」，那 create-colleague 會比單純模仿語氣更有價值。

create-colleague 和一般 prompt 有什麼不同

一般 prompt 可以模仿語氣，但 create-colleague skill 的目標是產出兩種不同結果：一個用於執行工作的 work skill，以及一層負責溝通風格的 persona。這個 repo 也內建了 Feishu、DingTalk、email 與檔案型輸入的資料匯入路徑，實際使用上比手動把零碎片段貼進聊天視窗更可行。

安裝前多數使用者最在意什麼

大部分人是否採用，通常取決於四個問題：你的來源資料是否支援、安裝是否綁定特定 agent 環境、第一次產出的內容之後能不能修改，以及結果能不能持續演進。就這幾點來看，create-colleague 在 Claude Code 風格的 skill 工作流中最完整，同時支援自動與手動兩種收集方式，也明確提供修正與加入新檔案後的更新／演化流程。

最適合與不適合的使用情境

當你手上真的有某人工作方式的證據時，就適合用 create-colleague：例如訊息紀錄、文件、email、截圖，或他人對其工作方式的文字描述。若你只是想做虛構人物、一次性的輕量風格模仿，或泛用的團隊角色模板，就不建議使用。這個 skill 著重的是有根據的萃取，不是憑空 roleplay。

如何使用 create-colleague skill

在正確的 skill 目錄中安裝 create-colleague

這個 repo 官方提供的安裝方式是 git clone，不是 npx。在 Claude Code 中，請把它以 create-colleague 這個名稱安裝到專案層級或全域 skills 目錄：

# 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

這一點很重要，因為 skill 的觸發方式與產出路徑，都預設你是以指定名稱安裝在對應目錄下。

測試收集器前先安裝相依套件

實務上，create-colleague 的安裝流程會取決於你要接哪些資料來源。基本需求是 Python 3.9+。若要啟用更完整的資料匯入能力，還需要安裝選配套件：

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

如果你跳過這些，skill 仍可搭配手動上傳與文字輸入使用，但部分自動收集與檔案轉換路徑就無法使用。

用真正的觸發方式啟動 create-colleague

在支援的 agent 環境中，請使用 /create-colleague 來呼叫它。repo 也記錄了自然語言觸發方式，例如要求建立 colleague skill，以及像 /update-colleague {slug}、/list-colleagues 這類更新流程。如果你的測試計畫是「先裝好，再確認它有沒有正常被喚起」，那首先要驗證的就是這個觸發行為。

了解 create-colleague 需要哪些輸入

create-colleague 的最佳輸出，通常來自兩類輸入的組合：

1. 關於此人的結構化基本資訊
2. 他實際如何工作的證據

流程中會先詢問姓名、角色、職級、公司背景、個性線索，以及你主觀上的觀察。接著再匯入 Feishu 訊息、DingTalk 文件、匯出的 JSON、電子郵件、截圖、PDF、markdown 或貼上的文字。如果你只提供基本背景資料，卻沒有工作產物，輸出通常會偏淺。

把模糊需求寫成更強的 create-colleague prompt

弱的請求會像是：「幫 Alice 做一個 skill。」

更好的 create-colleague usage prompt 應該包含：

• 這個人是誰
• 他做的是哪一類工作
• 你手上有哪些素材
• 你希望生成的 skill 擅長什麼
• 哪些地方的訊號最強
• 哪些內容不應該被推論

範例：

/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

這種寫法可以降低模型過度貼近表面語氣的風險，也更能把工作能力與 persona 明確區分開來。

選對資料收集路徑

repo 提供多種資料來源管線，而你選哪一條，會直接影響投入成本與可靠性：

• tools/feishu_auto_collector.py：最適合已有 Feishu app credentials 的情境
• tools/feishu_browser.py：適合需要透過瀏覽器登入才能存取的內部文件
• tools/feishu_mcp_client.py：用於透過 token-based flow 存取 Feishu 文件
• tools/dingtalk_auto_collector.py：DingTalk 的收集路徑
• tools/email_parser.py：處理 .eml 或 .mbox
• tools/feishu_parser.py：解析匯出的 Feishu JSON

如果你的團隊無法提供 app credentials，那以 browser 路徑或手動檔案匯入作為起點，通常更務實。

想快速判斷 create-colleague 是否適合，先看這些檔案

如果你想快速評估 create-colleague 是否符合需求，建議依照這個順序閱讀：

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 證據。相較於把所有內容混成一個 prompt，create-colleague 的實用之處在於它把能力與風格視為不同訊號處理。

預期 create-colleague 需要反覆迭代

比較好的 create-colleague guide 心態，是把第一次執行視為草稿生成。這個 skill 支援在你補新檔案、修正錯誤推論、或完成審閱後進一步微調行為的「evolution mode」。對真實職場知識萃取而言，這比一開始就要求完美的一次性 prompt 更貼近實際。

能提升 create-colleague 輸出品質的實用技巧

高訊號的輸入包括：

• 以決策為主的對話，而不只是社交閒聊
• 明確寫出標準、取捨或審查意見的文件
• 橫跨多個任務的例子，而不是單一孤立產物
• 你自己補充「這個人絕對不會這樣做」的修正說明

低訊號的輸入包括：

• 只有截圖，卻沒有上下文
• 只有稱讚式描述
• 只有正式文件，卻看不出其決策風格
• 混進多個人的材料，卻沒有標記來源

輸出會寫到哪裡，以及這為什麼重要

安裝文件提到，在偏向 Claude Code 的使用方式下，產生的 colleague skills 預設會寫到 ./colleagues/。這在實務上很關鍵：正式導入前，你要先決定這些生成出來的 skills 應該放在 repo、共享的內部工作區，還是個人環境裡。很多團隊往往低估了生成型 skills 後續維護的成本。

create-colleague skill 常見問題

create-colleague 適合 Skill Authoring 新手嗎？

適合，前提是你已經能安裝 repo-based skill，並且能準備好來源資料。整體流程雖然有引導，但它不是一鍵式的消費型 app。如果你能自己判斷資料來源，並對生成結果做有意識的審查，通常會得到更好的結果。

create-colleague 比一般 prompt 更好嗎？

通常是，特別是在你的真正需求是保留同事的工作模式，而不只是模仿他講話的口氣時。它的額外價值來自結構化輸入、支援的收集器、分離式的 work/persona 生成，以及明確的更新路徑。若你只需要「寫得直接一點」，那一般 prompt 可能就夠了。

哪些來源資料最適合 create-colleague？

最理想的是帶有任務脈絡的素材：與決策相關的訊息串、review comments、內部文件、流程筆記、交接 email，以及展現取捨判斷的例子。如果你期待生成出的 skill 能可信地完成工作，只有個性資料是遠遠不夠的。

create-colleague 一定要搭配 Feishu 或 DingTalk 嗎？

不需要。Feishu 與 DingTalk 是重要的收集選項，但不是硬性要求。你也可以使用 PDF、markdown、截圖、電子郵件、貼上的文字，以及匯出檔。這也讓 create-colleague 不會被綁死在單一 Feishu 工作流中。

什麼情況下不該安裝 create-colleague？

如果你要的是簡單的風格預設、虛構角色，或希望在證據稀少的情況下也能保證高準確度地模擬某個人，就不建議選 create-colleague。另外，如果你的環境無法執行所需的 skill tooling，或你的資料存取規則根本不允許匯出／收集必要素材，也應該直接跳過。

第一次生成後，還能更新 create-colleague 產物嗎？

可以。repo 明確支援追加檔案、修正錯誤推論，以及持續演化既有的 colleague。這也是相較於手工寫死的靜態 prompt，create-colleague 最值得優先考慮的原因之一。

如何改進 create-colleague skill

給 create-colleague 的是證據，不只是形容詞

想讓 create-colleague 的結果更好，最快的方法就是把「很嚴謹」、「講話有點銳利」這類標籤，換成可驗證的材料：

• 他反覆出現的 review comments
• 哪些工作他會接受、哪些會退回的實例
• 能看出其預設結構的文件
• 事故期間的 escalation 訊息
• 他在不確定時常用的措辭

有證據，生成出來的 work skill 才會更可執行，persona 也比較不會變成扁平 caricature。

把能力訊號和人格訊號分開

使用者很常把「他會什麼」和「他講話怎麼樣」混在一起。更好的做法，是在輸入時明確標示：

• work inputs：specs、code review notes、runbooks、architecture comments
• persona inputs：聊天語氣、衝突處理風格、幽默感、表達不同意見的方式

這樣有助於 skill 維持 work/persona 的分離，不會最後只生成一個模糊的模仿品。

標示來源可靠度

不是所有輸入都應該有同等權重。你應該告訴 skill 哪些材料是權威版本、哪些較新、哪些雜訊較多。例如：

• 「這些 review comments 代表目前的標準」
• 「這些 2022 年的聊天已經過時」
• 「這張截圖是二手轉傳，可能不準確」

這能降低錯誤推論，也能幫助 create-colleague 優先採信更好的證據。

用具體修補來修正第一版

如果第一版輸出有問題，不要只說「感覺不太對」。更有效的修正方式像是：

• 「他偏好先 rollback，不是原地 hotfix」
• 「她對同儕很精簡，但對 junior engineers 會解釋得更完整」
• 「不要讓他在正式文件裡顯得像在諷刺」
• 「她最強的是需求釐清，不是 system design」

這種具體修補，比模糊的不滿更容易被合併進下一版。

如果你要自訂行為，請看 prompts 檔案

如果你打算調整 skill 如何分析或合併證據，prompts/ 目錄很值得讀。像 intake.md、work_analyzer.md、persona_analyzer.md、work_builder.md、persona_builder.md、merger.md、correction_handler.md 這些檔案，才是真正決定輸出品質的地方。如果你覺得預設的 work 與 persona 比重不適合你的情境，就應該從這裡開始檢查。

留意 create-colleague 常見失敗模式

主要的品質風險包括：

• 過度重視語氣，卻沒有建立起真正的工作能力
• 在資料稀少或帶偏差時推論過多
• 把多位同事混成同一個 profile
• 把舊資料誤當成現在的行為模式
• 把公司流程誤認為個人風格

這些不是抽象的 AI 問題，而是生成出來的 colleague 之所以顯得假或不好用的實際原因。

透過縮小任務範圍來改進 create-colleague

如果第一次跑出來的結果太發散，就把目標收窄。先要求一個只針對特定領域最佳化的 colleague skill，例如 incident response、architecture review、customer escalation 或 PM 溝通。相較於一次重建整個人，更聚焦的初始目標通常更容易得到可信且實用的結果。

在團隊導入前建立 review loop

如果生成的 skill 之後要給其他人用，最好找一位真正和原始對象密切合作過的人一起審查。請他驗證：

• 這個 skill 一定要會做什麼
• 它絕對不該宣稱什麼
• 哪些情況必須升級處理
• 它的溝通風格是否準確到足以實用

這是在真實團隊情境中改進 create-colleague for Skill Authoring 最穩妥的方式。

維持可維護的安裝路徑

若想讓 create-colleague 長期可用，請先標準化：生成的 colleagues 放在哪裡、更新如何做版本管理，以及團隊正式支援哪些選配收集器。只能在單一維護者筆電上運作的 skill，通常比不上有清楚安裝與更新規範的 skill 值得信任。

改善 create-colleague usage 最簡單有效的方法

如果只記一條原則：提供更少、但品質更高且標示清楚的材料，然後用具體修正逐步迭代。這是同時提升生成結果與整體 create-colleague usage 體驗，槓桿最高的做法。