ln-100-documents-pipeline

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

タイプ： L1 トップオーケストレーター カテゴリ： 1XX ドキュメントパイプライン

ドキュメントパイプライン（オーケストレーター）

このスキルは、1 つの L2 コーディネーターと 3 つの L2 ワーカーを呼び出して、完全なドキュメントシステムの作成をオーケストレーションします。コーディネーター（ln-110）は、プロジェクトドキュメント用に 5 つの L3 ワーカーへ処理を委任します。他の L2 ワーカーは、リファレンス、タスク、テストの各領域を担当します。各コンポーネントは独自の出力を検証し、オーケストレーターは最終的なドキュメント品質の受け入れゲートを担います。

目的

1 回の実行で完全なプロジェクトドキュメントシステムを作成する、最上位のオーケストレーターです。ln-110 コーディネーターと ln-120/130/140 ワーカーを順番に実行し、その後、全体のクリーンアップ（重複排除、孤立ファイルの報告、相互リンクの検証）を実施します。

ランタイム契約

必ず読み込むこと： references/coordinator_runtime_contract.md、references/docs_pipeline_runtime_contract.md、references/docs_generation_summary_contract.md を読み込みます。

ランタイムファミリー：docs-pipeline-runtime

識別子：

• docs-pipeline

フェーズ：

1. PHASE_0_CONFIG
2. PHASE_1_LEGACY_SCAN
3. PHASE_2_CONFIRMATION
4. PHASE_3_DELEGATE
5. PHASE_4_QUALITY_GATE
6. PHASE_5_CLEANUP
7. PHASE_6_SELF_CHECK

コンポーネントサマリー契約：

• ln-110、ln-120、ln-130、ln-140 は docs-generation エンベロープを書き込むか、返します
• ln-100 は、これらのサマリーとドキュメント品質チェックポイントをオーケストレーションの SSOT として使用します

アーキテクチャ

ln-100-documents-pipeline (L1 Top Orchestrator - this skill)
|- ln-110-project-docs-coordinator (L2 Coordinator)
|  |- ln-111-root-docs-creator (L3 Worker) -> 5 docs
|  |- ln-112-project-core-creator (L3 Worker) -> 3 docs
|  |- ln-113-backend-docs-creator (L3 Worker) -> 2 conditional
|  |- ln-114-frontend-docs-creator (L3 Worker) -> 1 conditional
|  `- ln-115-devops-docs-creator (L3 Worker) -> 1 always + 1 conditional
|- ln-120-reference-docs-creator (L2 Worker)
|- ln-130-tasks-docs-creator (L2 Worker)
`- ln-140-test-docs-creator (L2 Worker - optional)

このスキルを使う場面

次の場合に、このスキルを使用します：

• 新しい IT プロジェクトを開始し、一度に完全なドキュメントシステムが必要な場合
• 複数のワーカーを手動で呼び出す代わりに、自動化されたワークフローを使用する場合
• ドキュメント構造全体（AGENTS.md を正規ファイルとし、CLAUDE.md をインポート用スタブとして docs/ に配置）を一度に作成する場合
• スキルを手動で連鎖させる方法より、オーケストレーションされた CREATE パスを優先する場合
• 全体のクリーンアップ（重複排除、孤立ファイルの処理、統合）を自動化する必要がある場合

代替方法：より細かな制御が必要な場合は、ワーカーを手動で呼び出します：

1. ln-110-project-docs-coordinator - ルートおよびプロジェクトドキュメント（5 つの L3 ワーカーを調整）
2. ln-120-reference-docs-creator - reference/ 構造
3. ln-130-tasks-docs-creator - tasks/README.md とカンバン
4. ln-140-test-docs-creator - tests/README.md（任意）

必ず読み込むこと： references/docs_quality_contract.md を読み込みます。

注： 各ワーカーは、フェーズ 2/3 で自身の出力をローカルに検証します。クリーンアップを続行する前に、オーケストレーターは最終的なドキュメント品質マニフェスト、検証、修復ループを引き続き担当します。

ワークフロー

このスキルは 5 フェーズのオーケストレーションワークフローに従います：レガシー移行（任意） -> ユーザー確認 -> コーディネーターとワーカーを順番に実行 -> 全体のクリーンアップ -> サマリー。

---

フェーズ 0：ソースドキュメントの整理（任意）

目的：正規の形式に準拠していないドキュメントを検出し、有用な情報を正規化して、生成前に重複するドキュメントの場所を削除します。

実行条件：リポジトリに正規の構成以外の場所にドキュメントがすでに存在する場合、パイプラインの開始時に実行します。

処理：

0a. 正規の形式に準拠していないソースの検出：

• references/legacy_detection_patterns.md のパターンを使って、プロジェクト内の標準外のドキュメントをスキャンします：
  • ルート直下の .md ファイル：ARCHITECTURE.md、REQUIREMENTS.md、STACK.md、API.md、DATABASE.md、DEPLOYMENT.md
  • 正規の形式に準拠していないフォルダー：documentation/、doc/、wiki/、または構成が正しくない docs/
  • README.md のセクション：## Architecture、## Tech Stack、## Requirements など
  • CONTRIBUTING.md のセクション：## Development、## Code Style、## Coding Standards
• source_manifest を作成します：{ path, detected_type, target_doc, confidence } のリスト
• 正規の形式に準拠していないドキュメントが見つからない場合は、フェーズ 1 に進みます

0b. 情報の抽出：

• 検出された各ソースファイルについて：
  • Markdown の構造（見出し、リスト、コードブロック）を解析します
  • 種類別の抽出処理を適用します（必ず読み込むこと： references/legacy_detection_patterns.md を読み込みます）：
    • architecture_extractor -> { layers[], components[], diagrams[] }
    • requirements_extractor -> { functional[], non_functional[] }
    • tech_stack_extractor -> { frontend, backend, database, versions }
    • principles_extractor -> { principles[], anti_patterns[] }
    • api_spec_extractor -> { endpoints[], authentication }
    • database_schema_extractor -> { tables[], relationships[] }
    • runbook_extractor -> { prerequisites[], install_steps[], env_vars[] }
    • infrastructure_extractor -> { servers[], domains[], ports[], services[], artifacts{}, cicd{} }
  • コンテンツの品質を評価します（0.0-1.0）
• 結果を source_notes に保存します

0c. ユーザーによる確認：

• 検出した、正規の形式に準拠していないファイルを表示します：

  Non-Canonical Documentation Detected:
  
  | File | Type | Confidence | Target |
  |------|------|------------|--------|
  | README.md (## Architecture) | architecture | HIGH | docs/project/architecture.md |
  | docs/ARCHITECTURE.md | architecture | HIGH | docs/project/architecture.md |
  | CONTRIBUTING.md (## Development) | principles | MEDIUM | docs/principles.md |
  
  Cleanup Options:
  1. NORMALIZE (recommended): Extract facts -> Archive -> Remove duplicate sources
  2. ARCHIVE ONLY: Backup without extraction
  3. SKIP: Leave non-canonical docs as-is (may cause duplication)
  
  Choose option (1/2/3): _
  

• ユーザーが「1」（NORMALIZE）を選択した場合：
  • 任意：「抽出した情報を正規のコンテキストに統合する前に確認しますか？（yes/no）」
  • 確認：「整理を実行し、正規の形式に準拠していないファイルをアーカイブしますか？」
• ユーザーが「2」（ARCHIVE ONLY）を選択した場合：
  • 確認：「正規の形式に準拠していないファイルを .archive/ にアーカイブしますか？コンテンツは正規化されません。」
• ユーザーが「3」（SKIP）を選択した場合：
  • 警告：「正規の形式に準拠していないファイルは残ります。これにより重複の問題が発生する可能性があります。」
  • フェーズ 1 に進みます

0d. バックアップとアーカイブ：

• .archive/source-docs-{timestamp}/ ディレクトリを作成します
• 構成：

  .archive/
  `- source-docs-YYYY-MM-DD-HHMMSS/
      |- README_cleanup.md          # Rollback instructions
      |- original/                  # Exact copies of non-canonical files
      |  |- README.md
      |  |- ARCHITECTURE.md
      |  `- documentation/
      `- extracted/                 # Extracted facts (for reference)
          |- architecture_content.md
          `- principles_content.md
  

• 検出したソースファイルをすべて original/ にコピーします
• 抽出した情報を extracted/ に保存します
• ロールバック手順を記載した README_cleanup.md を生成します

0e. コンテキストの正規化：

• 抽出した情報から SOURCE_DOC_NOTES を作成します：

  {
    "SOURCE_DOC_NOTES": {
      "architecture_notes": { "sections": [...], "diagrams": [...] },
      "requirements_notes": { "functional": [...] },
      "principles_notes": { "principles": [...] },
      "tech_stack_notes": { "frontend": "...", "backend": "..." },
      "api_notes": { "endpoints": [...] },
      "database_notes": { "tables": [...] },
      "runbook_notes": { "install_steps": [...] },
      "infrastructure_notes": { "servers": [...], "domains": [...], "ports": {} }
    }
  }
  

• 抽出した情報は、補足的な根拠としてのみコーディネーターへの入力に統合します
• ワーカーは正規化されたコンテキストのフィールドと現在のソース情報を直接使用します。レガシー専用の分岐はありません
• 優先順位：現在のソース情報と正規化されたプロジェクトドキュメント > テンプレートのデフォルト

0f. 整理（正規の形式に準拠していないファイル）：

• ルート直下のファイル（README.md、CONTRIBUTING.md）の場合：
  • 削除しないでください
  • Edit ツールを使って重複するセクションを削除します
  • 新しい場所へのリンクを追加します：
    • ## Architecture -> リンク [Architecture](docs/project/architecture.md) に置き換えます
    • ## Tech Stack -> リンク [Tech Stack](docs/project/tech_stack.md) に置き換えます
• 単独の、正規の形式に準拠していないファイル（ARCHITECTURE.md、documentation/）の場合：
  • ファイルを削除します（バックアップ済みです）
  • ログに記録します：「Deleted: ARCHITECTURE.md (migrated to docs/project/architecture.md)」
• 空になった、正規の形式に準拠していないディレクトリを整理します

出力：cleanup_summary { normalized_count, archived_count, skipped_count, source_doc_notes }

フェーズ 1：ユーザーの確認

目的：既存ファイルを確認し、ワークフローを説明して、ユーザーの承認を得ます。

プロセス：

0. クリーンアップの概要（フェーズ 0 が実行された場合）：

   • 表示：「正規形式ではない {N} 件のドキュメントを正規化しました」
   • 表示：「.archive/source-docs-{date}/ にアーカイブしました」
   • 表示：「コーディネーターへの入力に、正規化したソースノートを追加しました」

1. 事前確認（既存ドキュメントをスキャン）：

   • Glob ツールを使用して、候補となるすべてのファイルを確認します：
   • ルートドキュメント：AGENTS.md、CLAUDE.md、docs/README.md、docs/documentation_standards.md、docs/principles.md
   • リファレンス構成（5 項目）：docs/reference/README.md、docs/reference/adrs/、docs/reference/guides/、docs/reference/manuals/、docs/reference/research/
   • タスクドキュメント（2 ファイル）：docs/tasks/README.md、docs/tasks/kanban_board.md
   • プロジェクトドキュメント（最大 8 ファイル）：docs/project/requirements.md、architecture.md、tech_stack.md、api_spec.md、database_schema.md、design_guidelines.md、infrastructure.md、runbook.md
   • テストドキュメント（2 ファイル）：docs/reference/guides/testing-strategy.md、tests/README.md
   • 既存ファイルと不足ファイルの数を数えます
   • ユーザーに概要を表示します：

     ドキュメントの状況：
     検出：既存ファイル X 件
     不足：Y 件
     
     パイプラインでは不足しているファイルのみ作成します。
     既存ファイルは保持されます（上書きしません）。
     

2. 作成するファイルをユーザーに提示します：

   • ルートおよびプロジェクトドキュメント（AGENTS.md の正規ファイル + CLAUDE.md のインポート用スタブ + docs/README.md + documentation_standards.md + principles.md + ln-110-project-docs-coordinator による docs/project/）
   • リファレンス構成（ln-120-reference-docs-creator による docs/reference/）
   • タスク管理ドキュメント（ln-130-tasks-docs-creator による docs/tasks/）
   • テストドキュメント（ln-140-test-docs-creator による tests/ - 任意）
   • 推定所要時間：対話形式で 15～20 分

3. 質問：「不足しているファイルの作成を進めますか？（yes/no）」

4. 質問：「テストドキュメント（tests/README.md）を含めますか？（yes/no）」

出力：ファイルスキャンの概要 + ユーザーの承認 + テストドキュメントの希望

フェーズ 2：コーディネーターとワーカーを順に呼び出す

目的：L2 コーディネーターと 4 つの L2 ワーカーを順に呼び出し、完全なドキュメントシステムを作成します。

プロセス（Skill ツールによる自動呼び出し）：

2a. ルートおよびプロジェクトのドキュメントを作成する：

• 呼び出し：Skill(skill: "ln-110-project-docs-coordinator") -> 自動
• 入力：クリーンアップを実施した場合は、フェーズ 0 で正規化したソースノートを渡します
• 動作：コーディネーターがコンテキストを 1 回だけ収集し、その後、5 つの L3 ワーカーに委任します：
  • ln-111-root-docs-creator -> ルートドキュメント（AGENTS.md を正本として、CLAUDE.md のスタブ、docs/README.md、documentation_standards.md、principles.md）
  • ln-112-project-core-creator -> コアドキュメント 3 件
  • ln-113-backend-docs-creator -> 条件に応じて 2 件
  • ln-114-frontend-docs-creator -> 条件に応じて 1 件（hasFrontend の場合）
  • ln-115-devops-docs-creator -> ドキュメント 2 件：常に作成する 1 件と条件に応じて作成する 1 件
• 出力：ルートドキュメント（AGENTS.md を正本として、CLAUDE.md の @AGENTS.md インポート用スタブ、docs/README.md、docs/documentation_standards.md、docs/principles.md）と、プロジェクトドキュメント（docs/project/requirements.md、architecture.md、tech_stack.md、infrastructure.md、および条件に応じて api_spec.md、database_schema.md、design_guidelines.md、runbook.md）
• 保存：ln-110 の結果から context_store を保存します（ln-120 が使用する TECH_STACK を含みます）
• 検証：各 L3 ワーカーが出力を検証します（SCOPE、メタデータマーカー、最上位セクション、Maintenance）
• 確認：続行する前に、すべてのドキュメントが存在することを確認します

2b. リファレンス構成とスマートドキュメントを作成する：

• 呼び出し：Skill(skill: "ln-120-reference-docs-creator") -> 自動
• 入力：ln-110 の context_store を渡します（TECH_STACK によりスマートドキュメントの作成が可能になります）
• 出力：docs/reference/README.md と adrs/、guides/、manuals/、research/ ディレクトリ、および妥当性が確認された ADR／ガイド／マニュアル
• スマート作成：重要な技術選択に関するドキュメントのみを作成します（ln-120 の妥当性確認ルールを参照）
• 検証：ln-120 がフェーズ 2／3 で出力を検証します
• 確認：続行する前に、リファレンスハブが存在することを確認します

2c. タスク管理ドキュメントを作成する：

• 呼び出し：Skill(skill: "ln-130-tasks-docs-creator") -> 自動
• 出力：docs/tasks/README.md と、必要に応じて kanban_board.md（ユーザーが Linear の設定を提供した場合）
• 検証：ln-130 がフェーズ 2／3 で出力を検証します
• 確認：続行する前に、Tasks README が存在することを確認します

2d. テストドキュメントを作成する（任意）：

• 条件：フェーズ 1 でユーザーがテストドキュメントを承認した場合
• 呼び出し：Skill(skill: "ln-140-test-docs-creator") -> 自動
• 出力：tests/README.md（Story-Level Test Task Pattern を含むテストドキュメント）
• スキップ：「no」の場合 -> 後から ln-140-test-docs-creator を手動で実行できます

2e. ドキュメントからスキルを抽出する（任意）：

• 条件：フェーズ 1 でユーザーがスキルの抽出を承認した場合、または後から手動で実行した場合
• 呼び出し：Skill(skill: "ln-160-docs-skill-extractor") -> 自動
• 入力：ln-110 から ln-140 までで作成したすべてのドキュメント
• 出力：手順を説明するドキュメントのセクションから抽出した .claude/commands/*.md ファイル
• スキップ：承認されていない場合 -> 後から ln-160-docs-skill-extractor を手動で実行できます

出力：コーディネーターと 4 つのワーカーによる作成と検証が完了した、完全なドキュメントシステム

ワーカーの呼び出し（必須）

ホストスキルの呼び出し： Skill(skill: "...", args: "...") による委任が必須です。

• Claude：表示どおりに Skill ツールを呼び出します。
• Codex：Skill ツールが存在しない場合は、利用可能なスキルから指定されたスキルを見つけ、その SKILL.md を読み、args を $ARGUMENTS として扱い、そのスキルのワークフローを実行してから、結果／成果物とともにここに戻ります。
• ワーカーのロジックをインラインで実行したり、対象スキルを実行せずにワーカーを完了扱いにしたりしないでください。

TodoWrite の形式（必須）

開始前に、すべての呼び出しを Todo に追加します：

- Invoke ln-110-project-docs-coordinator (pending)
- Invoke ln-120-reference-docs-creator (pending)
- Invoke ln-130-tasks-docs-creator (pending)
- Invoke ln-140-test-docs-creator (pending)
- Run Global Cleanup (Phase 3) (pending)
- Show Summary (Phase 4) (pending)

各ワーカーの実行開始時に in_progress、成功して戻った時点で completed に設定します。

---

フェーズ 3：全体のクリーンアップと統合

目的：すべてのドキュメントから重複ファイルや孤立ファイルを削除し、知識を統合します。

トリガー：すべてのワーカーが Phase 2/3 の検証を完了した後にのみ実行します。

プロセス：

3a. docs-quality マニフェストを作成する

クリーンアップの前に、ワーカーの出力から正規化済みのマニフェストを1つ作成します。

1. ln-110、ln-120、ln-130、ln-140 から created_files、skipped_files、quality_inputs を収集します
2. quality_inputs.doc_paths と quality_inputs.owners を統合し、パスの重複を除去します。正規化された戻り値の契約を省略したワーカーがある場合は、直ちに失敗させます
3. 共有ベリファイアーを使って明示的なマニフェストを書き込みます：

   node {skills_repo_root}/references/scripts/docs-quality/cli.mjs manifest \
     --project-root . \
    --files "AGENTS.md,CLAUDE.md,docs/README.md,docs/project/requirements.md" \
     --output docs/project/.audit/ln-100/docs-quality-manifest.json
   

4. Phase 3 の品質に関するすべての判断で、このマニフェストを唯一の信頼できる情報源として使用します

3b. docs-quality の一元化ベリファイアーを実行する

マニフェストに対して共有ベリファイアーを実行します：

node {skills_repo_root}/references/scripts/docs-quality/cli.mjs verify \
  --project-root . \
  --manifest docs/project/.audit/ln-100/docs-quality-manifest.json \
  --output docs/project/.audit/ln-100/docs-quality-report.json

ベリファイアーは共有 docs-quality 契約／ルールに基づいてチェックを行い、次の項目を含みます：

• 必須ドキュメント内の SCOPE タグ
• Maintenance セクションとマーカー
• 禁止プレースホルダーと漏洩したテンプレートメタデータ
• 内部リンク切れ
• 許可されていないコードフェンス
• 古いインライン日付
• 非公式なスタックのドキュメントリンク

ゲート： Phase 3 のクリーンアップに進む前に、HIGH／CRITICAL の指摘をすべて解消する必要があります。

3c. 上限付き修正ループ

ベリファイアーが HIGH／CRITICAL の指摘を報告した場合：

1. パス1 - 決定的なインライン修正：
   • 不足している SCOPE タグを追加します
   • ## Maintenance を追加または完成させます
   • リンク先が明らかな内部リンク切れを修正します
   • 古い生成日付を更新します
   • 漏洩したテンプレートメタデータと未解決のマーカーを削除します
   • 不正なコードフェンスをテーブル、コマンド、またはリンクに置き換えます
2. パス2 - オーナーに限定した意味的修正：
   • 残りの指摘を quality_inputs.owners[path] でグループ化します
   • 対象ファイルの指摘を絞り込み、該当するワーカーだけを再実行します
   • 無関係なワーカーは再実行しません
3. 各修正パスの後にベリファイアーを再実行します
4. 修正の反復は合計2回で停止します
5. HIGH／CRITICAL の指摘が残っている場合は、品質の低いドキュメントを出力せずにパイプラインを失敗させます

ベリファイアーの概要と doc-registry の出力を Phase 5 の最終出力に記録します。

3d. 重複コンテンツをスキャンする

1. docs/ 内のすべての .md ファイルを読み取る

   • Glob ツールを使用します：pattern: "docs/**/*.md"
   • すべてのドキュメントファイルの一覧を保存します

2. 重複セクションを特定する：

   • ファイルごとに：
     • ファイルの内容を読み取ります
     • セクション見出し（##、###）を抽出します
     • セクションの内容（見出し間のテキスト）を抽出します
   • ファイル間でセクションを比較します：
     • 2つ以上のセクションが次の条件を満たす場合：
       • 見出しが同じ（大文字・小文字を区別しない）
       • 内容の類似度が80%を超える（単語の単純な重複チェック）
     • 重複としてマークします

3. 正規版を決定する：

   • 正規の配置場所のルール：
     • 「Development Principles」 -> principles.md（常に正規版）
     • 「Testing Strategy」 -> testing-strategy.md（常に正規版）
     • 「Linear Configuration」 -> tasks/kanban_board.md（常に正規版）
     • その他の重複については、最初に見つかったファイル（アルファベット順）に残します

4. 重複を削除する：

   • 重複するセクションごとに：
     • Edit ツールを使って、正規版ではないファイルから削除します
     • Edit ツールを使って、正規の場所へのリンクを追加します：

       Canonical source: [Development Principles](../principles.md#development-principles)
       

   • 削除した重複の数を記録します

5. 結果を記録する：

   • 「重複セクションを{count}件削除しました」
   • 一覧：「{section_name} を {file} から削除しました（正規版：{canonical_file}）」

3e. 想定外のファイルを報告する（参考情報）

1. docs/ 内のすべての .md ファイルを一覧表示する

   • Glob ツールを使用します：pattern: "docs/**/*.md"

2. 想定される構成と照合する（ワーカーが作成したファイルと、ユーザーが作成した参考ドキュメント）

3. 確認結果を報告する（移動／削除／アーカイブは行わない）：

   • 想定外のファイルを参考情報として一覧表示します
   • 対応はユーザーが判断します
   • 次のように記録します：「想定外のファイルが{count}件見つかりました（想定される構成に含まれません）-> ユーザー確認用に一覧表示」

3f. 知識を統合する

1. 散在している情報を特定します：

   • 既知のパターン：
     • Linear の設定が散在：kanban_board.md + tasks/README.md
     • 開発原則が散在：AGENTS.md + principles.md + architecture.md
     • テスト情報が散在：testing-strategy.md + tests/README.md + architecture.md

2. 散在している各概念について：

   • Single Source of Truth（SSoT）を決定します：
     • Linear の設定 -> kanban_board.md
     • 開発原則 -> principles.md
     • テスト戦略 -> testing-strategy.md

3. SSoT 以外のファイルを更新します：

   • Edit ツールを使用して、重複する内容をリンクに置き換えます：

     Canonical source: [Linear Configuration](../tasks/kanban_board.md#linear-configuration)
     

   • 統合件数を記録します

4. 結果を記録します：

   • 「散在している概念を {count} 件統合しました」
   • 一覧：「{concept} を {SSoT_file} に統合」

3g. クロスリンクの検証

1. すべての .md ファイルをスキャンして内部リンクを確認します：

   • 各ファイルについて：
     • 内容を読み取ります
     • すべての Markdown リンクを抽出します：[text](path)
     • 内部リンク（相対パスで、http:// ではないもの）に絞り込みます

2. リンク先が存在することを確認します：

   • 各リンクについて：
     • 相対パスを解決します
     • リンク先のファイルが存在するか確認します（Glob ツール）
     • 存在しない場合：リンク切れとしてマークします

3. リンク切れを修正します：

   • リンク切れごとに：
     • リンク先がアーカイブ済みの場合：リンクをアーカイブ先のパスに更新します
     • リンク先が一度も存在しない場合：リンクを削除します（プレーンテキストに変換）
   • 修正件数を記録します

4. 不足している重要なリンクを追加します：

   • AGENTS.md -> docs/README.md:
     • AGENTS.md を読み取ります
     • docs/README.md へのリンクがあるか確認します
     • ない場合：「Documentation Hub」セクションに追加します
   • docs/README.md -> セクションの README:
     • project/、reference/、tasks/、tests/ の README へのリンクがあるか確認します
     • ない場合：追加します
   • 追加したリンク数を記録します

5. 結果を記録します：

   • 「リンク切れを {count} 件修正しました」
   • 「不足していた重要なリンクを {count} 件追加しました」
   • 変更内容の一覧

3h. 最終レポート

Global Cleanup Complete:

Structure:
- Removed {N} duplicate sections (canonical: principles.md)
- Found {N} unexpected files (listed for user review)
- Consolidated {N} scattered concepts

Links:
- Fixed {N} broken links
- Added {N} missing critical links:
  - list of added links

出力：ドキュメントをすべて整理し、重複を削除し、想定外のファイルを報告し、ナレッジを統合して、クロスリンクを検証した状態

---

フェーズ 4：概要と次のステップ

目的：作成したシステムの全体像を示します。

手順：

1. 作成したすべてのファイルとサイズを一覧表示します：

   • AGENTS.md（プロジェクトの正式なエントリーポイント）
   • CLAUDE.md（Claude Code 用の @AGENTS.md インポートスタブ）
   • docs/README.md（ルートのドキュメントハブ）
   • docs/documentation_standards.md（共通の要件 60 件）
   • docs/principles.md（開発原則 11 件）
   • docs/project/requirements.md、architecture.md、tech_stack.md + 条件付きドキュメント（合計 3～7 件）
   • docs/reference/README.md（adrs/、guides/、manuals/、research/ の空ディレクトリを含むリファレンスハブ）
   • docs/tasks/README.md + 任意で kanban_board.md
   • tests/README.md（作成した場合）

2. ドキュメントシステムの機能を示します：

   • SCOPE タグ（ドキュメントの範囲を定義）
   • メンテナンスセクション（更新の契機 + 検証）
   • README ハブ（中央ナビゲーション）
   • DAG 構造（有向非巡回グラフ型のナビゲーション）
   • ライブドキュメントとして利用可能
   • 重複を排除したコンテンツ（正式な情報源のみ）
   • 検証済みのクロスリンク（リンク切れなし）

3. 次のステップを提案します：

   • 「生成されたドキュメントを確認する（AGENTS.md が正式な情報源、CLAUDE.md は docs/ を参照するスタブ）」
   • 「ln-210-epic-coordinator を実行して、スコープをエピックに分解する」
   • 「技術関係者とドキュメントを共有する」

4. docs-quality ゲートを要約します：

   • Verifier score: X/10
   • Repair passes used: 0-2
   • Remaining warnings: list LOW/MEDIUM only

出力：ファイル一覧、検証ステータス、推奨事項を含む概要メッセージ

---

完全な出力構造

project_root/
|- AGENTS.md                         # Canonical project entry point (map-first root)
|- CLAUDE.md                         # Derived Anthropic entrypoint
|- docs/
|  |- README.md                     # Root documentation hub (general standards)
|  |- documentation_standards.md    # 60 universal requirements (Claude Code + industry standards)
|  |- principles.md                 # 11 development principles (Standards First, YAGNI, KISS, DRY, etc.)
|  |- project/
|  |  |- requirements.md           # Functional Requirements (NO NFR per project policy)
|  |  |- architecture.md           # arc42-based architecture with C4 Model
|  |  |- tech_stack.md             # Technology versions, Docker config
|  |  |- api_spec.md               # API endpoints (conditional)
|  |  |- database_schema.md        # Database schema (conditional)
|  |  |- design_guidelines.md      # UI/UX system (conditional)
|  |  |- infrastructure.md         # Infrastructure inventory (always)
|  |  `- runbook.md                # Operations guide (conditional)
|  |- reference/
|  |  |- README.md                 # Reference documentation hub (registries)
|  |  |- adrs/                     # Empty, ready for ADRs
|  |  |- guides/                   # Empty, ready for guides
|  |  |- manuals/                  # Empty, ready for manuals
|  |  `- research/                 # Empty, ready for research
|  |- tasks/
|  |  |- README.md                 # Task management system rules
|  |  `- kanban_board.md           # Linear integration (optional)
`- tests/
   `- README.md                    # Test documentation (optional)

---

プロジェクトのワークフローとの統合

新規プロジェクトで推奨されるワークフロー：

1. ln-100-documents-pipeline（このスキル）- ドキュメント一式を作成します
2. ln-210-epic-coordinator - スコープをエピック（Linear プロジェクト）に分割します
3. ln-220-story-coordinator - 各エピックのユーザーストーリーを作成します（自動分割＋再計画）
4. ln-300-task-coordinator - ストーリーを実装タスクに分割します（自動分割＋再計画）
5. ln-310-multi-agent-validator - 開発前にストーリーを検証します
6. ln-400-story-executor - ストーリーの実装を統括します
7. ストーリー品質ゲート - 完了したストーリーをレビューします

---

トレードオフ

トレードオフ：

• 詳細な制御がしにくくなります（コーディネーターのフェーズをスキップできません）
• 実行時間が長くなります（15～20 分）
• 作成されたファイルが 1 つだけでも、全体のクリーンアップが実行されます

代わりに手動の方法を使う場合：

• 特定の ADR／ガイド／マニュアルが 1 つ必要な場合 -> references/templates/ + references/documentation_creation.md を使用します

---

ドキュメント標準

このパイプラインで作成するすべてのドキュメントは、以下のルールに従う必要があります。

ルール	説明	適用方法
NO_CODE ルール	ドキュメントでは実装ではなく契約を記述します	5 行を超えるコードブロックは禁止し、表／ASCII／リンクを使用します
スタックへの適合	リンクはプロジェクトの TECH_STACK に合わせる必要があります	.NET -> Microsoft のドキュメント、JS -> MDN
形式の優先順位	表／ASCII > リスト（列挙のみ） > テキスト	パラメーター、設定、代替案には表を使用します

これらの標準は、L3 ワーカー（ln-111-115）、ln-120/130/140、および共有の docs-quality ゲートによって適用されます。

---

エラー処理

呼び出したスキルが失敗した場合：

1. 失敗したスキルをユーザーに通知します
2. 失敗したスキルのエラーメッセージを表示します
3. デバッグのために手動で呼び出すことを推奨します
4. すでに完了したステップ（部分的な進捗）を列挙します

---

技術的な実装メモ

スキルの呼び出し：

• コマンドパラメーターを指定して Skill tool を使用します
• 次に進む前に、各スキルの完了を待ちます
• 次のフェーズに進む前に、出力ファイルが存在することを確認します

ファイルの確認：

• Glob ツールを使用して docs/project/ 構造を確認します
• ユーザーが確認できるよう、ファイルサイズを一覧表示します
• 想定されるファイルがない場合は警告します

全体のクリーンアップ：

• Glob ツールを使用してすべての .md ファイルを検索します
• Read ツールを使用して内容を分析します
• Edit ツールを使用して重複を削除し、リンクを追加します
• 想定外のファイルを報告します（参考情報のみ、自動アーカイブは行いません）

Docs-Quality ゲート：

• references/scripts/docs-quality/cli.mjs を使用して、ワーカーの出力からマニフェストを作成します
• クリーンアップ前と修正処理の後に、共有の検証ツールを実行します
• 未解決の HIGH／CRITICAL の問題がある場合、品質の低いドキュメントを出力するのではなく、速やかに失敗させます

標準への準拠：

• すべての出力は、基盤となるスキルと同じ標準に従います
• ISO/IEC/IEEE 29148:2018（要件）
• ISO/IEC/IEEE 42010:2022（アーキテクチャ）
• arc42 + C4 Model + Michael Nygard の ADR 形式

---

重要なルール

• 冪等性： 不足しているファイルのみを作成し、既存ファイルは上書きせずに保持します
• 順次呼び出し： ワーカーは順番どおりに呼び出す必要があります（ln-110 -> ln-120 -> ln-130 -> ln-140）。次のワーカーを呼び出す前に、各ワーカーを検証します
• Docs-Quality ゲートは必須： フェーズ 3 では、マニフェストを作成し -> 検証ツールを実行し -> 制限付きの修正ループを実施してから、クリーンアップを続行する必要があります
• 全体のクリーンアップは必須： フェーズ 3（重複排除、孤立ファイルの報告、SSoT の統合、相互リンクの検証）は、docs-quality ゲートの通過後にのみ実行します
• ユーザーの確認が必要： ファイルを作成する前に、事前確認を行い、明示的な承認を得ます
• NO_CODE ルール： 生成するすべてのドキュメントでは表／ASCII／リンクを使用し、5 行を超えるコードブロックを使用しません

フェーズ 5：メタ分析

任意の参照資料：実行後のメタ分析またはプロトコル形式の実行振り返りをユーザーが求めた場合に限り、references/meta_analysis_protocol.md を読み込みます。

スキルの種類：planning-coordinator。依頼された場合、すべてのフェーズが完了した後に実行します。planning-coordinator 形式を使用してチャットに出力します。

参照ファイル

• 正規ではないソースパターン：references/legacy_detection_patterns.md
• ワーカースキル：ln-110-project-docs-coordinator、ln-120-reference-docs-creator、ln-130-tasks-docs-creator、ln-140-test-docs-creator
• 共通のドキュメント品質契約：references/docs_quality_contract.md
• 共通の検証用 CLI：references/scripts/docs-quality/cli.mjs

完了の定義

作業を完了する前に、すべてのチェックポイントを確認してください。

ソースのクリーンアップ（Phase 0 — 該当する場合）：

• 標準形式でないドキュメントのパターンを適用（Glob + Grep）
• ソースマニフェストを作成：{ path, type, confidence, target }
• ユーザーがクリーンアップ方法を選択（NORMALIZE / ARCHIVE / SKIP）
• NORMALIZE の場合：タイプ別エクストラクターを使って事実を抽出
• バックアップを作成：.archive/source-docs-{timestamp}/original/
• 抽出した事実を保存：.archive/source-docs-{timestamp}/extracted/
• ロールバック手順を含む README_cleanup.md を生成
• コーディネーターへの入力用に SOURCE_DOC_NOTES を準備
• 標準形式でないファイルをクリーンアップ（README.md から該当セクションを削除し、独立したファイルを削除）

ユーザーの確認（Phase 1）：

• 移行の概要を表示（Phase 0 を実行した場合）
• ワークフローをユーザーに説明（コーディネーター + 4 つのワーカー：ln-110 -> ln-120 -> ln-130 -> ln-140）
• ユーザーが承認：「完全なドキュメントシステムの作成を進めますか？（yes/no）」
• テストドキュメントの希望を確認：「テストドキュメントを含めますか？（yes/no）」

コーディネーターとワーカーを順番に呼び出し（Phase 2）：

• ln-110-project-docs-coordinator を呼び出し -> 出力を確認：ルートドキュメント（AGENTS.md + CLAUDE.md + docs/README.md + docs/documentation_standards.md + docs/principles.md）+ プロジェクトドキュメント（docs/project/requirements.md、architecture.md、tech_stack.md + 条件付きファイル）
• ln-120-reference-docs-creator を呼び出し -> 出力を確認：docs/reference/README.md + ディレクトリ（adrs/、guides/、manuals/、research/）+ TECH_STACK に基づく妥当な ADR／ガイド／マニュアル
• ln-130-tasks-docs-creator を呼び出し -> 出力を確認：docs/tasks/README.md + オプションの kanban_board.md
• ln-140-test-docs-creator を呼び出し（有効な場合） -> 出力を確認：tests/README.md
• 各コンポーネントが独自の出力を検証（SCOPE、メタデータマーカー、冒頭セクション、Maintenance、POSIX 準拠）
• 各ワーカーが正規化済みの created_files、skipped_files、quality_inputs、validation_status を返す

ファイル検証の完了：

• 期待されるすべてのファイルが存在（Glob ツールで構造を検証）
• ユーザー確認用にファイルサイズを一覧表示
• 期待されるファイルが見つからない場合は警告を表示

全体クリーンアップの完了（Phase 3）：

• 3a：正規化されたワーカー出力からマニフェストを作成
• 3b：マニフェストに対して共有検証ツールを実行
• 3c：範囲を限定した修復ループを完了し、HIGH／CRITICAL の指摘事項が残っていない
• 3d：重複セクションを特定して削除（類似度 >80%）
• 3d：正式な場所（principles.md、testing-strategy.md、kanban_board.md）へのリンクを追加
• 3e：想定外のファイルを報告（参考情報、自動アーカイブなし）
• 3f：散在する概念を信頼できる唯一の情報源（SSoT）に統合
• 3g：内部リンクを検証（リンク切れを修正し、重要なリンクを追加）
• 3h：最終レポートを生成（品質ゲートの概要、件数、一覧、対応内容）

概要の表示（Phase 4）：

• 作成したすべてのファイルをサイズとともに一覧表示
• ドキュメントシステムの機能を強調（SCOPE、メタデータマーカー、クイックナビゲーション、エージェントエントリー、Maintenance、README ハブ、DAG 構造、重複を排除したコンテンツ、検証済みリンク）
• Docs-quality 検証ツールの概要を表示（スコア、修復パス数、残っている LOW／MEDIUM の警告）
• 次のステップとして ln-210-epic-coordinator を推奨

エラー処理（該当する場合）：

• いずれかのワーカーが失敗した場合：失敗したワーカーをユーザーに通知し、エラーメッセージを表示して、手動での呼び出しを推奨し、部分的な進捗を一覧表示

出力： 完全なドキュメントシステム（AGENTS.md を正式なファイルとし、CLAUDE.md は @AGENTS.md のインポート用スタブ、docs/ には README.md、documentation_standards.md、principles.md を含み、必要に応じて tests/ も追加）。全体クリーンアップ済み（重複なし、孤立ファイルを報告、ナレッジを統合、相互リンクを検証）

---

バージョン： 8.1.0 最終更新日： 2025-01-12