mcpField
S
ssot

ssot

github.com/venhdevドキュメント1140 回インストール今日更新
リポジトリ

ssot について

ソフトウェアリポジトリの文書を管理するスキルで、検索、監査、承認済みの更新を支援します。概念ごとの権威ある文書を一つに定め、変更を段階化してリンクを検証します。

主な機能

  1. 01概念ごとに単一の権威文書を指定
  2. 02読み取り専用の文書検索と監査
  3. 034種類の操作による変更計画
  4. 04編集前の承認範囲確認
  5. 05Markdownリンクとアンカーの検証

活用シーン

  1. 01重複または矛盾する文書の監査
  2. 02規則の権威ある記載場所の特定
  3. 03承認範囲内での文書移動や更新

インストール

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

$npx skills add https://github.com/venhdev/zenforge --skill ssot

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

同梱ファイルreferences/document-contract.mdscripts/discover-docs.sh

詳細

ssot — 信頼できる唯一の情報源とドキュメント管理者

運用上の不変条件

  • 権威性の根拠：各ルール、契約、概念について、権威ある所有者を必ず1つだけ維持し、文書間で重複する権威や競合する権威を禁止します。フォルダーパスやファイルのメタデータは根拠として扱いますが、権威性の証明とはみなしません。
  • 読み取り専用の調査規律：検索、ナビゲーション、監査のみを求める依頼では、権威あるファイル、セクション、調査結果を確認して報告し、その間はドキュメントを変更しません。
  • スコープの規律：承認されたドキュメントファイルのみを、リポジトリ相対の POSIX リンクを使って編集、移動、整理します。コードベースの変更、ホストの絶対パス、file:/// URI は禁止します。
  • 変更前のゲート：ドキュメントの変更は Changeset 形式（[CREATE]、[UPDATE]、[MOVE]、[DELETE]）で準備します。具体的なスコープに承認がない場合は編集前に停止し、すでに得られている承認は尊重します。

ドメインの分類基準

予定しているドキュメント操作はすべて、次の4つの基本アクションのうち、必ず1つだけに分類します。

  • [CREATE]：新たな規範仕様、ADR、スキーマ、または配置マップ（docs/README.md）を作成します。
  • [UPDATE]：事実に関する不足を修正する、既存の所有者ドキュメントに簡潔な用語を追加する、またはフロントマターのメタデータ（updated: YYYY-MM-DD）を更新します。
  • [MOVE]：長期的に維持するコンテンツを指定された規範上の所有者へ移動し、ローカルで読む際に上流の文脈が必要な場合に限り、直接のアンカーリンク（[Doc § N.N](path#anchor)）に置き換えます。
  • [DELETE]：規範上の所有者への統合後に元の重複コンテンツを整理するか、独立した価値がまったくない古いドキュメントを削除します。

実行プロトコル

フェーズ1：調査と権威性の監査

  1. インデックスの最短経路：リポジトリのドキュメントインデックス（docs/README.md または README.md）を確認し、配置マトリックスがすでに存在するか調べます。ライフサイクルの分類と推奨ディレクトリのテンプレートについては、ローカルの references/document-contract.md を参照します。

  2. 詳細監査へのフォールバック：インデックスが存在しない場合、またはスコープが広い場合は、ローカルのインベントリースキャナーを実行します。

    bash scripts/discover-docs.sh <path_to_repository>

  3. 読み取り専用での終了：依頼が検索または監査のみの場合、ポインター付きの引用（file:///path#L1-L20）とともに権威ある場所を報告し、そのターンを直ちに終了します。

  4. 矛盾のエスカレーションゲート：仕様が矛盾している場合、または規範上の権威が曖昧な場合：

    • 人間の指示を仰ぐため、直ちにターンを終了します。
    • ポインター付きの引用（[Doc A:L12] と [Doc B:L40]）を用いて、矛盾する根拠を報告します。
    • 解決策を提示し、変更の準備に進む前に人間からの明示的な指示を待ちます。
フェーズ2：変更の準備と承認ゲート

  1. 予定している変更を Changeset 形式で準備します。

    # Changeset: SSOT Documentation Governance (<Target Scope>) [(<optional_docs_root>/)]

|-- docs/<collapsed_subsystem_dir>/
|   |-- <document_1>.md
|   |   `-- [<ACTION>] <Specification or canonical update>.
|   `-- <document_2>.md
|       `-- [<ACTION>] <Reconciliation or duplicate pruning>:
|           * <Specific document authority or section update>.
`-- docs/<deep/path/to/canonical_spec.md>
    `-- [<ACTION>] <Direct leaf spec without redundant folder node>.

Summary: <N> files affected (<C> created, <U> updated, <M> moved, <D> deleted).

  2. 要点を絞った Changeset の概要と技術的な根拠を提示します。生のドキュメント差分はチャットに含めません。

  3. 準備したスコープに承認がない場合は、ドキュメントの変更前に停止します。具体的なスコープがすでに承認されている場合は、適用に進みます。

フェーズ3：適用とリンクの検証
  1. 承認を受けたら、ディスク上の変更を適用します（[DELETE] より先に [CREATE] と [MOVE] を完了します）。
  2. 有効なドキュメント契約に従い、意味のある内容変更またはライフサイクルの変更がある場合に限り、updated: YYYY-MM-DD を更新します。
  3. Markdown リンクの解決とアンカーの有効性を検証します。
  4. 承認されたスコープ内でリンクとアンカーの不備を修正し、再検証します。解決に新たな権威性の判断、スコープの拡大、または利用できない検証手段が必要な場合は、根拠と変更内容を保持したうえで UNRESOLVED と報告し、当初のスコープ外の再設計は行いません。

コメント

Markdown 対応