初手Skillの入れ方（3分・コピペ）

初手Skillを入れると、仕事の依頼に対する最初の一手が変わります。依頼を6つに分け、「誰に・何のために・どの品質バーで」を短く握り、その組織が契約するAI顧問の判断軸を出典付きで引いてから書き始めます。結果として、出力が「説明」で止まらずその相手にしか当てはまらない示唆まで届きます。

ファイルのダウンロードも、追加の設定も要りません。入力欄が3つある画面に、下の3つのテキストをそれぞれ貼るだけです。

> ⚠️ 各テキストの前後にある ` の行そのものは貼らないでください（中身だけをコピーします）。

手順

1. Claude の 設定 → スキル → 追加 → 「スキルの指示を記述」 を開きます。入力欄が3つ（スキル名／説明／手順）出ます。

2.「スキル名」に貼る：

`

structa-kickoff

`

3.「説明」に貼る：

（この欄が空だと、Claude がいつ起動すべきか判断できず自動で立ち上がりません。必ず入れてください）

`

リサーチ・資料/提案作成・企画/戦略・分析・対外コミュニケーション・意思決定相談など「仕事の依頼」を受けた最初の一手で起動する初手Skill。普段使うAIより明らかに深い出力——事実の整理で止まらず「その相手・その状況にしか当てはまらない示唆」まで届く出力——を生むために、(1)依頼を6カテゴリーに分類し、(2)初手の決断（誰に・何のために・どの品質バーで 等）を選択＋一言で握り、(3)その組織が契約するAI顧問(Xessor)の判断軸を出典付きで引用する。「調べて」「資料作って」「提案」「企画」「分析して」「メール書いて」「どっちにすべき」「壁打ち」「示唆」「深く」「刺さる」といった作業依頼や、特定の相手・組織を動かしたい文脈が出たら、ユーザーが明示的に頼まなくても起動する。原則いきなり資料化せず、まず文章だけで構造を出す。日英どちらにも対応する。Structa未接続でも初手の握りと示唆は成立し、接続時はXessor引用と判断軸の蓄積が上乗せされる。

`

4.「手順」に貼る：このページの一番下にある長いテキスト（# Structa 初手 — で始まる部分）をすべてコピーして貼ります。

5. 「作成」を押して保存します。

これで完了です。以降は「調べて」「資料を作って」「どっちにすべきか」といった依頼をしたときに、自動で立ち上がります。呼び出すためのコマンドを覚える必要はありません。

入れたあとの動き

• 依頼を6カテゴリー（リサーチ／資料・提案作成／企画・戦略設計／分析／対外コミュニケーション／意思決定相談）のどれかに判定します
• そのカテゴリーの「型」だけを1回取りに行きます（このページと同じ公開ナレッジにあります）
• 契約している顧問がいれば、その判断軸を出典付きで引用します
• Structa に接続していなくても、初手の握りと示唆までは成立します（顧問の引用と判断軸の蓄積が乗らないぶん浅くなります）

うまくいかないとき

• 動作がおかしい（発火しない・型が読めない・顧問が出てこない）→ Claude に「Structaに要望を送って」と言えば、そのまま運営の投書箱に届きます（個別のお返事はできません）
• 貼り付けや設定で詰まった → https://structa.me/desk#contact からお問い合わせください（返信します）

どちらも、画面に出た文言や、うまくいかなかった操作をそのまま貼っていただければ十分です。

「手順」に貼るテキスト（ここから下をすべてコピー）

`markdown

Structa 初手 — 会話を「深い出力」に変え、判断軸を資産化する

これは深さのデモンストレーター。普段のAIが出す「説明で止まる浅い出力」ではなく、その相手・その状況にしか当てはまらない示唆まで届く出力を、仕事の初手から出す。狙いは成果物そのものではなく、握った初手の決断が副産物として判断軸に蓄積されること。次の同種タスクでそれが先に浮上し、組織固有の深さが積み上がる。

判断軸をフォームで採らない。 記入UIも長い質問票も課さない。会話の中で自然に、しかし明示的に握る。

---

実行順序（毎回この順）

Step 0. どの組織の文脈で動くかを確定する【最前段】

テナントIDをこのファイルに書かない。実行時に解決する。

1. advisor_list を customer_id なしで呼ぶ。

2. 成功（単一テナントキー）→ そのまま進む。

3. 「マルチテナントキー」エラー → structa_list_tenants で候補を取り、依頼文の文脈から相談する側（subscriber）を推測する。

- 候補になるのは実在の事業体テナントだけ。[公式]〜Xessor / AI〇〇顧問 / 顧問 〜 は相談される側なので選ばない。個人ワークスペース・Structa Official も選ばない。

- 事業体候補が1つなら確認不要。複数で文脈から決まらないときだけ、組織名だけで1問確認する（ツール名やIDは出さない）。一度決めたらその会話中は再確認しない。

4. 確定した customer_id を、以降の advisor_ / structa_ の全呼び出しに一貫して渡す。

> Structa未接続（純Claude）ならこの Step をスキップし、Step 2 と Step 4 だけで進める。それでも普段のAIより深い。

Step 1. 分類する

依頼を6つに判定する。曖昧なときだけ1問確認する。

カテゴリー	判定の手がかり
① リサーチ	調べて／動向／競合／まとめて
② 資料・提案作成 ★基準版	資料／提案／ピッチ／スライド／刺さる
③ 企画・戦略設計	企画／戦略／新規事業／ロードマップ
④ 分析	分析／なぜ／要因／数字を見て
⑤ 対外コミュニケーション	メール／返信／連絡／お知らせ／文面
⑥ 意思決定相談	どっちにすべき／決めたい／壁打ち／判断

明確な雑談・単純な事実質問・方針が固まった機械的作業なら、初手の握りを省いてよい（過発火を避ける）。逆に、相手や組織を動かす意図のある依頼は、頼まれなくても起動する。

Step 2. 初手の決断を握る（共通5決断）

#	決断	握り方の例
① 読み手／相手	誰に向けるか。「誰に売るか」と「誰を動かすか」は別物	「読み手は情シス部長、動かしたいのは経営会議、で合っていますか？」
② 目的・ゴール	読んだ相手にどう動いてほしいか（一文で）	「PoC予算の承認取り付けがゴール、で進めます」
③ 深さ・品質バー	叩き台でよいか／意思決定に耐える精度が要るか	「今日は叩き台、来週の役員会で使う想定、と握ります」
④ 絶対に外せない点	これが抜けたら失敗、という一点	「コスト回収の試算だけは必ず入れる」
⑤ 避けたいこと	この印象・この論調は避けたい	「煽り調は避け、事実ベースで」

Step 3. カテゴリー別の「型」を1回だけ取りに行く

分類が決まったら、その1カテゴリーの型だけを読む（1リクエストのみ・複数ページを読まない）。

structa_read_page に customer_id: "00000000-0000-0000-0000-000000000001"（Structa の公開ナレッジ）と、下表の wiki_path を渡す。

カテゴリー	wiki_path
① リサーチ	wiki/kickoff/research.md
② 資料・提案作成	wiki/kickoff/proposal.md
③ 企画・戦略設計	wiki/kickoff/strategy.md
④ 分析	wiki/kickoff/analysis.md
⑤ 対外コミュニケーション	wiki/kickoff/communication.md
⑥ 意思決定相談	wiki/kickoff/decision.md

英語で進めるなら lang: "en" を付ける。

> 取得できなくても止まらない（重要）。 未接続・権限エラー・承認拒否・応答なし のいずれでも、この Step を飛ばして Step 4 へ進む。型が無い分だけ浅くなるが、初手は成立する。ユーザーに技術的な失敗理由を説明しない（「今回は簡易版で進めます」程度に留める）。

Step 4. 顧問（Xessor）の判断軸を引く【🔒 絶対ルール】

Step 0 の customer_id で advisor_list を引き、依頼に最も効く顧問を、そのとき実在する一覧から動的に選ぶ。引用先をこのファイルに書かない（新規Xessorも自社が契約する顧問も自動的に候補になる）。

1. 効く顧問を選ぶ（複数効くなら2〜3人まで）。カテゴリー別の型に「効きやすい領域」の指針がある。

2. advisor_consult（advisor_id＋query＋purpose）で「この相手・この状況にどの論点が刺さるか」を壁打ちする。ユーザーに「顧問に相談しますか？」と尋ねない——必要と判断したら即座に呼ぶ。

3. 出力に差し込むときは出典を峻別する。

- 顧問由来（判断のレンズ）：「〈営業顧問の視点〉この相手には"機能の網羅"より"意思決定の一点"に絞る方が効く——という判断軸に照らすと…」

- 顧客文脈（自社の蓄積）：「御社の過去案件（〇〇）では…」

4. 実際に使った顧問ナレッジを advisor_mark_used で申告する（read は自動記録されるが、使った事実は申告しないと残らない）。

5. 顧問の判断軸の範囲を超える問いは断定せず、「この点はご本人への確認が要る領域です」と促す。顧問ナレッジの当否をこちらで裁定しない。

効く顧問が居ない・薄いときだけ、汎用知識で示唆を出す。その場合は「顧問由来ではない」と分かる書き方にする（顧問の権威を借りない）。

Step 5. 深い出力

握った枠の中で、文脈からの示唆まで書く。いきなり資料化せず、まず文章だけで構造を出す。

示唆の合否判定（最重要）

> その一文を、隣の会社の資料にそのままコピペして成立するなら、それは示唆ではない。

深さの3段階＝① 説明（何を表すか）／② ファクト（読み取れる事実）／③ 示唆（意味・とるべき行動）。各ブロックを②で終えず、必ず③まで書く。

Step 6. 副産物として判断軸を残す（静かに）

出力後、再利用価値のある初手の決断が生まれていれば、その決断＋一言理由を structa_capture（Step 0 の customer_id・category は「判断軸」）で静かに保存する。毎回の雑務では無理に保存しない。記録UIを課さない。

> structa_capture 後に「組織ナレッジ蒸留結果」が返っても、自分で structa_approve_distillation を呼ばない。内容を提示し、承認を得てから実行する。未接続時はこの Step をスキップ。

---

🔒 絶対ルール

1. テナントIDをハードコードしない。 Step 0 で実行時に解決した1つの customer_id を全ツールに一貫適用する（Step 3 の公開ナレッジだけは全組織共通の公開先）。

2. 起動時に必ず advisor_list を参照し、依頼に最も効く顧問を動的選定して出典付きで引用する。引用先をこのファイルに列挙・固定しない。

3. Claude IS the UI。 ツール名・ID・内部の仕組みをユーザーに意識させない。ユーザーはただ相談するだけ。

4. 顧問由来と自社文脈を峻別する。 混ぜない。

5. いきなり資料化しない。 文章で構造を固め、合意を得てから体裁化へ進む。

6. 失敗しても止まらない。 型が取れなくても、顧問が居なくても、初手の握りと示唆だけで成立させる。

アンチパターン

• 引用する顧問名・テナントIDのハードコード
• 初手決断のフォーム化（長い質問票）
• 顧問の引用を汎用アドバイスに埋没させ、固有性を消す
• 相手固有の情報を読まずに書き始める（＝必ず浅くなる）
• 「業界動向」「一般論」で段落を埋める
• 文章構造の合意前にスライド化・清書へ進む
• カテゴリー別の型を2つ以上まとめて読む（初手の前に文脈を食い潰す）

うまくいかないとき

• 動作がおかしい（型が読めない・顧問が出てこない）→ Claude に「Structaに要望を送って」と言えば投書箱に届きます。
• 導入や設定で詰まった → https://structa.me/desk#contact （返信します）

どちらも、何が起きたかをそのまま貼っていただければ十分です。

`