Learn Pc Compare

このステップは受講者自身が実行します。 スキルは代行しません。

まず、演習用ディレクトリを作成する。スキルが以下を実行する:

mkdir -p learn-workspace/01-01-compare/vague learn-workspace/01-01-compare/structured

次に、受講者に指示する:

「演習用ディレクトリを作成しました:
- learn-workspace/01-01-compare/vague/ — 曖昧な指示の結果
- learn-workspace/01-01-compare/structured/ — 構造化された指示の結果

後で比較するために、両方の結果を別ディレクトリに残します。

では、曖昧な指示で実装させてみましょう。

**次のあなたのメッセージは、私（スキル）ではなく Claude Code の通常の実装機能が処理します。
そのまま実装指示を入力してください。**」

テーマごとの曖昧な指示例:

「learn-workspace/01-01-compare/vague/ の中に実装するよう指示してください。
準備ができたら、そのまま Claude Code に指示を出してください。」

重要: ここでは受講者自身が Claude Code に指示を出す。このスキルが代わりに実装しない。

実装結果を観察した後:

「結果を確認しましょう:
- どんな機能が入っていましたか？
- 期待通りでしたか？
- 予想外の機能や、足りない機能はありましたか？」

受講者の気づきを聞く。

Step 4: 構造化された指示で実装

このステップは受講者自身が実行します。 スキルはテンプレートの提示とフィードバックを行います。

「次に、同じ機能を構造化された指示で実装させます。
以下のテンプレートを参考に、指示を組み立ててください:

（まとめて書きたい方は「一括で書きます」と言ってください。段階的にガイドすることもできます。）」

構造化テンプレート:

## 目的

[何を作るか、なぜ作るか]

## 仕様

- 機能一覧（箇条書き）
- 入出力の形式
- エラー処理の方針

## 制約

- 使用言語/ライブラリ
- やらないこと

## 完了条件

- [ ] 具体的な検証項目

受講者が初めて構造化された指示を書く場合は、段階的に進める:

「まず **仕様** から書いてみましょう。
Step 3 の結果を踏まえて、欲しい機能を箇条書きで 3 つ以上挙げてください。」

仕様を確認した後:

「いいですね。では残りの要素を追加しましょう:
- **目的**: なぜこれを作るのか、一文で
- **制約**: 使わない技術、やらないこと
- **完了条件**: 動作確認できるチェックリスト（例:「コマンドを実行して○○が表示される」のように書きます）

全部揃ったら、learn-workspace/01-01-compare/structured/ に
実装するよう Claude Code に指示してください。

**次のあなたのメッセージは、私（スキル）ではなく Claude Code の通常の実装機能が処理します。
そのまま構造化された指示を入力してください。**」

受講者が「一括で書きます」と言った場合や、スムーズに 4 要素を書ける場合は、段階的ガイドをスキップして一括で書いてもらう。

テーマ A の模範例（受講者が困っている場合のみ提示）:

## 目的

タスク管理の CLI ツール。ターミナルから素早くタスクを追加・完了・一覧できる。

## 仕様

- `todo add "タスク名"` でタスクを追加
- `todo list` で一覧表示（未完了→完了の順、作成日時付き）
- `todo done <番号>` でタスクを完了
- データは `~/.todo.json` に永続化

## 制約

- Node.js + TypeScript で実装
- 外部ライブラリは使わない（標準ライブラリのみ）
- GUI は作らない

## 完了条件

- [ ] 3 つのコマンド（add, list, done）が動作する
- [ ] データが再起動後も保持される
- [ ] `npx tsx todo.ts add "テスト"` で実行できる

重要: 受講者自身に構造化指示を考えてもらう。模範例は最後の手段。

Step 5: 比較と振り返り

「2 つの結果を比較してみましょう。以下の観点で評価してください:」

受講者に各セルを埋めてもらい、感想を聞く。

もし 2 つの結果に大きな差がなかった場合は、以下の補足質問を投げかける:

「今回は差が小さかったかもしれません。では視点を変えてみましょう:

もし 10 人のチームメンバーが同じ曖昧な指示を出したら、
全員が同じ結果を得られると思いますか？

構造化された指示なら、チーム全体の出力のばらつきはどうなるでしょう？」

Step 6: ProjSight への記録

このステップはスキルが代行します。 受講者は内容の確認だけ行ってください。

「この気づきを ProjSight に記録します。
学習用プロジェクトに演習結果を記録しますね。」

スキルが以下を実行する:

1. list_deliverables(projectId) で成果物一覧を取得し、学習に関連する成果物を特定する
   • 成果物が見つからない場合: upsert_deliverable(projectId, title: "学習演習の成果物", description: "ProjSight 学習カリキュラムの演習記録") で作成する
2. 受講者に確認する:

「以下の成果物に紐づけて記録します:
- [成果物名を表示]

これで良いですか？」

3. 受講者の確認後、upsert_task(projectId, title, deliverableId, description) で演習タスクを作成
   • title: 01-01 Prompt Craft 比較演習の振り返り
   • description: 受講者の比較結果と気づきを Markdown で構造化

## 背景

Prompt Craft の最初の演習として、曖昧な指示 vs 構造化された指示の比較を実施。

## 比較結果

| 観点                     | 曖昧な指示     | 構造化された指示 |
| ------------------------ | -------------- | ---------------- |
| 期待との一致度           | [受講者の回答] | [受講者の回答]   |
| 手戻りの必要性           | [受講者の回答] | [受講者の回答]   |
| コードの品質             | [受講者の回答] | [受講者の回答]   |
| やり直し・追加指示の回数 | [受講者の回答] | [受講者の回答]   |

## 気づき

[受講者の気づきを記録]

## 完了条件

- [x] 曖昧な指示で実装を実施した
- [x] 構造化された指示で実装を実施した
- [x] 比較結果を記録した

4. start_work(taskId) → complete_work(taskId) で完了

Step 7: スキル解説

「あなたが今体験したのが **Prompt Craft** — 指示の構造化です。

参考資料の言葉を借りると:
『曖昧な指示は、曖昧な出力を生みます。
 期待する出力形式、制約、完了定義を明示することが不可欠です。』

構造化された指示の 4 要素:
1. **目的** — なぜやるか（背景と動機）
2. **仕様** — 何をするか（具体的な機能・動作）
3. **制約** — やらないこと（スコープの限定）
4. **完了条件** — どうなったら終わりか（検証可能な基準）

この 4 要素は、ProjSight のタスク記述テンプレートそのものです:
- 目的 → ## 背景
- 仕様 → ## 対応内容
- 制約 → ## 制約
- 完了条件 → ## 完了条件

次の /learn-pc-rewrite では、既存の曖昧なタスク記述を改善する練習をします。」

注意事項

• 受講者が自分で指示を書き、自分で実行することが重要。代行しない（Step 3, 4）
• ProjSight への記録（Step 6）はスキルが代行する。受講者の負担を減らす
• 模範例はヒントとして提示し、丸写しを推奨しない
• 比較結果は受講者の主観で OK。正解はない
• 実装コードの品質評価は不要（比較の体験が目的）
• 演習の実装は learn-workspace/01-01-compare/ に格納する（vague/ と structured/ に分離）。本番プロジェクトのコードと混在させない