mcpField
L
ln-611-docs-structure-auditor

ln-611-docs-structure-auditor

github.com/levnikolaevichドキュメント584256 回インストール2 日前に更新
リポジトリ

ln-611-docs-structure-auditor について

ln-611-docs-structure-auditorは、プロジェクト文書の構造を評価するスキルです。Markdownファイルを走査し、AGENTS.mdまたはCLAUDE.mdから階層を構築して、重要度付きの指摘と適合スコアを返します。

主な機能

  1. 01プロジェクトのMarkdownを走査
  2. 02文書階層を構築
  3. 038つの構造カテゴリを確認
  4. 04場所と推奨事項を報告
  5. 05適合スコアを算出

活用シーン

  1. 01プロジェクト文書の構成確認
  2. 02リンク切れや孤立した文書の検出
  3. 03文書の鮮度と技術スタック適合性の確認
  4. 04CLAUDE.mdの指示重複の検出

インストール

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

$npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-611-docs-structure-auditor

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

同梱ファイル

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

references/
agent_instructions_writing_guide.md
audit_checklist.md
audit_scoring.md
audit_summary_contract.md
audit_worker_core_contract.md
docs_quality_contract.md
docs_quality_rules.json
docs_quality_rules.json.SOURCE.md
markdown_read_protocol.md
mcp_integration_patterns.md
mcp_tool_preferences.md
size_limits.md
references/templates/
audit_worker_report_template.md

詳細

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

ドキュメント構造監査担当（L3 ワーカー）

タイプ： L3 ワーカー

プロジェクトドキュメントの構造品質を監査する専門ワーカーです。

目的と範囲

  • 8 つのカテゴリにわたって、ドキュメントの構造品質を監査します
  • プロジェクト内のすべての .md ファイルをスキャンし、AGENTS.md がある場合はそこから階層を構築します
  • 重大度、場所、推奨事項を含む、構造化された指摘事項をコーディネーターに返します
  • ドキュメント構造の適合スコア（X/10）を算出します

入力

必須の読み込み： references/audit_worker_core_contract.md、references/docs_quality_contract.md、references/markdown_read_protocol.md、references/mcp_tool_preferences.md を読み込みます。 ルールカタログは任意です。正確なルール ID、パスマトリクス、または許可リストに登録されたプレースホルダーの例外が必要な場合に限り、references/docs_quality_rules.json を読み込みます。 ツールポリシー：ホストの AGENTS.md が対象範囲外となる独立したサブエージェントとして実行される場合があるため、ファイルの読み込み、検索、編集にはまず hex-line MCP を使用します。MCP の動作が不明な場合に限り、references/mcp_integration_patterns.md を読み込みます。

tech_stack、project_root、output_dir を含む contextStore を受け取ります。

このドキュメント専用ワーカーでは、hex-line は任意です。利用できる場合は、大きな Markdown のアウトラインや対象を絞った読み込みを効率化するために使用します。利用できない場合は、組み込みの Read/Grep/Glob/Bash を使用して続行します。

ワークフロー

  1. コンテキストを解析： contextStore から技術スタック、プロジェクトルート、output_dir を抽出します
  2. レジストリがあれば読み込む： 利用可能な場合は、最初の振り分け元として docs/project/.context/doc_registry.json を使用します
  3. ドキュメントをスキャン： プロジェクト内のすべての .md ファイルを検索します（AGENTS.md、CLAUDE.md、README.md、docs/**）
  4. セクションを優先して読み込む： 大きなドキュメントは、まずアウトラインを確認し、その後、見出しマーカー、Quick Navigation、Agent Entry、Maintenance を読み込みます
  5. ツリーを構築： AGENTS.md がある場合は、その外部リンクから階層を構築します。ない場合は CLAUDE.md から構築します
  6. 監査カテゴリ 1～7： 構造チェックを実施します（下記の監査カテゴリを参照）
  7. 指摘事項を収集： 各違反について、重大度、場所（file:line）、作業量の見積もり（S/M/L）、推奨事項を記録します
  8. スコアを算出： 重大度別に違反件数を数え、適合スコア（X/10）を算出します
  9. レポートを作成： references/templates/audit_worker_report_template.md に従って完全な Markdown レポートを作成し、単一の Write 呼び出しで {output_dir}/611-structure.md に書き込みます
  10. 概要を返す： 最小限の概要をコーディネーターに返します（出力形式を参照）

監査カテゴリ

#カテゴリ確認項目
1階層とリンクAGENTS.md が存在する場合は正規のルートとして扱うこと。すべてのドキュメントにリンクからアクセスできること。孤立したファイルがないこと。リンク切れがないこと
2信頼できる唯一の情報源内容が重複していないこと。重複箇所は情報源へのリンクに置き換えること。所有者が明確であること
3積極的な簡潔化冗長な内容や重複する内容を排除すること。文章を表にすること。意味のない情報を削除すること。上限未満のファイルも簡潔化すること。size_limits.md を参照
4要件への準拠ヘッダーマーカーが正しいこと。先頭のセクションが正しいこと。サイズ制限内であること。許可されていないコードブロックがないこと。技術スタックに適したドキュメントリンクであること
5鮮度の指標古さを示すシグナルを検出します。コンテンツ内の日付が6か月以上前であること、サポートされていない API／ツールへの言及、TODO／FIXME マーカー、プレースホルダーテキストが残っていること。詳細な事実確認は専任のワーカーが担当します
6レガシーの整理履歴セクションがないこと。「変更された」といった注記がないこと。サポートされていない情報がないこと。現状のみを記載していること
7技術スタックへの適合リンク／参照がプロジェクトの技術スタックに合っていること。.NET プロジェクトに Python の例がないこと。適切なプラットフォームの公式ドキュメントを参照していること
8インポートパターンへの準拠リポジトリのルートに AGENTS.md が存在する場合、CLAUDE.md には @AGENTS.md の行がちょうど1つ含まれ、ハーネス固有の差分は上限が設定されていること（合計≤50行）。CLAUDE.md 内で AGENTS.md の内容と重複するものはすべてドリフトです。理由については references/agent_instructions_writing_guide.md を参照
重大度の対応表
問題の種類重大度
鮮度の指標（古い日付、サポートされていない参照、TODO マーカー）MEDIUM
リンク切れ、孤立したドキュメントHIGH
内容の重複MEDIUM
簡潔化できる箇所の見落としLOW
レガシー／履歴コンテンツMEDIUM
誤った技術スタックの参照HIGH
インポートパターンのドリフト（CLAUDE.md 内で重複している AGENTS.md の内容、サイズ超過のスタブ、@AGENTS.md 行の欠落）HIGH

スコアリングアルゴリズム

必読： references/audit_scoring.md を読み込んでください。

出力形式

必読： references/templates/audit_worker_report_template.md を読み込んでください。

references/audit_summary_contract.md に従って JSON サマリーを作成してください。管理モードでは呼び出し元が runId と summaryArtifactPath の両方を渡します。スタンドアロンモードでは、共有コントラクトに従ってワーカーが実行スコープのアーティファクトパスを生成します。

{output_dir}/611-structure.md に category: "Documentation Structure" と次のチェック項目を含むレポートを作成してください：hierarchy_links、ssot、compression、requirements_compliance、freshness_indicators、legacy_cleanup、stack_adaptation、import_pattern_compliance。

references/audit_summary_contract.md に従ってサマリーを返してください。

スタンドアロンモードでも、共有コントラクトに従ってワーカーが所有する実行スコープのアーティファクトパスに、同じ JSON サマリーを作成します。

重要なルール

すでに読み込まれている references/audit_worker_core_contract.md を適用してください。

  • 自動修正しないでください： 違反のみを報告してください。コーディネーターがユーザー向けに集約します
  • 技術スタックを考慮してください： tech_stack の contextStore を使用して、技術スタック固有のチェックを適用してください（例：.NET と Node.js のドキュメント標準の違い）
  • 詳細な事実確認は行わないでください： 鮮度を示すシグナル（日付、サポートされていない参照、TODO マーカー）のみを検出してください
  • 常に簡潔化してください： サイズ制限は上限であり、目標ではありません。300行ではなく100行のファイルにすることには価値があります
  • ドキュメントにコードを書かないでください： ドキュメントでは、アルゴリズムを表や ASCII 図で説明します。コードはコードベースに記述してください
  • コードが真実です： ドキュメントとコードに矛盾がある場合、コードではなく、更新が必要なドキュメントとして報告してください
  • アーカイブではなく削除してください： レガシーコンテンツは「archive」に移動せず、削除してください
  • 場所を正確に示してください： プログラムから移動できるように、常に file:line を記載してください
  • 共有コントラクトを優先してください： プレースホルダーポリシー、テンプレートメタデータポリシー、コードを含めない例外は、docs_quality_contract.md／docs_quality_rules.json に従ってください

完了の定義

読み込み済みの references/audit_worker_core_contract.md を適用します。

  • contextStore を正常に解析した（output_dir を含む）
  • 8 つの構造カテゴリをすべて監査した
  • 重要度、場所、作業量、推奨事項を含む指摘事項を収集した
  • ペナルティアルゴリズムを使用してスコアを計算した
  • {output_dir}/611-structure.md にレポートを書き込んだ（1 回の Write 呼び出しでアトミックに実行）
  • コントラクトに従って概要を書き込んだ

参照ファイル

バージョン： 1.0.0 最終更新日： 2026-03-01

コメント

Markdown 対応