context-driven-development

context-driven-development skill 概覽

context-driven-development skill 的作用

context-driven-development skill 會協助你在 conductor/ 目錄中建立並維護一組精簡但關鍵的專案脈絡文件，讓 AI 輔助開發有穩定、可重用的依據。你不需要在每次對話裡重講一次專案背景，而是先定義像 product.md、tech-stack.md、workflow.md、tracks.md 這類核心文件，之後再隨著專案演進持續更新。

哪些人適合安裝

如果你採用 Conductor 風格工作流、會在多個 session 中與 AI 協作開發，或是在團隊環境裡需要讓專案意圖、技術選擇與工作追蹤在不同 prompt 之間保持一致，那這個 skill 很適合你。尤其適用於：

• 新專案初始化
• 讓 AI agent 快速理解既有 codebase
• 想建立可重複使用專案脈絡的團隊
• 厭倦每次 session 都要重新補上下文的使用者

它真正要解決的工作

大多數使用者真正缺的不是「更多文件」，而是能讓 AI 輸出不要一直漂移的穩定脈絡。context-driven-development 的實際價值，在於把模糊、只存在於單次 session 的專案知識，轉成可管理的 artifacts，讓它們能跨越實作任務、規劃工作與交接情境持續發揮作用。

它和一般 prompting 有什麼不同

一般 prompt 可以在某一次對話中描述你的 app。context-driven-development skill 則提供一套結構，讓這份描述能隨時間持續更新，並維持內部一致性。它的差異化重點不只是幫你產生程式碼，而是在開發前與開發過程中，先把 context 的骨架搭好並同步維護。

適合時你會得到什麼

如果你是把 context-driven-development for Context Engineering 用在長期專案上，最大的回報通常是更好的延續性：

• 產品意圖更清楚
• 技術棧決策有紀錄可查
• 開發流程期望更明確
• 工作項目有結構化追蹤，而不是零散 TODO
• 對 brownfield repo 的 agent onboarding 更順利

什麼情況不適合

如果你只需要一次性的程式碼片段、沒有打算維護專案文件，或你的工作流本來就不會因為持久化 context 而改善後續輸出，那就可以跳過這個 skill。它的價值主要來自同一個專案會被反覆使用與持續演進。

如何使用 context-driven-development skill

安裝來源與 skill 所在位置

這個 skill 來自 wshobson/agents repository，路徑位於 plugins/conductor/skills/context-driven-development。在支援 Skills 的環境中，標準安裝方式是：

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

安裝後，當你需要建立或更新專案 context 時，再從你的 AI 環境中呼叫它，而不是一開始就直接跳進實作。

第一次使用前，先讀這些檔案

如果你想快速上手、降低猜測成本，建議先讀：

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

SKILL.md 會說明什麼時候該用這個 skill、各 artifact 之間的關係，以及後續維護流程。references/artifact-templates.md 則更偏實務加速用途：它直接展示 product.md、tech-stack.md 等檔案應有的結構，讓你更快提供完整輸入給 agent。

context-driven-development skill 需要哪些輸入

context-driven-development skill 在你提供足夠來源材料時效果最好，因為它是要根據這些資料來生成或更新 context artifacts。高品質輸入通常包括：

• 專案類型：greenfield 或 brownfield
• 目前的 repository 或資料夾結構
• 產品目的與目標使用者
• 技術限制與技術棧選擇
• 開發工作流偏好
• 目前的 roadmap、milestones 或工作項目
• 現有文件，例如 README.md、tickets、架構筆記或程式碼

如果你只說「幫我的 app 建立 context」，輸出通常會很泛。若你能提供產品、技術棧、工作流，以及既有 repo 證據，產出的 artifacts 會更能直接拿來用。

Greenfield 用法：從新專案開始

對新專案來說，最適合在程式碼還沒寫太多之前，就先用 context-driven-development 建立核心 artifacts。比較好的請求內容會包含：

• 產品是什麼
• 服務的是哪些人
• 哪些核心功能在範圍內、哪些不在
• 預期使用的技術棧
• 部署與測試的期望
• 工作要怎麼被追蹤

這個階段它特別有價值，因為它會逼你把原本可能要到實作才被迫面對的模糊決策先講清楚。

Brownfield 用法：從既有 repo 萃取 context

如果是既有 codebase，可以請這個 skill 從 repository 中推斷並整理脈絡。你可以明確指向這些來源：

• source tree
• dependency files
• CI config
• README 和 issue 歷史
• 既有文件
• 命名慣例與工作流線索

很多人會在這種情境下很快感受到導入價值：context-driven-development guide 能把一個「明明可運作、但很難解釋清楚」的 repo，轉成之後 agent 可以反覆重用的 artifacts。

核心 artifacts，以及每個檔案的用途

這個 repository 的重心，是放在 conductor/ 裡的一組持久化檔案：

• product.md：問題、使用者、解法、功能、指標、roadmap
• tech-stack.md：語言、frameworks、dependencies、infrastructure、tools
• workflow.md：開發應該如何進行
• tracks.md：工作單元、狀態，或持續交付的組織方式

真正重要的不是「把檔案生出來」而已，而是它們彼此之間要對得起來。產品決策要和技術棧選擇一致，工作流規則要符合團隊實際狀況，追蹤中的工作也要對齊 roadmap 與實作優先順序。

把模糊目標變成高品質呼叫方式

較弱的 prompt：

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

較強的 prompt：

• “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.”

這樣效果更好的原因：

• 有明確指出 repo 目前狀態
• 有點名目標 artifacts
• 有提供證據來源
• 有要求把假設與事實分開

第一次導入時建議的 workflow

一個實用的 context-driven-development usage 流程如下：

1. 從 repo 與文件蒐集目前證據。
2. 請 skill 起草核心 conductor/ artifacts。
3. 檢查內容中的事實錯誤與缺漏的限制條件。
4. 解決產品、技術棧與工作流文件之間的矛盾。
5. 完成上述步驟後，再開始依賴這些 artifacts 的實作或規劃任務。
6. 當 scope、架構或工作流有重大變動時，重新執行這個 skill。

這個順序很重要，因為它的設計目的不是一次性產出文件，而是改善後續所有下游工作。

怎麼善用 artifact templates

當 skill 掌握的資訊還不完整時，references/artifact-templates.md 特別有用。與其讓 agent 自行補齊缺漏段落，不如直接針對 template 欄位提供答案，例如：

• target personas
• feature status
• success metrics
• dependency rationale
• hosting choice
• test and lint toolchain

你能用真實限制填得越多，後面需要清理與返工的量就越少。

會明顯影響輸出品質的實用技巧

如果你想讓 context-driven-development usage 的結果更好，建議這樣做：

• 要求 agent 明確標記未知項
• 把目前狀態與期望未來狀態分開
• 告訴它哪些決策已定案、哪些暫定、哪些尚未決定
• 如果 workflow.md 很重要，提供你們團隊實際 workflow 範例
• 在接受 artifacts 前，要求先做一致性檢查

一個很好用的模式是：「先起草，再檢查跨檔案矛盾。」這能抓出像是 roadmap 承諾了 mobile app，但技術棧與 workflow 卻明顯只支援 web-only MVP 這類不一致。

context-driven-development skill 常見問題

如果我本來就很會寫 prompt，還值得安裝 context-driven-development 嗎

通常值得，前提是你會反覆回到同一個專案。好的 prompt 能幫助你處理單次 session；context-driven-development skill 則是把脈絡做成可持續使用的基礎，讓後續 prompt 可以直接引用，而不是每次從零重建。

這對新手友善嗎

算是友善，但前提是你願意回答一些基本的專案問題。這個 skill 提供的是結構，不是商業判斷或產品清晰度。若新手本身對專案目標仍很模糊，即使使用它，產出的 artifacts 仍可能偏泛，直到使用者把目標使用者、功能與限制條件講得更具體為止。

它只能搭配 Conductor 嗎

它是為 Conductor 風格的 context artifacts 設計的，所以這是最契合的使用情境。不過底層方法本身是可攜的：把產品、技術棧、workflow 與追蹤文件結構化，在其他 AI 輔助開發流程中同樣有幫助。

這個 skill 的主要邊界在哪裡

它不能取代實作能力，也不能取代系統設計審查。context-driven-development 最強的地方，是整理專案 context、釐清 artifacts 之間的關係，以及讓文件內容與實際工作保持一致。

它和只維護一份 README 有什麼不同

README 通常偏向對外說明，內容也比較概括。這個 skill 更強調開發執行層面的 operational context：產品是什麼、技術棧為什麼這樣選、工作如何流動，以及在不同 agent session 之間有哪些東西必須維持一致。

什麼時候不該使用 context-driven-development

如果是很小的拋棄式實驗、一次性腳本，或是你根本不會維護這些 artifacts 的專案，就不建議使用。它的價值來自持續重用與同步維護，而不是第一次起草本身。

如何改進 context-driven-development skill 的使用效果

提供證據，而不是只講理想

想讓品質有明顯提升，關鍵是讓 skill 立足在真實 repo 證據與既有決策上。附上或明確指向實際檔案、config 與功能清單。如果你提供的只有願景或理想，產出的 artifacts 很容易變成泛泛的規劃文件，而不是可操作的工作 context。

要求區分已確認事實與推論假設

一個常見失敗模式，是把從 repo 觀察到的事實與推測混在一起。要改善 context-driven-development 輸出，可以明確要求分成兩層：

• 從檔案或文件確認的事實
• 從模式推斷或因資訊缺漏而做的假設

這會讓後續審查快很多，也能降低脈絡逐漸漂移的風險。

讓每個 artifact 都圍繞「決策」來寫

使用者最在意的，通常不是文件漂不漂亮，而是這些 artifacts 能不能幫到之後的 coding session。要做到這點，就要讓每個檔案都以決策為中心：

• product.md：服務誰、解什麼問題、範圍、成功指標
• tech-stack.md：選了哪些工具，以及為什麼
• workflow.md：變更如何提出、實作、測試、審查
• tracks.md：哪些在進行中、哪些被卡住、下一步是什麼、哪些已完成

如果某個段落無法幫助未來的 coding 決策，就應該考慮刪減。

在信任輸出前，先驗證一致性

當你要求 skill 主動檢查矛盾時，它會變得實用很多，例如：

• 產品範圍超出 roadmap
• 技術棧選擇和部署限制互相衝突
• workflow 期望沒有對應的 repo tooling 支撐
• tracks 沒有反映目前真正的優先順序

對 context-driven-development for Context Engineering 而言，這個驗證步驟是最有價值的習慣之一。

用 repository-reading 指示改善 prompt 品質

不要只說「分析我的 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。先請它產出完整 artifacts，再做第二輪要求，例如：

• 移除泛泛的填充內容
• 補上缺漏的限制條件
• 把假設改寫成待確認問題
• 讓 tracks 對齊 roadmap
• 在已知情況下，把技術棧依據補上確切版本

這種迭代方式，通常比一開始就試圖把第一個 prompt 寫到完美更有效。

隨著專案變動，持續維護 artifacts

只有在文件保持最新時，context-driven-development install 這個決策才會真正回本。以下情況發生時，就應重新執行或回頭更新這個 skill 產出的內容：

• 架構變更
• 優先順序調整
• tooling 改變
• onboarding 摩擦變明顯
• agent 輸出開始偏離專案真實狀態

過時的 context 往往比缺少 context 更糟，因為它會製造一種虛假的把握感。