mcpField
K
k2f-one-pager

k2f-one-pager

github.com/suzhengドキュメント3689 回インストール2 週間前に更新
リポジトリ

k2f-one-pager について

k2f-one-pagerは、単ページの意思決定文書や説明資料の内容とデザインを構成するエージェント向けスキルです。情報の階層とデザイン意図を定め、文書の作成と出力には別途 k2f スキルを使います。

主な機能

  1. 01単ページ文書の型
  2. 02素早く読める情報階層
  3. 03主張・根拠・境界の分類
  4. 04トーンと階層のデザイン指針
  5. 05事実の創作を防ぐ確認

活用シーン

  1. 01製品・機能の概要
  2. 02イニシアチブの提案
  3. 03リリース概要
  4. 04ソリューション・企業紹介

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/suzheng/k2f --skill k2f-one-pager

インストール後、Claude Code で/k2f-one-pagerを入力して読み込まれたか確認します。

詳細

K2F ワンページ資料 — AI ネイティブな美的デザイン

目的

エージェントが意思決定やストーリーを伝える1ページ資料向けの content_and_design.md を作成できるようにします。1ページに何を載せるか、経営層がすばやく全体を把握できる情報の階層化の方法、そして美的な意図(トーン、階層、密度)を扱います。K2F のパッケージ化やエクスポートは対象外です。

K2F を基盤に構築

このスキルは、ワンページ資料を .K2F パッケージとして生成します。作成には k2f スキルを使用してください。ワークスペースを展開または初期化し、セマンティックツリーを編集してから、パッケージ化/検証し、エクスポートします。K2F を使うことで、エージェントは座標ではなく、意味(セクション、主張、証拠の形式、CTA)に集中できます。エンジンがレイアウト、タイポグラフィ、テーマをコンパイルし、エクスポート可能な出力を生成します。

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

使用する場面

  • 1ページにまとめた製品や機能の概要、取り組みの提案、ソリューション/企業の概要、パートナーシップの要約、リリースの概要。
  • 詳細なデザイン、エンジニアリングへの引き継ぎ、またはローンチ告知の前の認識合わせ。
  • ひと目で把握できる1つの資料。ピッチデッキ、チラシ、ポスター、完全版の PRD、複数ページのレポートには適しません。

対象外: 詳細な技術設計、リサーチデッキ、または日付/会場と目立つ CTA を中心にしたイベント告知(k2f-flyer)。

ワークフロー

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

1 枚のキャンバス向けに、ラベル付きセクションブロックで意味的なコンテンツとデザイン意図を設計します。

サブステップ

  1. 1 ページ資料を確定する — 唯一の目的(承認、リリース概要、ソリューションの販売)を決めます。対象読者、チャネル(印刷用 PDF、メール、Wiki)、ジャンルを定めます。アーキタイプを 1 つ選び、相容れない構成を混在させないでください。

  2. アーキタイプとセクションの順序 — 次の見出しで固定の縦方向の構成にします。

    • 意思決定/製品:主張 → 課題(痛点と今である理由)→ ソリューション(UI ではなく、何を解決するか)→ ユーザー → 指標(ベースラインと目標)→ 対象範囲内/対象範囲外 → 制約 → 未解決の質問 → オプションで担当者/次のステップ。
    • リリース/変更履歴:バージョン、日付、概要 → 追加 → 修正 → 破壊的変更 → 既知の問題 → アップグレードに関する注意 → 実際のリンク先がある場合のみ CTA。
    • ソリューション/会社:対象読者 → ひとことの提案 → 3 つの差別化要素 → 裏付け → オプションで価格 → 次のステップを 1 つ。
    • 取り組みの提案:課題 → アプローチ → 影響 → リソース/タイムライン → 依頼事項 → リスク。
  3. スキャンの階層 — ひと目でわかる情報:タイトル、主張、主要指標またはバージョン。スキャンして把握する情報:2~4 個の箇条書きブロック。詳細:出典と注記。主張より目立たせないようにします。

  4. コンテンツの階層 — 主張(ページのストーリー)、根拠(数値、引用、リスト)、境界(範囲、制約、「なし」を明示)。2 ページ目に相当する内容は削除するか、付録へのリンクにします。

  5. 誠実さ — 指標、日付、顧客、破壊的変更を捏造しないでください。入力が不足している場合は None、No … provided、または TBD を使います。バージョン/日付が不明な場合は、ラベルを添えて — を使います。

  6. 削減する — 長文の説明、機能カタログ、API、重複する指標を削除します。曖昧な目標は、測定可能な成果または TBD に置き換えます。主な CTA は 1 つにし、追加の連絡先は連絡先欄にまとめます。

  7. デザイン意図(座標は指定しません):

    • トーン:意思決定向けは根拠を重視し、リリース向けは事実に基づき、ソリューション向けは根拠がある場合のみ自信のある語り口にします。形容詞の組み合わせは 1 つにします。
    • 階層:主張を最も大きくし、セクションラベルは一貫させ、主要指標/バージョンを視線の起点にし、境界の情報は最も小さくします。
    • 密度:ユーザーから指定がない限り、約 250~450 語にします。文章より箇条書きを優先し、各ブロックは箇条書き 5 個程度までにします。対象範囲内/対象範囲外のみ、短い並列カラムを使います。
    • リズム:箇条書きと 1 つの視覚的な表現(指標の行、ロゴの帯、タイムラインのチップ)を組み合わせ、箇条書きが続きすぎないようにします。
    • コントラスト:明るい背景を使い、主張/指標/CTA にアクセントを付けます。ブランドカラーは読みやすくします。

ルールと制約

  • 1 ページに主張は 1 つ。複数の観点がある場合は、別々の 1 ページ資料に分けます。
  • 変更履歴:標準セクションをすべて含めます。内容がない場合は、None 形式の文言で明示します。
  • 機能は画面仕様ではなく、成果のレベルで記述します。
  • 指標:ベースラインと目標、または TBD を記載し、装飾として使わないでください。
  • 対象範囲内/対象範囲外を明確にし、必要に応じて MVP と後続対応を分けます。
  • CTA は実際のリンク先がある場合のみ使用し、プレースホルダーは使いません。

よくある失敗

失敗対処
スライド資料/PRD の貼り付けアーキタイプに沿って整理し、箇条書き 1 つにつきアイデア 1 つにして、詳細は対象範囲外に移します。
製品概要のチラシのようなトーンキャッチコピーより先に、課題と指標を示します。
リリースセクションの省略None 形式の文言を使って、ラベル付きブロックを作成します。
曖昧な課題痛点とシグナル、または TBD を示します。
対象範囲の拡大境界の階層を設け、対象範囲外のリストを作成します。
主張が 2 つある1 ページにつき目的を 1 つにします。
根拠の捏造仮の記述を置くか、NEEDS USER INPUT と記載します。

品質チェックリスト

  • 目的、対象読者、ジャンル、チャネルを確定した。
  • アーキタイプの順序に沿っており、主張がひと目でわかる階層にある。
  • 主張/根拠/境界を整理し、文字数の目安を記録した。
  • 主張の出典を追跡できるか仮の記述を置いており、対象範囲/変更履歴のセクションが揃っている。
  • デザイン意図として、トーン、階層、密度、リズム、コントラストを定めた。
  • 主な次のステップは 1 つで、偽の CTA はない。
ステップ 2. content_and_design.md と k2f スキルを使って K2F ファイルを生成し、適切なファイル形式にエクスポートする

k2f に従って、設計図から 1 ページを作成し、デザインの役割を適用して検証したうえでエクスポートします(通常は PDF)。

コメント