mcpField
K
k2f-fillable-pdf

k2f-fillable-pdf

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

k2f-fillable-pdf について

k2f-fillable-pdfは、入力可能なフォームをK2F文書として設計するエージェント向けスキルです。表示文言、入力項目の一覧、セクション構成、デザイン方針をまとめ、k2fを通じて入力可能なPDFへ出力します。

主な機能

  1. 01表示文言と入力項目の一覧
  2. 02項目の種類と入力制約
  3. 03記入シナリオに沿ったセクション順
  4. 04条件付き表示ルールの明示
  5. 05フォームに適した視覚的階層
  6. 06k2fスキルによる出力

活用シーン

  1. 01申請書や受付フォームの作成
  2. 02紙のPDFを入力可能なフォームに再構築
  3. 03複雑なフォームのセクション分割

インストール

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

$npx skills add https://github.com/suzheng/k2f --skill k2f-fillable-pdf

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

詳細

K2F 入力可能な PDF — AI ネイティブな美的デザイン

目的

実際に人が記入するフォーム向けに、エージェントが content_and_design.md を作成できるようにします。明示的な静的文言、種類と制約を網羅した完全なフィールド一覧、論理的なセクション構成、スキャンして入力しやすいことを重視した美的意図を盛り込みます。一般的なアンケートの羅列や、ボックスを貼り付けただけの静的な PDF にはしません。

K2F を基盤に構築

このスキルでは、入力可能なドキュメントを .K2F パッケージとして生成します。作成時は k2f スキルに従ってください。ワークスペースを展開または初期化し、セマンティックツリーを編集して、パックと検証を実行してからエクスポートします。K2F を使うと、エージェントはピクセル座標ではなく、意味(ラベル、フィールドの役割、説明、グループ化)に集中できます。レイアウト、タイポグラフィ、インタラクティブなフィールドはエンジンがコンパイルするため、出力の一貫性が保たれます。

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

使用する場面

  • 要件や既存の紙の PDF をもとに、新しい申請、登録、受付、オンボーディング、コンプライアンス関連のフォームを作成する場合。
  • 再構築の前に、煩雑な旧式フォームを再構成する場合。
  • ユーザーから提供された法的文言やポリシー文言を正確に維持しながら、長いフォームをスキャンしやすいセクションに分割する場合。

ワークフロー

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

読者が見るもの(静的)と読者が入力するもの(インタラクティブ)、さらにエンジンが解釈できるデザイン意図を統合した設計図です。ラベル付きブロックを使用し、ページへの割り当ては後で k2f で行います。

サブステップ

  1. 完了シナリオ — 誰が記入するのか(申請者、スタッフ、患者)、単独で記入するのか添付書類を付けるのか、所要時間、提出方法、必須セクションと任意セクションを記載します。結果に影響しないフィールドは削除します。

  2. 静的レイヤー — タイトル、バージョンまたは発効日、発行者の情報、簡潔な「記入方法」の手順、プライバシーまたは保存期間に関する通知(ユーザーのテキストにある内容のみ)、セクションの導入文、フッター(ページ x / y、連絡先)を記載します。法的条項を捏造してはいけません。

  3. フィールド一覧 — 表または構造化リストに、安定した ID、人が読めるラベル、コントロールの種類(1 行テキスト、複数行テキスト、チェックボックス、ラジオボタングループ、ドロップダウン、日付、署名による証明)、必須フラグ、プレースホルダーまたは形式のヒント、選択式フィールドの選択肢、最大文字数または行数、1 行以内のヘルプテキストを記載します。ラジオボタンやチェックボックスのセットは 1 つの質問の下にまとめ、相互排他的か複数選択可能かを明記します。

  4. 情報アーキテクチャ — 認知の流れに沿って、識別 → 詳細 → 選択 → 承認 → 確認の順に並べます。1 セクションあたり 5~9 個のフィールドをまとめ、トピックが変わるところで新しいセクションを始めます。短いラベルと入力欄は 2 列の行に並べ、段落、複数行の回答、宣言ブロックは全幅を使用します。条件付きブロック(「Employment = Yes の場合のみ、雇用主ブロックを表示」など)は、レイアウトから推測させず、明示的なルールとして記載します。

  5. デザイン意図 — トーン(公的機関らしい、穏やかな臨床的雰囲気、親しみやすい受付)、階層(タイトルを最大、セクション見出しは H2、ラベルは中程度の太さ、ヘルプテキストは小さく薄い色)、密度(縦方向にゆとりを持たせ、ボックスばかりの見た目を避ける)、配置(ラベルを右揃えまたは上揃えで並べ、選択肢グループは質問の下にインデント)、アクセント(セクションバーまたは必須マークに使う色は 1 色)、コントラスト(ラベルと説明文は WCAG AA に準拠)を指定します。チェックボックスでは明確なクリック領域が必要な箇所と、法的テキストにインラインで配置する箇所を明記します。

ルールと制約

  • ラベルの明確さ:すべてのフィールドで「何の情報か」がわかるようにします(「Email」ではなく「Work email」)。
  • 1 つの質問に 1 つのコントロールパターン:排他的な選択肢にはラジオボタン、複数選択にはチェックボックスを使い、混在させてはいけません。
  • 必須項目の適正表示:任意フィールドにはその旨を示します。すべてを必須に設定してはいけません。
  • 原文の遵守:ポリシー、同意、証明に関する文言は、ユーザーの提供した資料からのみ転記します。
  • 完了の流れ:ユースケースで必要な場合、最後のセクションに証明者の氏名、日付、署名のフィールドを含めます。

よくある失敗

  • プレースホルダーがラベルの代わりになっている → 表示ラベルを追加します。プレースホルダーはヒントに限ります。
  • むやみに情報を集めるフォーム → 審査担当者またはシステムでの利用目的が明記されていないフィールドを削除します。
  • フィールドの順序に一貫性がない → シナリオの流れに合わせて並べ替え、関連する行をまとめます。
  • 同じ情報を重複して尋ねている(例:2 つのセクションで市区町村を尋ねる)→ 1 か所にまとめるか、1 度だけ相互参照します。
  • ラジオボタンやチェックボックスの選択肢が未指定 → すべての選択肢ラベルを明記します。
  • 1 列に項目が詰め込まれた長大なフォーム → セクションを分け、短い項目にはラベルと入力欄のペアを使用します。
  • 条件付きロジックが不明 → 影響を受けるフィールドのそばに表示・非表示のルールを記載します。
  • 汎用的な「フォームテンプレート」の文体 → デザイン意図でトーンと発行者の背景を設定します。

品質チェックリスト

  • すべてのインタラクティブコントロールが、種類と必須フラグを含めてフィールド一覧に記載されています。
  • セクションの順序が完了シナリオに沿っており、タブ移動は上から下へ、ペア内では左から右へ進みます。
  • 静的な説明は、それが適用されるフィールドより前に配置されています。
  • 選択式フィールドには、完全で重複のない選択肢が記載されています。
  • 法律またはポリシーに関するテキストはユーザーが提供したもので、変更されていません。
  • デザイン意図では、レイアウト座標を指定せずに、トーン、階層、密度、アクセントを扱っています。
  • 孤立したラベルや、シナリオ上の目的がないフィールドはありません。
ステップ 2. content_and_design.md と k2f スキルを使用して K2F ファイルを生成し、適切なファイル形式でエクスポートします。

k2f に従って、ブループリントからページを作成し、インベントリからフィールドの役割を割り当て、確認して、入力可能な PDF の成果物をエクスポートします。

コメント