context-driven-development

context-driven-development スキルの概要

context-driven-development スキルでできること

context-driven-development スキルは、conductor/ ディレクトリ内に少数のプロジェクトコンテキスト用アーティファクトを作成・維持し、AI支援開発の前提情報を安定して再利用できる状態に整えるためのものです。毎回のチャットでプロジェクト説明をやり直す代わりに、product.md、tech-stack.md、workflow.md、tracks.md といった中核ドキュメントを定義し、プロジェクトの進行に合わせて更新していきます。

どんな人に向いているか

このスキルは、Conductor流のワークフロー、複数セッションにまたがるAI開発、あるいはプロジェクトの意図・技術選定・作業管理をプロンプト間で一貫させたいチーム環境に特に向いています。とくに有効なのは次のようなケースです。

• 新規プロジェクトの立ち上げ
• 既存コードベースにAIエージェントをオンボードするとき
• 再現性のあるプロジェクトコンテキストを持ちたいチーム
• セッションをまたぐたびに文脈が失われることに疲れているユーザー

このスキルが実際に解決する課題

多くのユーザーが必要としているのは「ドキュメントを増やすこと」ではありません。AIの出力がだんだんズレていくのを止めることです。context-driven-development の実務上の役割は、あいまいでセッション内に閉じたプロジェクト知識を、実装タスク・計画・引き継ぎをまたいで生き続ける管理可能なアーティファクトに変えることにあります。

通常のプロンプトと何が違うか

通常のプロンプトでも、アプリの説明を一度することはできます。ですが context-driven-development skill は、その説明を時間の経過とともに最新かつ内部整合の取れた状態で保つための構造を提供します。差別化ポイントはコード生成そのものではなく、開発の前後でコンテキストを足場化し、同期し続けることにあります。

ハマる場合に得られるもの

context-driven-development for Context Engineering を使う主なメリットは、継続性の向上です。

• プロダクト意図が明確になる
• スタック選定が文書化される
• ワークフロー上の期待値が明文化される
• ばらばらの TODO ではなく、追跡可能な作業単位で管理できる
• ブラウンフィールドのリポジトリでもエージェントを載せやすくなる

向いていないケース

一度きりのコードスニペットだけ欲しい場合、プロジェクト文書を維持するつもりがない場合、あるいは永続的なコンテキストが後続出力の質を上げるようなワークフローを使っていない場合は、このスキルは見送って構いません。同じプロジェクトに繰り返し手を入れるほど、価値が大きくなります。

context-driven-development スキルの使い方

インストール元とスキルの配置場所

このスキルは wshobson/agents リポジトリの plugins/conductor/skills/context-driven-development に含まれています。Skills対応環境での基本的なインストール方法は次のとおりです。

npx skills add https://github.com/wshobson/agents --skill context-driven-development

インストール後は、いきなり実装に入るのではなく、プロジェクトコンテキストを新規作成・更新したいタイミングでAI環境から呼び出すのが基本です。

初回利用前にまず読むべきファイル

最初に迷わず立ち上げたいなら、まず次のファイルを読んでください。

1. plugins/conductor/skills/context-driven-development/SKILL.md
2. plugins/conductor/skills/context-driven-development/references/artifact-templates.md

SKILL.md には、このスキルを使うべき場面、アーティファクト同士の関係、メンテナンスの流れがまとまっています。references/artifact-templates.md は実務面で特に有用で、product.md、tech-stack.md などの期待される形が分かるため、エージェントに必要十分な入力をより速く渡せます。

context-driven-development スキルに必要な入力

このスキルは、コンテキストアーティファクトを生成・更新できるだけの元情報があると最も力を発揮します。質の高い入力には通常、次のような情報が含まれます。

• プロジェクト種別: greenfield か brownfield か
• 現在のリポジトリ構成またはフォルダ構成
• プロダクトの目的と対象ユーザー
• 技術的制約とスタック選定
• 開発ワークフローの好み
• 現在のロードマップ、マイルストーン、作業項目
• README.md、チケット、設計メモ、コードなど既存ドキュメント

「自分のアプリ用にコンテキストを作って」だけだと、出力はどうしても汎用的になります。プロダクト、スタック、ワークフロー、既存リポジトリの根拠まで渡せば、アーティファクトはずっと実用的になります。

Greenfield での使い方: 新規プロジェクトを始める場合

新規プロジェクトでは、コードを書き始める前に context-driven-development で中核アーティファクトをひな形化するのがおすすめです。よい依頼には次の要素が入っています。

• どんなプロダクトか
• 誰のためのものか
• 主要機能のスコープ内・スコープ外
• 想定スタック
• デプロイやテストに関する前提
• 作業をどう追跡したいか

この段階での価値が高いのは、実装が始まるまで曖昧なままになりがちな意思決定を、先に言語化させられるからです。

Brownfield での使い方: 既存リポジトリから文脈を抽出する

既存コードベースでは、リポジトリからコンテキストを推定・整理する用途でこのスキルを使います。見るべき対象として、次のようなものを明示すると効果的です。

• ソースツリー
• 依存関係ファイル
• CI 設定
• README と issue の履歴
• 既存ドキュメント
• 命名規則やワークフローの手がかり

ここで導入効果を実感するユーザーは多く、context-driven-development guide を使うことで、「動いてはいるが説明しづらい」リポジトリを、後からエージェントが再利用できるアーティファクトに変えやすくなります。

中核アーティファクトとそれぞれの役割

このリポジトリは、conductor/ 内に置くいくつかの永続ファイルを中心に設計されています。

• product.md: 課題、ユーザー、解決策、機能、指標、ロードマップ
• tech-stack.md: 言語、フレームワーク、依存関係、インフラ、ツール
• workflow.md: 開発をどう進める想定か
• tracks.md: 作業単位、状態、継続的なデリバリーの整理

重要なのは、単にファイルを作ることではなく、それぞれの関係性です。プロダクト判断はスタック選定と噛み合っているべきですし、ワークフロールールはチームの実態に合っているべきです。追跡している作業も、ロードマップや実装優先度と揃っている必要があります。

粗い要望を、強い依頼文に変える

弱いプロンプト:

• “Use context-driven-development for my project.”

よりよいプロンプト:

• “Use context-driven-development to create initial conductor/ artifacts for a brownfield SaaS repo. Infer product scope from README.md, src/, and issue labels. Capture stack choices from package.json, Docker config, and CI. Create product.md, tech-stack.md, workflow.md, and tracks.md. Flag assumptions separately from confirmed facts.”

これがうまく機能する理由:

• リポジトリの状態を明示している
• 作成対象のアーティファクトを指定している
• 根拠にする情報源を示している
• 推測と事実を分けるよう求めている

初回導入におすすめのワークフロー

実践的な context-driven-development usage の流れは次のとおりです。

1. リポジトリとドキュメントから現状の根拠を集める。
2. スキルに中核 conductor/ アーティファクトの初稿を作らせる。
3. 事実誤認や制約漏れがないか確認する。
4. プロダクト、スタック、ワークフロードキュメント間の矛盾を解消する。
5. その後で初めて、それらのアーティファクトに依存する実装や計画タスクに進む。
6. スコープ、アーキテクチャ、ワークフローに大きな変更があったら再実行する。

この順番には意味があります。このスキルは単発で文書を生成するためではなく、その後の作業の精度を底上げするために設計されているからです。

アーティファクトテンプレートをうまく使う方法

references/artifact-templates.md は、スキル側の情報が不足しているときに特に役立ちます。足りないセクションをエージェントに埋めさせるのではなく、テンプレート項目に対して直接答えを渡してください。たとえば次のような項目です。

• 対象ペルソナ
• 機能のステータス
• 成功指標
• 依存関係の採用理由
• ホスティング方針
• テストと lint のツールチェーン

テンプレートのどれだけを実際の制約で埋められるかで、後工程の手直し量は大きく変わります。

出力品質を大きく左右する実践的なコツ

context-driven-development usage の結果を良くしたいなら、次の点が効きます。

• 不明点を明示的にマークするよう依頼する
• 現在の状態と目指す将来像を分ける
• 判断が確定済みか、暫定か、未決定かを伝える
• workflow.md が重要なら、チームの進め方の具体例を渡す
• アーティファクト受け入れ前に整合性チェックを求める

便利なのは “Draft, then validate for cross-file contradictions.” という進め方です。たとえば、ロードマップではモバイルアプリを約束しているのに、スタックやワークフローは Web 限定の MVP を前提にしている、といったズレを検出できます。

context-driven-development スキル FAQ

すでに良いプロンプトを書けるなら、context-driven-development を入れる価値はあるか

同じプロジェクトを何度も扱うなら、たいていはあります。よいプロンプトは1セッションでは有効です。一方 context-driven-development skill は、後続のプロンプトがゼロから組み立て直さなくても参照できる、持続性のあるコンテキストを作る助けになります。

初心者でも使いやすいか

はい。ただし、プロジェクトに関する基本的な問いには答えられることが前提です。このスキルが与えるのは構造であって、事業の明確さそのものではありません。プロジェクト目標がまだ曖昧な初心者だと、ユーザー、機能、制約をより具体化するまでは、出力も汎用的になりやすいです。

Conductor でしか使えないのか

Conductor流のコンテキストアーティファクト向けに設計されているため、最も相性がよいのはその環境です。ただし、根本にある方法論自体は移植可能です。プロダクト、スタック、ワークフロー、作業追跡を構造化した文書は、ほかのAI支援開発環境でも役立ちます。

このスキルの主な限界は何か

実装の専門知識やシステム設計レビューを置き換えるものではありません。context-driven-development が最も強いのは、プロジェクトコンテキストを整理し、アーティファクト間の関係を浮かび上がらせ、ドキュメントと実作業を揃え続ける点です。

README を整備するだけではだめなのか

README は通常、外向けで広く浅い説明になりがちです。このスキルが目指すのは、開発のための運用コンテキストです。つまり、何を作るのか、なぜそのスタックなのか、作業がどう進むのか、エージェントのセッションをまたいで何を一貫させるべきか、という情報です。

どんなときに context-driven-development を使うべきでないか

小さな使い捨て実験、単発スクリプト、あるいはアーティファクトを保守しないプロジェクトには向きません。価値が出るのは初稿を作る瞬間ではなく、その後も再利用し、同期し続ける運用にあります。

context-driven-development スキルを改善する方法

願望ではなく、根拠を渡す

品質が最も大きく伸びるのは、実際のリポジトリ証拠や決定事項にこのスキルをしっかり接地させたときです。実ファイル、設定、機能一覧を添付または参照してください。願望だけを渡すと、アーティファクトは実務コンテキストではなく、ありがちな企画書のような内容になりがちです。

確認済みの事実と推定した仮説を分けて出させる

ありがちな失敗は、リポジトリから観測できる事実と推測を混ぜてしまうことです。context-driven-development の出力を改善するには、次の2層で整理するよう依頼してください。

• ファイルやドキュメントから確認できたもの
• パターンや不足情報から推定したもの

これだけでレビューはかなり速くなり、意図しないドリフトも減らせます。

各アーティファクトを意思決定中心に引き締める

ユーザーが本当に知りたいのは、そのアーティファクトが後続のコーディングセッションに役立つかどうかです。そのためには、各ファイルを意思決定に結びつく形に寄せるのが有効です。

• product.md: 誰向けか、何の課題か、スコープ、成功指標
• tech-stack.md: 何を採用したか、なぜそれを選んだか
• workflow.md: 変更提案、実装、テスト、レビューをどう進めるか
• tracks.md: 何が進行中か、何がブロックされているか、次に何をやるか、何が完了したか

将来のコーディング判断を導けないセクションなら、削ってしまったほうがよいです。

出力を信用する前に整合性を検証する

このスキルは、次のような矛盾をチェックさせると一気に実用度が上がります。

• プロダクトスコープがロードマップを超過している
• スタック選定がデプロイ制約と衝突している
• ワークフロー上の期待がリポジトリのツール構成で支えられていない
• tracks が現在の優先度と合っていない

この検証ステップは、context-driven-development for Context Engineering を活かすうえで最も費用対効果の高い習慣のひとつです。

リポジトリ読解の指示をプロンプトに入れる

“analyze my repo” とだけ言うのではなく、どこに事実があるかを具体的に指定してください。たとえば次のように書けます。

• “Use package.json, Dockerfile, .github/workflows/, and README.md as primary evidence.”
• “Treat issue labels and milestone names as workflow clues.”
• “Prefer explicit config over naming heuristics.”

こうすると、スタックやプロセスに関する幻覚が減ります。

初稿の前に詰めすぎず、初稿の後で磨く

よい進め方は draft -> review -> refine です。まずは完全なアーティファクト一式を出させ、その後の2回目で次のような調整を依頼します。

• generic filler を削る
• 抜けている制約を追加する
• 仮定を質問に変える
• tracks をロードマップに揃える
• 分かる範囲で正確なバージョンを入れ、スタック採用理由を更新する

最初のプロンプトを完璧にしようとするより、この反復のほうがたいてい結果は良くなります。

プロジェクト変化に合わせてアーティファクトを生かし続ける

context-driven-development install の判断が意味を持つのは、ドキュメントが最新状態を保っている場合だけです。次のような変化があったら、スキルを再実行するか、内容を見直してください。

• アーキテクチャが変わった
• 優先順位が変わった
• ツール構成が変わった
• オンボーディングで詰まりが出始めた
• エージェントの出力が実際のプロジェクト実態からズレ始めた

古いコンテキストは、コンテキストがない状態より悪いことがあります。誤った前提に自信を与えてしまうからです。