技能介绍

问题在哪

AI 辅助开发里，上下文往往散落在单次对话、口头约定和零散文档里。换会话要重讲一遍，新人靠猜，技术选型与「为什么这样写」也留不住。结果是输出风格漂移、重复劳动，以及隐式知识随人员流动而丢失。

技能在做什么

本技能描述 上下文驱动开发（Context-Driven Development）：把上下文当成与代码一起版本化的一等产物，用固定结构支撑 上下文 → 规范与计划 → 实现 工作流。

核心原则包括：

上下文先于代码：先界定要做什么、怎么做，再写实现
活文档：product.md、tech-stack.md、workflow.md 等随项目演进
单一事实来源：每类信息有唯一规范位置
AI 对齐：同一套文档让多轮会话行为可预期

典型产物分工：product.md（WHAT/WHY）、product-guidelines.md（沟通与术语）、tech-stack.md（WITH WHAT）、workflow.md（HOW to work）、tracks.md（当前工作单元与状态）。Greenfield 可用 /conductor:setup 从零搭建；Brownfield 则从现有代码与配置反推并预填上下文，再与团队期望对齐。

每个 track 开工前应跑一遍上下文验证清单（产品、技术、工作流、track 是否最新），并把依赖变更、功能完成、工作流调整写回对应产物，避免文档与仓库脱节。

适用边界

任务与「结构化上下文 + Conductor 式工作流」无关时，不必套用全文
需要本技能范围外的其他领域或工具时，应另选技能
警惕陈旧上下文、上下文蔓延与过度规范：产物应聚焦能影响 AI 行为与团队对齐的决策，而不是堆无法维护的细节

截图预览

使用场景

使用 Conductor 搭建全新项目时，先通过 `/conductor:setup` 生成 `product.md`、`tech-stack.md`、`workflow.md` 等产物再创建 track。
新开会话继续开发前，阅读 `index.md` 与 `tracks.md`，并对照相关 track 的 `plan.md` 确认当前任务与阻塞。
在任意 track 进入实现阶段前，按清单验证产品愿景、依赖版本、工作流门禁与活跃 track 是否仍与仓库一致。
引入新依赖或完成功能 track 后，将理由与版本写入 `tech-stack.md`，并把能力状态从 planned 更新到 `product.md`。