Context-Driven Development
Treat project context as a first-class artifact managed alongside code. Instead of relying on ad-hoc prompts or scattered documentation, establish a persistent, structured foundation that informs all AI interactions.
Installation
OpenClaw / Moltbot / Clawbot
CODEBLOCK0
WHAT This Skill Does
Creates and maintains a set of context documents that:
- - Define what you're building and why (product.md)
- Specify technology choices and constraints (tech-stack.md)
- Establish how the team works (workflow.md)
- Track what's happening (tracks.md)
WHEN to Use
Use for:
- - Setting up new projects with AI-assisted development
- Onboarding team members to existing codebases
- Ensuring consistent AI behavior across sessions
- Documenting decisions that affect code generation
- Managing projects with multiple contributors or AI assistants
Skip for:
- - Solo experiments or throwaway prototypes
- Single-file scripts
- Projects without AI assistance
Keywords: context, project setup, documentation, AI alignment, team workflow, product vision, tech stack
Core Philosophy
CODEBLOCK1
- 1. Context precedes code — Define what you're building and how before implementation
- Living documentation — Context artifacts evolve with the project
- Single source of truth — One canonical location for each type of information
- AI alignment — Consistent context produces consistent AI behavior
The Workflow
CODEBLOCK2
- 1. Context Phase: Establish or verify project context artifacts exist and are current
- Specification Phase: Define requirements and acceptance criteria for work units
- Planning Phase: Break specifications into phased, actionable tasks
- Implementation Phase: Execute tasks following established workflow patterns
The Context Documents
product.md — WHAT and WHY
Purpose: Captures product vision, goals, target users, and business context.
Contents:
- - Product name and one-line description
- Problem statement and solution approach
- Target user personas
- Core features and capabilities
- Success metrics and KPIs
- Product roadmap (high-level)
Update when:
- - Product vision or goals change
- New major features are planned
- Target audience shifts
tech-stack.md — WITH WHAT
Purpose: Documents technology choices, dependencies, and architectural decisions.
Contents:
- - Primary languages and frameworks
- Key dependencies with versions
- Infrastructure and deployment targets
- Development tools and environment
- Testing frameworks
- Code quality tools
Update when:
- - Adding new dependencies
- Upgrading major versions
- Changing infrastructure
- Adopting new tools or patterns
workflow.md — HOW to Work
Purpose: Establishes development practices, quality gates, and team workflows.
Contents:
- - Development methodology (TDD, trunk-based, etc.)
- Git workflow and commit conventions
- Code review requirements
- Testing requirements and coverage targets
- Quality assurance gates
- Deployment procedures
Update when:
- - Team practices evolve
- Quality standards change
- New workflow patterns are adopted
tracks.md — WHAT'S HAPPENING
Purpose: Registry of all work units with status and metadata.
Contents:
- - Active tracks with current status
- Completed tracks with completion dates
- Track metadata (type, priority, assignee)
- Links to individual track specs
Update when:
- - New work starts
- Work status changes
- Work completes
Directory Structure
CODEBLOCK3
Setup: New Project (Greenfield)
For new projects, create all artifacts from scratch:
- 1. Create
context/product.md:
- Define the problem you're solving
- Describe target users
- List core features for v1
- Define success metrics
- 2. Create
context/tech-stack.md:
- Choose languages and frameworks
- Document key dependencies with versions
- Specify infrastructure targets
- List development tools
- 3. Create
context/workflow.md:
- Define branching strategy
- Set commit conventions
- Establish testing requirements
- Document deployment process
- 4. Create
context/tracks.md:
- Start with empty registry
- Add work units as they're created
Setup: Existing Project (Brownfield)
For existing codebases, extract context from what exists:
- 1. Analyze the codebase:
- Read package.json, requirements.txt, go.mod, etc.
- Look at existing README and docs
- Check git history for patterns
- 2. Create
context/tech-stack.md:
- Document discovered dependencies
- Note infrastructure from configs (Docker, CI, etc.)
- 3. Create
context/product.md:
- Infer product purpose from code
- Document current feature set
- Note any README content
- 4. Create
context/workflow.md:
- Document existing practices
- Note any established patterns
Maintenance Principles
Keep Artifacts Synchronized
Changes in one artifact should reflect in related documents:
- - New feature in product.md → Update tech-stack.md if new dependencies needed
- Completed track → Update product.md to reflect new capabilities
- Workflow change → Update all affected track plans
Update tech-stack.md When Adding Dependencies
Before adding any new dependency:
- 1. Check if existing dependencies solve the need
- Document the rationale for new dependencies
- Add version constraints
- Note any configuration requirements
Verify Context Before Implementation
Before starting any work:
- 1. Read all context artifacts
- Flag any outdated information
- Propose updates before proceeding
- Confirm context accuracy
Validation Checklist
Before starting implementation, validate:
Product Context:
- - [ ] product.md reflects current vision
- [ ] Target users are accurately described
- [ ] Feature list is up to date
Technical Context:
- - [ ] tech-stack.md lists all current dependencies
- [ ] Version numbers are accurate
- [ ] Infrastructure targets are correct
Workflow Context:
- - [ ] workflow.md describes current practices
- [ ] Quality gates are defined
- [ ] Commit conventions are documented
Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|
| Stale Context | Documents become outdated and misleading | Update context as part of each track's completion |
| Context Sprawl |
Information scattered across multiple locations | Use defined artifact structure; resist new document types |
| Implicit Context | Relying on knowledge not captured in artifacts | If referenced repeatedly, add to appropriate artifact |
| Over-Specification | Context so detailed it's impossible to maintain | Keep focused on decisions affecting AI behavior and team alignment |
Session Continuity
Starting a New Session
- 1. Read context/product.md to orient yourself
- Check context/tracks.md for active work
- Read relevant track specs for current task
- Verify context artifacts are current
Ending a Session
- 1. Update track status with current progress
- Note any blockers or decisions made
- Commit in-progress work with clear status
- Update tracks.md if status changed
Benefits
Team Alignment:
- - New team members onboard faster with explicit context
- Consistent terminology across the team
- Shared understanding of product goals
AI Consistency:
- - AI assistants produce aligned outputs across sessions
- Reduced need to re-explain context
- Predictable behavior based on documented standards
Institutional Memory:
- - Decisions and rationale are preserved
- Context survives team changes
- Historical context informs future decisions
NEVER Do
- 1. NEVER start implementation without reading context — context precedes code
- NEVER add dependencies without updating tech-stack.md — keep the source of truth current
- NEVER let context documents get stale — update them as part of completing work
- NEVER scatter context across ad-hoc documents — use the defined structure
- NEVER assume AI remembers previous sessions — context must be in artifacts
- NEVER skip context for "quick" changes — small changes compound into drift
上下文驱动开发
将项目上下文视为与代码一同管理的一级工件。不再依赖临时提示或零散文档,而是建立持久、结构化的基础,为所有AI交互提供信息。
安装
OpenClaw / Moltbot / Clawbot
bash
npx clawhub@latest install context-driven-development
该技能的作用
创建并维护一组上下文文档,用于:
- - 定义构建内容及其原因(product.md)
- 明确技术选型与约束(tech-stack.md)
- 确立团队工作方式(workflow.md)
- 跟踪项目进展(tracks.md)
使用时机
适用场景:
- - 使用AI辅助开发搭建新项目
- 让团队成员熟悉现有代码库
- 确保跨会话的AI行为一致性
- 记录影响代码生成的决策
- 管理多贡献者或多AI助手的项目
跳过场景:
- - 个人实验或一次性原型
- 单文件脚本
- 无AI辅助的项目
关键词: 上下文、项目设置、文档、AI对齐、团队工作流、产品愿景、技术栈
核心理念
上下文先于代码。
活文档。
单一事实来源。
AI对齐。
- 1. 上下文先于代码 — 在实现前定义构建内容与方式
- 活文档 — 上下文工件随项目演进
- 单一事实来源 — 每类信息有唯一权威位置
- AI对齐 — 一致的上下文产生一致的AI行为
工作流
上下文 → 规格与计划 → 实现
- 1. 上下文阶段: 确认项目上下文工件存在且为最新
- 规格阶段: 定义工作单元的需求与验收标准
- 计划阶段: 将规格分解为分阶段、可执行的任务
- 实现阶段: 按照既定工作流模式执行任务
上下文文档
product.md — 内容与原因
目的:记录产品愿景、目标、目标用户和业务背景。
内容:
- - 产品名称与一句话描述
- 问题陈述与解决方案
- 目标用户画像
- 核心功能与能力
- 成功指标与KPI
- 产品路线图(高层级)
更新时机:
- - 产品愿景或目标变更
- 计划新增主要功能
- 目标受众发生变化
tech-stack.md — 使用什么
目的:记录技术选型、依赖关系和架构决策。
内容:
- - 主要语言与框架
- 关键依赖及其版本
- 基础设施与部署目标
- 开发工具与环境
- 测试框架
- 代码质量工具
更新时机:
- - 添加新依赖
- 升级主要版本
- 变更基础设施
- 采用新工具或模式
workflow.md — 如何工作
目的:确立开发实践、质量门禁和团队工作流。
内容:
- - 开发方法论(TDD、主干开发等)
- Git工作流与提交规范
- 代码审查要求
- 测试要求与覆盖率目标
- 质量保证门禁
- 部署流程
更新时机:
tracks.md — 正在发生什么
目的:所有工作单元的注册表,包含状态和元数据。
内容:
- - 进行中的工作项及当前状态
- 已完成的工作项及完成日期
- 工作项元数据(类型、优先级、负责人)
- 各工作项规格的链接
更新时机:
目录结构
context/
├── product.md # 产品愿景与目标
├── tech-stack.md # 技术选型
├── workflow.md # 开发实践
├── tracks.md # 工作单元注册表
└── styleguides/ # 语言特定规范
├── python.md
├── typescript.md
└── ...
设置:新项目(绿地项目)
对于新项目,从头创建所有工件:
- 1. 创建 context/product.md:
- 定义要解决的问题
- 描述目标用户
- 列出v1核心功能
- 定义成功指标
- 2. 创建 context/tech-stack.md:
- 选择语言和框架
- 记录关键依赖及其版本
- 明确基础设施目标
- 列出开发工具
- 3. 创建 context/workflow.md:
- 定义分支策略
- 设定提交规范
- 确立测试要求
- 记录部署流程
- 4. 创建 context/tracks.md:
- 从空注册表开始
- 创建工作项时添加
设置:现有项目(棕地项目)
对于现有代码库,从已有内容中提取上下文:
- 1. 分析代码库:
- 读取package.json、requirements.txt、go.mod等
- 查看现有README和文档
- 检查git历史中的模式
- 2. 创建 context/tech-stack.md:
- 记录发现的依赖
- 从配置中记录基础设施(Docker、CI等)
- 3. 创建 context/product.md:
- 从代码推断产品目的
- 记录当前功能集
- 记录README中的内容
- 4. 创建 context/workflow.md:
- 记录现有实践
- 记录已建立的模式
维护原则
保持工件同步
一个工件中的变更应反映在相关文档中:
- - product.md中的新功能 → 如需新依赖则更新tech-stack.md
- 完成的工作项 → 更新product.md以反映新能力
- 工作流变更 → 更新所有受影响的工作项计划
添加依赖时更新tech-stack.md
添加任何新依赖前:
- 1. 检查现有依赖是否满足需求
- 记录新依赖的理由
- 添加版本约束
- 记录任何配置要求
实现前验证上下文
开始任何工作前:
- 1. 阅读所有上下文工件
- 标记任何过时信息
- 在继续前提出更新建议
- 确认上下文准确性
验证清单
开始实现前,验证:
产品上下文:
- - [ ] product.md反映当前愿景
- [ ] 目标用户描述准确
- [ ] 功能列表为最新
技术上下文:
- - [ ] tech-stack.md列出所有当前依赖
- [ ] 版本号准确
- [ ] 基础设施目标正确
工作流上下文:
- - [ ] workflow.md描述当前实践
- [ ] 质量门禁已定义
- [ ] 提交规范已记录
反模式
| 反模式 | 问题 | 修复 |
|---|
| 过时上下文 | 文档过时且误导 | 将上下文更新作为每个工作项完成的一部分 |
| 上下文蔓延 |
信息分散在多个位置 | 使用定义的工件结构;抵制新增文档类型 |
| 隐式上下文 | 依赖未记录在工件中的知识 | 如反复引用,添加到适当工件 |
| 过度规格化 | 上下文过于详细难以维护 | 聚焦于影响AI行为和团队对齐的决策 |
会话连续性
开始新会话
- 1. 阅读context/product.md以了解方向
- 检查context/tracks.md中的进行中工作
- 阅读当前任务的相关工作项规格
- 验证上下文工件为最新
结束会话
- 1. 更新工作项状态及当前进度
- 记录任何阻塞项或已做决策
- 提交进行中的工作并附清晰状态
- 如状态变更则更新tracks.md
优势
团队对齐:
- - 新团队成员通过显式上下文更快上手
- 团队内术语一致
- 对产品目标的共同理解
AI一致性:
- - AI助手跨会话产生对齐输出
- 减少重新解释上下文的需求
- 基于文档标准的行为可预测
机构记忆:
- - 决策及其理由得以保留
- 上下文在团队变更后仍存在
- 历史上下文为未来决策提供信息
绝对禁止
- 1. 绝不在未阅读上下文的情况下开始实现 — 上下文先于代码
- 绝不在未更新tech-stack.md的情况下添加依赖 — 保持事实来源为最新
- 绝不让上下文文档过时 — 将其作为完成工作的一部分进行更新
- 绝不将上下文分散在临时文档中 — 使用定义的结构
- 绝不假设AI记住之前的会话 — 上下文必须在工件中
- 绝不因快速变更而跳过上下文 — 小变更会累积成偏差