Setup project context

Setup Project Context Skill

リポジトリのコードベースを自動調査し、.claude/skills/references/project-context.md を生成する。

テンプレート（project-context-template.md）の各セクションにある HTML コメント（<!-- -->）を、調査結果に基づくプロジェクト固有の情報で置き換える。

前提条件

• 対象リポジトリのルートディレクトリで実行すること

手順

1. テンプレートの読み込み

プラグイン内のテンプレートファイルを読み込む。

plugins/dev-workflow/skills/references/project-context-template.md

テンプレートの構造を把握し、各セクションで何を記述すべきかを理解する。

2. コードベースの調査

以下の観点でリポジトリを網羅的に調査する。調査は推測ではなく、実際にファイルを読んで確認した事実に基づくこと。

2-1. プロジェクト基本情報

• 言語・フレームワーク: 使用言語、主要フレームワーク、ランタイムバージョン
• ビルドツール: ビルドシステム、パッケージマネージャ（Gradle, Maven, Go modules, npm, pnpm, Cargo など）
• エントリポイント: package.json, go.mod, build.gradle.kts, Cargo.toml, pom.xml 等のプロジェクト定義ファイル

2-2. ディレクトリ構成

• トップレベルのディレクトリ構造を把握する
• モノレポの場合はワークスペース構成を確認する（pnpm-workspace.yaml, settings.gradle.kts, go.work など）
• src/, lib/, internal/, pkg/, app/, cmd/ などの主要ディレクトリの役割を把握する

2-3. テスト構成

• テストフレームワーク（Jest, Vitest, Go testing, JUnit, pytest など）
• テストの種類（ユニット、統合、E2E）ごとの配置場所とディレクトリ構成
• テスト実行コマンド
• テストに必要な外部依存（Docker, テスト用 DB など）

2-4. ビルド・開発ツール

• フォーマッター（prettier, gofumpt, spotless, rustfmt など）とその実行コマンド
• リンター（eslint, golangci-lint, clippy など）とその実行コマンド
• ビルドコマンド
• CI 構成ファイル（.github/workflows/, .circleci/ など）を確認し、CI で実行される検証項目を把握する

2-5. 既存パターン

• アーキテクチャパターン（レイヤードアーキテクチャ、クリーンアーキテクチャ、DDD など）
• 拡張ポイント（インターフェース、SPI、プラグインシステム、レジストリ、DI など）
• 命名規則やコーディング規約の傾向

2-6. ラベル・ワークフロー

• GitHub Labels の一覧を確認する（gh label list が使える場合）
• Kind/Type prefix の規約を把握する
• コード生成ツールの有無を確認する

3. ユーザーへのヒアリング

自動調査だけでは把握しきれない情報をユーザーに確認する。以下の観点でまとめて質問し、回答を生成内容に反映する。

• 自動調査で判断がつかなかった項目: 複数の可能性があり特定できなかったもの（例: テストで Docker が必要かどうか、フォーマッターの優先順位）
• 暗黙知・運用ルール: コードからは読み取れないチーム固有の規約や慣習（例: 「統合テストは CI に任せる」「PR には必ず Kind ラベルを付ける」）
• 追加したい情報: テンプレートのセクションに収まらないプロジェクト固有の注意事項や補足

質問は箇条書きでまとめて一度に提示し、やり取りの往復を最小限にする。ユーザーが「特にない」と回答した場合は自動調査の結果のみで生成を進める。

4. project-context.md の生成

テンプレートの各セクションを調査結果とヒアリング内容で埋め、.claude/skills/references/project-context.md に出力する。

記述ルール

• テンプレートの HTML コメント（<!-- -->）はすべて削除し、実際の内容に置き換える
• 該当しないセクションは、セクション見出しを残した上で「該当なし」と記載する（セクション自体は削除しない）
• 具体的なコマンドやパスは、実際にリポジトリ内で確認できたものだけを記載する
• テーブルのカラム構成はプロジェクトに合わせて調整してよい

セクション別の記述ガイド

コードベース調査ガイド

• モジュール構成の把握方法: 最初に読むべきファイル（ビルド定義、ワークスペース設定）を具体的に列挙する
• 既存パターンの調査手順: 新機能実装時にリファレンスとすべきディレクトリやファイルパターンを記載する。拡張ポイント（インターフェース、SPI、レジストリ等）があれば具体的に示す
• テスト構成の確認方法: テストの種類ごとに配置場所と実行方法を記載する

実装ガイド

• ビルド・フォーマットコマンド: フォーマッター、リンター、ビルド、テストの各コマンドを列挙する。注意事項（例: go fmt ではなく gofumpt を使う）も記載する
• 言語固有の実装規約: コードベースから読み取れる規約を記載する（例: ドキュメントコメントの言語、エラーハンドリングパターン）
• テスト配置ルール: テストファイルの配置先ルールを具体的なパスで記載する
• 実装順序: モノレポなど実装順序が重要な場合のみ記載する
• CI に委ねてよい項目: ローカルでの実行が困難な検証項目を CI 構成ファイルから特定して記載する

レビューガイド

• ファイルパス → カテゴリマッピング: リポジトリのディレクトリ構成から、パスパターンとレビューカテゴリ（architecture, code, test, security, docs, build）の対応表を作成する
• カテゴリ別レビュー観点: 各カテゴリについてプロジェクト固有の観点を記載する
• セキュリティチェックリスト: プロジェクトの技術スタックに応じたセキュリティチェック項目を記載する
• テストカバレッジマトリクス: プロジェクトのテスト種類に合わせたカラム構成を記載する

プランテンプレート補足

• 影響範囲テーブル: プロジェクトの単位（パッケージ、モジュール、サービスなど）に合わせたカラム構成を記載する
• ファイル構成の記述例: プロジェクトの典型的なパス表記例を記載する
• テスト戦略テーブル: プロジェクトのテスト種類に合わせたカラム構成を記載する
• ドキュメント更新対象: プロジェクト内のドキュメントファイルと更新条件を列挙する

ラベル・ワークフロー規約

• Issue/PR ラベルの prefix: 実際の GitHub Labels から prefix を記載する
• コード生成: コード生成ツールがある場合のみ記載する

5. 既存ファイルの確認と出力

mkdir -p .claude/skills/references

既存ファイルがない場合

生成した内容を .claude/skills/references/project-context.md に書き込む。

既存ファイルがある場合

1. 生成した内容を一時ファイル .claude/skills/references/project-context.md.new に書き込む
2. 既存ファイルと新規生成ファイルをセクション単位で比較し、差分をユーザーに提示する
   • 変更があるセクションのみを表示する
   • 各セクションについて「既存の記述」と「新規生成の記述」を並べて見せる
3. ユーザーに以下の選択肢を提示する:
   • 全体を上書き: 新規生成の内容で全体を置き換える
   • セクション単位で選択: セクションごとに既存を残すか新規に置き換えるかを選ぶ
   • キャンセル: 既存ファイルをそのまま維持する（一時ファイルは削除）
4. ユーザーの選択に従ってファイルを更新し、一時ファイルを削除する

6. 結果の報告

生成した project-context.md の内容をユーザーに報告する。以下を含めること:

• 生成したファイルのパス
• 各セクションの概要（何を記載したか）
• 手動で確認・補完が必要な箇所があればその指摘

注意事項

• 推測ではなく、実際にファイルを読んで確認した事実に基づいて記述すること
• コマンドは実際に実行可能なものだけを記載すること（存在しない Makefile ターゲットなどを書かない）
• テンプレートの構造（セクション見出し・テーブル形式）は維持し、他のスキルが参照するセクション名を変更しないこと