create-colleague

create-colleague skill の概要

create-colleague skill でできること

create-colleague skill は、実在する同僚の成果物や履歴を、再利用できる AI skill に変換するためのものです。単なる人物紹介や経歴文の生成が目的ではありません。docs、chat、screenshots、emails、そして Feishu や DingTalk のような業務プラットフォームに残っている情報から、その人の仕事の進め方、コミュニケーションの癖、意思決定の仕方を抽出し、実務で使える協働プロファイルとして再構成します。

どんな人に create-colleague をおすすめできるか

create-colleague は、チームメンバーの退職・異動・引き継ぎのあとも、実務上のノウハウを残したい Skill Authoring ユーザーに特に向いています。社内ツール上に手がかりが点在していて、「この人っぽい prompt を書いて」よりも、もう一段構造化された形で引き継ぎたいチームには特に相性が良いです。

通常の prompt と何が違うのか

普通の prompt でも口調の模倣はできます。一方で create-colleague skill は、明確に 2 種類の出力を目指します。1 つはタスク実行のための work skill、もう 1 つはコミュニケーションスタイルを扱う persona layer です。さらにこの repo には、Feishu、DingTalk、email、ファイル入力向けの取り込み経路も用意されています。チャットに断片を手作業で貼り込むだけの運用より、実務ではかなり扱いやすい設計です。

インストール前にユーザーが気にするポイント

導入判断では、だいたい次の 4 点が重要になります。自分たちのソースが対応範囲に入っているか、インストールが特定の agent 環境に依存するか、初回生成後に出力を編集できるか、そして結果を継続的に育てられるかです。この観点で見ると、create-colleague は Claude Code 系の skill workflow で特に使いやすく、自動収集と手動収集の両方をサポートし、修正や追加ファイルに対応する update / evolution フローも明示されています。

create-colleague が向くケース・向かないケース

create-colleague を使うべきなのは、その人が実際にどう働いていたかを示す証拠があるときです。たとえば message history、docs、emails、screenshots、あるいは文章による具体的な記述などがある場合です。逆に、架空の persona を作りたいだけのケース、軽い一発ネタの文体模倣、汎用的なチーム役割テンプレートが欲しいだけのケースには向きません。この skill は、根拠のある蒸留のためのものであり、薄い入力から roleplay を作るためのものではありません。

create-colleague skill の使い方

正しい skill directory に create-colleague をインストールする

この repo のインストール方法は npx ではなく clone 前提です。Claude Code では、project または global の skills directory 配下に 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

ここは重要です。skill の trigger や生成物の出力先が、「その名前でインストールされた skill directory」であることを前提にしているためです。

collector を試す前に依存関係を入れておく

実際の create-colleague install 手順は、どのソースを使いたいかで変わります。最低条件は Python 3.9+ です。追加パッケージを入れると、より多くの取り込み経路が使えるようになります。

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

これらを入れなくても、手動アップロードやテキスト入力だけで skill 自体は動かせます。ただし、自動収集や一部のファイル変換ルートは使えなくなります。

実際の trigger で create-colleague skill を起動する

対応している agent 環境では、/create-colleague で起動します。repo には、同僚 skill を作りたいと自然文で依頼する trigger や、/update-colleague {slug}、/list-colleagues といった更新系フローも記載されています。「インストールして、ちゃんと起動するかをまず確かめたい」というテスト方針なら、最初に確認すべきなのはこの trigger の挙動です。

create-colleague に必要な入力を理解する

良い出力を得るには、次の 2 種類の入力を組み合わせるのが基本です。

1. その人に関する構造化された基本情報
2. その人がどう働いていたかを示す証拠

workflow では、名前、役割、レベル、会社の文脈、性格のヒント、あなた自身の印象といった基本情報を尋ねられます。そのうえで、Feishu messages、DingTalk docs、exported JSON、emails、screenshots、PDFs、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

このような prompt にすると、表面的な口調への過剰適合を避けやすくなり、work と persona の切り分けも改善しやすくなります。

create-colleague に合った収集ルートを選ぶ

この repo には複数の収集パイプラインがあり、どれを選ぶかで手間も信頼性も変わります。

• tools/feishu_auto_collector.py: Feishu app credentials がある場合に最適
• tools/feishu_browser.py: ブラウザログインの先にある社内 docs を扱いたいときに便利
• tools/feishu_mcp_client.py: token-based flow で Feishu docs にアクセスする場合向け
• tools/dingtalk_auto_collector.py: DingTalk の収集ルート
• tools/email_parser.py: .eml または .mbox 用
• tools/feishu_parser.py: export 済み Feishu JSON の解析用

もしチームで app credentials を発行できないなら、browser 経由か手動ファイル投入が、現実的なスタート地点になることが多いです。

まず読むべきファイル

短時間で適合性を見極めたいなら、読む順番は次がおすすめです。

1. SKILL.md — trigger logic、使える tools、workflow を把握する
2. INSTALL.md — 実際の環境構築と依存関係の選択肢を確認する
3. README_EN.md — 対応ソースとユーザー向けの位置づけをつかむ
4. docs/PRD.md — 想定されている出力モデルと evolution flow を確認する
5. prompts/ 配下のファイル — 分析の挙動を調整したい場合に読む

repo tree を漫然と眺めるより、この順で追うほうが導入判断に必要な情報へ早くたどり着けます。

create-colleague の生成出力はどう分かれているか

この repo の設計では、出力は次のように分かれています。

• Work Skill
• Persona
• 直接使える統合版の SKILL.md 形式の結果

この分離は、導入時にかなり重要です。欲しいのが「その人がどう仕事を解くか」なら persona の重みを軽めにできます。逆に、コミュニケーションの再現性を重視するなら persona 側の根拠を厚くできます。能力と話し方を別信号として扱うため、1 本の混合 prompt より実務では使い分けしやすいのが利点です。

create-colleague は反復前提で使う

良い create-colleague guide の考え方は、「初回生成は draft」と捉えることです。この skill は、ファイル追加・誤推論の修正・レビュー後の挙動調整に対応する “evolution mode” をサポートしています。初日から完璧な一発 prompt を狙うより、現実の職場知見を蒸留する用途にはこちらのほうがずっと合っています。

出力品質を上げる実践的なコツ

シグナルが強い入力は次のようなものです。

• 雑談だけでなく、意思決定が含まれる会話
• 明確な標準、トレードオフ、review comments が書かれた docs
• 単発の成果物ではなく、複数タスクにまたがる例
• 「その人なら絶対にしないこと」についてのあなたの補足

逆にシグナルが弱い入力は次のようなものです。

• 文脈なしの screenshots だけ
• 褒め言葉ばかりの説明
• 意思決定スタイルの証拠がない形式的な docs だけ
• ラベル分けせずに複数人の資料を混ぜたもの

生成物がどこに書き出されるかと、その運用上の意味

install docs には、Claude Code 寄りの使い方では生成された colleague skills がデフォルトで ./colleagues/ 配下に出力されるとあります。これは運用面で重要です。本番利用の前に、生成 skill を repo に置くのか、共有の社内 workspace に置くのか、個人環境に置くのかを決めておくべきです。チーム運用では、生成 skill の保守コストを見落としがちです。

create-colleague skill の FAQ

create-colleague は Skill Authoring 初心者でも使える？

はい、repo ベースの skill をインストールできて、元データを用意できるなら使えます。ただし、ワンクリックの消費者向けアプリではありません。workflow 自体はガイド付きですが、データソースを選んだり、生成結果を批判的に見直したりできる人ほど、良い結果を得やすいです。

create-colleague は普通の prompt より良い？

多くの場合は yes です。特に課題が「同僚の働き方を残すこと」であって、単なる話し方の模倣ではないなら、その差は大きくなります。価値の源泉は、構造化された intake、対応 collector、work/persona の分離生成、そして明示的な update path にあります。必要なのが「簡潔で直接的な文体で書いて」程度なら、通常の prompt で十分なこともあります。

どんなソース資料が最も向いている？

最も相性がいいのは、実務の負荷が乗っている資料です。たとえば、意思決定に関する message threads、review comments、社内 docs、process notes、handoff emails、トレードオフ判断の具体例などです。生成された skill に実務上の説得力を求めるなら、性格だけを示すデータでは足りません。

create-colleague は Feishu や DingTalk が必須？

いいえ。これらは重要な収集オプションではありますが、必須条件ではありません。PDFs、markdown、screenshots、emails、貼り付けテキスト、exported files でも使えます。つまり、Feishu 専用の workflow に縛られない環境でも運用可能です。

どんなときは create-colleague を入れないほうがいい？

単純な文体 preset、架空キャラクター、あるいは乏しい証拠から高精度に本人再現してほしいケースには向きません。また、必要な skill tooling を実行できない環境や、必要資料の export / 収集がデータアクセス上できない環境でも、導入は見送ったほうがよいです。

最初のバージョンを作ったあとで colleague を更新できる？

はい。repo には、ファイルの追加入力、誤った推論の修正、既存 colleague の継続的な進化が明示的にサポートされています。静的な手書き prompt より create-colleague を選ぶ強い理由の 1 つです。

create-colleague skill を改善する方法

create-colleague には形容詞ではなく証拠を渡す

create-colleague の結果を最も手早く改善する方法は、「とても厳密」「少しキツめ」といったラベルを、具体的な根拠に置き換えることです。

• 繰り返し書いていた review comments
• 受け入れる仕事と差し戻す仕事の例
• その人の標準的な文書構成が分かる docs
• incident 時の escalation messages
• 不確実なときによく使う言い回し

根拠があると、生成される work skill はより実務的になり、persona も caricature に寄りにくくなります。

スキルのシグナルと性格のシグナルを分ける

ユーザーは「何を知っているか」と「どう話すか」を混ぜがちです。より良い結果を得るには、入力を明示的に分けて渡してください。

• work inputs: specs、code review notes、runbooks、architecture comments
• persona inputs: chat tone、conflict style、humor、反対するときの言い回し

こうすると、曖昧な模倣に流れず、work/persona の出力をきちんと分離しやすくなります。

ソースの信頼度をラベル付けする

すべての入力を同じ重みで扱うべきではありません。どの資料が canonical か、どれが最新か、どれがノイズ混じりかを skill に伝えましょう。たとえば次のような形です。

• 「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 files を読む

解析や証拠のマージ方法を変えたいなら、prompts/ directory は読む価値があります。intake.md、work_analyzer.md、persona_analyzer.md、work_builder.md、persona_builder.md、merger.md、correction_handler.md などを見ると、出力品質が実際にどこで決まっているかが分かります。work と persona の標準バランスが用途に合わないと感じたとき、まず確認すべき場所です。

create-colleague の典型的な失敗パターンを把握する

主な品質リスクは次のとおりです。

• 口調ばかり拾って、実務能力の再現が弱くなる
• 乏しい、または偏った資料から推測しすぎる
• 複数の同僚を 1 つの profile に混ぜてしまう
• 古い成果物を現在の振る舞いとして扱ってしまう
• 会社の process を個人の style と取り違える

これらは抽象的な AI の問題ではありません。生成された colleague が「偽物っぽい」「使いづらい」と感じられる、現場レベルの典型要因です。

create-colleague の対象ジョブを絞ると改善しやすい

初回結果が広すぎると感じるなら、まず対象を絞ってください。たとえば incident response、architecture review、customer escalation、PM communication のように、1 つの領域に最適化した colleague skill を先に作るとよいです。最初から人間全体を再現しようとするより、狭いターゲットのほうが、信頼できて使える結果になりやすいです。

チーム展開前にレビューのループを作る

生成された skill を他の人も使うなら、元の本人と近く働いていた人にレビューしてもらうのが安全です。確認してもらう観点は次のとおりです。

• その skill が確実にできるべきこと
• 絶対に主張してはいけないこと
• どの状況で escalation が必要か
• コミュニケーションスタイルが実用上十分に正確か

これは、実チーム環境で create-colleague for Skill Authoring を改善するうえで最も堅実な方法です。

install path を保守しやすくしておく

長期運用を改善するには、生成された colleagues をどこに置くか、更新をどう versioning するか、どの optional collectors をチームとして正式サポートするかを標準化しておくことが大切です。1 人の maintainer の laptop でしか動かない skill は、明確な install / update policy がある skill より信頼されにくくなります。

create-colleague usage を良くする最短ルール

実践的なルールを 1 つだけ挙げるなら、「数を増やすより、質の高い artifacts を、ラベル付きで少数渡し、狙いを定めて修正を回す」です。これが、生成結果そのものと、全体としての create-colleague usage 体験の両方を最も効率よく改善するやり方です。