create-boss

create-boss skill の概要

create-boss skill でできること

create-boss skill は、散在した上司に関する材料を、再利用できる運用モデルへ整理するための skill です。具体的には、そのリーダーが仕事をどう評価するか、どうマネージアップすべきか、プレッシャー下で普段どんな話し方をするかを構造化します。使い方は大きく2通りあります。チャット、メール、会議メモ、コメントなど実在の素材から作る方法と、Elon Musk、Jeff Bezos、Steve Jobs、Jensen Huang のような起業家アーキタイプから始める方法です。

create-boss を導入すべき人

create-boss が特に向いているのは、一般論のリーダーシップ助言ではなく、特定の上司に合わせたアウトプットが必要な人です。たとえば、上方向のコミュニケーションを改善したい IC、レビュー準備を進める staff / product / project lead、後から呼び出せる再現性のある boss profile を作りたい Playbooks ユーザーに適しています。実務上の問いが「この上司は何を突っ込んでくるのか」「どう見せれば通りやすいのかを予測したい」であれば、create-boss skill はかなり相性が良いです。

通常のプロンプトではなく create-boss skill を使う理由

通常のプロンプトでも、一度きりなら口調の模倣はできます。ですが create-boss skill の強みは、judgment、management、persona を分けた持続的な構造を作れ、さらにバージョニングや修正フローまで持てることです。実際に運用で詰まりやすいのは生成そのものではなく、微調整の部分です。たとえば「この人はそういう基準で判断しない」「まずリスクを見るタイプだ」「1on1 よりレビューの場ではもっと厳しい話し方になる」といったズレを詰めていく必要があります。create-boss skill は、そうした改善前提の運用に向いています。

create-boss skill の使い方

Claude Code または OpenClaw に create-boss をインストールする

Claude Code をプロジェクトローカルで使う場合は、repo のルートで次を実行します。

mkdir -p .claude/skills && git clone https://github.com/vogtsw/boss-skills.git .claude/skills/create-boss

Claude Code をグローバルに入れる場合はこちらです。

git clone https://github.com/vogtsw/boss-skills.git ~/.claude/skills/create-boss

OpenClaw の場合はこちらです。

git clone https://github.com/vogtsw/boss-skills.git ~/.openclaw/workspace/skills/create-boss

開発用の任意依存関係:

pip3 install -r requirements.txt

agent 内で skill を呼び出すだけなら、通常は Python ツールを手動実行する必要はありません。

create-boss がうまく機能する入力

良い create-boss usage は、単なる口調ではなく、意思決定パターンが見える材料から始まります。優先したいのは次のような入力です。

• プロジェクトに対する批評や深掘り質問
• 計画、週次更新、戦略ドキュメントへの修正
• 遅延、リスク急増、リソース競合時のコメント
• 称賛、却下、緊急対応、方針転換が起きた場面

弱い入力: きれいに整った全社会議スピーチや一般的な経歴文。
強い入力: 何が承認され、却下され、エスカレーションされ、言い換えられたのかが分かる生のコメント。

質の高い依頼には、次の要素を入れると効果的です。

• boss 名または archetype
• 役割 / 文脈
• 自分との関係性
• 代表例 5〜20 件
• 返してほしいもの: review simulator、upward-management guide、または persona clone

create-boss の出力を良くするプロンプトの書き方

/create-boss、analyze my boss、build a Musk-style boss のようなトリガーフレーズを使います。create-boss for Playbooks として使う場合は、どんな再利用可能な成果物がほしいのかを明示するのが重要です。

より良いプロンプト例:
「Create a boss skill for my VP of Product. Use these meeting notes, Slack excerpts, and doc comments. Focus on how she judges roadmap risk, what information she wants first, and how I should escalate bad news. Output clear judgment, management, and persona sections.」

さらに良い例:
「Weight examples from launch delays and resource conflicts more heavily than casual chat. If patterns conflict, note the condition where behavior changes.」

この追加指示が効くのは、安定したルールと、状況によって変わる振る舞いを切り分けやすくなるからです。

先に読むべきファイルとおすすめの進め方

読む順番は次の通りです。

1. SKILL.md でトリガーフレーズ、モード、ワークフローを確認
2. INSTALL.md でプラットフォーム別セットアップと検証フローを確認
3. README_EN.md または README.md でコマンド例と対応データソースを確認
4. prompts/ で intake、analysis、merging、correction の構成を確認
5. archetypes/ と bosses/ で出力の形を確認

実務的な進め方としては、次の流れがおすすめです。

1. まずは 1 人の上司と少量の証拠セットから始める
2. 最初のドラフトを生成する
3. 「In roadmap reviews, he asks about owner and deadline before strategy.」のように、明確な事実ベースでズレを修正する
4. 生成された skill が反応を安定して予測できるまで、再実行または更新する

create-boss skill FAQ

create-boss は実在の上司向けか、有名 archetype 専用か

両方に使えますが、主な価値は実在の上司向けモードにあります。archetype は発想出しやシミュレーションには手早い一方で、実際の材料から作るほうが、マネージアップの指針としてははるかに使えます。インスピレーションより実務で使えることを重視するなら、実際のソース材料で create-boss を導入するのが適しています。

初心者でも使いやすいか

はい。すでに投入できる材料があるなら、初心者でも扱いやすいです。難しいのはセットアップよりも入力の質です。初心者は汎用的な会話を大量に入れがちで、レビューコメント、エスカレーションが発生した瞬間、修正されたドキュメントを十分に入れない傾向があります。高度な prompt engineering は不要ですが、代表性のある証拠は必要です。

create-boss skill を使わないほうがいい場面

上司が着任したばかりでまだサンプルが少ない場合、ほとんど事例を持っていない場合、あるいは欲しいものが「どうやって stakeholder に影響を与えるか」といった汎用的な助言にすぎない場合は、create-boss skill は見送ったほうがよいです。また、臨床的な性格分析を求める用途にも向いていません。この skill は、仕事上の行動、判断パターン、コミュニケーション戦術の把握に最適化されています。

通常のプロンプトに対して create-boss は何を加えるのか

create-boss guide の価値は、構造化と再現性にあります。この repo では persona を意思決定ロジックや managing-up の助言から切り分けて扱い、修正処理も組み込まれており、一覧表示、rollback、削除コマンドにも対応しています。そのため、場当たり的なプロンプトで毎回上司像を説明し直すより、長期運用しやすくなります。

create-boss skill を改善する方法

量ではなくパターンを与える

テキスト量が多ければ自動的に良くなるわけではありません。より強い create-boss usage にしたいなら、上司がトレードオフをどう処理したかが見える場面を入れてください。たとえば、スピード vs 品質、リスク vs 野心、プロセス vs 成果、自律性 vs エスカレーションといった判断です。淡々とした会話を大量に渡すより、鋭い例を少数入れるほうが効果的です。

初稿のあとに具体的な修正を入れる

この repo の correction フローは、もっとも価値の高い部分のひとつです。「なんとなく違う」とは言わず、次のように具体化してください。

• 「He does not start with strategy; he starts with timeline risk.」
• 「She sounds calm in writing but sharp in live reviews.」
• 「He tolerates uncertainty if ownership is clear.」

具体的な修正があると、skill は judgment、management、persona のどの層を更新すべきかを正しく判断しやすくなります。

Playbooks ワークフロー向けに create-boss を改善する

create-boss for Playbooks を使うなら、出力を繰り返し発生する状況に結び付けましょう。たとえば、project reviews、status updates、resource asks、launch-risk escalations、postmortems です。各シナリオについて例を生成するよう skill に依頼してください。そうすることで、出来上がった boss profile が静的な人物スケッチで終わらず、運用 playbooks の中で再利用しやすくなります。

主な失敗パターンを把握する

よくある外し方は次の通りです。

• 承認ロジックではなく口調に過剰適合してしまう
• たまたま機嫌の悪かった 1 日を恒常的な性質として扱ってしまう
• 公の場でのスタイルと、内面的な意思決定ルールを混同してしまう
• 使える指針ではなく、耳障りのよい要約に寄ってしまう

create-boss skill の結果を改善するには、矛盾する事例を反復的に見直し、文脈を明確にラベル付けし続けることが大切です。そのうえで常に、「この上司なら何を承認し、何を却下し、最初に何を問い、次に自分に何を求めるか？」と問い続けてください。