/dev-context

name: dev-context
description: This skill should be used when the user asks to "dev-context", "プロジェクトコンテキストを生成", "プロジェクトを分析", "generate project context", "analyze project", "コンテキストを更新". プロジェクトの技術スタック・テストフレームワーク・コーディング規約・アーキテクチャを自動分析し、コンパクトなコンテキストファイルを生成する。

Dev Context

プロジェクトの技術スタック、テストフレームワーク、コーディング規約、アーキテクチャパターンを自動分析し、後続のdev-plan/dev-impl/dev-verify/dev-debugスキルが参照するコンパクトなコンテキストファイル（Memory Bank）を `docs/dev/context.md` に生成する。

前提知識

dev-*スキル全体像

本スキルは以下のワークフローの最初のステップ:

dev-context → dev-plan → dev-impl → dev-verify
                                ↘ dev-debug (必要時)

コンテキストファイルの役割

`docs/dev/context.md` は後続スキルの共通基盤:

• **dev-plan**: プロジェクトパターンに沿った設計・タスク分解
• **dev-impl**: テスト規約・命名規則に準拠した実装
• **dev-verify**: テスト・ビルド・Lintコマンドの取得
• **dev-debug**: 環境情報・依存関係の把握

500行以内のコンパクトなファイルにまとめ、後続スキルのコンテキスト消費を最小化する。

ワークフロー

Step 1: 並列探索

Explore サブエージェントを複数並列で起動し、プロジェクト情報を収集する。以下の4領域を並列に探索する:

1a. プロジェクトルート分析

• パッケージ定義ファイルの検出: `package.json`, `Cargo.toml`, `go.mod`, `pyproject.toml`, `build.gradle`, `pom.xml` 等
• 言語・フレームワーク・ランタイムの特定
• パッケージマネージャの特定（npm/yarn/pnpm/bun, cargo, pip/uv 等）

1b. テスト環境分析

• テストフレームワークの検出: Jest, Vitest, pytest, go test, cargo test, JUnit 等
• テスト設定ファイルの確認
• テスト実行コマンドの特定
• テストディレクトリの構造把握

1c. ディレクトリ構造分析

• 主要ディレクトリの役割マッピング（src/, lib/, tests/, docs/ 等）
• エントリポイントの特定
• モジュール構成の把握（モノレポ判定含む）

1d. コード規約サンプリング

• 代表的なソースファイルを3-5個読み込み
• 命名規則の推定（camelCase, snake_case, PascalCase 等）
• エラーハンドリングパターンの抽出
• ログ方式の特定
• インポートスタイルの確認

**サブエージェント設定**: `subagent_type: Explore`, `model: haiku`（高速・低コスト）

Step 2: 情報統合

サブエージェントの結果を統合し、追加情報を取り込む。**各ファイルの読み込みには行数上限を設け、コンテキスト消費を制限する**:

1. **CLAUDE.md の読み込み**（上限: **100行**）: プロジェクトルートに CLAUDE.md がある場合:

• 100行以内 → そのまま Read で読み込み統合する
• 100行超過 → Explore サブエージェント（`model: haiku`）で全文を読ませ、コーディング規約・テスト方針・ビルド手順の **要約のみ** 取得する

2. **README.md の読み込み**（上限: **100行**）: プロジェクト概要がある場合:

• Read の `limit: 100` で **先頭100行のみ** 読み込む（概要は通常先頭にある）

3. **設定ファイルの確認**（各上限: **50行**）: .eslintrc, .prettierrc, tsconfig.json 等:

• 各ファイルを Read の `limit: 50` で読み込み、追加規約を抽出する

4. **リポマップ生成**: 主要モジュールとエントリポイントの一覧を構造化する（Aider的アプローチ）

Step 3: コンテキストファイル出力

`docs/dev/context.md` を生成する。`references/context-template.md` のテンプレートに従い、500行以内に収める。

出力前に `docs/dev/` ディレクトリが存在しない場合は作成する（プロジェクトルートの絶対パスを使用）:

mkdir -p "$(git rev-parse --show-toplevel)/docs/dev"

既存の `docs/dev/context.md` がある場合は上書きする。差分がある場合はユーザーに通知する。

信号機システム

生成したコンテキストファイルの各セクションに確信度を付与する:

• 🔵 **前工程指示**: パッケージ定義ファイルや設定ファイルから直接読み取れた情報
• 🟡 **妥当な推測**: コードサンプリングから推定した規約・パターン
• 🔴 **AI推論補完**: 明確な根拠がなくAIが推測した情報（組織固有のルール等）

ルール・制約

• context.md は **500行以内** に収める。超える場合は情報を要約・圧縮する
• サブエージェントの結果は要約のみメインコンテキストに返す（トークン節約）
• プロジェクト全体のコードを読まない。代表的なファイル（3-5個）からパターンを推定する
• テスト実行コマンドは必ず含める（後続スキルが依存）
• ビルドコマンドは検出できた場合のみ含める
• 既存の `docs/dev/plans/` 配下のファイルには影響を与えない
• Bash コマンドはプロジェクトルートの **絶対パス** を使用する（`$(git rev-parse --show-toplevel)` でルートを取得）

追加リソース

リファレンスファイル

• **`references/context-template.md`** — context.md のテンプレートと各セクションの記述ガイド