Claude Code の Skill / Workflow 入門
— 「お客様向け提案書の自動作成」を題材に —

この資料は、Claude Code の Skill（スキル） と Workflow（ワークフロー） を、実際に社内で作った「提案書自動作成リポジトリ（proposal-automation）」を題材に学ぶハンズオン教材です。「リポジトリ」とはプロジェクトのファイル一式が入った共有フォルダのことで、以降もこの意味で使います。

• 対象読者：エンジニアに限りません。「Claude Code を触ったことがある（起動して日本語で頼んだことがある）」程度の経験があれば読み進められます
• この資料でできるようになること：①スキルが何かを人に説明できる ②専用ツールなしで自分のスキルを作れる ③作ったスキルを実行結果を見ながら改善できる ④スキルを繋いで大きな作業を自動化する Workflow の考え方が分かる
• 題材：企業名を渡すと、Web調査 → 課題分析 → 提案書ドラフト作成 → セルフレビューまで自動で行う実在のリポジトリ。説明に使う例・失敗談はすべてこのリポジトリで実際に起きたことです

この資料の立場：スキル作成に専用ツールは使いません。スキルの実体はただのテキストファイルなので、「Claude との会話」だけで作成・改善・共有まで完結できます。その方法を最初から最後まで通します（世の中にはスキル作成を支援するツールもあります。それとの使い分けは 2-5節のコラムで説明します）。

前提・準備

• Claude Code（CLI＝ターミナルで使う版・デスクトップアプリ・VSCode拡張のいずれか）が使えること。インストール・初回起動がまだの場合は、社内ハンズオン資料 cc-handson/session1.html（第1回）を先に済ませてください
• 演習は2種類あります：
  • どのフォルダでもできる演習（演習2・3）— 自分の普段の作業フォルダでOK
  • 題材リポジトリを使う演習（演習1・4）— 下の手順で題材フォルダを開いておく
• プログラミングの知識は不要です。Section 3 に少しだけプログラムの断片が出てきますが、「雰囲気を眺める」だけで大丈夫な構成にしてあります

題材リポジトリの開き方（演習1・4で使います）

1. リポジトリを自分のPCに取得する（この複製操作を「clone（クローン）」と呼びます）。場所（URL）は社内の案内で確認してください（リポジトリ管理者に確認するか、資料の配布連絡に記載があります）。操作が分からなければ、Claude Code に入手したURLを貼って「これを clone して」と頼めばやってくれます（名前だけだと同名の別リポジトリと紛らわしいので、URLで指示するのが確実です）。cloneできたら「どこに保存した？」と聞いて、フォルダの場所を控えておきましょう。エラーらしきメッセージが出て進めない場合は、無理に粘らず先輩や管理者に画面を見せて相談してください（GitHubのアカウントやアクセス権の準備が必要なことがあります）
2. 取得したフォルダを Claude Code で開く。スキルは「いま開いているフォルダ」を基準に読み込まれるため、この一手がいちばん重要です：
   • デスクトップアプリ：フォルダを開くメニューから proposal-automation を選ぶ
   • VSCode拡張：VSCode の「フォルダーを開く」で proposal-automation を開いてから、Claude Code のパネルを開く
   • CLI：ターミナルを開き（Mac は Spotlight で「ターミナル」と検索、Windows は「PowerShell」）、cd に続けてフォルダの場所を入力して移動し、claude と入力して起動。フォルダの場所が分からなければ、cd と打った後に Finder／エクスプローラーからフォルダをターミナルへドラッグすると自動入力されます
3. 不安なら Claude に「いま開いているフォルダはどこ？」と聞き、proposal-automation になっていることを確認してから演習に進んでください

Section 1: 知る — スキルとは何か

1-1. スキルとは何か

Claude Code に毎回同じ説明をしていませんか。「議事録をまとめるときは、決定事項と宿題を分けて、宿題には期日を付けて…」——こうした口頭で繰り返し説明していた作業手順を、名前のついた手順書にして棚に置いておく仕組みがスキルです。

• 一度スキルにすれば、/スキル名 と打つだけで呼び出せます。また、依頼の内容から Claude が「この作業はあのスキルの出番だ」と判断して自動で使ってくれることもあります
• 実体は SKILL.md というただのテキストファイル（Markdown）です。プログラミングは一切不要で、日本語で手順を書くだけです

題材リポジトリの実例

提案書自動化リポジトリには、提案書作成の工程ごとに12個のスキルが入っています。例えば：

ポイントは、どれも「人間がやるなら30分〜数時間かかる定型作業」を、手順書として言語化してあることです。スキル化の候補は「またこの作業か」と思った瞬間に見つかります。

1-2. SKILL.md の解剖 — 中身はこれだけ

スキルファイルは「ヘッダー（3項目の自己紹介）＋本文（手順書）」の2部構成です。題材リポジトリの skill-collect-strategy を簡略化して見てみます：

---
name: skill-collect-strategy
description: 顧客企業の経営方針・重点領域・中期目標を、IR資料や公式サイト、
  ニュースなどの公開情報から調査して箇条書きでまとめる。お客様向け提案書を
  作成する際、最初のステップとして必ず使う。
allowed-tools: WebSearch, WebFetch
---

## 目的
提案書は、顧客企業の経営方針とずれていると響かない。提案の土台として、
まず顧客企業が中長期的に何を目指しているかを、公開情報から把握する。

## 手順
1. 渡された企業名で、中期経営計画・IR資料・プレスリリース等をWeb検索で探す
2. 見つかった情報から、経営方針・重点領域・中期目標を抽出する
3. 情報の鮮度（いつ時点の情報か）を必ず確認し、出力に記載する
4. 非上場企業などで公開情報が乏しい場合、無理に情報を作り出さない

## 出力フォーマット
（まとめ方の型をここに書く）

## 気をつけること
- 噂レベルの情報とIR資料のような一次情報を同列に扱わない
- 誇張・断定を避ける。分からないことは「不明」「推測」と明記する

ヘッダー（--- で挟まれた部分）に書ける項目はほかにもありますが、まずはこの3つを覚えれば十分です：

💡 本文は呼ばれた時だけ読まれる：Claude が常に読んでいるのは description だけで、本文はスキルが呼ばれた時に初めて読まれます。だから手順書が長くなっても、普段の会話の邪魔にはなりません。

1-3. スキルフォルダの構成 — 同梱できるファイルと役割

スキルは「1フォルダ＝1スキル」で、フォルダ名がそのまま呼び出しコマンド名になります（meeting-summary/ → /meeting-summary）。フォルダに必ず要るのは SKILL.md の1つだけですが、補助ファイルを同梱することもできます：

skill-name/
├── SKILL.md        ← 必須
├── reference.md    ← 参考資料（任意）
├── templates/      ← 雛形（任意）
└── scripts/        ← 実行スクリプト（任意）

各ファイルの役割と使いどき（名前は自由です。上記は分かりやすい例）：

💡 補助ファイルも会話の邪魔にならない：1-2節の「本文は呼ばれた時だけ読まれる」仕組みは補助ファイルにも効きます。読まれるのは「スキルが呼ばれ、かつ本文がそのファイルを参照したとき」だけなので、長い資料を同梱しても普段の会話には影響しません。

このリポジトリでの使い分け（設計判断の実例）

※ この項は初読では読み飛ばして構いません。スキルを複数作るようになったら戻ってきてください。

題材リポジトリの12個のスキルは、実はすべて SKILL.md 単体で構成されていて、補助ファイルを同梱していません。ただし補助ファイルに相当するものは存在します——リポジトリ共通の inputs/ フォルダです：

• inputs/提案書テンプレート.md …… templates/（雛形）に相当。提案書の章立ての型
• inputs/自社概要.md …… reference.md（参照資料）に相当。自社の強み・事業内容の情報源

スキルフォルダに同梱しなかった理由は、これらを複数のスキルが共有して参照するからです（テンプレートは骨子作成・提案書執筆・レビューの3スキルが、自社概要は5スキルが使う）。ここから使い分けの指針が導けます：

そのスキル専用の資料 → スキルフォルダに同梱（スキルごと持ち運べて、コピー改変時も一緒に付いてくる）
複数のスキルで共有する資料 → リポジトリの共通フォルダに置き、SKILL.md からパス（＝ファイルの置き場所を示す住所のような文字列）で参照（1箇所直せば全スキルに反映される）

1-4. 置き場所とスコープ

スキルは、置き場所によって使える範囲が変わります：

💡 ~ は自分のユーザーフォルダ（ホーム）のことです。また .claude のような「.」始まりのフォルダは隠しフォルダで、標準設定では画面に表示されません。探すときは Claude に「中身を見せて」と頼むのが早道です。「コミット＆プッシュ」は変更を記録して共有場所へ反映する操作のことで、これも Claude に頼めます（2-4節）。

題材リポジトリは後者です。リポジトリを clone した人は、12個のスキルを追加設定なしでそのまま使えます——これが 2-4節 で扱う「スキル共有」の正体です。

1-5. 作る前に知っておく — 既に用意されているスキル

スキルの入手経路は自作だけではありません。①最初から入っている（組み込み）／②配布されているものを導入する（プラグイン）／③自作するの3つがあり、作り始める前に①②を確認する癖をつけると、車輪の再発明を避けられます。

組み込みスキル — Claude Code に最初から同梱されているもの

自作しなくても、Claude Code には最初から多数のスキルが入っています。代表例：

• このほかにも多数あります。利用できる顔ぶれは環境やバージョンで変わるので、「いま使えるスキルの一覧を教えて」と Claude に聞くのが確実です
• 組み込みスキルは .claude/skills/ フォルダを覗いても見えません（本体に同梱されていて、呼ばれたときに読み込まれるため）。「フォルダに無い＝使えない」ではない点に注意してください

配布されたスキルを導入する — プラグインという仕組み

スキルは「プラグイン」というパッケージの形で配布されていることもあります。Anthropic 公式の配布カタログ（マーケットプレイス）があり、/plugin コマンドで導入します。2-5節のコラムで扱う skill-creator も、この形で配布されている道具の1つです。

💡 プラグインの導入手順と公式カタログの内容は、本資料のスコープ外なので割愛します。社内ハンズオン資料 cc-handson/session2.html の 3-2節・3-6節に導入例（security-guidance）と主要プラグインの一覧があります。

「探す→無ければ作る」の順番で

まとめると、定型作業を見つけたときの動きはこうなります：

1. まず「この作業をするスキルってもう無い？」と Claude に聞く（組み込み・導入済みの確認）
2. 配布されているプラグインに良いものがあれば導入する
3. それでもカバーされない、自分たちの業務に固有の定型作業こそ、自作スキルの出番——ここからが Section 2 です

☕ ここまでが「知る編」です。読み疲れたら、ここで一区切りして続きは別の日でも大丈夫です（ここから先は、手を動かす演習が中心になります）。

Section 2: 作る・育てる — 専用ツールなしのスキル作成

2-1. 作り方の4つの入口

スキルの実体はテキストファイルなので、作り方は突き詰めると「誰かが書く」だけです。ただし「何を元に書くか」で4つの入口があり、状況によって使い分けます。

入口A：要件を言葉で伝えて、Claude に書かせる

作りたい手順を最初から言語化できるときの方法です。題材リポジトリの最初のスキルは、実際に次のような依頼で作られました：

• コツは「入力（何を渡すか）・出力（何がどんな形で出てくるか）・注意点」の3点をセットで伝えること。この3点が揃っていれば、Claude はかなり良い初版を書きます

入口B：実際にやった作業を、あとからスキル化する

実務ではこちらの方が自然です。要件を先に言語化できなくても、まず1回やってみればいいのです。Claude と対話しながら作業を1回やり、うまくいったら：

• 実演した手順・途中で出した修正指示・最終的な出力の形が、そのまま手順書の材料になります
• 「またこの作業か」と思った瞬間が、この入口の使いどきです

入口C：既存スキルをコピーして改変する

2個目以降のスキルはほぼこれです。構成（目的・手順・出力フォーマット・気をつけること）を流用して中身だけ差し替えるので、速くて品質も安定します：

• コピー元は自分のリポジトリでなくてもかまいません。公開されているスキルや、プラグインに同梱されているスキルも、中身は同じ SKILL.md です

入口D：構造を理解して、自分で手直しする

「自分で書くのは Claude に頼むのと同じでは？」と思うかもしれません。半分正しいのですが、決定的な違いが1つあります。SKILL.md の構造（1-2節）を理解している人は、Claude が書いたスキルをレビューして手直しできるのです。入口A〜Cで作った初版の品質を最終的に決めるのは、この「読める・直せる」力です。次の 2-2節 でチェック観点を示します。

8/20 営業定例MTG メモ
・新パンフレットは10月改訂で確定（担当: 田中）
・価格表の値上げ反映は保留。9月の部会で再協議
・山田 → 競合3社の価格を調査して次回共有
・佐藤 → 見積テンプレの誤字修正（8/25まで）
・佐藤 → 顧客アンケートの集計もお願いしたい
・次回アジェンダ作成は山田

9/3 企画部 週次MTG メモ
・秋のキャンペーンはSNS中心で実施に決定（担当: 高橋）
・ノベルティの再発注は保留。在庫数の確認待ち
・鈴木 → LPの文言案を作成（9/10まで）
・高橋 → 過去キャンペーンの効果データをまとめる
・田中 → 会場の空き状況を確認して次回報告

2-2. 良いスキルのチェック観点（入口Dの実践）

Claude が書いた SKILL.md を受け取ったら、次の4点をチェックします。ダメな例→良い例で見るのが早いです：

💡 理由を添えると守られやすい：AI への指示は、命令口調を強めるより「なぜそうするのか」を添える方が効きます。禁止ルールには必ず理由をセットで書いてください。

2-3. スキルを育てる — 実行→観察→ルール追記の改善ループ

スキルは一度作って終わりではありません。実際に使い、出力の問題を見つけ、その問題が二度と起きないルールを SKILL.md に追記する——このループがスキルの品質を決めます。

作る → 実行する → 出力を観察する → 問題を見つける
                                        ↓
        SKILL.md に「理由付きのルール」を追記する → また実行する…

題材リポジトリで実際に起きた失敗と、追記されたルールを3つ紹介します。すべて本当にあった話です（登場する金額は、いずれもAIが業界相場から仮置きした試算値で、実際の商談額ではありません）：

実話①：AI が架空の「実績」を書いた

• 起きたこと：完成した提案書に「チャネル横断のデータ活用基盤構築の実績があります」という一文が入っていた。しかし自社資料のどこにもそんな実績は書かれていない——AI が文章を整える過程で「事実を作って」しまった。顧客に出せば虚偽の実績主張になる、一番危険なミス
• 追記したルール（skill-write-proposal）：「前工程の出力や自社概要に存在しない事実（実績・数値・固有名詞）を新たに作らない。この工程の仕事は言い換え・整文までであり、事実の追加ではない」＋実際に事故が起きた旨の注意書き

実話②：検算できない見積もり金額が出た

• 起きたこと：提案書の見積もり表に「上限ケース 4,680万円」とあったが、同じ表に書かれた単価×人数×期間をどう組み合わせても、この金額にならなかった。しかもレビュー工程も目視チェックだけで見逃した
• 追記したルール（skill-estimate-price）：「合計行には必ず計算式（単価×人数×月数）を併記し、検算可能にする」。さらにレビュー側にも「金額表は目視ではなく必ず自分で再計算して照合する」を追加

実話③：施行済みの法改正を「予定」と書いた

• 起きたこと：既に施行済みの法改正を、Web記事の古い時制のまま「施行予定」と書いてしまい、その誤りが後続の分析にもそのまま伝播した
• 追記したルール（skill-analyze-market）：「法規制・制度の施行日は、必ず今日の日付と突き合わせて『施行済み』か『未施行』かを確定して書く」

このループの本質：失敗を「今回だけ手で直す」で終わらせず、失敗の実話をルールとしてスキルに刻むこと。そうすればチームの誰が使っても、同じ失敗は二度と起きません。スキルは「チームの経験が蓄積されるノート」になります。

2-4. スキルを共有する — チームの資産にする

• リポジトリ内の .claude/skills/ に置いたスキルは、コミット・プッシュするだけでチーム全員に共有されます。clone した人は追加設定なしでそのまま使えます。操作自体も「このスキルをコミットしてプッシュして」と Claude に頼めます
• スキルの改善（2-3節のルール追記）も、コミットすれば全員に行き渡ります。誰かの失敗から生まれたルールが、チーム全員の再発防止になるのが共有の最大の価値です
• 個人的な作業用スキルは ~/.claude/skills/（自分専用）に置き、チームで使うものだけリポジトリに入れる、という使い分けが基本です

2-5. コラム — skill-creator を使わない理由と、使うべき場面

※ この節はコラムです。読み飛ばしても、以降の理解に影響はありません。

Anthropic 公式のプラグイン skill-creator を使うと、対話形式でスキルを作成でき、さらにテスト・評価・改善・性能比較まで支援してくれます。それでもこの資料があえて使わなかったのには理由があります。公平に、両方の言い分を並べます。

この資料が「使わない方法」で通した3つの理由

1. 構造の理解が先だから（教材として）
   ツール経由で作ると、できあがった SKILL.md が「よく分からないけど動くもの」（ブラックボックス）になりがちです。ところがスキルの品質を最終的に決めるのは、入口D（2-1節）の「読める・直せる」力——これは skill-creator で作ったスキルの手直しにも結局必要になります。先に素の作り方を身につければ、ツールは後からいつでも足せます。逆は簡単ではありません。
2. 導入不要で、どの環境でも同じやり方が通用するから
   skill-creator はプラグインのインストールが必要で、環境によっては /plugin コマンド自体が使えないことがあります（実話：本リポジトリの作成時も、最初に使った環境ではインストールコマンドが通りませんでした）。「Claude との会話だけ」の方法は、CLI・デスクトップ・VSCode拡張のどれでも、追加設定なしでそのまま使えます。
3. 社内スキルには「実務の中の改善ループ」の方が軽くて的を外さないから
   skill-creator の評価機能は、テスト用の課題を複数用意し、スキルあり／なしで並列実行して比較する本格的なものです。強力ですが、時間も AI の利用コストもかかります。チーム内の定型作業スキルなら、2-3節の「本番で使う→困った点をルール化する」ループで十分なことがほとんどです。実際に起きた失敗から作ったルールは、想定で作ったテストより的を外しません。

逆に、skill-creator が本領を発揮する場面

フェアに言うと、skill-creator の真価は「対話で作れること」よりも「作った後の品質保証」にあります：

• 効果の数値比較（Eval / Benchmark）：同じ課題を「スキルあり」「スキルなし」で並列実行し、合否・所要時間・コストを比較してくれる。「このスキル、本当に効いてるの？」に数字で答えられる
• description の自動最適化：「このスキルが自動起動すべき質問／すべきでない質問」を20個ほど生成し、起動精度を測りながら description の言い回しを自動で改善するループを回してくれる。自動起動の精度チューニングは手動では難しい領域
• 配布用パッケージ化：スキルを配布ファイルにまとめられる

使い分けの目安

💡 両者は排他ではありません。手作りで作って育てたスキルを、広く配布する前に skill-creator の評価だけ借りる——という併用が現実的な落としどころです。skill-creator を使う場合の手順は cc-handson/session2.html の3-3節を参照してください。

☕ スキルを「作って・育てて・共有する」——この資料の中心はここまでで完了です。Section 3 は複数のスキルを繋ぐ発展編で、読み物が中心です。

Section 3: 繋ぐ — Workflow でスキルを組み合わせる

3-1. Workflow とは何か

スキルが「料理人1人が持つ1品のレシピ」だとすると、Workflow は「オーダーが入ってから料理が出るまでの厨房全体の段取り表」です。複数の AI 担当者（エージェント）に、どの手順書（スキル）を、どの順番で、どれを同時並行でやらせるかを決めておく仕組みです。

• 置き場所はリポジトリ内の .claude/workflows/。中身はプログラム（JavaScript）ですが、使う側はプログラムを読む必要はありません
• 実行はチャットで頼むだけです（例は次節で説明する「第1段階」の Workflow）：

💡 fileSlug（ファイルスラッグ）は、成果物を保存するフォルダの名前になる短い文字列です（例：企業名の短縮形）。

• 実行するとバックグラウンドで複数のエージェントが動き出し、20分〜45分ほど（段階による。実測値は演習4参照）で成果物（ファイル）ができあがります。進行中も別の会話を続けられます

事前情報を渡したいとき — ヒアリングメモの仕組み

実行前に proposals/（企業名）/ヒアリングメモ.md というファイルを置いておくと、調査を担当するスキルたちがWeb検索の前にそれを読み、書かれている内容を一次情報として扱います。営業が実際に聞いてきた話（予算感・社内体制・経営陣の温度感など、Webには載っていない情報）を提案に反映させたいときや、公開情報が乏しい企業を扱うときに使います。

• ファイルが無ければ、従来どおりWeb検索だけで進みます（置かなくても動作は変わりません）
• メモに書かれていないことは、これまでどおり「不明」「推測」として扱われます。メモがあるからといって、それ以外まで断定されることはありません（2-3節・実話①の「存在しない事実を作らない」ルールとの共存）

スキルと Workflow の役割分担

3-2. 実例：提案書の2段階生成

題材リポジトリの Workflow は、12個のスキルを次の流れで繋いでいます：

【第1段階】proposal-angles-workflow（切り口の探索）
  顧客理解（経営戦略・市場環境を並列で調査 → 課題分析）
    ↓
  切り口探索（4つの視点のエージェントが並列で提案の切り口候補を列挙）
    ↓
  集約（重複をまとめ、スコアリングした比較表を出力）

━━━ ここで人間が比較表を見て、どの切り口で提案するかを決める ━━━

【第2段階】proposal-workflow（提案書の作成）
  第1段階の調査結果を読み込み、選ばれた切り口を軸に、
  価値訴求・体制（並列）→ 骨子 → 見積もり・スケジュール（並列）→ ROI
  → 提案書ドラフト執筆 → 自動レビュー（検算・事実確認）

なぜ「2段階」なのか — 実話から生まれた設計

最初は1段階（企業名→提案書まで全自動）でした。ところが同じ企業に対して同じ日に2回実行したら、全く別の提案書が出てきたのです。1回目は「法改正への緊急対応」（約2ヶ月・1,200万円規模）、2回目は「内製力強化」（約6ヶ月・4,000万円規模）。どちらも間違いではなく、Web検索でたまたま見つけた情報に提案の軸が引っ張られていました（金額はいずれもAIが業界相場から仮置きした試算値です）。

そこで「切り口の候補を網羅的に並べて、選択は人間がやる」構造に変えました。ポイントは、人間の判断を一番効く場所に置いたことです：

• 完成した提案書を事後レビューして方向性を直すのは、手戻りが大きい（ほぼ作り直し）
• 着手前に「どの切り口で行くか」を判断すれば、手戻りはほぼゼロ。AI に任せる部分と人間が判断する部分の境界設計こそが、Workflow 設計の本質です

Workflow の中身の「雰囲気」

中身のプログラムがどんなものかだけ、雰囲気を見ておきます（読めなくて大丈夫です）：

// エージェントに「スキルを読んで、その指示に従って作業して」と頼む
const strategy = await agent(
  `.claude/skills/skill-collect-strategy/SKILL.md を読み、その指示に従って
   企業「${companyName}」の経営戦略サマリーを作成してください。`
)

// 依存関係のない作業は parallel() で同時並行に走らせる
const [valueProp, constraints] = await parallel([...])

• つまり Workflow は「各エージェントに、どのスキル（手順書）を読ませて働かせるか」を並べたものです。作業の品質はスキル側が、段取りは Workflow 側が受け持ちます
• だから Section 2 でスキルを改善すると、Workflow 全体の品質が自動的に上がります。この分業が保守を楽にします

3-3. Workflow のハマりどころ（実体験より）

⚠️ エージェントは「気を利かせて」情報を落とすことがある

あるエージェントが、結果の全文を返す代わりに「結果はファイルに保存しました」という要約だけを返したことがありました。後続のエージェントは返答テキストしか受け取れないため、情報が途切れかけました。対策として、後続の工程が結果テキストを受け取る全ての指示に「結果の全文をそのまま返すこと。要約だけを返すのは禁止」という一文を入れています。

⚠️ 失敗は静かに起きる

途中のエージェントが失敗しても、Workflow は気づかず走り続けることがあります（実際、企業名が渡らないまま全工程が走り、中身が空の提案書ができたことがあります）。対策は「各工程の出力が空なら、そこで止めてエラーにする」チェックを入れること。自動化は「失敗したら大きな音で止まる」ように作るのが鉄則です。

⚠️ AI の出力は毎回変わる

同じ指示でも、Web検索の結果や文章の生成は毎回変わります。これはバグではなく性質です。「毎回同じであること」に頼る設計ではなく、変わっても大丈夫な構造（人間の判断ポイントを挟む、中間成果物を保存して根拠を追跡できるようにする、自動レビューで検算する）で受け止めます。題材リポジトリの2段階方式・中間成果物を保存する research フォルダ・レビュー工程は、すべてこの性質への対策です。

まとめ

• スキル＝名前のついた手順書。実体はテキストファイルで、プログラミング不要。description（何をするか＋いつ使うか）が自動起動の鍵。専用の資料はスキルフォルダに同梱でき、共有資料は共通フォルダに置いてパスで参照する
• 作る前にまず探す：組み込みスキル・配布プラグインで足りないかを確認し、カバーされない自分たちの業務固有の作業だけ自作する
• 作り方は4つの入口：要件を伝える／やった作業をスキル化する／既存スキルをコピー改変する／構造を理解して手直しする。学習と社内スキルには専用ツール不要で、Claude との会話だけで完結する（広く配布する段階では skill-creator の評価機能の併用も選択肢——2-5節）
• スキルは育てるもの：実行→観察→「理由付きルール」の追記。失敗の実話をルールに刻めば、チームの誰が使っても同じ失敗は起きない
• 共有はコミット＆プッシュするだけ：リポジトリの .claude/skills/ がチームの資産置き場になる（共有するのは本当にチームで使うスキルだけ。演習の練習スキルは共有しない——演習3の後片付け参照）
• Workflow はスキルを繋ぐ段取り表：品質はスキル側、段取りは Workflow 側という分業。設計の本質は「AI に任せる部分と人間が判断する部分の境界」を決めること

参考資料

• 題材リポジトリ：proposal-automation（README に使い方・docs/判断ログ.md に設計判断の記録）
• 社内ハンズオン資料：cc-handson/session2.html（Skills とプラグイン・skill-creator を使う場合の方法・Hooks・MCP など、本資料が扱わなかった周辺機能）
• 公式ドキュメント：https://code.claude.com/docs