k2f-policy-document

K2F Policy Document — AI-Native Aesthetic Design

目的

レイアウトに着手する前に、エージェントがポリシー文書の設計図を作成できるようにします。スキャンしやすいルール構成、従業員向けの平易な説明レイヤー、正式な階層構造を備えつつ、ユーザーまたは人事・法務が提示していない福利厚生、法的義務、管轄区域、承認経路を作り出さないようにします。

K2F を基盤とする

このスキルでは、ポリシー文書を .K2F パッケージとして作成します。作成には k2f スキルを使用してください。ワークスペースを展開または初期化し、セマンティックツリーを編集して、pack/verify を実行した後にエクスポートします。K2F により、エージェントはピクセル座標ではなく、意味（セクション、強調、表）に集中できます。レイアウト、タイポグラフィ、テーマはエンジンがコンパイルし、エクスポート可能な一貫した出力にします。

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

使用する場面

• 新規または更新する単一ポリシーのページ（PTO、リモートワーク、経費、行動規範、出張、セキュリティ、休暇の種類）。
• ハンドブックのセクション。社内スタイルとの一貫性を保ちつつ、最初のスキャンで見つけやすくする必要があるもの。
• 人事または法務のレビューに向け、草稿や貼り付けられたポリシー文面を公開可能な構成に整える場合。
• チャットのみでのポリシーに関する Q&A、AgentRC のスコアリングポリシー、弁護士水準の契約書には使用しないでください（k2f-contract を使用）。

ワークフロー

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

情報アーキテクチャとデザインの意図を組み合わせた設計図を作成します。後から k2f スキルがセクション、コールアウト、強調に割り当てられるよう、ブロックにラベルを付けます。

サブステップ

1. 文書の枠組み — ポリシーのタイトル、ユーザーが提示した場合は文書 ID、発効日、バージョン、ポリシー責任者（チーム／役割）、適用範囲（法人、所在地、雇用形態）。この文書が新規、改定、または以前の文面に優先するものかを明記します。以前のバージョンへのリンクは、ユーザーからの入力がある場合に限ります。

2. 目的と適用範囲 — 2 つの短いブロックで構成します。ポリシーの目的（最大 1 段落）と、対象者および適用時期を示します。タイトルを繰り返す説明は削除し、ユーザーが指定していない地域をまたぐ適用範囲には HR VERIFY を付けます。

3. 概要レイヤー — 簡単な要約（3～5 個の箇条書き、または短い 1 段落）：詳細を読む前に従業員が把握しておくべきことを示します。これはスキャン時の目印であり、すべてのルールをもう一度掲載する場所ではありません。

4. 定義 — このポリシーにおけるコンプライアンス上の意味を変える用語に限定し、辞書のような用語集は省略します。

5. ポリシーの条項 — 番号付きのルールとして記載します。対象を明確にし、法助動詞（must／may not／requires approval）と結果を示します。箇条書き 1 つにつき義務は 1 つとし、同じ箇条書きに「ポリシー＋手順」を混在させないでください。

6. 手順 — 申請、報告、エスカレーション、コンプライアンスの記録方法を、番号付きの個別のフローにします（フォーム、システム、期限はユーザーが提示したものに限ります）。手順からルールを参照し、説明文でルールを繰り返さないでください。

7. 役割と責任 — 従業員、マネージャー、人事、IT、財務、法務などについて、各ステップで誰が何をするかを簡潔なマトリックスまたは箇条書きで示します。

8. 例外と承認 — 例外を承認できる人、必要な文書、記録の保管場所を示します。不明な場合は APPROVAL PATH — USER TO CONFIRM と記載します。

9. 関連ポリシーと参考情報 — クロスリンクや外部規制は、ユーザーが名前を挙げたものに限ります。架空の引用は作成しないでください。

10. 適用と問い合わせ — 結果や段階的な懲戒措置は、ユーザーが提示した場合に限ります。それ以外の場合は LEGAL/HR TO CONFIRM と記載します。例外的なケースの問い合わせ先と、問い合わせ窓口を 1 つ示します。

11. 改訂履歴 — バージョン、日付、変更内容の要約、承認者を表またはリストで記載します。ユーザーが記入するまで、プレースホルダーには TBD と記載します。

12. デザインの意図 — 装飾よりも明瞭さを重視します。

    • トーン：概要では中立的で権威があり、平易な言葉を使います。番号付きルールでは厳密で正式な表現を使い、宣伝や謝罪のトーンは避けます。
    • 階層：タイトルと適用範囲を最初に示します。概要とポリシーの規定を最も目立たせ、手順と役割をその次に、改訂履歴を最後に配置します。
    • 情報密度：中程度にします。段落は短くし、ルールと手順には箇条書きを使います。ユーザーから数値が提示されている場合は、役割やしきい値を表にまとめます。文章が長く続く構成は避けます。
    • 配色：落ち着いたニュートラルカラーを使い、本文とのコントラストを高くします。必須／禁止、期限、承認経路にはアクセントカラーを最小限に使用します。WCAG AA に準拠し、ルールの妨げになるストック画像は使いません。

ルールと制約

• ソースゲート：必須の文言または管轄区域固有の文言は、ユーザーから提供された内容を一字一句そのまま使用します。それ以外の草案にはすべて FOR HR/LEGAL REVIEW と記載します。
• 正確性ゲート：PTO の日数、金額の上限、法的引用、システム、承認者名を創作しません。
• 分離ゲート：ルールはポリシーの規定に、手順は手順に記載します。手順の段落にルールを埋め込まないでください。
• 適用範囲ゲート：すべての義務について、誰に適用されるのかを明記します。地理的な適用範囲が曖昧な場合は、米国がデフォルトであると暗黙に想定せず、確認事項として示します。
• 単一トピックゲート：ブループリントごとにポリシーの主題を1つにします。ユーザーが明示的に、名前付きのパートを含む統合ハンドブックの章を求めている場合を除き、無関係なトピック（例：出張と経費）は分けます。

よくある失敗

• 概要のないエッセイ形式の導入文 → 従業員がルールを見つけられません。
• FAQ の説明文にルールが埋もれる → 命令形の文を番号付きのポリシーの規定として抜き出します。
• ルールより先に手順を記載する → 「何をするか」を「どのようにするか」より先に示すよう並べ替えます。
• 簡潔な要約と詳細なセクションが重複する → 要約は短く保ち、詳細は後続のセクションに記載します。
• 汎用的な AI ハンドブックの文体になる → ユーザーの用語、システム、承認者を使うか、未確定としてマークします。
• 問い合わせ先が記載されていない → 例外的なケースが非公式な窓口に回されてしまいます。
• 改訂履歴に変更内容がない → コンプライアンスの追跡に支障が出ます。
• 従業員向けの平易な文章に、法的な機密分析を混在させる → 外部向けのトーンだけを維持します。

品質チェックリスト

• 冒頭に適用範囲、発効日、新規／改訂／置き換えのステータスが含まれています。
• 概要だけで内容が完結し、ポリシーの規定は番号付きの命令形になっています。
• 手順は分けて記載し、役割と例外時の経路を示すか、未確定としてマークしています。
• ユーザーが指定した文言は一字一句そのまま使用し、上限、引用、連絡先を創作していません。
• 関連ポリシーは、ユーザーから提供された情報に基づくものだけを記載しています。
• デザインの意図に、トーン、階層、情報密度、ルールと手順の強調方法が指定されています。

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

k2f に従ってブループリントからポリシーを作成し、デザインの意図に沿った役割を適用して内容を検証したうえで、HR／法務レビュー用にエクスポートします（通常は PDF または DOCX）。