Context-Driven Development

コードと並行して管理されるアーティファクトとしてのコンテキストを実装・維持するためのガイド。構造化されたプロジェクトドキュメントを通じて、一貫した AI インタラクションとチームの整合性を実現します。

このスキルを使用する場面

• Conductor でプロジェクトをセットアップするとき
• コンテキストアーティファクト間の関係を理解するとき
• AI 支援開発セッション間での一貫性を維持するとき
• 既存の Conductor プロジェクトに新しいチームメンバーをオンボードするとき
• コンテキストドキュメントを更新すべき時期を判断するとき
• グリーンフィールド対ブラウンフィールドのプロジェクトコンテキストを管理するとき

コアフィロソフィ

Context-Driven Development は、プロジェクトのコンテキストをコードと並行して管理される第一級のアーティファクトとして扱います。場当たり的なプロンプトや散在するドキュメントに頼るのではなく、すべての AI インタラクションを導く永続的で構造化された基盤を確立します。

主要な原則：

1. コンテキストはコードより先に: 実装する前に何を構築し、どのようにするかを定義する
2. 生きたドキュメント: コンテキストアーティファクトはプロジェクトとともに進化する
3. 単一の情報源: 各情報タイプに対する 1 つの規範的な場所
4. AI アライメント: 一貫したコンテキストは一貫した AI 動作を生み出す

ワークフロー

コンテキスト → 仕様・計画 → 実装ワークフローに従います：

1. コンテキストフェーズ: プロジェクトコンテキストアーティファクトの存在と現在性を確立または確認する
2. 仕様フェーズ: 作業単位の要件と受け入れ基準を定義する
3. 計画フェーズ: 仕様を段階的で実行可能なタスクに分割する
4. 実装フェーズ: 確立されたワークフローパターンに従ってタスクを実行する

アーティファクトの関係

product.md - WHAT と WHY を定義

目的：プロダクトビジョン、目標、ターゲットユーザー、およびビジネスコンテキストをキャプチャします。

内容：

• プロダクト名と 1 行の説明
• 問題ステートメントとソリューションアプローチ
• ターゲットユーザーペルソナ
• コア機能と能力
• 成功メトリクスと KPI
• プロダクトロードマップ（高レベル）

更新時期：

• プロダクトビジョンまたは目標が変わるとき
• 新しい主要機能が計画されるとき
• ターゲットユーザーがシフトするとき
• ビジネス優先度が変わるとき

product-guidelines.md - コミュニケーション方法を定義

目的：ブランドボイス、メッセージング標準、およびコミュニケーションパターンを確立します。

内容：

• ブランドボイスとトーンガイドライン
• 用語とグロッサリー
• エラーメッセージの規約
• ユーザー向けコピーの標準
• ドキュメント化スタイル

更新時期：

• ブランドガイドラインが変わるとき
• 新しい用語が導入されるとき
• コミュニケーションパターンの改善が必要なとき

tech-stack.md - 何で構築するかを定義

目的：技術選択、依存関係、およびアーキテクチャ決定をドキュメント化します。

内容：

• プライマリ言語とフレームワーク
• バージョン付きの主要な依存関係
• インフラストラクチャとデプロイターゲット
• 開発ツールと環境
• テストフレームワーク
• コード品質ツール

更新時期：

• 新しい依存関係を追加するとき
• メジャーバージョンをアップグレードするとき
• インフラストラクチャを変更するとき
• 新しいツールまたはパターンを採用するとき

workflow.md - どのように作業するかを定義

目的：開発プラクティス、品質ゲート、およびチームワークフローを確立します。

内容：

• 開発方法論（TDD など）
• Git ワークフローとコミット規約
• コードレビュー要件
• テスト要件とカバレッジターゲット
• 品質保証ゲート
• デプロイメント手順

更新時期：

• チームプラクティスが進化するとき
• 品質標準が変わるとき
• 新しいワークフローパターンが採用されるとき

tracks.md - 何が起きているかを追跡

目的：ステータスとメタデータを持つすべての作業単位のレジストリ。

内容：

• 現在のステータス付きのアクティブなトラック
• 完了日付付きの完了したトラック
• トラックメタデータ（タイプ、優先度、担当者）
• 個別のトラックディレクトリへのリンク

更新時期：

• 新しいトラックが作成されるとき
• トラックステータスが変わるとき
• トラックが完了またはアーカイブされるとき

コピーペースト用の初期テンプレートは references/artifact-templates.md を参照してください。

コンテキスト保守原則

アーティファクトの同期を保つ

1 つのアーティファクトの変更が関連ドキュメントに反映されることを確認します：

• product.md での新しい機能 → 新しい依存関係が必要な場合は tech-stack.md を更新
• 完了したトラック → product.md を更新して新しい機能を反映
• ワークフロー変更 → 影響を受けるすべてのトラック計画を更新

依存関係を追加するときに tech-stack.md を更新

新しい依存関係を追加する前に：

1. 既存の依存関係が必要性を解決するかどうかをチェック
2. 新しい依存関係の根拠をドキュメント化
3. バージョン制約を追加
4. 設定要件を記述

機能が完了したときに product.md を更新

機能トラックの完了後：

1. product.md で機能を「計画済み」から「実装済み」に移動
2. 影響を受けたサクセスメトリクスを更新
3. 元の計画からのスコープ変更をドキュメント化

実装前にコンテキストを検証

任意のトラックを開始する前に：

1. すべてのコンテキストアーティファクトを読む
2. 古い情報にフラグを付ける
3. 実装を進める前に更新を提案
4. ステークホルダーとのコンテキスト精度を確認

グリーンフィールド対ブラウンフィールドハンドリング

グリーンフィールドプロジェクト（新規）

新規プロジェクト向け：

1. /conductor:setup を実行して、すべてのアーティファクトをインタラクティブに作成
2. プロダクトビジョン、技術選好、およびワークフローに関する質問に答える
3. 選択した言語向けの初期スタイルガイドを生成
4. 空のトラックレジストリを作成

特徴：

• コンテキスト構造を完全に制御
• コードが存在する前に標準を定義
• パターンを早期に確立

ブラウンフィールドプロジェクト（既存）

既存のコードベース向け：

1. 既存コードベース検出を使用して /conductor:setup を実行
2. システムが既存コード、設定、およびドキュメントを分析
3. 検出されたパターンに基づいてアーティファクトを事前入力
4. 生成されたコンテキストを確認および調整

特徴：

• 既存コードから暗黙的なコンテキストを抽出
• 既存パターンを希望パターンと調整
• 技術的負債と最新化計画をドキュメント化
• 動作パターンを保持しながら標準を確立

メリット

チームの整合性

• 明示的なコンテキストでスムーズにオンボード
• チーム全体で一貫した用語と規約
• プロダクト目標と技術決定の共有理解

AI の一貫性

• AI アシスタントはセッション全体で整合出力を生成
• 各インタラクションでコンテキストを再説明する必要が削減
• ドキュメント化された標準に基づいた予測可能な動作

組織的な記憶

• 決定と根拠が保持される
• チーム変更時にコンテキストが生き残る
• 歴史的コンテキストが将来の決定を導く

品質保証

• 標準は明示的で検証可能
• コンテキストからの逸脱は検出可能
• 品質ゲートはドキュメント化および実行可能

ディレクトリ構造

conductor/
├── index.md              # Navigation hub linking all artifacts
├── product.md            # Product vision and goals
├── product-guidelines.md # Communication standards
├── tech-stack.md         # Technology preferences
├── workflow.md           # Development practices
├── tracks.md             # Work unit registry
├── setup_state.json      # Resumable setup state
├── code_styleguides/     # Language-specific conventions
│   ├── python.md
│   ├── typescript.md
│   └── ...
└── tracks/
    └── <track-id>/
        ├── spec.md
        ├── plan.md
        ├── metadata.json
        └── index.md

コンテキストライフサイクル

1. 作成: /conductor:setup を通じた初期セットアップ
2. 検証: 各トラックの前に検証
3. 進化: プロジェクト成長に応じて更新
4. 同期: アーティファクトを整合させ続ける
5. アーカイブ: 歴史的決定をドキュメント化

コンテキスト検証チェックリスト

任意のトラックで実装を開始する前に、コンテキストを検証します：

プロダクトコンテキスト

• product.md は現在のプロダクトビジョンを反映している
• ターゲットユーザーが正確に説明されている
• 機能リストが最新である
• サクセスメトリクスが定義されている

技術コンテキスト

• tech-stack.md がすべての現在の依存関係をリストしている
• バージョン番号が正確である
• インフラストラクチャターゲットが正しい
• 開発ツールがドキュメント化されている

ワークフローコンテキスト

• workflow.md が現在のプラクティスを説明している
• 品質ゲートが定義されている
• カバレッジターゲットが指定されている
• コミット規約がドキュメント化されている

トラックコンテキスト

• tracks.md がすべてのアクティブな作業を示している
• 古い、または放棄されたトラックがない
• トラック間の依存関係が記されている

一般的なアンチパターン

これらのコンテキスト管理ミスを回避します：

古いコンテキスト

問題：コンテキストドキュメントが古くなり、誤解を招く。 解決策：各トラックの完了プロセスの一部としてコンテキストを更新します。

コンテキストの拡散

問題：情報が複数の場所に散在している。 解決策：定義されたアーティファクト構造を使用します。新しいドキュメントタイプの作成に抵抗します。

暗黙的なコンテキスト

問題：アーティファクトにキャプチャされていない知識に依存している。 解決策：何かを繰り返し参照する場合は、適切なアーティファクトに追加します。

コンテキスト独占

問題：1 人がチーム入力なしでコンテキストを維持している。 解決策：プルリクエストでコンテキストアーティファクトをレビュー。更新を協業的にします。

過度な仕様化

問題：コンテキストが詳細になり過ぎて、維持不可能になっている。 解決策：アーティファクトを AI 動作とチーム整合性に影響する決定に焦点を当てます。

開発ツールとの統合

IDE 統合

コンテキストファイルを目立つように表示するよう IDE を設定します：

• conductor/product.md をピンして素早く参照
• tech-stack.md をプロジェクトノートに追加
• スタイルガイドからの一般的なパターンのスニペットを作成

Git フック

以下を実行する pre-commit フック を検討します：

• 依存関係が変わったのに tech-stack.md が更新されないとき警告
• 機能ブランチがマージされるときに product.md を更新するよう通知
• コンテキストアーティファクト構文を検証

CI/CD 統合

パイプラインにコンテキスト検証を含めます：

• tech-stack.md が実際の依存関係と一致するかをチェック
• コンテキストドキュメント内のリンクが解決するかを確認
• tracks.md ステータスが git ブランチ状態と一致することを確認

セッションの継続性

Conductor はコンテキスト永続性を通じてマルチセッション開発をサポートします：

新しいセッションの開始

1. index.md を読んでオリエンテーション
2. tracks.md でアクティブな作業を確認
3. 関連するトラックの plan.md で現在のタスクを確認
4. コンテキストアーティファクトが現在であることを確認

セッションの終了

1. 現在の進捗で plan.md を更新
2. 実施されたブロッカーまたは決定を記述
3. 明確なステータスで WIP をコミット
4. ステータスが変わった場合 tracks.md を更新

中断への対応

タスク中断時：

1. タスクを [~] でマークし、停止点に関するメモを付ける
2. 機能ブランチに作業中止をコミット
3. コミットされていない決定を plan.md にドキュメント化

ベストプラクティス

1. 最初にコンテキストを読む: 作業を開始する前に常に関連アーティファクトを読む
2. 小さな更新: 大規模な改分ではなく増分コンテキスト変更を行う
3. 決定をリンク: 実装選択時にコンテキストを参照する
4. バージョンコンテキスト: コンテキスト変更をコード変更と並行してコミット
5. コンテキストを確認: コードレビューにコンテキストアーティファクトレビューを含める
6. 定期的に検証: 主要な作業前にコンテキスト検証チェックリストを実行
7. 変更を連絡: コンテキストアーティファクトが大きく変わった場合チームに通知
8. 履歴を保持: git でコンテキスト進化を追跡
9. 古さに疑問を呈する: コンテキストが間違っているように感じたら、調査して更新する
10. 実行可能に保つ: すべてのコンテキスト項目は決定または動作を導くべき