knowledge-base-add-project について
ナレッジベースリポジトリへの上流プロジェクトの追加と、既存項目の更新を行うワークフロー向けスキルです。文書作成、索引更新、冪等な変更のコミット手順を案内します。
主な機能
- 01プロジェクトとカテゴリの追加
- 02既存項目の更新
- 03文書とメタデータ仕様への準拠
- 04追跡対象プロジェクト索引の更新
- 05冪等で範囲を絞った変更
活用シーン
- 01新しい上流リポジトリの記録
- 02定期的なプロジェクト保守
- 03リリースや変更された API 文書の更新
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ mmontes11/ skills --skill knowledge-base-add-projectインストール後、Claude Code で/knowledge-base-add-projectを入力して読み込まれたか確認します。
詳細
ナレッジベースへのプロジェクトの追加または更新
新しい上流プロジェクトを projects/<category>/<project>/ に追加するか、既存のプロジェクトを更新します。ナレッジベースのルートにある
README.md が基準となります。Standard documents セクションは各固定ファイルに含める内容の正式な仕様であり、Metadata セクションはフロントマターを定義し、Tracked projects テーブルは索引です。このスキルはワークフローであり、これらの仕様を繰り返すのではなく、エントリーを冪等に作成および更新する方法を説明します。
ナレッジベースの場所
ナレッジベースのリポジトリ内で作業します。標準のローカルチェックアウト先は ~/code/knowledge-base です。存在しない場合は、git clone [email protected]:mmontes11/knowledge-base.git ~/code/knowledge-base を実行します。以下のすべてのパスは、リポジトリのルートからの相対パスです。
2 つのモード
- 追加 — 上流から新しいプロジェクトフォルダーを作成します(新しいカテゴリの追加も任意)。
- 更新 — 既存プロジェクト 1 件を冪等にメンテナンスします。月次の 更新スケジュールが実行するのはこのモードです。
モード A — プロジェクトを追加する
- 対象カテゴリの
projects/<category>/README.mdと、ルートREADME.mdの Standard documents および Metadata セクションを読みます。 - カテゴリ(既存のもの、または先に新規作成するもの。下記参照)と、プロジェクトのスラッグ(上流リポジトリ名を小文字のケバブケースにしたもの)を選びます。
projects/<category>/<project>/を作成し、上流から取得した情報を使って、ルートREADME.mdの仕様に沿った必須の標準ドキュメント 4 つを作成します。- 必須の 4 ファイルは
README.md、api-reference.md、releases.md、features.mdです。 architecture.mdは、プロジェクトが複雑な複数コンポーネントシステムである場合に限り作成します。作業を終える前に、すべての mermaid 図をレンダリングします。mermaid-render /tmp/d.mmd # SVG/PNG が正しく生成され、空でなければ、そのブロックは GitHub でレンダリングされます
- 必須の 4 ファイルは
- 各ドキュメントのフロントマターに
upstream(正規のリポジトリ URL)とlast_updated(UTC 日付)を記載します。 - コピーせずリンクする — 事実に関する記述にはすべて上流の出典へのリンクを付けます。スキーマ、仕様、生成されたダンプ全体をそのまま含めてはいけません。
- ルート
README.mdの Tracked projects テーブルに行を追加します。 docs(<category>/<project>): <summary>というコミットメッセージでコミットし、mainに直接プッシュします。
カテゴリを追加する
projects/<category>/README.mdを作成し、そのドメインを簡潔に説明します(名前は小文字のケバブケース)。- 最初のプロジェクトの行を Tracked projects に追加します。
モード B — プロジェクトを更新する(メンテナンス実行)
毎回の実行は冪等でなければなりません。上流の状態に変化がなければ、差分は空になります。対象のプロジェクト 1 件について、次の順序で作業します。
- 現在のフォルダーとフロントマターを読みます。
- 上流の最新情報を取得します。最新のリリースタグ、
releases.mdの最新エントリーより新しいリリース、API/機能ドキュメントの変更を確認します。 releases.md— 新しいエントリーを先頭に追加し、上限 10 件を維持します。api-reference.md— API サーフェスが変更された場合(Kind またはサーフェスの追加、削除、名前変更)に限り更新します。features.md— 機能ドキュメントまたはリリースノートに変更があった場合に限り更新します。architecture.md— ファイルが存在し、コンポーネントの構成または相互作用に変更があった場合に限り更新します。すべての mermaid 図を再レンダリング(mermaid-render)し、現在のコンポーネントを反映していることを確認します。README.md— 説明、ライセンス、または上流 URL が変更された場合に限り更新します。- 変更した各ファイルのフロントマターにある
last_updatedを更新します。 - プロジェクトごとに 1 回コミットします。コミットメッセージは
docs(<category>/<project>): <summary>とします。 mainに直接プッシュします。Multica の issue がこの実行のきっかけとなった場合は、プッシュが完了した時点で完了としてマークします。
品質管理(両モード共通)
- 認証情報、トークン、クラスター固有のデータは一切含めません。
- 要約してリンクし、上流のテキストをそのままコピーしてはいけません(上流のライセンスと帰属表示を尊重します)。
- 事実に関する記述にはすべて、情報元の上流ソースへのリンクを付けます。
- 差分を小さく、説明可能なものに保ちます。1 回の実行につき 1 プロジェクトです。
コメント
Markdown 対応