ln-110-project-docs-coordinator

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

プロジェクトドキュメントコーディネーター

タイプ： L2 コーディネーター
カテゴリ： 1XX ドキュメントパイプライン

ランタイムを利用するドキュメントコーディネーターです。コンテキストの組み立てチェックポイント、条件に応じたワーカーへのファンアウト、ドキュメント生成サマリーの集約は、ランタイムが担います。

目的と範囲

• コンテキストの一括収集 — プロジェクトを一度分析し、コンテキストストアを構築します
• プロジェクトタイプの検出 — hasBackend、hasDatabase、hasFrontend、hasDocker を判定します
• 5 つのワーカーに委譲 — 各ワーカーにコンテキストストアを渡します
• 結果を集約 — すべてのワーカーのステータスを収集し、サマリーを返します
• データを一度収集して明示的に渡すことで、「コンテキスト喪失」の問題を解決します
• ln-100 のドキュメント品質修復ループで使用するルーティングテーブルを構築します

ランタイム契約

必ず読むこと： references/coordinator_runtime_contract.md、references/docs_runtime_contract.md、references/docs_generation_summary_contract.md を読み込んでください。

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

識別子：

• project-docs

フェーズ：

1. PHASE_0_CONFIG
2. PHASE_1_CONTEXT_ASSEMBLY
3. PHASE_2_DETECTION
4. PHASE_3_DELEGATE
5. PHASE_4_AGGREGATE
6. PHASE_5_SELF_CHECK

ワーカーサマリー契約：

• ln-111..115 は summaryArtifactPath を受け取る場合があります
• 各ワーカーは docs-generation サマリーエンベロープを書き込むか、返します
• ln-110 は、自由記述のワーカー文章ではなく、ワーカーサマリーを使用します

呼び出し（呼び出し元／タイミング）

• ln-100-documents-pipeline： ドキュメントパイプラインで最初の L2 コーディネーターとして呼び出されます
• ユーザーから直接呼び出されることはありません

入力

ln-100 から（任意のソースクリーンアップフェーズ）：

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

SOURCE_DOC_NOTES は、ワーカーのディスパッチ前に標準のコンテキストストアを補完します。ワーカーは正規化されたコンテキストフィールドのみを使用します。レガシー固有のオーバーライド分岐はありません。

必ず読むこと： references/docs_quality_contract.md を読み込んでください。

アーキテクチャ

ln-110-project-docs-coordinator (this skill)
├── Phase 1: Context Gathering (ONE TIME)
├── Phase 2: Delegate to Workers
│   ├── ln-111-root-docs-creator → 4 root docs (ALWAYS)
│   ├── ln-112-project-core-creator → 3 core docs (ALWAYS)
│   ├── ln-113-backend-docs-creator → 2 docs (if hasBackend/hasDatabase)
│   ├── ln-114-frontend-docs-creator → 1 doc (if hasFrontend)
│   └── ln-115-devops-docs-creator → 2 docs (1 always + 1 if hasDocker)
└── Phase 3: Aggregate Results

ワークフロー

フェーズ 1：コンテキストの収集（1 回のみ）

1.1 自動検出（プロジェクトファイルをスキャン）：

ソース	抽出するデータ	コンテキストストアのキー
package.json	name, description, dependencies, scripts, engines, author, contributors	PROJECT_NAME, PROJECT_DESCRIPTION, DEPENDENCIES, DEV_COMMANDS, DEVOPS_CONTACTS
docker-compose.yml	services, ports, deploy.replicas, runtime:nvidia	DOCKER_SERVICES, DEPLOYMENT_SCALE, HAS_GPU
Dockerfile	ランタイムのバージョン	RUNTIME_VERSION
src/ structure	フォルダー、パターン	SRC_STRUCTURE, ARCHITECTURE_PATTERN
migrations/	テーブル定義	SCHEMA_OVERVIEW
.env.example	環境変数	ENV_VARIABLES
tsconfig.json, .eslintrc	規約	CODE_CONVENTIONS
README.md	プロジェクトの説明、スケーリングに関する記述	PROJECT_DESCRIPTION (fallback), DEPLOYMENT_SCALE (fallback)
CODEOWNERS	メンテナー	DEVOPS_CONTACTS
git log	頻繁にコミットするユーザー	DEVOPS_CONTACTS (fallback)
~/.ssh/config, deploy targets	SSH エイリアス、ホスト名、IP アドレス	SERVER_INVENTORY
docker-compose VIRTUAL_HOST vars	ドメインルーティング	DOMAIN_DNS
.env.example registry URLs, .npmrc	アーティファクトリポジトリ	ARTIFACT_REPOSITORY
docker-compose deploy.resources	リソース制限	HOST_REQUIREMENTS

1.2 プロジェクトタイプの検出：

フラグ	検出ルール
hasBackend	dependencies に express/fastify/nestjs/fastapi/django が含まれる
hasDatabase	dependencies に pg/mongoose/prisma/sequelize が含まれる、または docker-compose に postgres/mongo が含まれる
hasFrontend	dependencies に react/vue/angular/svelte が含まれる
hasDocker	Dockerfile または docker-compose.yml が存在する

1.3 ユーザーへの資料の確認：

• 質問：「既存の資料（要件、設計、ドキュメント）はありますか？」
• 提供された場合：回答を抽出してコンテキストストアに保存

1.4 MCP の調査（検出された技術について）：

• ベストプラクティスを確認するには Context7/Ref を使用
• ワーカー向けにコンテキストストアへ保存

1.5 コンテキストストアの構築：

{
  "PROJECT_NAME": "my-project",
  "PROJECT_DESCRIPTION": "...",
  "TECH_STACK": { "frontend": "React 18", "backend": "Express 4.18", "database": "PostgreSQL 15" },
  "DEPENDENCIES": [...],
  "SRC_STRUCTURE": { "controllers": [...], "services": [...] },
  "ENV_VARIABLES": ["DATABASE_URL", "JWT_SECRET"],
  "DEV_COMMANDS": { "dev": "npm run dev", "test": "npm test" },
  "DOCKER_SERVICES": ["app", "db"],
  "DEPLOYMENT_SCALE": "single",
  "DEVOPS_CONTACTS": [],
  "HAS_GPU": false,
  "SERVER_INVENTORY": [],
  "DOMAIN_DNS": [],
  "ARTIFACT_REPOSITORY": {},
  "HOST_REQUIREMENTS": {},
  "flags": { "hasBackend": true, "hasDatabase": true, "hasFrontend": true, "hasDocker": true }
}

DEPLOYMENT_SCALE の検出ルール：

• "single"（デフォルト）：deploy.replicas がなく、README にスケーリング関連のキーワードもない
• "multi"：deploy.replicas > 1、またはロードバランサーへの言及がある
• "auto-scaling"：README/docker-compose にオートスケーリング関連のキーワードがある
• "gpu-based"：docker-compose に runtime: nvidia がある

DEVOPS_CONTACTS のフォールバック順：

1. CODEOWNERS ファイル → メンテナーを抽出
2. package.json の author/contributors → 名前とメールアドレスを抽出
3. git log → コミット頻度の高い上位 3 名
4. すべて空の場合 → [TBD: Provide DevOps team contacts]

1.6 正規化されたソースノートを統合（ln-100 から提供された場合）：

• SOURCE_DOC_NOTES が ln-100 のクリーンアップフェーズから渡されているか確認
• 存在する場合、補足情報を標準のコンテキストストアに統合：

  contextStore.SOURCE_DOC_NOTES = input.SOURCE_DOC_NOTES
  

• 情報を補強する目的：
  • アーキテクチャノートは、アーキテクチャに関する根拠を補強します
  • 要件ノートは、要件に関する根拠を補強します
  • 技術スタックノートは、バージョンとその選定理由を明確にします
  • 原則、API、データベース、ランブック、インフラストラクチャに関するノートは、事実に基づく補足情報を提供します
• ワーカーは常に、正規化されたコンテキストと現在のプロジェクトソースに基づいて生成します
• SOURCE_DOC_NOTES がない場合：直接の自動検出と現在の正式なドキュメントを使用します

フェーズ 2: ワーカーへの委譲

必須: 該当するすべてのワーカーを呼び出す必要があります。ワーカーはコンテキスト分離のため、Agent ツールを介して並列で実行されます。

2.1 常に呼び出す（並列）:

• ln-111-root-docs-creator に Context Store を渡す
• ln-112-project-core-creator に完全な Context Store を渡す
• ln-115-devops-docs-creator に Context Store を渡す（infrastructure.md は常に、runbook.md は hasDocker に応じて内部的に条件付き）

2.2 条件付きで呼び出す:

• ln-113-backend-docs-creator — hasBackend または hasDatabase の場合
• ln-114-frontend-docs-creator — hasFrontend の場合

呼び出し（Agent ツールを介した並列実行）:

Agent(description: "{doc_type} docs via {worker}",
     prompt: "Invoke Skill(skill: \"{worker}\") with context below.\n\nCONTEXT: {contextStore}",
     subagent_type: "general-purpose")

委譲ルール:

• Agent+Skill パターンを介して Context Store とフラグをワーカーに渡す
• すべての Agent の完了を待機する
• 正規化された結果（created_files、skipped_files、quality_inputs、validation_status）を収集する

フェーズ 3: 結果の集約

1. すべてのワーカーからステータスを収集する
2. 合計を集計する: 作成されたファイル、スキップされたファイル
3. 検証の警告があれば報告する
4. 集約されたサマリーを ln-100 に返す
5. 後続のワーカー用に Context Store を含める（ln-120 は TECH_STACK を必要とする）
6. すべてのワーカーからの quality_inputs.owners を 1 つの修復ルーティングテーブルにマージする

出力:

{
  "workers_invoked": 5,
  "total_created": 11,
  "total_skipped": 0,
  "validation_status": "passed",
  "created_files": [
    "AGENTS.md",
    "CLAUDE.md",
    "docs/README.md",
    "docs/documentation_standards.md",
    "docs/principles.md",
    "docs/project/requirements.md",
    "docs/project/architecture.md",
    "docs/project/tech_stack.md",
    "docs/project/api_spec.md",
    "docs/project/database_schema.md",
    "docs/project/design_guidelines.md",
    "docs/project/infrastructure.md",
    "docs/project/runbook.md"
  ],
  "quality_inputs": {
    "doc_paths": ["AGENTS.md", "CLAUDE.md", "docs/README.md", "docs/project/architecture.md"],
    "owners": {
      "AGENTS.md": "ln-111-root-docs-creator",
      "CLAUDE.md": "ln-111-root-docs-creator",
      "docs/project/architecture.md": "ln-112-project-core-creator"
    }
  },
  "context_store": {
    "PROJECT_NAME": "...",
    "TECH_STACK": { "frontend": "React 18", "backend": "Express 4.18", "database": "PostgreSQL 15" },
    "DEPENDENCIES": [...],
    "flags": { "hasBackend": true, "hasDatabase": true, "hasFrontend": true, "hasDocker": true }
  }
}

重要な注意事項

• コンテキストは 1 回だけ収集 — ワーカー内で重複させない
• Context Store は明示的に渡す — 暗黙的な状態は使わない
• ワーカーは自己検証する — コーディネーターは集約のみを行う
• 冪等 — ワーカーは既存ファイルをスキップする
• 可能な限り並列 — ln-111 と ln-112 は並列で実行できる
• 修復ルーティングテーブルが必須 — 作成されたすべてのドキュメントパスは、それを所有する 1 つの作成元にマッピングする必要がある

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

ホストスキルの呼び出し: Skill(skill: "...", args: "...") は必須の委譲です。

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

フェーズ	ワーカー	コンテキスト	条件
2	ln-111-root-docs-creator	Agent（並列） — ルートドキュメント	ALWAYS
2	ln-112-project-core-creator	Agent（並列） — コアプロジェクトドキュメント	ALWAYS
2	ln-115-devops-docs-creator	Agent（並列） — インフラ + ランブック	ALWAYS
2	ln-113-backend-docs-creator	Agent（並列） — API 仕様 + DB スキーマ	hasBackend または hasDatabase
2	ln-114-frontend-docs-creator	Agent（並列） — 設計ガイドライン	hasFrontend

すべてのワーカー: Skill を伴う Agent ツールを介して呼び出します — ワーカーは Context Store を受け取ります。

TodoWrite 形式（必須）

- Build Context Store (pending)
- Invoke ln-111-root-docs-creator (pending)
- Invoke ln-112-project-core-creator (pending)
- Invoke ln-115-devops-docs-creator (pending)
- Invoke ln-113-backend-docs-creator [conditional] (pending)
- Invoke ln-114-frontend-docs-creator [conditional] (pending)
- Aggregate results (pending)

アンチパターン:

• ❌ ワーカーを呼び出さずにドキュメントファイルを直接作成する
• ❌ Agent+Skill を呼び出さずにワーカーのステップを完了扱いにする
• ❌ フラグを確認せずに条件付きワーカーをスキップする

ドキュメント標準（ワーカーに渡される）

• NO_CODE ルール: ドキュメントは実装ではなくコントラクトを記述する
• スタック適応: リンクは TECH_STACK（Context Store）と一致する必要がある
• フォーマット優先度: テーブル/ASCII > リスト > テキスト

完了の定義

• 発見されたすべてのデータで Context Store が構築されている
• プロジェクト種別フラグが決定されている
• 該当するすべてのワーカーが呼び出されている
• 結果が集約されている
• 実態が検証済み: すべてのドキュメントの事実が現在のコードと一致している（パス、関数、API、設定が存在し正確である）
• サマリーが ln-100 に返されている

フェーズ 4: メタ分析

任意の参照: ユーザーが実行後のメタ分析、またはプロトコル形式の実行リフレクションを求めた場合にのみ、references/meta_analysis_protocol.md を読み込みます。

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

参照ファイル

• ガイド: references/guides/automatic_analysis_guide.md、critical_questions.md、troubleshooting.md

---

バージョン: 2.1.0 最終更新: 2025-01-12