course-outline-design

コース概要の設計

スキーマの正本：プリミティブなフィールド名（unit / concept / prompt / task / material / quiz / faq / illustration）はすべて _shared/domain-primitives.md に定義されています。このスキルでフィールドに言及する際は、同ファイルを正本としてください。

ファイル名の規約（英語優先）：生成するファイルとディレクトリには英語名を使用します。以前の中国語名との対応は _shared/domain-primitives.md §0 に記載されています。

このスキルでは、コースの構成の骨組みを作成します。日数、各日のテーマ、各ユニットで教える内容、共通の継続シナリオ、メタ情報（時間、教室、スケジュール）などを定めます。講義内容は作成しません。それは course-content-authoring の担当です。

呼び出すタイミング

• 「X のワークショップを開催したい」とユーザーが言っているものの、構成がまだない場合。
• ユーザーが散在するメモをコースとして整理したい場合。
• 既存の概要を改訂したい場合（ユニットの追加・削除、日ごとの配分変更など）。

成果物

標準的な概要では、以下のファイルを作成します。パスはユーザーのプロジェクトに合わせて調整しますが、各ファイルの役割は分けたままにしてください。この分離によって、後続のサブスキルが機能します。

course-package/   (or your preferred root)
├── overview.md         ← top-level meta + day list + shared scenario summary
├── shared-scenario.md     ← the persistent scenario / fictitious company / characters used across days
├── supporting-docs.md     ← optional: FAQ, pre-reading, environment setup
└── day{n}/
    └── outline.md     ← per-day outline: theme, units, learning goals, hours

ここでのファイル名が中国語なのは、このスキルが生まれたプロジェクトの規約だからです。プロジェクトに合った言語を使用してください。ただし、ファイルの役割は分けたままにしてください。overview.md を各日の概要に統合するのはよくある間違いです。そうすると、メタ情報を更新するたびに N 箇所を編集する必要があります。

必ず決めておくべき 5 つの事項

ファイルを作成する前に、次の事項を確認してください（必要に応じて、1 つずつユーザーに質問します）。

1. 対象者と前提知識 — 以降の各概念の深さを決めます。
2. 合計の受講時間と日数 — 例：6 時間を 4 日間、または 8 時間を 1 日間。これをもとにユニット数を決めます。
3. 共通シナリオ — 優れたワークショップには、ユニットをつなぐ架空の事例（企業、登場人物、データセットなど）が繰り返し登場します。ユニットを設計する前に決めてください。シナリオの要素が各ユニットの例に反映されるためです。
4. 学習成果を示す動詞 — 各日の終わりまでに、受講者が何をできるようになるべきかを決めます。知識を表す動詞（「理解する」「知る」）ではなく、行動を表す動詞（use、build、evaluate）を使ってください。
5. 評価の形式 — 事前テスト／事後テスト／クイズ／ポートフォリオのどれにするかを決めます。これによって、評価用にユニット枠を確保するかどうかが変わります。

ファイルごとのテンプレート

overview.md（概要）

# {Course title}

## 基本資訊
- **對象**: {audience}
- **總時數**: {total hours} ({days} 天 × {hours/day})
- **上課時間**: {schedule, e.g. 每週三 14:00–17:00}
- **教室**: {location + mapUrl if physical}
- **講師**: {instructor}

## 課程目標
{3–5 outcome statements using action verbs}

## 每日主題
| Day | 主題 | 核心產出 |
|---|---|---|
| Day 1 | ... | ... |
| Day 2 | ... | ... |
...

## 共用案例
{1-paragraph summary of the persistent scenario; full details in shared-scenario.md}

day{n}/outline.md（日ごとの概要）

# Day {n}: {day theme}

## 學習目標 (action verbs!)
- 能夠 {do X}
- 能夠 {do Y}

## 時程
| 時段 | 單元 | 重點 |
|---|---|---|
| 14:00–14:50 | u-1 {unit title} | ... |
| 15:00–15:50 | u-2 ... | ... |
...

## 單元細部
### u-1: {title}
- **學習目標**: ...
- **任務 (tasks)**: 條列學員實作項目
- **素材需求**: 條列此單元需要的素材檔（給 content-authoring 階段填）

shared-scenario.md

繰り返し登場する架空の背景を説明する 1～2 ページのドキュメントです。次の内容を含めてください。

• 企業名／登場人物名（実在の組織や人物と間違われない仮名を使用）
• コースで解決する中心的な課題
• データ形式の例（列名、ファイル形式など）。これらはクイズ項目やプロンプトの例で再利用します

避けるべきアンチパターン

• 「等內容寫完再回來補大綱」 — 内容を作成する前に概要を確定してください。内容の作成者は、各ユニットを概要の ID に対応づけるためです。
• 名詞だけのユニット名（例：「提示詞」）— 受講者が何をするのかタイトルから分からないため、適切ではありません。「構造化されたプロンプトを作成する」のように、動詞を含むタイトルを選んでください。
• 共通シナリオがない — 共通シナリオがないと、各ユニットの例がその場限りになり、受講者は手法がどのように積み重なるのかを理解できません。
• 合計時間が一致しない — メタ情報では「1 日 6 時間」となっているのに、時間割では 4.5 時間分しか埋まっていない、といった状態です。必ず時間割を合計して整合させてください。

完了ゲート（必須ルール — 引き渡し前に必ず通過）

「アウトラインを確定」と宣言して course-content-authoring を提案する前に、以下の各項目について書面で記録した成果物が必要です（口頭での「はい」だけでは不可）。ユーザーと一項目ずつ確認してください。回答が曖昧な場合は、次へ進む前に確認の質問を 1 つしてください。

1. 対象者 + 前提条件 — overview.md の 對象 フィールドに、具体的な一文で記録します（例：「Excel は使えるが、プログラミング経験のない管理部門の担当者」）。一般的な「初心者」では不十分です。

2. 総時間 + 日数 — 總時數 が記入されており、每日主題 テーブルの日ごとの行数が正確にその日数と一致していること。各 day{n}/outline.md の時間テーブルを合計し、1 日あたりの時間数と一致することを確認します。

3. 共通シナリオ（任意。ただし明示的に決定する必要があります） — 以下のいずれかを満たします。

   • shared-scenario.md があり、会社名／登場人物名 + 中心的な課題 + データ例の形式が 1〜2 種類記載されている。
   • または、overview.md に次の内容を 1 行で明記します：本課無共用案例，每單元獨立舉例。

   何も記録されていない場合は通過できません。どちらかを質問し、記録してください。

4. 学習成果の動詞 — 各日の 學習目標 には行動を示す動詞（use、build、evaluate、design、compare）を使います。知識を示す動詞（understand、know、learn about）は不可です。ユーザーに言い換えを依頼してください。

5. 評価の形式 — overview.md に明示的に記録します（例：「事前テスト 5 問／事後テスト 10 問／毎日のクイズ 3 問」）。または、次のような 1 行の注記で評価を行わないことを明示します：「本課無評量，採作品集驗收」。何も記録されていない場合は通過できません。

5 項目すべての成果物が書面で記録される前に、ユーザーが「もう大丈夫なので、先にコンテンツを書き始めて」と急かしてきた場合は、丁寧に断ってください。

「Stage 1 の確定が不十分なまま進めると、後の content／SPA／visual のどの段階でもアウトラインの変更に伴い、複数ファイルを連動して作り直すことになります。まず第 N 項を補いましょう。およそ X 分かかりますが、その後の手戻りを防げます。」

決定時の既定値（推測せずに質問する）

ユーザーが本当に答えがわからない場合、テンプレートを提案したり、プレースホルダーの既定値を埋めたりしないでください。短く直接的な質問を 1 つし、回答を待ってください。誤った想定に基づいてやり取りを重ねるより、往復を 1 回増やすほうが効率的です。

• 対象者が不明 → 直接質問します：「この講座は誰を対象としていますか？どの部門／役割の受講者で、現時点で何ができて、何ができませんか？」項目 2 に進む前に、具体的な回答を待ちます。
• 時間／日数が不明 → 直接質問します：「総時間と 1 日あたりの時間帯はどのように設定しますか？たとえば『2 日間 × 6 時間』や『毎週水曜 14:00〜17:00 を 4 週間』のような形です。」1 日 × 6 時間／2 日 × 6 時間／4 日 × 6 時間のテンプレートを提案してはいけません。決めるのはユーザーの予定であり、こちらの推測ではありません。
• 共通シナリオを決めていない → 直接質問します：「この講座全体を通して使う架空の事例（たとえば 1 つの会社や登場人物を設定し、すべての単元の例をそれに沿わせるもの）を用意しますか？用意する場合は一緒に設定します。用意しない場合は overview.md に『本課無共用案例』と記入し、第 3 項をスキップします。」シナリオを押し付けず、どちらの回答も受け入れます。

原則：このスキルでは、回答が明確な場合にその回答に応じて進めることで判断力を保ち、沈黙から勝手に推測しないようにします。

次のステージへの引き渡し

完了ゲートを通過した後に限り、ユーザーは次のものを用意できているはずです。

• アウトライン .md ファイル一式
• コンテンツ作成ステージで使用する、明確な単元 ID の規則（例：d{n}-u{m}）
• 確定済みの共通シナリオ

ユーザーに次のように伝えます：「アウトラインは確定しました。ここから日数や単元 ID を変更すると、後続作業に影響します。変更する前に知らせてください。」続けて、次に course-content-authoring を実行するよう提案します。

修正フロー（既存のアウトラインを変更する場合）

1. 変更点の差分を確認する — 影響を受ける単元 ID をすべて列挙します。
2. Stage 3 以降がすでに存在するか確認する（course-data.js があるか）。存在する場合は、後続ファイルも並行して更新する必要があると警告し、引き渡し時に teaching-site にその点を伝えるようにします。
3. 次の順番でファイルを更新する：overview.md（メタ情報）→ 影響を受ける day{n}/outline.md → shared-scenario.md（シナリオを変更する場合）。
4. コンテンツが作成済みの単元 ID は、絶対に変更しないでください。非推奨として扱い、新しい ID を割り当てて追加します。