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 风格工作流、跨多轮会话进行 AI 开发，或者处于团队协作场景中，需要让项目目标、技术栈选择和工作跟踪在不同 prompt 之间保持一致，那么这个 skill 很适合你。尤其适用于：

• 新项目启动阶段
• 给 AI agent 讲清已有代码库
• 希望项目上下文可重复复用的团队
• 经常被会话间上下文丢失困扰的用户

它真正解决的是什么问题

大多数用户缺的并不是“更多文档”，而是让 AI 输出不要越写越偏。context-driven-development 真正要解决的问题，是把原本模糊、只存在于单次会话里的项目知识，转化为一组可管理的上下文工件，让这些信息能跨实现任务、规划过程和交接环节持续生效。

它和普通 prompting 的区别

普通 prompt 可以一次性描述你的应用。context-driven-development skill 则提供了一套结构，帮助你长期保持这份描述的更新与内部一致性。它的核心差异不在于单纯生成代码，而在于在开发前和开发过程中搭建并同步上下文框架。

适合时你能获得什么

如果你把 context-driven-development for Context Engineering 用在合适的场景里，最直接的收益是开发连续性显著提升：

• 产品目标更清晰
• 技术栈决策有文档可追溯
• 工作流预期更明确
• 工作项被结构化跟踪，而不是散落成 TODO
• 对 brownfield 仓库的 agent onboarding 更顺畅

哪些情况下不适合

如果你只想要一段一次性的代码片段、不打算维护项目文档，或者你的工作流并不依赖持久化上下文来提升后续输出质量，那就没必要用这个 skill。context-driven-development 的价值主要体现在同一个项目会被反复使用和持续迭代时。

如何使用 context-driven-development skill

安装上下文与 skill 所在位置

这个 skill 来自 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 说明了这个 skill 适合何时使用、各类工件之间的关系，以及后续维护流程。references/artifact-templates.md 则更偏实操：它展示了 product.md、tech-stack.md 等文件的预期结构，方便你更快给 agent 提供完整输入。

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

要让这个 skill 真正发挥效果，你需要提供足够的源材料，让它能生成或更新上下文工件。高质量输入通常包括：

• 项目类型：greenfield 还是 brownfield
• 当前仓库或目录结构
• 产品目的和目标用户
• 技术约束与技术栈选择
• 偏好的开发工作流
• 当前 roadmap、里程碑或工作项
• 现有文档，如 README.md、tickets、架构说明或代码

如果你只说一句“帮我的 app 建立上下文”，输出大概率会比较泛。若你能提供产品、技术栈、工作流以及现有仓库证据，生成的工件会更可执行、更能直接用于后续开发。

Greenfield 用法：从新项目开始

对于新项目，最好在写大量代码之前，先用 context-driven-development 搭建核心工件。一个好的请求通常会说明：

• 产品是什么
• 面向谁
• 哪些核心功能在范围内，哪些不在
• 预期技术栈
• 部署和测试要求
• 工作应如何被跟踪

在这个阶段，context-driven-development 的价值尤其明显，因为它会逼你提前做出那些本来常常拖到实现阶段才被迫明确的决策。

Brownfield 用法：从现有仓库提取上下文

对于已有代码库，可以让这个 skill 从仓库里推断并整理上下文。你可以明确让它重点查看：

• 源代码目录树
• 依赖文件
• CI 配置
• README 和 issue 历史
• 现有文档
• 命名约定与工作流线索

很多用户会在这里很快感受到 adoption 价值：context-driven-development guide 能把一个“能跑但很难讲清楚”的仓库，整理成 agent 后续可反复复用的上下文工件。

核心工件以及各自用途

这个仓库围绕 conductor/ 下的几类持久化文件展开：

• product.md：问题定义、用户、解决方案、功能、指标、roadmap
• tech-stack.md：语言、框架、依赖、基础设施、工具
• 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.”

它之所以更有效，是因为：

• 明确了仓库当前状态
• 指定了目标工件
• 给出了证据来源
• 要求把假设和事实分开

首次采用时推荐的工作流

一个实用的 context-driven-development usage 流程如下：

1. 先从仓库和文档中收集当前证据。
2. 让这个 skill 起草核心 conductor/ 工件。
3. 检查事实错误和遗漏的约束。
4. 解决产品、技术栈和工作流文档之间的冲突。
5. 在这之后，再开始依赖这些工件的实现或规划任务。
6. 当 scope、架构或工作流发生较大变化时，重新运行这个 skill。

这个顺序很重要，因为 context-driven-development 的设计目标是提升后续工作质量，而不是只生成一套文档就结束。

怎样更好地使用 artifact templates

当这个 skill 掌握的信息还不完整时，references/artifact-templates.md 会非常有用。与其让 agent 自己补齐缺失章节，不如你直接为模板字段提供明确答案，例如：

• 目标用户画像
• 功能状态
• 成功指标
• 依赖选择的原因
• 托管方案
• 测试与 lint 工具链

你能用真实约束填得越完整，后续清理和返工就越少。

会明显影响输出质量的实用技巧

想获得更好的 context-driven-development usage 结果，可以这样做：

• 要求 agent 明确标出未知项
• 把当前状态和目标状态区分开
• 说明哪些决策已经确定、哪些只是暂定、哪些仍未决定
• 如果 workflow.md 很关键，就提供团队工作流示例
• 在接受工件前，要求先做一致性检查

一个很好用的模式是：“先起草，再检查跨文件冲突。” 这样能及时发现一些错位，例如 roadmap 承诺了移动端应用，但技术栈和工作流却明显只支持 web-only MVP。

context-driven-development skill 常见问题

如果我本来就很会写 prompt，还有必要装 context-driven-development 吗

通常有必要，尤其是你会反复处理同一个项目时。好的 prompt 能改善单次会话效果；context-driven-development skill 则能把项目上下文沉淀成可持续复用的资产，后续 prompt 可以直接引用，而不必每次从头重建。

它对新手友好吗

友好，但前提是你愿意回答一些基础项目问题。这个 skill 提供的是结构，不是业务判断力。如果你的项目目标本身很模糊，即使是新手使用，也仍然可能只能得到比较泛的工件，直到你把用户、功能和约束说得更具体为止。

它只能配合 Conductor 使用吗

它是围绕 Conductor 风格的上下文工件设计的，所以这是最合适的场景。不过，它背后的方法本身是可迁移的：把产品、技术栈、工作流和跟踪信息结构化下来，在其他 AI 辅助开发环境里同样有帮助。

这个 skill 的主要边界是什么

它不能替代实现能力，也不能替代系统设计评审。context-driven-development 最擅长的是整理项目上下文、显化各类工件之间的关系，并让文档与实际工作保持同步。

它和只维护一个 README 有什么不同

README 通常面向外部读者，内容更宽泛。这个 skill 更强调开发用的操作性上下文：产品是什么、技术栈为什么这么选、工作如何流转，以及哪些信息需要在不同 agent 会话之间保持一致。

什么情况下不该用 context-driven-development

如果只是做很小的一次性实验、临时脚本，或者你根本不会维护这些工件，就不建议使用。context-driven-development 的价值来自持续复用和同步，而不是第一次生成出来的草稿本身。

如何提升 context-driven-development skill 的效果

给 skill 提供证据，而不是愿景

质量提升最明显的一点，是让这个 skill 建立在真实仓库证据和明确决策之上。附上或引用实际文件、配置和功能清单。如果你提供的只有“想做什么”，生成出来的工件就更像泛泛的规划文档，而不是能指导开发的工作上下文。

要求区分已确认事实和推断假设

一个常见失败模式，是把从仓库观察到的事实和模型猜测混在一起。要改善 context-driven-development 的输出，可以要求它按两层来写：

• 已从文件或文档确认的内容
• 根据模式或信息缺口推断的内容

这样复核速度会快很多，也能减少上下文逐步漂移的风险。

让每个工件围绕“决策”收紧

用户最关心的，是这些工件能否真正帮助后续 coding session。改进方式是让每个文件都服务于决策：

• product.md：用户是谁、问题是什么、范围是什么、成功指标是什么
• tech-stack.md：选了哪些工具，为什么选
• workflow.md：变更如何提出、如何实现、如何测试、如何评审
• tracks.md：当前在做什么、卡在哪里、接下来做什么、哪些已完成

如果某个部分无法指导未来的编码决策，就应该删减。

在信任输出前先做一致性验证

当你要求它主动检查矛盾时，这个 skill 会更有用，例如：

• 产品范围超出了 roadmap
• 技术栈选择与部署约束冲突
• 工作流要求并没有得到仓库工具链支持
• tracks 与当前优先级不一致

对 context-driven-development for Context Engineering 来说，这一步验证是最值得养成的高价值习惯之一。

用“如何读仓库”的指令改进 prompt

不要只说“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。先让它产出完整工件，再在第二轮明确要求：

• 删除空泛填充内容
• 补上缺失约束
• 把假设改写成问题
• 让 tracks 与 roadmap 对齐
• 在已知时补充带精确版本号的技术栈依据

相比试图一次把首个 prompt 打磨到完美，这种迭代方式通常更有效。

随着项目变化持续维护工件

是否安装 context-driven-development install，最终值不值得，取决于这些文档能不能保持最新。遇到以下情况时，应重新运行或重新审视这个 skill：

• 架构发生变化
• 优先级发生调整
• 工具链发生变化
• onboarding 摩擦开始增多
• agent 输出开始偏离项目真实情况

过时的上下文往往比没有上下文更糟，因为它会制造一种“看起来很有把握”的错误安全感。