k2f-application-form

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

目的

エージェントがcontent_and_design.mdで応募フォームの設計図を作成できるようにします。フォームに含める質問と添付書類に含める質問の切り分け、フィールドのグループ化と順序、美的な意図（トーン、階層、記入欄の密度）を扱います。ユーザーが提供していない雇用主、プログラム、法的条項、応募資格の条件を作り出してはいけません。

K2F を基盤に構築

このスキルでは、応募フォームを.K2Fパッケージとして作成します。作成時はk2fスキルに従ってください。ワークスペースを展開または初期化し、セマンティックツリーを編集して、パッケージ化・検証・エクスポートを行います。K2F を使うと、エージェントは座標ではなく、セクション、ラベル、フィールドの役割、説明などの意味に集中でき、レイアウトとタイポグラフィはエンジンが処理します。

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

使用するタイミング

• 求人、フェローシップ、助成金、会員登録、ボランティアの役割、プログラムへの申し込み用の印刷可能または記入可能なフォームを設計または再設計するとき。
• PDF に散在する質問を、ひと目で確認できる一つのフォームにまとめるとき。
• ユーザーが応募する場合に設計図へ回答を事前入力するとき。長文の添付書類にはk2f-cover-letterまたはk2f-resumeを使用します。

ワークフロー

Step 1. content_and_design.md を生成する

フォームの内容とデザイン意図をまとめた単一の設計図です。k2fスキルが後から対応付けできるよう、ラベル付きのブロック（ヘッダー、説明、セクション、フィールド行、確認事項）を使用します。

サブステップ

1. フォームの枠組み — 種類（雇用、学術、助成金、会員登録）、組織、役割またはプログラム、提出方法、ページ数の上限（多くの場合は1ページ。複数の記述式回答が必要な場合に限り2ページ）、トーンの方向性（フォーマル、温かみのある非営利団体向け、スタートアップらしく率直）。

2. 要件の監査 — ユーザーの説明、募集要項、またはテンプレートから、必ず収集するデータ（本人確認情報、連絡先、応募資格、日付、推薦者、アップロードファイル）を列挙します。履歴書やポートフォリオなど、添付書類で補える項目には印を付け、フォームで同じことを二度尋ねないようにします。法的文言、機会均等に関する文言、または同意文言が不足している場合はNEEDS USER INPUTと記し、コンプライアンス関連の文言を作り出してはいけません。

3. 情報設計（含める／削除する／統合する） — 枠組み上の要件から変更が必要な場合を除き、次の構成を基本とします。

   • ヘッダー → タイトル、組織、役割／プログラムの行、任意のロゴに関する注記。
   • 説明（短い行を2～4行）→ 添付するもの、締め切り、回答の使用方法。
   • 応募者の本人確認情報 → 氏名、連絡先、住所または必要に応じて就労資格。
   • 応募資格と事実情報 → 学位、年数、資格、はい／いいえで答える条件を簡潔な行にまとめる。
   • 適性と経験 → 履歴書の再入力ではなく、対象を絞った質問。
   • 自由記述 → 文章での回答が必要な質問のみ。ラベルに文字数の上限を明記。
   • 推薦者／リンク → URL 記入欄を含むリスト形式。
   • 確認事項 → 署名、日付、任意のチェックボックスによる確認。
   • 履歴書と重複するフィールド、「情熱的なチームプレーヤー」のような性格を表す形容語、カバーレターと重複する小論文の質問、プログラムの標準的な要件でない趣味の質問は削除します。

4. フィールドの種類を割り当てる — 各質問に質問の種類と回答欄の意図を割り当てます。事実を一言で答える質問、経験の概要（2～4文）、応募理由（約150語）、URL を記入するポートフォリオ欄、行動に関する STAR 回答（約150～250語）、自己紹介（100～200語）、意見（100～150語）などです。迷ったら短めにします。委員会は回答にざっと目を通すためです。

5. 事前入力レイヤー（任意） — ユーザーが履歴書、JD、回答を提供した場合は、直接的で具体的なフィールドごとの回答文を作成します。各回答は一つのフィールドの目的だけを果たし、そこで終えます。適性を明確にする場合に限り、JD の表現を取り入れます。募集要項を回答としてそのまま貼り付けてはいけません。プロジェクトや指標を作り出す代わりに、metric TBDまたはNEEDS USER INPUTを使用します。

6. デザイン意図 — トーン：落ち着いた、応募者に配慮した表現とします。法的な文体は、原文にある場合に限ります。階層：タイトルと職種／プログラムを先に示します。ラベルを目立たせ、フィールドはその下位に配置します。密度：セクション間に余白を設け、ラベルとフィールドは詰めて配置し、空行が続く構成は避けます。リズム：短い行はグリッド状に並べ、文章欄には広めの領域を設けます。ブランド：控えめな配色とし、アクセントカラーは1色に絞り、読みやすいコントラストを確保します。

ルールと制約

• 事実確認ゲート：組織名、応募資格、日付、事前入力した回答は、ユーザーの入力または明示的な仮入力に基づいていることを確認します。
• 単一目的ゲート：各フィールドでは1つのことだけを尋ねます。複合的な質問は分割します。
• 履歴書の重複防止ゲート：添付のCVに記載された情報を尋ねる場合は、職歴全体を再度求めず、該当箇所を示すポインターまたは要約文を求めます。
• 長さゲート：内容が収まらない場合は、長文を添付資料に移すか、質問を減らします。設計図では文字を小さくしません。
• 誠実性ゲート：事前入力する年数や評価は、実態に即したものとし、見栄えのために最適化しません。
• 具体性ゲート：職種名と組織名を正しく記載し、最終版に雇用主のプレースホルダーを残しません。

よくある失敗

• 小さな枠にカバーレターの文章を詰め込む → 質問を分割するか、添付資料に誘導します。
• 抽象的な特性を尋ねる質問や、ラベルでの職務記述書の繰り返し → 具体的で職種に即した質問に置き換えます。
• エッセイのように長くなる → 文章欄を減らし、語数上限を明記します。
• 区切りのない下線のグリッド → セクション区切りを設け、1行欄と複数行欄を使い分けます。
• 説明または確認欄がない → 提出方法の簡単な説明と、署名・日付の記入意図を追加します。
• 事前入力した回答が、背景説明なしにスキルを列挙している → 各項目について、経験年数と関連するプロジェクトを1つ記載します。

品質チェックリスト

• フォームの枠組み、ページ数の目安、トーン、要件（必須収集項目と添付資料）の確認結果を文書化します。
• セクションの構成がデフォルトの設計に沿っていることを確認し、削除や統合について説明します。
• すべてのフィールドについて、タイプ、ラベル文、回答欄／語数制限の意図を定めます。
• 任意の事前入力が単一目的ゲートと誠実性ゲートに従っていることを確認し、仮入力には印を付けます。
• フォーム全体のトーン、階層、密度、リズム、ブランドに関するデザイン意図を記載します。

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

k2f に従って、設計図からセクションとフォームフィールドを作成し、デザイン意図を適用して内容を確認したうえで、提出可能なフォーム（通常は入力可能な PDF または DOCX）をエクスポートします。