mcpField
D
durable-docs-update

durable-docs-update

github.com/preetamnath開発445 回インストール3 週間前に更新
リポジトリ

durable-docs-update について

durable-docs-update は、コードコメントと継続的なドキュメントを保守するエージェント向けのワークフロースキルです。事実を残す価値を判断してから、適切な記載先を選びます。

主な機能

  1. 01コメントと事実を順に評価
  2. 02指定モードで変更範囲を特定
  3. 03事実の正式な記載先を選択
  4. 04信頼度に基づき変更案を選別
  5. 05ドキュメント間の整合性を確認

活用シーン

  1. 01古い、または価値の低いコメントの削除
  2. 02安定した動作を適切なガイドに記載
  3. 03コミット範囲に伴う文書影響の確認

インストール

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

$npx skills add https://github.com/preetamnath/agent-skills --skill durable-docs-update

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

詳細

ドキュメントの継続的な更新

次の2つの判断を順番に行います。

判断質問「いいえ」の場合
スイープこのコメントは存在すべきですか?コメントを削除します。
ドキュメントの見直しこの事実は現在のガイダンスに含めるべきですか?その事実を削除します。

呼び出し元は、このスキルをインラインで呼び出します。リーフサブエージェントとして呼び出すことはありません。

入力

次のいずれかのモードでスコープを確定します。

モード使用する場合スコープと変更内容
A — セッション作業中のセッションで直接実行する場合。このエージェントが作成または編集したファイル。Edit/Write の履歴、現在の状態、セッションで得た知識を使用します。
B — 範囲コミット範囲 A..B がある場合。git diff --name-only A..B のファイル名を使用し、git diff A..B の内容を使用します。
C — 呼び出し元指定オーケストレーターが未コミットの編集を委任した場合。明示されたファイル一覧と、git diff -- <those files> を使用します。

スコープの確定に git status を使用してはいけません。作業ツリーはプロセス全体で共有されます。モード C では、呼び出し元が指定したファイルのみを使用します。

任意の入力:

  • discoveries — 呼び出し元の Discovery: 箇条書き。すでに注意点や依存関係に絞り込まれています。
  • context — 作業の目標と基準。
  • spec — 作業の spec.md。ステップ 2 で確定済みの D-NNN-XX の決定事項を抽出します。

プロトコル

ステップ 1 — スコープと規模の確定

モードを確定し、対象となる変更済みファイルの一覧を作成して、各ファイルを1回ずつ数えます。この数を使って、調査と適用の各パスで使用できるサブエージェントの上限を定めます。

ティア対象ファイル数パスごとのサブエージェント数
小規模1–3最大1
中規模4–8最大2
大規模9+最大3

ファイル同士の結びつきが強い場合は、サブエージェントを減らします。ファイルを最も近い親の AGENTS.md ごとにグループ化し、対象ファイルをそれぞれ1つの調査サブエージェントにのみ割り当てます。対象ファイルがない場合は、ステップ 5 の変更なしレポートに進みます。

  • 概要。 各調査サブエージェントには、担当ファイル、対象の差分または現在の内容、該当する調査結果、確定済みの決定事項、作業のコンテキストを渡します。
  • Git の安全性。 サブエージェントの Git 読み取りと変更は、担当ファイルのみに限定します。サブエージェントに git stash、git checkout -- .、git reset、その他のツリー全体に対する変更を実行させてはいけません。
  • 調査の境界。 調査サブエージェントは変更を加えません。
  • ベースライン。 コミット済みのベースラインは git show HEAD:<path> で読み取ります。
ステップ 2 — 発見、判断、配置

各発見サブエージェントは Skill ツールを呼び出して vet-fact と place-fact を読み込み、割り当てられたファイルと直接関連するガイダンスを調べます。変更されたコードファイルに候補となるコメントが含まれている場合に限り、そのファイル全体を読みます。リポジトリ全体を読むことは決してありません。

ファイル全体を読んでも、対象範囲が広がるわけではありません。変更されたコード内にあるコメント、変更されたコードを規定するコメント、または引き継がれた発見や判断で指定されたコメントのみを検討します。呼び出し元が明示的に対象範囲を広げない限り、テストの区切りコメントや過去の注記を含む、無関係なコメントには手を加えません。

関連するソースのみを調べます。

  • ファイルのコメント、祖先ディレクトリにある AGENTS.md ファイル、およびファイルに一致する引用符付きの paths: グロブを持つ .claude/rules/ 内の Claude パスルール。

  • 変更の目的がそのルートに一致する場合に限り、ルートから振り分けられるタスク文書。

  • place-fact が選択したターゲット。モジュールをまたぐことだけを理由に文書を選んではいけません。

  • 収集。 コメント、引き継がれた Discovery: の箇条書き、対象範囲内のファイルを制約する確定済みの仕様判断、影響を受ける動作を直接指定する既存のガイダンスから候補を収集します。

  • 統合。 発見内容を、言い換えている判断と統合し、その判断の根拠の文言を保持します。

  • 除外。 現在の状態を示す文書、日付付き調査、セッションログ、引き継ぎ文書、プロセス/ワークフロー文書、.agents/skills/、.claude/skills/、.claude/commands/、および無関係な資料は除外します。

  • デザインリファレンス:

    • ユーザー向け UI に影響する対象範囲内の作業では、該当する画面と、存在する場合は meta/DESIGN.md の Maintenance を調べます。
    • 安定したルールが変わる場合、重大な欠落や矛盾が生じる場合、または一覧にある更新トリガーに該当する場合に限り、更新を提案します。通常の CSS やコンポーネントの変更は該当しません。

各候補について、PLACE の前に WORTH を適用します。

  1. vet-fact を使い、その事実を残すべきか判断します。現在のコードと矛盾するコメントは UPDATE となり、WORTH を満たさないコメントは DELETE となります。
  2. 残す各事実に place-fact を適用し、正規の管理元と提供範囲を選びます。
  3. 提案する変更を分類します。不足している事実は ADD、古い事実または不明瞭な事実は UPDATE、事実を保ったまま履歴や冗長部分を削る場合は TRIM、正規の管理元に属さなくなった事実は DELETE、事実を正規の管理元に移す場合は MOVE とします。TRIM では有効な Discovered: の鮮度スタンプを保持します。
  4. 事実、操作、ターゲットのすべてが正しいという確信度を 0.00–1.00 で採点します。

事実を示す ID の横に D-NNN-XX または AC-NNN-XX の ID を記載します。事実を不明瞭にするタスク ID、ウェーブ番号、F-NNN-XX の指摘 ID は削除します。提案は { source: file:line | input, current_text, fact, action, target, proposed_change, confidence } として返します。候補の現在のテキスト以外は、ファイルの内容を返しません。

ステップ 3 — 統合、判定、割り当て

メインエージェントは発見結果を統合し、事実と正規のターゲットに基づいて重複を除き、最も確信度の高いものを残します。割り当てる前に、配置の競合を解決します。

  • 判定。 確信度が ≥ 0.80 の提案はすべて採用し、それ未満の提案は、ソースや操作にかかわらず、確認を求めずにすべて除外します。除外したコメントに関する提案は、ステップ 5 の left alone, unsure の報告用にのみ保持します。
  • デザインリファレンスのルート。 meta/DESIGN.md をターゲットとする提案が採用された場合、メインエージェントは該当する画面、対象範囲内のファイルまたは差分、採用された事実を指定して Skill ツールから map-design-language スキルを一度呼び出します。この提案はアプリケーション担当サブエージェントには割り当てません。このスキルは影響を受けるセクションのみを更新します。

その他の採用された提案はすべて、ステップ 1 のサブエージェント上限内でターゲットファイルごとにグループ化します。各ターゲットファイルは、アプリケーション担当サブエージェント 1 つだけに割り当てます。MOVE の移動元と移動先の両方は、同じサブエージェントに割り当てます。その他の提案が残らず、map-design-language もファイルを変更しなかった場合は、ステップ 5 に進みます。

ステップ 4 — 適用、調整、一貫性の確認

各適用サブエージェントに、承認済みの提案とステップ 1 の Git 安全ルールをそのまま渡します。各サブエージェントは次を行います。

  1. テキストを調整する前に、割り当てられた提案をすべて適用します。
  2. 作成または大幅に調整したすべての指示ドキュメントについて、Skill ツールを使って compress-file スキルを呼び出します。変更によってセクションの追加、削除、移動が行われる場合、または 3 つ以上のセクションにまたがる場合、そのドキュメントは大幅に調整されたものとします。
  3. この実行で変更したコメントと指示のみを対象に、Skill ツールを使って tighten-instruction スキルを呼び出し、続けて structure-prose スキルを呼び出します。
  4. 独立したレンズによる編集すべてに 0.00–1.00 のスコアを付け、c ≥ 0.80 なら適用し、それ未満なら保留します。
  5. ファイルごとに 1 行、コメントの集計(corrected、deleted、tightened)、削除したコメントの詳細を { file, line, text, confidence } の形式で返します。

すべての適用サブエージェントからの返答後、メインエージェントは次を行います。

  1. 変更された永続ドキュメントをそれぞれ 1 回ずつ数えます。該当するものがなければ、一貫性確認サブエージェントを省略します。該当するものがあれば、サブエージェント数の上限を決めるためにステップ 1 の区分を適用します。
  2. 新たな一貫性確認サブエージェントを上限数まで起動し、関連するドキュメントをグループ化して、各ドキュメントを 1 つのサブエージェントだけに割り当てます。
  3. すべての一貫性確認サブエージェントに、ステップ 1 の Git 安全ルールを渡します。

各一貫性確認サブエージェントは、割り当てられた各ドキュメントに対して個別に、Skill ツールを使って check-coherence スキルを呼び出します。

すべての一貫性確認サブエージェントからの返答後、メインエージェントは最終的な統合差分に承認済みの提案がすべて適用され、無関係な変更が含まれていないことを確認します。

ステップ 5 — 報告

呼び出し元は、この報告を繰り返しません。

**Docs sync:**
- Comments: [n] corrected, [m] deleted, [k] tightened
  - deleted: [file:line — "text" (0.NN), one per line | none]
  - left alone, unsure: [file:line — "text" (0.NN), one per line | none]
- Docs: [file — what changed, one per line | none needed]
- Dropped: [K] candidates below 0.80
- Instruction delta: [net lines], [artifacts added], [artifacts removed], [always-loaded lines]; review signal only, never a quota

コメント