k2f-invoice

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

目的

レイアウトに取りかかる前に請求書の設計図を作成するよう、エージェントに指導します。法務上および業務上必要な請求元・請求先と参照情報を漏れなく記載し、明細と税額の計算を整合させ、「支払う金額、支払期限、支払方法」がひと目で分かる視覚的階層を構築します。ユーザーが提示していない銀行情報、税務 ID、金額を捏造してはいけません。

K2F を基盤とする

このスキルは、.K2F パッケージとして請求書を生成します。作成時は k2f スキルに従ってください。ワークスペースを展開または初期化し、セマンティックツリーを編集してから、パック／検証を実行し、エクスポートします。K2F を使うことで、エージェントはピクセル座標ではなく、意味（請求元・請求先、明細の役割、合計、支払い欄）に集中できます。エンジンがレイアウト、タイポグラフィ、テーマをコンパイルし、PDF などの各形式で一貫した出力を生成します。

作成を始める前に、コアスキルをインストールします。npx skills add suzheng/k2f --skill k2f

使用する場面

• 見積書、タイムシート、契約書、または貼り付けられた明細から新しい請求書を発行するとき。
• 計算、参照情報、支払い詳細の整合性を取るため、雑然とした請求書や一般的な AI 請求書を作り直すとき。
• 支払期限や金額の意味が通常の請求書とは異なる、プロフォーマ請求書やデポジット請求書を作成するとき。

ワークフロー

ステップ 1. content_and_design.md を生成する

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

サブステップ

1. 請求書の種類と管轄の確定 — 通常の請求書、プロフォーマ、デポジット／一部請求、またはクレジット形式の調整のいずれかを指定します。通貨、ロケール（日付と数値の書式）、税が内税か外税かを記載します。その種類で不要なセクションは省略します（例：代金を徴収しないプロフォーマでは「支払額」欄を省略します）。

2. 請求元・請求先と識別情報の欄 — 販売者：正式名称、住所、連絡先、ロゴの意図、税／VAT ID。ただし、ユーザーが提供した場合に限ります。購入者：請求先の名称と住所。任意で発送先や宛名行も指定できます。登録番号や銀行情報を決して捏造してはいけません。

3. 参照メタデータ — 請求書番号、発行日、支払期限（または明確な「受領時払い／N 日以内」）。ユーザーから提供された場合は、発注書、プロジェクト、契約、顧客の参照情報も記載します。書類全体で通貨コードを一つに統一し、レイアウトに進む前に支払期限の欠落を明示します。

4. 明細の構成 — 文章の段落ではなく、表を中心にします。各行には、分かりやすい内容、数量、単位、単価、明細金額を記載します。オプションのセクション（サービスと経費、マイルストーンなど）は、ユーザーのデータがすでにそのように分かれている場合に限り、グループ化します。値引きは、明示的なマイナス行、または小計の計算ルールに結び付いた割合の注記として記載し、説明文に隠してはいけません。

5. 合計の計算過程（書類に計算を記載する） — 小計 → 税／値引きの各行と税率ラベル → 合計 → 任意で支払済み金額／残額。丸めルール（明細ごと、または請求書全体）を記載し、明細の合計、課税標準、総額が、指定したルールの範囲内で 1 セント以内に一致することを確認します。入力に矛盾がある場合は、推測せず NEEDS USER CONFIRMATION と記載します。

6. 支払いおよびコンプライアンスのフッター — 支払条件は平易な言葉で記載します。ユーザーが指定した支払方法（電信送金、ACH、カード決済リンク、小切手）を使います。銀行／ウォレット情報は、ユーザーの記載どおりに転記します。ホストされた URL がある場合は、支払いリンクへの行動喚起を追加します。延滞料金や送金に関する注記は、ユーザーから提供された場合に限り記載します。ユーザーが文面を提供していない限り、法的な定型文は最小限にします。

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

   • トーン：落ち着きと信頼感のある B2B 向け。代金回収の書類に宣伝文句は入れません。
   • 階層：書類タイトルと請求書番号はヘッダーでひと目で確認できるようにします。支払額と支払期限は、合計／支払い欄で最も強く強調します。明細表はその次、フッターはさらに控えめにします。
   • 密度：表の行間にはゆとりを持たせます。金額の列は右揃えにし、すべての金額に等幅数字を使います。短い注記欄は 1 つまでにします。
   • 配色：落ち着いたニュートラルカラーを基調に、合計／支払期限にはアクセントカラーを 1 色使います。WCAG AA に準拠し、装飾で煩雑にせずロゴ用のスペースを確保します。

ルールと制約

• 支払い準備ゲート：請求書番号、日付、通貨、照合済みの合計額、および支払いが予定されている場合はユーザーが確認した支払い指示がそろうまで、送信可能な設計書を作成しないでください。
• 信頼できる唯一の情報源：小計は明細項目から算出します。税率は、文書に記載された課税対象額にのみ適用します。
• 参照情報の徹底：PO／プロジェクト ID はメタデータに一度記載し、必要に応じて明細にも記載します。無関係な段落に繰り返し記載しないでください。
• 誠実性ゲート：税の取り扱いや為替レートが不明な場合は、その旨を記載します。ユーザーの入力なしに法定税率を推測しないでください。

よくある失敗

• 段落形式の明細項目 → 数量／単価／金額を含む表の行に書き換えます。
• 課税対象額の誤りや二重計上 → 課税対象額、税率、丸め後の税額を明記します。
• 期日や番号のない一般的な「請求書」 → ユーザーから情報を得るか、不足項目として明示します。
• デザイン意図の中で、折りたたみの下に支払額が埋もれている → 階層に関するメモで合計額／支払額を目立たせます。
• IBAN、VAT、支払いリンクの捏造 → 削除し、TBD — user must supply に置き換えます。
• 1 枚の請求書に複数の通貨が混在 → ユーザーが為替換算の明細行を確認しない限り、請求書を分けるか、エスカレーションします。

品質チェックリスト

• 当事者と税 ID は、ユーザーが提供したデータのみと一致しています。
• 明記された丸め規則に基づき、明細金額 × 数量が小計と一致しています。
• 税／割引の各明細の合計が総額と一致しています。前払いが記載されている場合、残額も正確です。
• 期日と支払い指示が支払い条件に沿っています。
• デザイン意図で、支払額、表、支払い欄の強調方法が指定されています。
• すべての数値を、ユーザーの入力または文書内に明記した計算式までたどれます。

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

k2f に従って、設計書から請求書を作成し、デザイン意図に基づいて役割を適用し、検証したうえで、支払い可能な成果物をエクスポートします。