k2f-checklist

K2F チェックリスト — AI ネイティブな美的デザイン

目的

エージェントが content_and_design.md にチェックリストの設計図を作成できるようにします。何を確認するか、項目をどのように分類して順序付けるか、美的意図（一覧性、チェックボックスのリズム、実務的なトーン）を定めます。ユーザーが提示していない組織のポリシー、コンプライアンス上の承認基準、しきい値を作り出すことはありません。

K2F を基盤とする

このスキルは、チェックリストを .K2F パッケージとして生成します。作成時は k2f スキルに従ってください。ワークスペースを展開または初期化し、セマンティックツリーを編集して、パッケージ化／検証し、エクスポートします。K2F を使うことで、エージェントは座標ではなく、意味（セクション、項目ラベル、チェック状態）に集中できます。

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

使用するタイミング

• ユーザーが繰り返し実行する、または時間に追われて一度だけ実行する、ローンチ前、デプロイ、移行、イベント、旅行、引き継ぎの確認。
• ランブックやデューデリジェンスのリストを、印刷または入力可能なチェックリストにまとめる場合。
• 1つのフラットなリストよりも、セクションごとに分類したほうが適切な、複数のワークストリームの準備状況を確認する場合。

ワークフロー

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

チェックリストの内容とデザイン意図をまとめた単一の設計図です。ラベル付きブロック（タイトル帯、コンテキスト行、セクション、チェックボックス行、トリガー、注記）を使用し、後で k2f スキルが対応付けられるようにします。

サブステップ

1. チェックリストの枠組み — 分野、実行者、単発か定期的な使用か、ページ数の目安（多くの場合、フェーズごとに1ページ）を定めます。トーンは、落ち着いた手順的なもの、時間に追われるデプロイ向け、または正式なコンプライアンス向けとします。

2. スコープと要件の監査 — ゲート、ツール、リスク、承認、判断基準（停止、ロールバック、エスカレーション）を確認します。不明点は OPEN QUESTION または NEEDS USER INPUT とし、SLA やしきい値を決して捏造しません。

3. 情報アーキテクチャ（含める／削る／まとめる） — 中心となる構成を選びます。

   • 時系列のフェーズ — 順序が重要な場合（例：開始前 → 実行 → 終了後、計画 → 準備 → 実行）。
   • 並行するワークストリーム — チームがそれぞれ独立して進める場合（財務、法務、運用）。各セクションは単独で完結させます。
   • ハイブリッド — 必要な場合のみ使用し、フェーズ見出しの下にワークストリームのサブブロックを設けます。 既定のブロック：
   • タイトルとコンテキスト → チェックリスト名、日付／バージョン欄、提示されている場合は担当者または役割。
   • 使い方（2～3行）：実行するタイミング、所要時間の目安、「完了」の定義。
   • 主要セクション → テーマごとに4～12項目をまとめます。トピック（「テスト」）よりも、動詞＋観察可能な結果（「リリースブランチで CI が成功している」）を優先します。
   • トリガー／例外 → ユーザーが定義したロールバック、リリース停止、エスカレーションの条件。
   • 任意の付録の意図 → リンク、チケット ID、データルームへの参照を含めます。チェックリスト項目の重複は避けます。 目標達成の条件にならない、曖昧な項目（「品質を再確認する」）、フェーズをまたいで重複する項目、説明文の段落、あればよい程度の項目は削除します。

4. 項目の要件確認 — 1行につきアクションを1つ、検証可能な完了状態を1つにします。同じ階層の項目では動詞をそろえます。優先度や担当者は、求められた場合のみ追加します。「はい」の場合の追加確認は、親項目の下に配置します。

5. カスタマイズの確認 — 移行、フラグ、業界固有の項目など、コンテキストに応じたセクションは、ユーザーの入力または明示されたテンプレートに基づく場合のみ追加します。定期的に使う場合は、セクションの順序を一定に保ちます。

6. デザイン意図 — トーン：直接的にします。緊急性は警告文ではなくセクションラベルで示します。階層：タイトル、コンテキスト、セクション見出し、チェックボックス行の順にします。密度：長くまとまりのないリストは分割します。リズム：項目ごとに1行とし、トリガーは通常の項目と分けます。ブランド：アクセントは控えめにし、印刷時のコントラストにも配慮します。

前提（セクションの順序、任意項目の省略）と、未解決の質問（しきい値、担当者、ポリシー文言の不足）を記録します。

ルールと制約

• 検証可能性のゲート：すべての項目について「完了したことをどう確認できるか」に答えられるようにします。答えられない場合は、書き直すか削除します。
• 事実確認のゲート：承認、環境、指標、法的手順は、ユーザーの入力または明示的な仮置き項目に基づいている必要があります。
• スコープのゲート：このチェックリストの対象範囲内／対象範囲外を記載します。チェックリスト後のワークフローは1行にまとめ、手順書のような長文にしないでください。
• 1アクションのゲート：「レビューしてデプロイし、通知する」のような複合項目は、個別の項目または順序付きのサブステップに分割します。
• ゲートの順序：時系列のチェックリストでは、ブロッカー（テスト、承認、バックアップ）を、取り消せない手順より前に配置します。
• ドキュメント更新のゲート：ステータス追跡の意図を記載するのは、依頼された場合に限ります。ステータスの列挙値を独自に作らないでください。

よくある失敗パターン

• フェーズやテーマのない単調な項目の羅列 → 時間軸または作業の流れに沿って再編します。
• 前提条件より前に項目がある（「ステージングでの検証」より先に「本番環境にデプロイ」など） → 時系列の流れに沿って並べ替えます。
• ユーザーがリスクに触れているのに、トリガーやロールバックの記載がない → トリガーのセクションを追加するか、NEEDS USER INPUT と明記します。
• ユーザーの技術スタックを無視した汎用テンプレート → ユーザーが指定したツールとゲートのみを組み込みます。
• 確認可能な項目の代わりに、説明文が長くなっている → チェックボックス項目と、簡潔な使い方の説明に置き換えます。
• 各フェーズに同じ確認項目が重複している → 最初に必要となるゲートのセクションに一度だけ記載します。

品質チェックリスト

• フレーム、ページ数の上限、トーン、要件の監査（ゲート、ツール、トリガー）を記載している。
• IA の選択（フェーズ、作業の流れ、またはハイブリッド）が明示され、対象範囲内／対象範囲外と削除項目が説明されている。
• すべての項目が、並列した表現による検証可能な1つのアクションになっている。フォローアップは親項目にひも付いている。
• トリガー／停止条件が記載されているか、仮置き項目になっている。前提条件と未解決の質問が列挙されている。
• デザインの意図として、チェックリスト全体のトーン、階層、密度、リズム、ブランドを網羅している。

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

k2f スキルに従い、設計図からセクションとチェックボックス項目を作成し、デザインの意図を反映して検証したうえで、実用可能なチェックリスト（通常は入力可能な PDF または DOCX）をエクスポートします。