ln-112-project-core-creator

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

プロジェクトのコアドキュメント作成ツール

種類： L3 ワーカー

4 つのコアプロジェクトドキュメントファイルを作成する L3 ワーカーです。これらはプロジェクトの種類にかかわらず、必ず作成されます。

目的と範囲

• 4 つのコアプロジェクトドキュメントファイルを作成します（すべてのプロジェクトで必須）
• ln-110-project-docs-coordinator から Context Store を受け取ります
• 自動検出を多用します（アーキテクチャの把握にはプロジェクト全体のスキャンが必要です）
• プレースホルダーをプロジェクト固有のデータに置き換えます
• 構造と内容を自己検証します（16 問以上）
• 自分でコンテキストを収集することはありません。コーディネーターからの入力を使用します

呼び出し（誰が／いつ）

• ln-110-project-docs-coordinator： 2 番目のワーカーとして必ず呼び出されます（ln-111 の後）
• ユーザーから直接呼び出されることはありません

入力

コーディネーターから：

• contextStore：検出されたすべてのデータを含む完全な Context Store
  • PROJECT_NAME、PROJECT_DESCRIPTION
  • TECH_STACK（frontend、backend、database などを含む完全なオブジェクト）
  • DEPENDENCIES（package.json から取得）
  • SRC_STRUCTURE（フォルダー分析）
  • EXTERNAL_SYSTEMS（.env.example から取得）
  • CODE_CONVENTIONS（eslint、prettier から取得）
  • ADR_LIST（docs/reference/adrs/ から取得）
• targetDir：プロジェクトのルートディレクトリ

必須の読み込み： references/docs_quality_contract.md と references/markdown_read_protocol.md を読み込みます。 オプションのルールカタログ：正確なルール ID、パスのマトリックス、または許可リストに登録されたプレースホルダーの例外が必要な場合に限り、references/docs_quality_rules.json を読み込みます。

作成するドキュメント（4 件）

ファイル	対象セクション	質問	自動検出
docs/project/requirements.md	機能要件（FR-XXX-NNN 形式）	Q23	低
docs/project/architecture.md	C4 図を含む 11 の arc42 セクション	Q24-Q34	高
docs/project/tech_stack.md	フロントエンド、バックエンド、データベース、追加項目	Q35-Q38	高
docs/architecture/patterns_catalog.md	パターンの概要、4 段階評価モデル、トレンドの追跡	—	高

ワークフロー

フェーズ 1：コンテキストの受け取り

1. コーディネーターから完全な Context Store を解析します
2. 必須キー（PROJECT_NAME、TECH_STACK）を検証します
3. アーキテクチャ固有のデータ（SRC_STRUCTURE、DEPENDENCIES）を抽出します

フェーズ 2：ドキュメントを作成する

各ドキュメント（docs/project/requirements.md、docs/project/architecture.md、docs/project/tech_stack.md、docs/architecture/patterns_catalog.md）について：

1. ファイルが存在するか確認します（冪等性を保ちます）
2. 存在する場合：ログを出力してスキップします
3. 存在しない場合：
   • references/templates/ からテンプレートをコピーします
   • docs/project/requirements.md：現在の製品／プロジェクトの情報源から要件を導き出し、FR-XXX 構造に正規化します
   • docs/project/architecture.md：現在のソースツリー、ADR、実行時の境界から構造を導き出し、実際のコードの事実に基づいて図を生成します
   • docs/project/tech_stack.md：現在の依存関係と設定ファイルからバージョンと採用理由を導き出します
   • docs/architecture/patterns_catalog.md：
     • references/templates/patterns_template.md からテンプレートをコピーします
     • 現在のコードベースでパターンを自動検出します：
       • Grep("Queue|Worker|Job|Bull") → ジョブ処理
       • Grep("EventEmitter|publish|subscribe") → イベント駆動
       • Grep("Cache|Redis|Memcached") → キャッシュ
       • Grep("CircuitBreaker|Retry") → レジリエンス
     • 検出したパターンを「Status: Detected」（未監査）として追加します
     • パターン名が一致する既存の ADR へのリンクを追加します
     • 次のようにマークします：``
   • {{PLACEHOLDER}} を Context Store の値に置き換えます
   • 共通の冒頭契約を保持します：SCOPE、DOC_KIND、DOC_ROLE、READ_WHEN、SKIP_WHEN、PRIMARY_SOURCES
   • 標準の上部セクションを保持します：Quick Navigation、Agent Entry、Maintenance
   • SRC_STRUCTURE から C4 図を生成します（レガシー図がない場合の architecture.md）
   • ADR リンクを挿入します（architecture.md のセクション 8）
   • 公開するプロジェクトドキュメントにテンプレートマーカーを残さないでください
   • データが不足している場合：記述を省くか、簡潔で中立的な代替表現を使用します。ただし、[TBD: ...] は出力しないでください

フェーズ 3：自己検証する

作成した各ドキュメントについて：

1. 冒頭ブロックの SCOPE タグとメタデータマーカーを確認します
2. 必須の上部セクション（Quick Navigation、Agent Entry、Maintenance）を確認します
3. 必須セクション（questions_core.md に記載）を確認します
4. 個別の形式要件を検証します：
   • requirements.md：FR-XXX 識別子、MoSCoW ラベル
   • architecture.md：11 セクション、C4 図、ADR 参照
   • tech_stack.md：各テクノロジーのバージョンと採用理由
5. docs-quality 契約への準拠を確認します（禁止されたプレースホルダーがないこと、テンプレートのメタデータが漏れていないこと、有効なドキュメント種別／役割であること）
6. 可能な場合は問題を自動修正します

フェーズ 4：ステータスを返す

コーディネーターに次を返します：

{
  "created_files": ["docs/project/requirements.md", "docs/project/architecture.md", "docs/project/tech_stack.md", "docs/architecture/patterns_catalog.md"],
  "skipped_files": [],
  "quality_inputs": {
    "doc_paths": ["docs/project/requirements.md", "docs/project/architecture.md", "docs/project/tech_stack.md", "docs/architecture/patterns_catalog.md"],
    "owners": {
      "docs/project/requirements.md": "ln-112-project-core-creator",
      "docs/project/architecture.md": "ln-112-project-core-creator",
      "docs/project/tech_stack.md": "ln-112-project-core-creator",
      "docs/architecture/patterns_catalog.md": "ln-112-project-core-creator"
    }
  },
  "validation_status": "passed",
  "diagrams_generated": 3
}

重要事項

• 冪等性： 既存のファイルは決して上書きしないでください
• 徹底した自動検出： architecture.md の作成には、プロジェクトの詳細な分析が必要です
• C4 図： SRC_STRUCTURE から Mermaid 形式で生成します
• ADR 連携： セクション 8 で docs/reference/adrs/ にリンクします
• arc42 準拠： ISO/IEC/IEEE 42010:2022 の構造に従います
• 公開可能な出力： 中核となるプロジェクトドキュメントに [TBD: ...]、TODO、テンプレートのメタデータが残っていてはいけません

NO_CODE_EXAMPLES ルール（必須）

ドキュメントでは実装ではなく、契約と決定事項を説明します：

• 禁止： 5 行を超えるコードブロック、関数の実装、インポート、DI 設定
• 許可： Mermaid 図、コンポーネント表、メソッドシグネチャ（1 行）、ADR リンク
• コードの代わりに： ソースを参照します：「src/Services/UserService.cs:45 を参照」
• テンプレートルール： すべてのテンプレートに `` タグが含まれています。これに従ってください

スタック適応ルール（必須）

• リンクには、スタックに適したドキュメントを指定します（.NET の場合は Microsoft、JS の場合は MDN）
• スタックの異なる参照を混在させないでください（.NET プロジェクトに Python の例を含めないでください）

形式の優先順位（必須）

表 > Mermaid／ASCII 図 > リスト > テキスト

実行時サマリーアーティファクト

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

任意の summaryArtifactPath を受け付けます。

サマリーの種類：

• docs-generation

必須ペイロードの内容：

• worker = "ln-112"
• status
• created_files
• skipped_files
• quality_inputs
• validation_status
• warnings

指定されたアーティファクトパスにサマリーを書き込むか、構造化出力で同じエンベロープを返してください。

完了の定義

• コンテキストストアを受け取り、検証済み
• 4つのコアドキュメントを作成済み（既存の場合はスキップ）
• C4 図を生成済み（コンテキスト、コンテナー、コンポーネント）
• ADR リンクを設定済み
• パターンを自動検出し、カタログに追加済み
• 自己検証に合格済み（メタデータマーカー、トップセクション、形式）
• 最新性を検証済み： すべてのドキュメントの事実が現在のコードと一致（パス、関数、API、設定が存在し、正確）
• ステータスを返却済み

参照ファイル

• テンプレート：references/templates/requirements_template.md、references/templates/architecture_template.md、references/templates/tech_stack_template.md
• パターンのテンプレート：references/templates/patterns_template.md
• 質問：references/questions_core.md（Q23-Q38）

---

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