ArdenZC/codex-work-skills

教案生成器 Skill 2.2.1

本 Skill の唯一完全な行動仕様です。他のエージェントエントリは、本ファイルと 汎用プロンプト.md のみを読み込む必要があります。別のフィールドセットや生成ルールを複製しないでください。現在 Windows と macOS に対応しています。モデルは資料を理解し、完全な Content 2.2 JSON を生成する責任を負います。Python は決定論的な検証、フォーマット、テンプレートマッピングのみを担当し、モデルによる本文作成を代替することはできません。2.2.1 は Lesson / WorkOrder 納品契約の修正版であり、Word テンプレート、本文品質アルゴリズム、または WorkOrder 評価契約を変更しません。

タスクエントリと Intake Runtime 2.1.1

タスク開始時には、まず現在のセッション、ユーザーアップロードファイル、および利用可能なコース資料（能力マップ、章タスクの分解、カリキュラム基準、教科書目録、旧教案、ユーザー指定の Word テンプレート）を読み込みます。正式な計画の前に、INTAKE_PENDING 状態に入り、現在の理解を一度に集中した、完全な日本語でのコース基本情報確認として整理する必要があります。たとえ情報がセッションや添付ファイルから推測できたとしても、表示し、ユーザーに一度確認を求める必要があります。確認が完了したら INTAKE_CONFIRMED 状態に移行し、直接資料検索、コースレベルのアウトライン、Content 2.2、QA、および DOCX の作成を開始します。

ユーザーインターフェースは日本語のラベルのみを使用し、内部フィールド名を質問内容として使用しないでください。一度の確認に必ず含めるコース基本情報は次のとおりです：コース名、専門分野、受講対象、総授業時間数。確認サマリーには、以下の非ブロッキング情報も含める必要があります：理論授業時間数、実践授業時間数、理論と実践の編成方法、1回の授業時間デフォルト2コマ、使用教科書、補助参考資料、実践タスク作業指示書を同時に生成するかどうか。

4つのコアフィールドのいずれかに情報が不足している場合、同じ確認サマリーに「未補充」と表示します。総授業時間数は、ユーザーが明示的に提供した事実のみを受け入れます。専門分野や受講対象がエージェントの推測に過ぎない場合は、「現在の理解 / 不正確な場合は修正してください」と注釈を付ける必要があります。理論/実践の分割、編成方法、または実践タスク作業指示書の優先順位が明示的に提供されていない場合は、「確認待ち」と表示し、50/50、統合型、または「いいえ」で自動補完してはいけません。default_hours=2 は、2コマで約何回の授業があるかを推定するためにのみ使用し、理論/実践の比率を推測するために使用してはいけません。内部フィールドマッピングと状態ルールについては docs/intake-contract-v2.1.1.json を参照してください。ユーザーインターフェースには「補助参考資料」と表示し、内部状態は引き続き auxiliary_references を使用し、この英語のキーをユーザーへの質問として表示してはいけません。

最初の応答は次のようにします：

まず、コース基本情報を確認します：
- コース名：『データ構造 上級』
- 専門分野：現在の理解 / 不正確な場合は修正してください
- 受講対象：現在の理解 / 不正確な場合は修正してください
- 総授業時間数：40 コマ
- 理論授業時間数：確認待ち
- 実践授業時間数：確認待ち
- 理論と実践の編成方法：確認待ち（オプション：すべて理論 / すべて実践 / 分割編成 / 統合編成）
- 1回の授業時間：デフォルト 2 コマ
- 使用教科書：未指定（指定教科書があればお知らせください。なくても続行可能です）
- 補助参考資料：未指定
- 同時に実践タスク作業指示書を生成しますか：確認待ち
上記の情報は正しいですか？調整が必要な場合は、一度にお知らせください。

教科書は推奨事項であり、必須ではありません。提供されたファイルや書名は直接表示し、提供されていなくても生成をブロックしません。practice_work_orders が提供されていない場合は、確認待ちのままにします。ユーザーが明示的に選択した場合にのみ、WorkOrder Skill を連携するかどうかを決定します。明示的に false を選択した場合でも、実践時間数はコースの総授業時間数に含まれますが、Practice Task Contract、handoff、WorkOrder、または実践側の追加ファイルは生成しません。明示的に true を選択した場合、Lesson Agent は Lesson QA/DOCX と Practice Task Contract handoff の完了後、利用可能な WorkOrder Skill を検出して呼び出します。WorkOrder Agent が完全な Content V1 を作成し、QA を実行し、作業指示書を生成し、最後に統一的に納品します。利用できない場合は、Lesson と handoff のみを納品し、「実践タスク作業指示書生成器は現在利用できません。実践タスクデータファイルは保存されました。作業指示書生成器が利用可能になった後に続けて生成できます。」と明確に表示し、作業指示書 DOCX を偽造してはいけません。

Intake が確認されるまでは、プロジェクトの数や名前、理論/実践の授業回数構造、実践タスク数、授業ごとの教育内容を決定したり、DOCX を生成したりしてはいけません。ただし、ユーザーがすでに対応する事実を明示的に提供している場合は除きます。一度確認した後は、アウトライン、プロジェクト名、授業ごとのタスク、評価、テンプレート、出力ディレクトリ、または「DOCX の生成を開始しますか？」について再度質問してはいけません。デフォルトのテンプレートとデフォルトの出力ルールを直接採用します。ユーザーが自ら要件を変更した場合、確認情報に合理的に解決できない直接的な競合が発生した場合、またはセキュリティやファイル上書きなど、真にユーザーの決定が必要な事項が発生した場合にのみ、再度停止することが許可されます。

ユーザーが「すべて理論」を明示的に選択した場合、theory_hours=total_hours、practice_hours=0、delivery_mode=theory_only に正規化し、実践タスク作業指示書を false に設定します。「すべて実践」を明示的に選択した場合、theory_hours=0、practice_hours=total_hours、delivery_mode=practice_only に正規化します。その他の分割は theory_hours + practice_hours = total_hours を満たす必要があります。等しくない場合は、まず競合を報告し、アウトラインを開始してはいけません。

資料検索は、ユーザーが提供した教科書/コース資料とユーザー指定の教科書を優先的に使用します。ネットワーク接続が可能な場合は、出版社や学校の公式ページ、標準/ガイドライン、公式技術文書、検証可能な公開文献も検索します。書名のみが提供された場合、実際に検証された著者、出版社、ISBN、版、年のみを記入できます。ネットワークが利用できない場合は、通常通り続行し、ネットワークに接続できないために生成を中断してはいけません。

• ユーザーが合理的な推論を許可した場合、プロジェクトベースの教育に従って、プロジェクト、タスク、教育内容、評価、事前生成された振り返りを補完します。
• 正式な DOCX には、「資料不足、推論、AI、QA、similarity、confidence」などの内部説明を記載してはいけません。

タスク資料がない場合でも、まずコースレベルのアウトラインを作成し、その後、授業ごとのコンテンツを生成する必要があります。アウトラインには少なくとも lesson_id、unit、task、lesson_type、hours、theory_hours、practice_hours、prior_learning、capability_stage、deliverable、next_bridge、および practice_task_ids が含まれている必要があります。長いコースの場合は、内部的に4～6授業ずつバッチで生成できますが、最終的には完全なコースコンテキストを使用して統一されたQAを実行する必要があります。

Content Contract V2.2

デフォルトでは assets/templates/lesson-plan/v1.1.2/template.docx を使用します。

正式な生成入力のデフォルトは content_contract_version: "2.2" であり、Word テンプレートのバージョンとは独立しています。実行時には "2.1" と "2.0" の読み込みも互換性を持ってサポートします。デフォルトの Word テンプレートは lesson-plan v1.1.2 であり、v1.0 legacy-coordinate、v1.1.0/v1.1.1 semantic-bookmark、および古い互換性テンプレートパスも引き続きサポートします。古い sparse JSON は生成されなくなりました。

コースレベルの必須フィールド：

content_contract_version, course_name, major, audience,
default_hours, total_hours, delivery_plan, course_materials,
reference_pool, artifact_plan, outline, lessons

2.2 の各理論授業では、以下を直接提供する必要があります：

lesson_id, unit, task, lesson_type, hours, theory_hours, practice_hours,
progression, reference_ids, practice_task_ids,
student_analysis, teaching_content, goals,
key_point, difficult_point, teaching_methods, resources,
implementation, evaluation, reflection

2.0 の入力は引き続き授業内の references オブジェクトを読み取ります。2.1 の互換入力は、元の授業セマンティクスを保持します。2.2 では、コースレベルの reference_pool の reference_ids を介してのみソースを選択し、各理論 Lesson は少なくとも1つの reference を持つ必要があります。2.2 の Lesson DOCX は理論のみを保持します：sum(lesson.hours) == theory_hours、すべての Lesson は lesson_type=theory、practice_hours=0 です。実践は Lesson DOCX には入りません。artifact_plan.practice_work_orders=true の場合にのみ、実践は Practice Task Contract / WorkOrder handoff に入ります。false の場合、contract やタスク ID を保持してはいけません。practice_task_ids はスキーマで要求される空の配列のみを保持します。practice_task_ids は理論授業に関連付けられた実践タスクを示し、実践 Lesson DOCX を生成することを意味しません。delivery_plan は theory_only、practice_only、split_lessons、integrated_lessons、hybrid をサポートし、theory_hours + practice_hours == total_hours である必要があります。integrated はアーティファクトレベルの理論実践一体型編成を説明するものであり、実践時間数を Lesson DOCX に詰め込んだり、1+1 を固定したりするものではありません。

default_hours は、エージェントが1授業あたりを作成する際に使用するデフォルトの授業時間数です。特定の授業で明示的に hours が提供された場合はそれを上書きできます。default_hours はすべての lessons.hours と等しい必要はありません。default_hours、total_hours、および各授業の hours はすべて正の整数の授業時間数である必要があります。値は 1、2、4、12 などの整数、文字列は "1"、"2"、"2.0" が可能です。空白の文字列、分数、ゼロ、負の数、NaN、または Infinity は受け入れられません。unit はプロジェクト名（例：「プロジェクト一……」）を使用します。progression には prior_lesson_id、具体的な prior_learning、capability_stage、deliverable、next_bridge が含まれます。capability_stage は 認知、理解、模倣、独立、総合、最適化、移行 のみを使用でき、機械的な線形増加は要求しません。最初の授業の prior_lesson_id は null である必要があり、後続の授業はすでに出現した前の授業のみを参照できます。4授業以上の場合、すべての能力段階が同一であってはいけません。

student_analysis の base/problems/strategies と3種類の goals はそれぞれ少なくとも2項目必要です。teaching_content は少なくとも3項目必要です。重要なポイントと難しいポイントにはそれぞれ content と strategy が必要です。methods は少なくとも2項目、resources は少なくとも2項目必要です。2.2 の理論 Lesson の reference_ids は空であってはいけません。空の reference は直接失敗します。純粋な実践コースには Lesson DOCX がない場合があります。実践作業指示書を生成することが明示的に選択された場合にのみ、Practice Task handoff を使用して実践時間数を表現する必要があります。生成しないことが明示されている場合は、handoff を作成してはいけません。また、理論授業を架空に作成してはいけません。

各授業の implementation は、以下の9つのIDを固定順序で完全に提供し、各段階の label、minutes、modality、content、teacher_actions、student_actions、objective はすべて JSON から取得する必要があります：

before_class_preparation
task_introduction
operation_demonstration
task_implementation
task_extension
project_practice
peer_review
lesson_summary
after_class_improvement

授業前準備と授業後改善は課外段階です。中間の7つの段階の分数は、厳密に hours * 45 と等しくなければなりません。各課外段階は0分を許可しますが、max(60, hours * 45) を超えてはいけません。2つの課外段階の合計は 2 * hours * 45 を超えてはいけません。エラーは lesson ID、stage、actual、limit を示す必要があります。operation_demonstration はセマンティックな行位置であり、看護、会計、機械などのコースでは、方法のデモンストレーション、ケース分析、またはスキルデモンストレーションとして表示されます。

評価は明示的に 85～96 の evaluation.score を提供し、0.5刻みを使用し、13の標準 criterion ID に対する授業ごとの remarks を提供する必要があります。各 remark には実質的な内容が必要です。すべての Content V2 テンプレートバージョンは、最大 48 意味文字の契約上限を一貫して適用します。マニフェストはさらに厳しくすることのみ可能で、上限を超えた場合は切り捨てずに失敗する必要があります。スコアが指定されていない場合は、自然に 88～94 に集中することをお勧めしますが、すべてが 90 であってはいけません。任意の短周期での循環、厳密な増加または減少であってはいけません。score_breakdown() は、明示的な合計スコアを決定論的に既存のテーブル行に分割する責任のみを負います。Python は備考を作成せず、3セットの固定 remarks の循環や機械的なスコアのフォールバックを使用しません。振り返りは明示的に summary、innovation、improvement を提供し、授業前の事前生成を許可しますが、本授業のタスク、重点・難点、編成、期待されるパフォーマンス、問題、および次回の授業との連携を中心に差異を生み出す必要があります。

2.2 の course_materials.textbook は個別に教科書を表し、オブジェクトまたは null が可能です。デフォルトでは Word の references セルに自動的に書き込まれません。エージェントは授業ごとの生成前に、まず course_reference_pool / reference_catalog planning concept を作成します。ディスクに書き込まれるフィールドは引き続き reference_pool であり、新しい JSON コントラクトフィールドではありません。各項目には reference_id、reference_type、識別可能な具体的なタイトル、source_kind、source_region（domestic/foreign/unknown）、および対応する evidence が必要です。授業ごとには reference_ids のみを書き込みます。allow_textbook_as_reference はデフォルトで false であり、明示的に true にされた場合のみ、教科書が references に入ることが許可されます。references は、読む、参照する、引用する、またはコースの根拠として使用できる文献/文書ソースのみを表し、モノグラフ、コース/教育基準、国家/業界/職業基準、ガイドライン/規範、論文、公開文献、公式技術文書、公式製品マニュアル、ユーザー提供の正式な教育文書が含まれます。resources は、教育の実施に使用されるツール、機器、環境、および材料（例：MySQL Workbench、データベースサーバー、PPT、プロジェクター、看護モデル、仮想マシン、実習タスクシート、ケースデータセット）を表します。これらは数を合わせるために references に書き込んではいけません。各授業は通常 1～3 項目の reference を選択し、コースレベルの有効な reference は再利用可能です。

source_kind は引き続き provided、generic、verified_public を保持します。provided はユーザーの実際の資料 evidence が必要です。verified_public は URL または特定可能な公式ソースが必要です。generic は具体的な文書セマンティクスのみを使用でき、詳細な書誌情報を偽造してはいけません。「統一モデリング言語関連公開文書」「関連ネットワークリソース」「関連公開文献」などの汎用的なプレースホルダーテキストは禁止であり、著者、ISBN、出版社、版、年、または標準番号の推測も禁止です。国内ソースを優先します：ユーザー提供資料、国内出版物/モノグラフ、国内高等教育機関の資料、国家/業界/職業基準、および国内権威文書は外国の古典よりも優先されます。国内比率が70%未満の場合は品質警告ですが、ハードフェイルではありません。ただし、国際標準/古典が実際に存在する場合、または国内ソースが不十分な場合は、外国ソースを補完できます。reference の授業間での完全な重複は許可され、reference_reusable に属し、exact/item/sentence/field/structural/frequency/whole-course の重複排除ハードフェイルから明示的に除外されます。同じ授業内での重複 ID または重複内容は、依然としてハードフェイルです。references の重複は、教案本文の重複問題には該当しません。コース重複率を下げるために、異なる教科書、著者、ISBN、出版社、標準番号、または公開文献をでっち上げることは禁止です。同じ教科書を18回繰り返す方が、18冊の教科書をでっち上げるより優れています。evidence は入力と QA にのみ使用され、DOCX には正式な引用テキストのみが書き込まれ、evidence メタデータは書き込まれません。

Practice Task Contract V1

artifact_plan.practice_work_orders=true の場合のみ、2.2 の入力は practice_task_contract を提供する必要があり、バージョンは 1.0、granularity: "per_task" です。実践時間数は正の偶数である必要があります。タスクフィールドは次のとおりです：task_id、project_id、title、lesson_ids、practice_hours、scenario、objectives、required_inputs、tools_or_materials、steps、deliverables、acceptance_criteria、safety_or_compliance。各 Practice Task は固定で 2 コマであり、タスク数は厳密に practice_hours / 2 と等しくなければなりません。各タスクは1つの WorkOrder に対応し、project_id はグループ化にのみ使用され、粒度を再計画してはいけません。lesson_ids は理論的な準備/前提知識を提供する理論 Lesson ID であり、複数の授業にまたがることができます。理論 Lesson がない純粋な実践コースの場合は空の配列です。practice_work_orders=false の場合、contract または handoff は許可されず、すべての practice_task_ids は空の配列のままである必要があります。true の場合、Lesson は canonical handoff の生成と QA のみを担当し、検出された WorkOrder Skill が Agent orchestration を介して handoff を消費します。Lesson Python ジェネレータは WorkOrder Python を subprocess 呼び出ししてはいけませんし、handoff を作業指示書本文に自動マッピングしてはいけません。WorkOrder Skill が利用できない場合は、practice-task-contract.json handoff のみを出力し、利用不可状態を明確にし、実践作業指示書 DOCX を偽造してはいけません。

現在の 2.2 の完全なルールは docs/content-contract-v2.md にあります。examples/tasks-v21.example.json は 2.1 互換の例として保持され、examples/tasks.example.json は 2.0 互換の例として保持されます。フィールドの説明は docs/content-contract-v2.md と docs/practice-task-contract-v1.md にあり、機械的な制約は schemas/lesson-plan-input.schema.json とリポジトリの canonical schemas/shared/practice-task-contract.schema.json にあります。schemas/practice-task-contract.schema.json は互換性のためのエントリポイントにすぎません。

Python と Agent の境界

Agent はコースレベルの計画とすべての授業ごとの教育本文を担当します。ジェネレータは、スキーマ検証、番号付け、改行、分フォーマット、フィールドマッピング、テンプレート書き込みのみを行います。V2 の正式なパスでは、古い generated_lesson_fields、implementation_cell_values、reflection_cell_values を呼び出してはいけません。flows[:3] を使用したり、欠落フィールドに基づいて本文を作成したりしてはいけません。コンテンツがマニフェストの max_chars または max_paragraphs を超えた場合、失敗して lesson、field、actual chars、limit を示す必要があります。切り捨てたり、黙って削減したりしてはいけません。

生成と QA の順序

資料を読み込む → 一度のコース基本情報確認
  -> コースアウトライン
  -> Content V2.2 JSON
  -> Input Contract QA
  -> Content Quality QA
  -> Template QA
  -> candidate DOCX generation
  -> Output Structure + Content-to-DOCX Fidelity QA
  -> optional LibreOffice render smoke
  -> atomic commit to final output and external QA report
  -> when practice_work_orders=true, detect and call WorkOrder Skill Agent, then unify Lesson + WorkOrder delivery
  -> Agent representative-page visual inspection

scripts/generate_lesson_plans.py を使用して生成します。すべての DOCX は、正式なディレクトリと同じ親ディレクトリ内の candidate に最初に書き込まれます。Content QA、テンプレート QA、出力構造/ブックマーク/フォーマット保護、コンテンツ忠実度 QA、および要求された render smoke がすべて合格した後、正式なディレクトリに交換されます。明示的な --qa-report により、外部レポートは同じ親ディレクトリ内でステージングされ、出力ディレクトリとともにコミットされます。いずれかの交換が失敗した場合、古い出力と古いレポートが復元されます。空でない正式なディレクトリには --backup-existing が必要です。交換が失敗した場合、古いディレクトリを復元する必要があります。コミットが成功した後、stdout は正式なディレクトリに実際に存在する DOCX パスのみを報告します。コース基本情報確認後、DOCX 生成のための確認を追加してはいけません。Agent の代表ページの視覚検査は、コミット後の検収に属します。オーバーフロー、切り捨て、異常な改ページ、または空白ページが見つかった場合は、V2 コンテンツを書き換え、--backup-existing を使用してトランザクション生成を再実行する必要があります。qa-report.json はレポートのみを書き込み、DOCX には書き込みません。

独立した scripts/content_quality.py は、ローカルで決定論的に実行する必要があり、オンライン API、埋め込み、またはモデルサービスを呼び出してはいけません。既存の本文重複、エンティティマスク後の構造的類似性、重複する長い文、古い決まり文句、完全性、授業内一貫性、進行の一貫性、スコアパターン、13の評価備考密度、および非IT汚染をチェックします。今回のラウンドでは、2.2 の reference 必須、ソース地域統計、理論/実践 handoff チェックのみが追加され、既存の repetition、progression、スコアリング、または implementation coherence アルゴリズムは変更されません。non_it_contamination とそのスコープメタデータは、「入力にはないがテンプレートやジェネレータが出力に注入した」IT デフォルト語のみを検出し、汎用的なコース分類器ではありません。診断は、限られた断片と安定した SHA-256 のみを保持し、ユーザー本文の段落全体を出力しません。すべての検出器は、共通の再利用ポリシーを共有します：narrative_strict、terminology_reusable、resource_reusable、reference_reusable、fixed_rubric_reusable、および ignore。教授法、必要なリソース、正当な reference、および attendance/compliance/habits の固定ルーブリックは、再利用の証拠を記録できますが、ハードフェイルにはなりません。reference は授業間での完全な重複が許可され、exact/item/sentence/field/structural/frequency/whole-course の重複排除ハードフェイルから明示的に除外されます。同じ授業内での exact duplicate と明らかな純粋なツール/機器 reference はハードフェイルする必要があります。ショートコースの用語免除は narrative field に入ってはいけません。コース重複率を下げるために参考文献を偽造してはいけません。

progression の artifact inheritance と forward transition は、両方とも語面/一貫性の証拠と substantive_anchor の証拠を同時に通過する必要があります。「設計、操作、分析、検査、プロセス、実施」などの一般的なアクションは、単独で anchor として機能してはいけません。隣接していない prior_lesson_id は引き続き許可されます。物理的な順序チェーンが review の場合、レポートは requires_agent_review=true を設定し、from/to/reason/score/declared_prior をリストする必要があります。Agent の最終検収は、physical sequence review を黙って無視してはいけません。実際の授業順序を説明できない場合は、progression を書き換える必要があります。

決定論的 QA が合格し、アトミックコミットが完了した後、Agent は授業ごとに内部レビューを実行する必要があります：この授業は前の授業と比べて何が新しく追加されたか、前の授業のどの知識や成果を使用したか、何を生み出したか、次の授業でこの成果をどのように使用するか。このレビューは DOCX に書き込まれません。--render が要求された場合、Python レポートは render.scope=smoke のみを示し、ページ数方式は軽量な pdf_page_object_regex です。これは視覚的な QA や改ページ検証と同等ではなく、オーバーフロー、切り捨て、異常な改ページ、またはテーブル変形がないことを証明するものでもありません。Agent は最初の授業、本文が最も密集している授業、最後の授業をチェックし、コースが 12 コマに達した場合は 1～2 の中間授業をチェックし、クリッピング、オーバーフロー、オーバーラップ、空白ページ、異常な行の高さ、およびテーブル境界に注意する必要があります。実際のチェック後、scripts/record_visual_inspection.py を使用して独立した visual-inspection.json に明示的に書き込みます。このファイルは、代表ページ、チェック、メモ、関連 qa-report、出力フィンガープリント、およびタイムスタンプを記録します。Python は自動的に視覚合格を主張しません。視覚的に不合格の場合は、V2 JSON を修正し、--backup-existing を使用してトランザクション生成を再実行し、再チェックする必要があります。

デフォルトの出力 QA は、元の V2 JSON を読み取り、純粋なフォーマッタを介して期待値を計算し、セマンティックブックマークまたは v1.0 座標と比較します。教育内容作成関数を再呼び出ししません。テンプレートレイアウト、70 のセマンティックブックマーク、ブックマーク ID/名前、フィンガープリント、v1.0/v1.1 互換性、および canonical バイナリは保護されます。ローカルマシンに LibreOffice が存在する場合、--render を使用して render smoke を実行します。レンダラーがない場合、構造的 QA は引き続き合格し、レポートは render.status=not_executed とマークします。実際の改ページ、オーバーフロー、および視覚的レイアウトの結論は、Agent の代表ページチェックからのみ得られます。

アダプターのインストールセマンティクスは次のように固定されています：デフォルトは instruction-only adapter install（ルール/指示のみのインストール） であり、プロジェクトルールと最小限の指示のみをインストールし、完全なランタイムをコピーせず、ターゲットプロジェクトがジェネレーターを独立して実行できることを約束しません。--copy-engine が追加された場合のみ、full runnable project-local Lesson engine（完全実行可能なエンジン） となります。ターゲットプロジェクトが .lesson-plan-docx-generator/scripts/generate_lesson_plans.py を直接呼び出す必要がある場合は、--copy-engine を使用する必要があります。visual-inspection.json は Agent visual inspection attestation for the current generated DOCX/QA state であり、現在の生成された DOCX/QA 状態に対する Agent の代表ページチェックを表し、チェックされた PDF/画像の暗号化された証明ではありません。

パスプレフライトは、mkdir、生成、移動、バックアップ、削除の前に実行され、Skill ルート、入力 JSON、スキーマ、選択/カスタムテンプレート、マニフェスト、canonical/compatibility パッケージ、スクリプト、およびテストを保護し、祖先、子孫、解決されたシンボリックリンク、および Windows lexical/8.3 エイリアスの重複を拒否します。出力を保護されたディレクトリやカスタムテンプレートパッケージに書き込まないでください。

コマンド

Windows：

python scripts/generate_lesson_plans.py `
  --tasks-json tasks.json `
  --output-dir output `
  --render

macOS：

python3 scripts/generate_lesson_plans.py \
  --tasks-json tasks.json \
  --output-dir output \
  --render

出力の個別検証：

scripts/validate_template.py --json
scripts/validate_output.py --input-json tasks.json --output-dir output --render
scripts/validate_visual_inspection.py --output-dir output --qa-report output/qa-report.json --evidence output/visual-inspection.json

手動インストールと依存関係チェック（インストーラーは自動的に Python 環境を変更しません）：

python scripts/install.py --skills-dir <skills-dir>
python <skills-dir>\lesson-plan-docx-generator\scripts\check_dependencies.py

check_dependencies.py は読み取り専用で docx、yaml、jsonschema をチェックします。不足している場合は pip install -r requirements.txt を促します。Agent の本番フローでは、--skip-template-validation または --skip-output-validation の使用は禁止されています。これらの互換性パラメータは、LESSON_ALLOW_UNSAFE_VALIDATION_SKIP=1 が明示的に設定されている場合にのみ、制御されたテストで使用でき、レポートで明確に skipped としてマークする必要があります。入力契約、コンテンツ品質、およびパス保護はスキップできません。一時的な JSON、PDF、画像、および candidate ディレクトリは、タスク終了後にクリーンアップされ、生成された DOCX はコミットされません。

テンプレートファイル

assets/templates/lesson-plan/v1.1.2/template.docx
assets/templates/lesson-plan/v1.1.2/manifest.yaml
assets/templates/lesson-plan/v1.1.1/template.docx
assets/templates/lesson-plan/v1.1.1/manifest.yaml
assets/templates/lesson-plan/v1.0.0/template.docx
assets/templates/lesson-plan/v1.0.0/manifest.yaml
schemas/lesson-plan-input.schema.json
scripts/content_contract.py
scripts/content_quality.py
scripts/generate_lesson_plans.py
scrip

…

[翻訳のため省略]