k2f-contract

K2F Contract — AI ネイティブな美的デザイン

目的

レイアウトに着手する前に、契約書の設計図を作成するようエージェントに教えます。契約の枠組み、当事者の役割、一貫性のある条項構成、参照や署名のための正式な階層を定めます。ユーザーが提示していない当事者、金額、準拠法、立場を捏造しないようにします。

K2F を基盤とする仕組み

このスキルは、契約書を .K2F パッケージとして作成します。作成時は k2f スキルに従ってください。ワークスペースを展開または初期化し、セマンティックツリーを編集して、パッケージ化と検証を実行した後にエクスポートします。K2F によって、エージェントはピクセル座標ではなく意味（条項、定義語、別紙、署名欄）に集中できます。レイアウト、タイポグラフィ、テーマはエンジンがコンパイルし、エクスポートに適した一貫性のある出力を生成します。

作成を始める前に、コアスキルをインストールしてください：npx skills add suzheng/k2f --skill k2f。

使用する場面

• 取引メモやプレイブックをもとに、新しい NDA、MSA、SOW、SaaS 注文書、ベンダー契約、または修正契約を作成するとき。
• 雑然としたドラフトテキストを、別紙や定義語を含む署名可能な構成に整えるとき。
• 承認済みの取引条件を、相手方への送付に適した洗練された契約書に仕上げるとき（弁護士によるレビューは引き続き必要です）。

ワークフロー

Step 1. content_and_design.md を生成する

セマンティックな内容と美的意図をまとめる単一の設計図です。k2f スキルが後で条項やページに対応付けられるよう、ラベル付きのブロックを使用します。

サブステップ

1. 契約の枠組み — 種別（NDA、MSA、SOW、ライセンス、SaaS、調達など）、発効日のロジック、およびどちらの当事者の立場でドラフトを作成するか（サプライヤー、顧客、ライセンサー、ライセンシー）を定めます。準拠法域と通貨は、ユーザーが提示した場合に限り記載します。その種別に不要な条項群は丸ごと省きます（例：相互 NDA では支払いスケジュールを省略します）。

2. 当事者と前文 — 正式名称、法人の種類、住所、定義する略称を記載します。前文には、ユーザーの入力に基づく背景事実のみを記載し、取引規模や戦略的な説明を捏造しないでください。署名権限や法人情報が不足している場合は、NEEDS USER CONFIRMATION として明示します。

3. 定義語のブロック — 条項全体で使用する大文字表記の用語（サービス、成果物、秘密情報、料金）を一元管理します。用語ごとに定義は1つとし、本文に重複した用語集を設けないでください。

4. 条項の構成（含める／削る／順序） — 条項の文章を作成する前に、条項を計画します。標準構成を契約の枠組みに応じて調整します。

   • 業務範囲／サービス → 料金と支払い → 契約期間と解除 → 知的財産 → 秘密保持 → データ保護（または DPA 別紙への参照） → 保証 → 責任制限 → 補償 → 保険 → 一般条項（譲渡、通知、不可抗力、完全合意、変更、複数通の作成）。
   • 重複する義務やマーケティング文言は削除します。
   • 相互参照：責任上限と補償、存続条項と解除の間に矛盾がないようにします。

5. 取引条件とリスク配分（ユーザー提供情報に基づく） — 支払い、上限、補償、知的財産、解除、データに関する条件は、原文のまま、または TBD とします。プレイブックの条項には、必須、交渉可能、またはプレースホルダーのラベルを付けます。必須条項を緩和しないでください。

6. 別紙とスケジュール — 長い表（SOW のマイルストーン、SLA、DPA、価格設定）は、安定したラベル（別紙 A、スケジュール 1）を付けて別紙に移します。本文ではラベルで別紙を参照し、参照されない別紙や添付資料のみで定義される用語を避けてください。

7. 署名欄 — 各当事者の署名欄、氏名、役職、日付を記載します。証人や公証人は、ユーザーから求められた場合に限り含めます。当事者の順序は前文と一致させます。

8. 設計意図 — エンジン向けの正式な文書のトーンと階層：

   • トーン：正確で中立的かつ機関向けの文体とし、条項本文では販売促進的な表現を使用しません。
   • 階層：表紙および冒頭ページでは契約書のタイトルと当事者欄を最も目立たせます。条番号（1、1.1、1.1(a)）を主要なスキャン時の目印とし、定義語のセクションは視覚的に区別します。別紙と署名欄は文書の末尾であることが明確に分かるようにします。
   • 密度：法律文書として適度な密度にします。段落は短くし、義務には番号付きリストを用います。条項を長文の壁にしないでください。料金と納品物の表は別紙にのみ使用します。
   • 配色：落ち着いたニュートラルカラーを基調とし、アクセントは最小限にします（署名欄・日付欄）。本文は高コントラストにし、WCAG AA に準拠します。条番号と競合する装飾的なグラフィックは使用しません。

ルールと制約

• 弁護士確認のゲート：この設計図は法的助言ではないことを明記します。拘束力のある文言には、資格を有する弁護士による確認が必要です。
• 当事者側のゲート：義務と保護は、文書で起草当事者として定められた側に有利になるようにします。当事者側が不明な場合は作業を中断して確認します。反対側の立場で起草すると、リスクが逆転します。
• 記載のない事項に関するゲート：責任上限、変更注文、データ処理など、重要な項目が欠けている場合は、市場標準の条件を作り出さず、その旨を指摘します。
• 整合性のゲート：定義語、別紙への参照、当事者名がすべての箇所で一致するようにします。ユーザーが分割構成を確認した場合を除き、通貨と準拠法の条項はそれぞれ一つにします。
• 誠実性のゲート：登録番号、保険限度額、料金額、法令の引用を決して捏造しません。

よくある失敗例

• 取引に関するメールを、構成のない段落として貼り付ける → 番号付き条項と別紙に再構成します。
• 定義が本文のあちこちに散在する → 定義語をまとめ、表記の揺れを修正します。
• 別の箇所に「上限」があるのに、責任と補償が無制限に読める → レイアウトに進む前に、設計図の注記で整合させます。
• SOW の業務範囲が、納品物、検収、変更手続きなしの文章で記載されている → 別紙に表を追加するか、不足項目として明示します。
• 当事者や発効日が記載されていない一般的な「契約書」 → ユーザーから情報を得るか、不足として明示します。
• 契約書の表紙が過度にデザインされている → 装飾性はタイトル欄だけに留め、条項は簡潔で控えめにします。

品質チェックリスト

• 契約の種類、起草する側、省略された条項が明示されています。
• 当事者と定義語が揃っており、別紙の記載とも整合しています。
• 重要な各項目が記載されているか、意図的に省略されているか、または未確定として示されており、黙示的に仮定されていません。
• 条項間の相互作用（上限、補償、存続、終了）に矛盾なく触れています。
• 本文で参照されている別紙が存在し、署名欄の当事者数が一致しています。
• 設計意図で、条番号、定義語、別紙、署名欄の強調方法が明示されています。
• 弁護士による確認の注意書きが含まれており、法的事実や商取引上の事実が捏造されていません。

ステップ 2. content_and_design.md と k2f スキルを使用して K2F ファイルを生成し、適切なファイル形式でエクスポートします。

k2f スキルに従って、設計図から契約書を生成し、設計意図に基づいて条項と別紙の役割を適用して、検証を行い、署名可能な成果物をエクスポートします。