作業フォルダで Claude Code を起動し、/init を実行します。Claude Code がフォルダの中身を調べ、CLAUDE.md の初版を提案します。生成された CLAUDE.md を開いて、何が書かれているか（プロジェクト概要、構成、コマンド類）を読んでください。

/context を実行し、現在のコンテキストの内訳（CLAUDE.md、会話履歴、読み込んだファイルなど）と消費トークンの目安を確認します。CLAUDE.md がコンテキストの先頭に固定で乗っていることを目で見てください。

適当な質問を 3 往復してから /context で増えたトークンを確認し、/compact を実行します。会話が要約に圧縮され、流れは保たれたままトークンが減ることを確認してください。次に /clear を実行し、履歴ごと消えて仕切り直しになることを確認します。

/model でモデル一覧を開き、Haiku 系に切り替えてから「このフォルダの構成を 3 行で説明して」と依頼します。次に Sonnet 系に切り替えて同じ依頼を投げ、応答の深さと速さを見比べてください。

同じモデルのまま、「軽く考えて答えて」と「じっくり手順を踏んで考えて」で同じ設計判断を 1 つ相談し、出力の丁寧さがどう変わるかを観察します。Effort をどこで上げ、どこで下げるとコストと品質の釣り合いが取れるかを 1 行メモしてください。

VS Code で ~/.claude/（ユーザー設定）と作業フォルダの .claude/（プロジェクト設定）を両方開きます。Claude Code に次を聞いてください。

~/.claude/ のユーザー設定とこのプロジェクトの .claude/ 設定は、
同じ項目が衝突したときどちらが優先されますか。
このプロジェクトで実際に効いている設定がどこ由来かを一覧にしてください。

確認方法：ユーザー設定が全プロジェクト共通の土台で、プロジェクト設定がそれを上書きする関係になっていることを、Claude の回答と実ファイルの両方で確かめます。

Skills / Subagents / Commands / MCP / Hook の 5 つについて、「何のための道具か」「いつ発火するか」「どこに置くか」を 1 行ずつ、notes/parts_map.md に自分の言葉でまとめます。たたき台を Claude に出させてから、自分で削って整えてください。

Claude Code の Skills / Subagents / Commands / MCP / Hook の 5 つについて、
「役割」「発火するタイミング」「置き場所」を 1 行ずつの比較表にしてください。
公式ドキュメントの用語に合わせ、私が判断できる粒度で簡潔に。

5 部品それぞれについて「協栄産業の自分の業務だと何に使えそうか」を 1 例ずつ書き足してください。

Claude Code で / を打ち、候補に /summarize-file と /explain-error が出ることを確認します。/summarize-file src/sample.py を実行し、引数で渡したファイルが要約されることを見てください。

.claude/commands/summarize-file.md を VS Code で開きます。中身が普通のプロンプト文で、$ARGUMENTS で引数を受け取っていることを確認してください。ファイル名がそのままコマンド名になる規則も押さえます。

「毎回同じ指示を打っている作業」を 1 つ思い浮かべてください。例：変更差分をレビューして commit メッセージ案を 3 つ出す、エラーログを貼ると原因候補を絞る、関数にテスト雛形を生やす。引数で渡す対象（ファイル名など）も決めます。

Claude Code に作らせても、自分で書いても構いません。Claude に頼む場合の指示例：

.claude/commands/review-diff.md を作ってください。
中身は「git の変更差分をレビューし、リスクの高い変更を上から指摘し、
commit メッセージ案を 3 つ出す」プロンプトにしてください。
対象パスは $ARGUMENTS で受け取れるようにしてください。

確認方法：/ を打って候補に自作コマンド名が出ること、実行して期待どおりの動きが返ることを確認します。出てこない場合はファイルの置き場所（.claude/commands/ 直下か）とファイル名を見直してください。

1 回実行してみて、毎回手で補足説明を足しているなら、その説明をコマンド本文に書き足します。「補足なしで一発で意図どおり動く」状態をゴールにしてください。

早く終わったら：引数を 2 つ受け取るコマンドや、複数行プロンプトのコマンドにも挑戦してください。作ったコマンドは Day 2 でもそのまま使えます。

Claude Code で「data/meeting_sample.md を会議サマリ形式に整形して」と依頼します。meeting-summary Skill が読み込まれ、3 区分の Markdown が返ることを確認してください。/meeting-summary と打って手動発火もできます。

.claude/skills/meeting-summary/SKILL.md を開き、frontmatter の name description と、本文に書かれた手順を読みます。description が「いつこの Skill を使うか」の判定材料になっていることを押さえてください。

「src/order.py を multi-review でレビューして」と依頼します。3 つの観点が同時に走り、最後に統合レポートが返ります。実行中、複数の Subagent が並行して動いている表示を見てください。

SKILL.md を開き、本文が「3 観点を並列で起動して集約する」という段取りを書いていることを確認します。段階 1 との差は「自分で全部やる」か「別働隊に振って束ねる」かです。観点が独立しているほど並列が効くことをメモしてください。

「assets/mock_screen.png を ui-from-mock で構造化して」と依頼します。Skill が画像を読み、画面の要素（ヘッダー、テーブル、フィルタなど）を一覧にし、HTML スケルトンを出力します。

Skill フォルダの中に SKILL.md だけでなく、参照テンプレートや変換手順が同梱されていることを確認します。出力された HTML を実際にブラウザで開き、「どこまで合っていて、どこから人間が直す必要があるか」を 1 行で書いてください。

「src/order.py を code-reviewer サブエージェントでレビューして、指摘を重要度順に並べて」と依頼します。実装の文脈に引きずられない、観点の独立した指摘が返ることを確認してください。

.claude/agents/spec-checker.md を開き、責務（何を見て、何を見ないか）が書かれていることを確認します。Subagent は「役割を絞った別人格」だと捉えると設計しやすくなります。

/triple-review src/order.py を実行します。3 つの観点が並列で走り、最後に観点別の指摘がまとまった 1 枚のレポートが返ります。3 体が同時進行している表示を見てください。

.claude/commands/triple-review.md を開き、「どの観点を、どの Subagent に、何ファイルに対して並列で投げるか」が書かれていることを確認します。コマンドが指揮、Subagent が実働という分担です。逐次で 3 回レビューする場合と比べて待ち時間がどう違うかを 1 行メモしてください。

早く終わったら：triple-review.md に 4 体目の観点（例：テスト網羅）を足して、自分の .claude/agents/ に対応するエージェント定義を 1 つ作ってください。Day 2 の本題材でそのまま再利用できます。

docs/meeting-notes.md を自分の目で 3 分読み、「結局なにを作る話か」を 1 行で言語化してください。閾値・通知頻度・通知先など、メモに書かれていない箇所（未確定事項）も拾っておきます。Claude Code は speckit-inventory/ で起動します。

議事メモを /specify に渡し、仕様を生成します。AI への指示例：

/specify docs/meeting-notes.md の内容をもとに、在庫アラート通知ツールの仕様を作成してください。
スコープは「在庫データの監視」「閾値判定」「通知メッセージ生成」の 3 機能とし、
実際の通知送信はモック（送信内容を標準出力に出す）で代替します。
議事メモに書かれていない要件は勝手に追加せず、未確定事項として最後にまとめてください。

確認方法：生成された spec を必ず通読し、Step 0 で拾った未確定事項が「勝手に埋められて」いないかを確認します。埋まっていたら「この項目は議事メモに根拠がありません。未確定事項に戻してください」と差し戻します。

/plan を実行し、spec から技術選定・モジュール構成・データ構造を導出させます。生成された plan に「なぜその構成か」の理由が書かれているかを見てください。理由が書けていない選定は、たいてい雰囲気で選ばれています。

確認方法：3 機能（監視・閾値判定・通知生成）が plan の中で別々のモジュールに割れているかを確認します。

/tasks を実行し、plan を検証可能な粒度のタスク列に分解させます。確認方法は次の 2 点です。タスクの先頭グループが「テスト作成」になっているか（実装が先頭なら並べ替えを依頼）、1 タスクが 15 分以内に終わるサイズに割れているか。

到達点の確認：specs/ 配下に spec.md / plan.md / tasks.md の 3 ファイルが揃っていれば本日分は完了です。実装（/implement）は Day 2 の冒頭で続けます。

早く終わったら：tasks のうち「通知メッセージ生成」をさらに 2 つに分割できないか検討し、分割案を tasks に反映してください。