kb-init

kb-init — ナレッジバンドルをひな形から作成する

kb に準拠した バンドル をひな形から作成します。独自に行うのは、スキーマ層 （ステップ 2）とシードの適応（ステップ 3）です。

作成前にバージョンプロファイルを読んでください。新しいバンドルでは OKF v0.2 を対象とします。以下の用語が不明な場合は、用語集を読んでください。

1. 場所とバンドル名を決める

デフォルトでは、knowledge/ にバンドルを作成します。ユーザーの依頼に別の指定があれば、それを優先します。

• 別のパス（例：docs/kb）→ 代わりにその場所へひな形を作成します。
• 名前付きバンドル（例：「ci バンドル」）→ knowledge/<name>/ にひな形を作成し、 knowledge/ を複数バンドル用のフォルダーとして扱います。バンドルを一覧表示する最上位の knowledge/index.md が存在することを確認し、なければ作成して、このバンドルを追加します。

対象ディレクトリにすでにバンドル（ルートの index.md）がある場合は、処理を中止してその旨を伝えてください。上書きしてはいけません。リポジトリのドキュメントにはkb-document、取り込んだソースには kb-ingest を案内してください。

generated.by には、実際の生成元を表すアクターを指定します。現在のエージェント／ツールを <producer>/<version> として指定し、人間が実際にコンテンツを作成した場合を除き、human:<id> は使わないでください。

完了条件： 対象パス、バンドル名、生成元アクターが確定し、対象が既存のバンドルと重複しないことを確認できていること。

2. ひな形を作成する前にドメインを理解する

ひな形の作成は決定論的ですが、スキーマ層には判断が必要なため、先に情報を集めます。ワークスペースで手掛かり（README、既存のドキュメント、コード、ユーザーが指定したメモなど）を調べ、リポジトリドキュメント用か、取り込んだソース用かを判断してください。そのうえで、まだ推測できないことだけをユーザーに尋ねます。

• このバンドルにはどのようなナレッジを格納しますか？（業務の文脈――人物、取引、製品など。論文を継続的に追加する研究コーパス。コードベースや製品のハンドブック。競合状況。学習中の書籍やコース。このリポジトリの OKF バンドルのように、文書化する仕様やパターンなど。）
• 主なエンティティは何ですか？ それぞれに概念を割り当てる価値のある、繰り返し登場するものは何ですか？ これらが type の語彙になります（例：person、deal、metric、または character、chapter、theme）。
• 取り込んだソース用のバンドルの場合：どのような生のソースを取り込みますか？ それらを各エンティティにどのように振り分けますか？ 明示的に管理する取り込み先はどこですか？
• リポジトリドキュメント用の場合：リポジトリのどの部分を対象とし、コンポーネント、ワークフロー、インターフェース、運用、決定事項をどのように振り分けますか？ リポジトリ内のファイルはそのまま証拠として扱い、生の取り込み対象にはしません。

簡潔にしてください。まずは暫定的なタイプをいくつかと、1 行の振り分けルールがあれば十分です。これは初期の語彙であり、確定した列挙型ではありません。取り込みによってドメインが明らかになるにつれて、スキーマ層も共に進化します。 Reference（取り込んだソース資料）と Spec Section（バンドル独自のスキーマ文書）は、シードが提供するワークフロータイプであり、ユーザーが設計するドメイン上の選択肢ではありません。

対話上のルール：

• ワークスペースを一度調べ、可能であれば関連する読み取りをまとめて行います。
• 不明な点が残る場合は、すべてをまとめた簡潔な自由記述の質問を 1 つだけ行います。
• このドメイン固有の入力に、定型の選択肢を使ってはいけません。
• ユーザーの回答後は、この手順を読み込んだ状態から続行します。kb-init を再度読み込んではいけません。
• 確認のためにスキーマ案を提示した場合は、ユーザーの回答を一度受け入れます。承認後は、案を言い直したり再計画したりせず、ひな形を作成します。

完了条件： バンドルの初期 type 値を挙げられ、さらに、生のソースと 1 行の取り込み振り分けルール、またはリポジトリの対象範囲と 1 行のドキュメント振り分けルールのいずれかを明示できていること。

3. 適応したシード層とスキーマ層を作成する

../kb/example-bundle/ を元となるひな形として読み込み、適応した成果物をターゲットに書き込みます。まず変更していないコピーを書き、その後で上書きするのではなく、ディレクトリを作成し、各ターゲットファイルをドメイン固有の最終内容で一度だけ書き込みます。ユーザーの承認後は、読み書きのたびに説明せず、静かに作業を進めてください。

以前の試行ですでにターゲットファイルが作成されている場合、そのファイルは新規ではありません。編集する直前にそのファイルを読み込み、有効な作業を保持したうえで、未完了の手順から再開してください。読み込み前に書き込んでしまった失敗を、確認せずに繰り返したり、誤報として片付けたりしないでください。

成果物	操作
index.md	okf_version: "0.2" のフロントマターを維持し、本文をこのバンドルのタイトルとセクション一覧に置き換えます。
log.md	日付入りの **Creation** エントリーを1件だけ記載して、新規作成します。
spec/types.md	Spec Section と Reference を維持し、例のドメイン型を置き換えて、generated に現在の作成者／時刻を設定します。
spec/conventions.md	フォルダーの分類、ルーティング、管理責任、信頼ルールに置き換え、generated に現在の作成者／時刻を設定します。
concepts/*	例のエンティティ（customers、orders）を削除し、concepts/ を空のままにするか、ドメインのスターターフォルダーを作成します。
references/*	合成された例のソースを削除し、実際のソースが取り込まれるまで references/ を空のままにします。
knowledge/index.md	複数バンドルの場合（手順1）、このバンドルのカタログエントリーを作成または更新します。

新しいコンセプト／インデックス／ログファイルを作成する場合は、../kb/templates/ を使用してください。

完了条件： バンドルが OKF v0.2 としてディスク上に存在し、上記のすべての行に対応していること。作成したすべてのコンセプトで、従来の timestamp ではなく generated を使用していること。spec/types.md と spec/conventions.md がこのプロジェクトについて記述していること。該当する場合は、複数バンドルのカタログが更新されていること。

4. 検証する

利用可能であれば kb-lint を実行します。利用できない場合は、kb（SPEC §11 — 唯一の必須ルール）に従って、バンドルが準拠していることを確認します。

完了条件： 準拠エラーが0件であること。

5. 引き継ぐ

バンドルの準備が整ったことと、その場所をユーザーに伝えます。コードベースのバンドルの場合は kb-document に引き継ぎ、それ以外の場合は kb-ingest に引き継ぎます。どちらの場合も、結果に基づいて kb-query が回答します。このプロジェクトで CLAUDE.md／AGENTS.md を使用している場合は、関連する作業の前にエージェントがバンドルのルート index.md を読むよう、1行の参照を追加することを提案します。合意なしに追加してはいけません。