k2f-purchase-order

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

目的

レイアウトに着手する前に、エージェントが発注書の設計図を作成できるようにします。買い手とベンダーの識別情報、出荷先と請求先の振り分け、照合済みの明細コミットメント、そして何を、どこへ、いつまでに、どの条件で注文するのかを明確に示す視覚的な階層を整えます。ユーザーが提示していない SKU、価格、承認情報を創作することはありません。

K2F を基盤として構築

このスキルは、.K2F パッケージとして発注書を作成します。作成時はk2fスキルに従ってください。ワークスペースを展開または初期化し、セマンティックツリーを編集して、パックと検証を実行してからエクスポートします。K2F により、エージェントはピクセル座標ではなく、意味（関係者、明細の役割、合計、納品ブロック）に集中できます。エンジンがレイアウト、タイポグラフィ、テーマをコンパイルすることで、PDF やその他の形式でも一貫した出力が得られます。

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

使用する場面

• 承認済みの見積もり、購買依頼、カタログのカート、または貼り付けられた明細から発注書を発行する場合。
• 参照情報、数量、合計を調達担当者が送付する内容と一致させるため、曖昧または汎用的な AI 発注書を作り直す場合。
• ユーザーが定義した範囲のみを文書に記載する、標準的な物品の発注書、サービスの発注書、包括発注書／分納発注書を作成する場合。

ワークフロー

Step 1. content_and_design.md を生成する

セマンティックな内容と美的意図をまとめる単一の設計図です。後でk2fスキルが各領域に割り当てられるよう、ラベル付きブロックを使用します。

サブステップ

1. 発注書の種類とコミットメントの枠組み — 標準的な物品、サービス、包括発注書／分納発注書、または既存の発注書に対する変更注文のいずれかを指定します。通貨、ロケールに応じた表記、価格が確定価格か見積もりのみかを記載します。その種類で不要なセクションは省略します（たとえば、ユーザーがデジタル納品のみと指定した場合、サービスのみの発注書では出荷先を省略します）。

2. 関係者と振り分けブロック — 買い手（発行する事業体）：正式名称、住所、連絡先、ロゴの意図。ベンダー：サプライヤー名と住所（ユーザーが提示したものに限る）。買い手の本社と異なる場合は、出荷先と請求先を記載します。担当者宛てや荷受け場に関する注記は、原文どおりに記載します。ベンダーの納税者番号、DUNS 番号、買い手側の承認者名を決して捏造しないでください。

3. 参照メタデータ — 発注書番号、発行日、希望納期または予定納期（ユーザーが提示している場合は、ヘッダーおよび／または明細ごとに記載）。変更注文の場合は、関連する見積もり、RFQ、購買依頼、契約、または以前の発注書を記載します。文書全体で通貨は一つに統一し、レイアウト作成前に納期の不足を明示します。

4. 明細の構成 — 説明文の段落ではなく、表を優先します。各行には、行番号、説明、任意の部品番号／SKU／モデル、数量、単位、単価、行合計を記載します。ユーザーのデータですでに分かれている場合に限り、セクション（ハードウェアと設置など）をグループ化します。変更注文の明細では、差し替えまたは追加の対象を参照します。無関係な SKU を曖昧な一行にまとめないでください。

5. 合計の内訳（計算内容を文書に記載） — 小計 → 運賃／取扱料、税金または手数料それぞれに率を明記 → 発注書合計。端数処理の方法（明細ごとか文書全体か）を記載します。見積もりと購買依頼の合計が一致しない場合は、どちらかを黙って選ぶのではなく、NEEDS USER CONFIRMATION と記載します。

6. 条件と履行に関するフッター — 支払条件、インコタームズ、または配送方法はユーザーが提示したとおりに記載します。特別な指示（分納の可否、梱包、請求規則、送金先）も記載します。承認者または署名欄は、ユーザーが役職または氏名を指定した場合に限り含めます。ユーザーが文面を提示していない限り、法的な定型文は最小限にします。

7. デザインの意図 — エンジン向けのトーン、階層、情報密度、配色を指定します。

   • トーン：権威ある、業務向けの B2B。営業的な表現は一切使いません。これは供給を求める拘束力のある依頼です。
   • 階層：ヘッダーでは「Purchase Order」、発注書番号、ベンダー名を見つけやすくします。明細表を主役にし、二次的な領域では出荷先と発注書合計を目立たせ、条件をフッターに控えめに配置します。
   • 情報密度：倉庫での利用に適した表のリズムにします。列順（#、品目、数量、単価、行合計）を固定し、金額は右揃え、数字は等幅にします。メインビューの注記ブロックは簡潔なものを最大一つにします。
   • 配色：彩度を抑えたニュートラルカラーを基調に、発注書番号と合計にはアクセントカラーを一色使用します。WCAG AA に準拠し、振り分け先の住所と明細データを明確に区別します。 ルールと制約

• 発行ゲート：PO番号、発行日、通貨、照合済み合計、ベンダーの識別情報、物理的な商品の場合は配送先／請求先の指定がない限り、送付可能なブループリントを作成しないでください。
• 唯一の信頼できる情報源：明細の小計を基準に小計を算出し、手数料と税金は文書に記載された基準額にのみ適用してください。
• 参照情報の管理：見積もり／依頼／契約のIDはメタデータに記載し、必要に応じて明細ごとに記載します。本文で重複させないでください。
• 誠実性ゲート：税金、送料、承認の情報が不足している場合は明記してください。ユーザーの入力なしにカタログ価格や承認を推測してはなりません。

よくある失敗

• 段落で「ノートパソコンが50台必要です」と記載 → 数量、単位、価格を含む番号付きの行に書き換えます。
• 配送先がない、または購入者と配送先が混同されている → 住所を明確に分けます。
• 明細の説明に見積もりの宣伝文句が含まれている → SKU、仕様、数量などの納品情報に置き換えます。
• PO合計や納期が埋もれている → メタデータとデザイン意図で目立たせます。
• 部品番号、支払条件、承認者を捏造している → 削除し、TBD — user must supplyを使用します。
• 通貨の混在や明細番号の重複 → 番号を振り直すか、エスカレーションします。

品質チェックリスト

• 購入者、ベンダー、出荷先／請求先住所が、ユーザーから提供されたデータのみと一致している。
• 明記された丸め処理に基づき、明細の数量×単価が小計と一致している。
• 手数料／税金の合計がPO合計と一致している。該当する場合、変更POが親POを参照している。
• 両方が記載されている場合、予定納期が取引条件および明細単位の日付と一致している。
• デザイン意図で、PO番号、ベンダー、表、配送先、合計の強調方法が指定されている。
• すべての数値を、ユーザー入力または文書内の明示的な数式までたどれる。

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

k2f スキルに従ってブループリントから発注書を作成し、デザイン意図に基づいてロールを適用し、検証したうえで、発行可能な成果物をエクスポートします。