mcpField
K
kb-creator

kb-creator

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

kb-creator について

kb-creator は、既存資料または対話をもとに、プロジェクト向けの構造化されたナレッジベースを作成するスキルです。docs/ と knowledge-base/ の状態に応じて、資料取り込みか対話型の手順を選び、所定のファイル群を生成します。

主な機能

  1. 01資料取り込みと新規作成を自動判定
  2. 02docs/ の資料を標準構成のナレッジベースに整理
  3. 03戦略的な質問で新規文書作成を支援
  4. 04標準の10ファイルと索引 README を作成

活用シーン

  1. 01長いプロジェクト文書をテーマ別に整理
  2. 02既存の docs/ からプロジェクト情報をまとめる
  3. 03目標、アーキテクチャ、未解決事項を一から整理

インストール

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

$npx skills add https://github.com/juancruzrobledo/kb-creator --skill kb-creator

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
assets/
strategic-questions.md
state-contract.md
canonical-templates.md

詳細

使用するタイミング

  • プロジェクト向けに、構造化されていて閲覧しやすいナレッジベースを生成します。
  • モノリシックなドキュメント(.txt、.docx、.pdf、長い .md)をテーマ別の KB に変換します。
  • 戦略的パートナーとしてユーザーに伴走し、システムをゼロからドキュメント化します。

使用しない場合:

  • knowledge-base/ がすでに存在し、必須の 10 ファイルがすべてそろっている場合(代わりに個別のファイルの更新を提案してください)。
  • ユーザーが特定のドキュメントを 1 つ求めている場合(これは個別ファイルではなく、KB 全体を扱うスキルです)。

動作モード

このスキルは、開始時にモードを自動検出します。

モード A — 既存のソースドキュメントを使用(サイレント)

自動トリガー:docs/ フォルダーが存在し、ソースファイル(.txt、.docx、.pdf、または README 以外の .md)が含まれている場合。

動作:docs/ 内のすべてのソースを読み取り、分析して、プロジェクトのルートにある knowledge-base/ に正規 KB 全体を質問せずに生成します。実行後は何も求めません。

モード B — ゼロから作成(対話型)

自動トリガー:docs/ フォルダーが存在しない、空である、または README しか含まれておらず、ルートに knowledge-base/ が存在しない場合。 明示的なトリガー:ユーザーが「ゼロから始めましょう」「KB を作りましょう」「既存のドキュメントはありません」と言った場合。

動作:戦略的パートナーとして、コンテキストを分析し、不足事項を特定して、戦略的な質問を 3~5 個行い、長所と短所を含むアプローチを提案します。その後、ファイルごとに検証しながら反復します。


重要なパターン

出力先(両モード共通)

KB のすべてのファイルは、プロジェクトのルートにある knowledge-base/ に配置します。ソースドキュメントを含む docs/ と決して混在させないでください。

正規ファイル(必須の 10 ファイル)

KB には、以下の 10 ファイルを指定された名前で必ず含めてください。

#ファイル内容
0101_vision_y_objetivos.md目的、アクター別の目標、スコープ、対象外
0202_descripcion_general.md技術スタック、全体アーキテクチャ、外部連携
0303_actores_y_roles.mdシステムのアクター、RBAC テーブル、権限、公開ルート
0404_modelo_de_datos.mdエンティティ、ERD、リレーション、シードデータ
0505_reglas_de_negocio.mdドメイン別にコード化されたルール(RN-XX 形式のコードを使用)
0606_funcionalidades.mdエピック別に整理したユーザーストーリー/機能
0707_flujos_principales.mdエンドツーエンドのフロー(認証、主要ドメインなど)
0808_arquitectura_propuesta.mdパターン、ディレクトリー構成、セキュリティ、環境変数
0909_decisiones_y_supuestos.md文書化された設計判断+推定した前提
1010_preguntas_abiertas.md検出した不整合+優先順位を付けた未解決の質問

さらに、knowledge-base/README.md に目次となる README.md を追加します。

各ファイルに想定される内部構成については、assets/canonical-templates.md を参照してください。

追加ファイル(任意)

ドメインに応じて、1X_ または 2X_ を接頭辞とし、kebab-case の名前を付けた追加ファイルを作成できます。例:

  • 11_pagos_mercadopago.md(特定の決済ゲートウェイを使用する e コマース)
  • 12_devops_y_despliegue.md(複雑なインフラを持つプロジェクト)
  • 13_observabilidad.md(高度なテレメトリーを備えたシステム)

追加ファイルが正規の 10 ファイルの代わりになることはありません。あくまで補完するものです。

Mode A のワークフロー(サイレント)

Mode A → source: "ingest"(下記の State integration を参照)

  1. glob docs/*.{txt,docx,pdf,md} — ソースを列挙します(README は除外)。
  2. すべてのソースを読みます。
  3. 各カノニカルファイルについて、ソースから関連する内容を抽出し、assets/canonical-templates.md に従って構成します。
  4. ソースが追加のドメイン(例:特定の PSP を使った決済)を扱っている場合は、追加ファイル 1X_*.md を作成します。
  5. 10 個のカノニカルファイルと追加ファイル、および README.md を作成します。
  6. 最後に、ファイル → 行数 → 対象トピック の要約表を作成します。
  7. オーケストレーション実行時:生成したドキュメントから 6 つの discovery フィールドを推定し、状態フックを実行します(assets/state-contract.md §4 を参照)。ソースは "ingest" です。

このモードでは質問しないでください。 ソースが曖昧な場合は、疑問点を 10_preguntas_abiertas.md に記録して続行します。discovery フィールドを確信を持って推定できない場合は、不確実性を 10_preguntas_abiertas.md に記録します。値を捏造してはいけません。

Mode B のワークフロー(対話型)

Mode B → source: "interactive"(下記の State integration を参照)

  1. 利用可能なコンテキスト(リポジトリ名、ユーザーメッセージ、表示可能なファイル)を分析します。
  2. プロジェクトについて理解した内容を 1 段落で要約します。
  3. 主な不確実性を 3~5 個挙げます。
  4. 初期アプローチを 2~3 個、それぞれの長所と短所とともに提案します。
  5. system_type と scale に対応する discovery の P0-sys と P0-scale の質問を含め、戦略的な質問を 3~5 個行います(assets/strategic-questions.md を参照)。
  6. ファイルを生成する前に、ユーザーの回答を待ちます。
  7. その後、KB の初期構成を提案し、確認します。
  8. ファイルごとに作業を進め、ファイルを書いてフィードバックを求めます。
  9. オーケストレーション実行時:ユーザーの回答から 6 つの discovery フィールドを記録し、状態フックを実行します(assets/state-contract.md §4 を参照)。ソースは "interactive" です。
モードに応じたトーン
  • Mode A:効率的かつ事実に基づき、簡潔にします。
  • Mode B:シニアアーキテクト兼プロダクトマネージャーとして対応します。根拠の弱い判断には疑問を呈します。前提には **仮定:** と明記します。代替案を提案し、リスクを見つけます。

State integration(オーケストレーション実行時)

このフックは条件付きで、単独実行にも対応しています。.jr-orchestrator-state.json` がプロジェクトのルートにすでに存在する場合(jr-orchestrator によるオーケストレーション実行時)にのみ実行します。ファイルが存在しない場合、動作はこれまでと同じで、状態ファイルは作成されません。

実行タイミング:knowledge-base/ の書き込み直後(ユーザーに戻す前のワークフロー最終ステップ)。

書き込む内容:state.kb のみです。step、owner、roadmap、skills、agents には一切触れません。

Mode → source の対応:

モードstate.kb.source
Mode A(サイレント、docs/ から)"ingest"
Mode B(対話型、ゼロから)"interactive"
複合実行の場合:実行が docs/ から開始された場合(Mode A のトリガー)、質問によって不足箇所が補われていても "ingest" とします。実行の主な起点によって source を決定します。

完全なアルゴリズム、Mode A の推定ルール、信頼度が低い場合のルール:assets/state-contract.md を参照してください。


コード例

Mode A:終了時の要約表
## KB generada en knowledge-base/

| Archivo | Líneas | Temas cubiertos |
|---------|--------|-----------------|
| 01_vision_y_objetivos.md | 84 | Propósito, 3 actores, alcance v5.0 |
| 02_descripcion_general.md | 132 | FastAPI + React, REST, 14 endpoints |
| ...
Mode B:戦略的な質問の例
**Pregunta 2 de 4 — Alcance del MVP**

¿Cuál es el alcance MÍNIMO viable para considerar el sistema "lanzable"?

- (a) Solo flujo de compra (catálogo + carrito + checkout simulado).
- (b) Flujo completo con pago real integrado.
- (c) Pago + panel admin con métricas.

**Por qué importa**: define qué entra en la primera versión y qué se posterga. Una respuesta vaga acá te genera scope creep en sprint 2.

コマンド

# Instalar la skill
npx skills add https://github.com/JuanCruzRobledo/kb-creator

# Invocar en el agente (carga automática por contexto):
"crear base de conocimiento del proyecto"
"generar KB desde los docs"
"armemos la documentación desde cero"

リソース

  • テンプレート:assets/canonical-templates.md を参照してください。10 個のカノニカルファイルに期待される内部構成が記載されています。
  • 戦略的な質問:assets/strategic-questions.md を参照してください。Mode B 用の質問集です(オーケストレーション実行時の discovery に使う P0-sys と P0-scale を含みます)。
  • State contract:assets/state-contract.md を参照してください。state.kb のスキーマ部分、条件付き書き込みアルゴリズム、Mode A の推定ルール、信頼度が低い場合のルールが記載されています。

コメント