mcpField
S
ssot

ssot

github.com/venhdev開発1135 回インストール今日更新
リポジトリ

ssot について

ssot は、プロジェクトの正式なドキュメントを監査・管理する開発スキルです。文書の権威性を整理し、許可された変更を準備しながら、コードベースの変更を避けます。

主な機能

  1. 01ドキュメントの権威性を監査
  2. 02編集せずに文書を調査
  3. 03操作種別ごとに変更を準備
  4. 04承認済みファイルだけを編集
  5. 05Markdownのリンクとアンカーを検証

活用シーン

  1. 01ルールの正式な参照元を特定
  2. 02文書内の主張の矛盾を監査
  3. 03許可された文書更新を計画

インストール

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

$npx skills add https://github.com/venhdev/skills --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. 矛盾のエスカレーションゲート：仕様が競合している、または正規の権威が曖昧な場合：

    • ただちにそのターンを終了します。フェーズ2への進行は禁止します。
    • 参照箇所の引用（[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 対応