Agent skill
project-bootstrap
项目启动工作流。当用户需要从零开始启动一个完整项目、进行功能模块重构或开发独立子系统时使用。提供从需求分析到开发准备的标准化流程。
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/project-bootstrap
SKILL.md
项目启动工作流
概述
本 Skill 提供完整的项目启动标准化工作流,支持三种工作模式:
- 新项目模式:从零开始的 6 阶段完整流程
- 迭代模式:在现有项目上增量添加新功能
- 开发执行模式:按任务清单开发已定义的功能
⚠️ 关键行为规则
规则1:文件存在性检查(防止重复生成)
在创建任何文件之前,必须先检查文件是否已存在:
执行顺序:
1. 使用 Read 工具检查目标文件是否存在
2. 如果文件已存在且内容完整 → 跳过创建,直接进入下一步
3. 如果文件不存在或内容不完整 → 创建/补充文件
规则2:强制用户确认(禁止自动继续)
遇到 ⛔ STOP - 等待用户确认 标记时,必须:
- 输出确认模板内容
- 立即停止执行,不要继续任何操作
- 等待用户明确输入"确认"或修改意见后才能继续
禁止行为:
- ❌ 自动假设用户确认
- ❌ 在同一轮对话中继续下一阶段
- ❌ 替用户做选择
规则3:阶段状态追踪
每次执行前,先读取 doc/func.md 检查当前进度:
- 如果某阶段已标记完成 → 跳过该阶段
- 如果某阶段正在进行 → 从断点继续
- 更新阶段状态到
doc/func.md
模式选择流程
┌─────────────────────────────────────────────────────────────────────────────────┐
│ 模式自动选择流程 │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ Step 1: 检查 doc/PRD.md 是否存在? │
│ │ │
│ ├── 不存在 ──→ 🆕 新项目模式(6阶段完整流程) │
│ │ │
│ └── 存在 ──→ Step 2 │
│ │
│ Step 2: 用户请求的功能是否已在 PRD 中定义? │
│ │ │
│ ├── 未定义(新功能)──→ 🔄 需求迭代模式(4阶段增量流程) │
│ │ │
│ └── 已定义 ──→ Step 3 │
│ │
│ Step 3: 检查 doc/func.md 中该功能的状态 │
│ │ │
│ ├── 状态为"待开发" ──→ 🛠️ 开发执行模式(按任务清单开发) │
│ │ │
│ ├── 状态为"开发中" ──→ 🛠️ 开发执行模式(继续开发) │
│ │ │
│ └── 状态为"已完成" ──→ 提示用户功能已完成,询问是否需要修改 │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
手动指定模式:
- 用户说"新项目"/"从零开始" → 新项目模式
- 用户说"添加功能"/"新增需求"/"迭代" → 需求迭代模式
- 用户说"开发"/"实现"/"编码" + 已有功能名 → 开发执行模式
🆕 新项目模式(6阶段)
┌────────────────────────────────────────────────────────────────────────────────┐
│ 项目启动工作流 6 阶段 │
├────────────────────────────────────────────────────────────────────────────────┤
│ │
│ [1] 初始化 ──→ [2] 需求分析 ──→ [3] 原型设计 ──→ [4] 任务拆分 │
│ ↓ ↓ ↓ ↓ │
│ 检查点1 ⛔ 用户确认PRD ⛔ 设计风格选择 检查点4 │
│ ↓ ↓ │
│ 检查点2 检查点3 │
│ │
│ [5] API设计 ──→ [6] 开发准备 ──→ 🎉 完成 │
│ ↓ ↓ │
│ 检查点5 检查点6 │
│ │
│ 💡 交互环节说明: │
│ ⛔ 用户确认PRD - 必须停止等待用户确认后才能继续 │
│ ⛔ 设计风格选择 - 必须停止等待用户选择后才能继续 │
│ │
└────────────────────────────────────────────────────────────────────────────────┘
阶段执行指南
阶段1:项目初始化
任务: 收集项目信息,创建项目目录结构
前置检查:
1. 检查项目目录是否已存在
2. 检查 README.md 是否已存在
→ 如果都存在且内容完整,跳过本阶段
执行步骤:
-
询问并确认:
- 项目名称和类型(管理后台/移动端H5/小程序/API服务)
- 技术栈选择(前端框架、UI组件库、后端框架、数据库)
- 核心功能列表
-
创建项目目录和 README.md
-
检查点1:验证目录和 README.md 已创建
阶段2:需求分析
前置检查:
1. 检查 doc/PRD.md 是否已存在
2. 检查 doc/database-design.md 是否已存在
3. 检查 sql/schema.sql 是否已存在
→ 如果都存在且内容完整,跳过本阶段,直接进入阶段3
执行步骤:
- 根据用户需求生成 PRD 初稿
- ⛔ STOP - 等待用户确认:展示 PRD 核心内容,等待用户确认或修改
- 用户确认后,调用
database-designskill 生成数据库设计和 SQL 脚本
⛔ STOP - 用户确认模板(必须停止等待):
📋 PRD 确认清单:
【核心功能】
1. {功能1}
2. {功能2}
...
【页面清单】
1. {页面1} - {功能描述}
2. {页面2} - {功能描述}
...
【数据实体】
1. {实体1} - {字段概要}
2. {实体2} - {字段概要}
...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⛔ 请确认以上内容是否符合预期?
- 输入 "确认" 继续下一步
- 输入修改意见,我将调整后重新确认
⚠️ 等待您的回复,不会自动继续...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
输出物:
doc/PRD.md- 产品需求文档doc/database-design.md- 数据库设计文档sql/schema.sql- 建表脚本sql/init-data.sql- 初始化数据
检查点2:验证所有文件已创建,PRD.md 包含完整页面清单,且已获得用户确认
阶段3:原型设计(关键阶段)
调用 Skill: prototype-design
前置检查:
1. 检查 prototype/ 目录是否已存在
2. 检查 prototype/css/styles.css 是否已存在
3. 检查 PRD 中定义的页面是否都已生成
→ 如果都存在且完整,跳过本阶段
执行步骤:
- ⛔ STOP - 设计风格选择:展示设计风格选项,等待用户选择
- 用户选择后,创建
doc/func.md记录设计规范 - 按 PRD 页面清单生成所有原型页面
⛔ STOP - 设计风格选择模板(必须停止等待):
🎨 请选择设计风格:
┌─────────────────────────────────────────────────────────────┐
│ [1] 简约现代风格 │
│ - 大量留白,扁平化设计 │
│ - 主色调:蓝/灰,适合企业管理系统 │
│ - 代表:Ant Design、Element Plus │
├─────────────────────────────────────────────────────────────┤
│ [2] 活力渐变风格 │
│ - 渐变色彩,圆角卡片 │
│ - 主色调:紫/橙渐变,适合C端产品 │
│ - 代表:Linear、Notion │
├─────────────────────────────────────────────────────────────┤
│ [3] 暗黑科技风格 │
│ - 深色背景,霓虹高亮 │
│ - 主色调:深蓝/青色,适合数据大屏、监控系统 │
│ - 代表:Grafana、DataV │
├─────────────────────────────────────────────────────────────┤
│ [4] 清新自然风格 │
│ - 柔和色彩,自然元素 │
│ - 主色调:绿/米白,适合生活服务类应用 │
│ - 代表:豆瓣、小红书 │
├─────────────────────────────────────────────────────────────┤
│ [5] 自定义风格 │
│ - 请描述您期望的设计风格、主色调、参考网站等 │
└─────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⛔ 请输入选项编号(1-5)或描述您的设计偏好:
⚠️ 等待您的回复,不会自动继续...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
输出物:
doc/func.md- 功能清单(含设计规范)prototype/css/styles.css- 全局样式prototype/js/main.js- 交互逻辑prototype/js/mock-data.js- Mock 数据prototype/index.html- 原型主入口prototype/*.html- PRD 中定义的所有页面
检查点3:对照 PRD 页面清单,验证每个页面都已生成,且设计风格符合用户选择
阶段4:任务拆分
参考规则: task-splitting
前置检查:
1. 检查 doc/frontend-tasks.md 是否已存在
2. 检查 doc/backend-tasks.md 是否已存在
→ 如果都存在且内容完整,跳过本阶段
核心原则: 任务越小越细,代码质量越高(每个任务 2-8 小时)
输出物:
doc/frontend-tasks.md- 前端任务清单doc/backend-tasks.md- 后端任务清单
检查点4:验证任务清单文件已创建
阶段5:API 接口设计
调用 Skill: api-documentation
前置检查:
1. 检查 doc/api/ 目录是否已存在
2. 检查 doc/architecture.md 是否已存在
→ 如果都存在且内容完整,跳过本阶段
输出物:
doc/api/*.md- 各模块 API 文档doc/architecture.md- 系统架构文档
检查点5:验证 API 文档和架构文档已创建
阶段6:开发准备
任务: 完善功能清单文档,确认开发规范
更新 doc/func.md,补充完整内容
检查点6(最终验证):验证所有输出物完整
检查点验证模板
每个阶段结束时,输出以下格式:
🔍 阶段 N 检查点验证:
已创建文件:
✅ {文件路径1}
✅ {文件路径2}
跳过的文件(已存在):
⏭️ {文件路径} - 文件已存在,跳过创建
缺失文件:
❌ {文件路径} - 需要补充
验证结果:[通过/未通过]
⚠️ 未通过检查点,禁止进入下一阶段!
最终输出物清单
{project}/
├── README.md
├── doc/
│ ├── PRD.md
│ ├── database-design.md
│ ├── frontend-tasks.md
│ ├── backend-tasks.md
│ ├── func.md
│ ├── architecture.md
│ └── api/*.md
├── sql/
│ ├── schema.sql
│ └── init-data.sql
└── prototype/
├── index.html
├── css/styles.css
├── js/main.js
├── js/mock-data.js
└── *.html
🔄 需求迭代模式(4阶段)
适用场景: 在现有项目上添加 PRD 中未定义 的新功能模块
┌────────────────────────────────────────────────────────────────────────────────┐
│ 需求迭代工作流 4 阶段 │
├────────────────────────────────────────────────────────────────────────────────┤
│ │
│ [I-1] 需求收集 ──→ [I-2] 增量设计 ──→ [I-3] 原型更新 ──→ [I-4] 任务追加 │
│ ↓ ↓ ↓ ↓ │
│ 📖 读取现有PRD ⛔ 用户确认增量 继承现有风格 检查点I-4 │
│ ↓ ↓ ↓ │
│ 检查点I-1 检查点I-2 检查点I-3 🎉 迭代完成 │
│ │
└────────────────────────────────────────────────────────────────────────────────┘
迭代阶段执行指南
阶段I-1:需求收集
任务: 分析现有项目,收集新需求
执行步骤:
- 读取现有
doc/PRD.md,了解已有功能 - 读取现有
doc/func.md,了解设计规范和技术栈 - 询问用户新需求内容
展示模板:
📖 现有项目分析:
【项目名称】{项目名称}
【已有功能模块】
1. {模块1} - {状态}
2. {模块2} - {状态}
...
【已有页面】
1. {页面1}
2. {页面2}
...
【设计风格】{风格描述}
【技术栈】{前端} + {后端}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
请描述您要添加的新需求:
⚠️ 等待您的回复...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
检查点I-1:已读取现有 PRD,用户已提供新需求描述
阶段I-2:增量设计
任务: 设计新功能,更新相关文档
执行步骤:
- 分析新需求与现有功能的关系
- 生成增量 PRD 内容
- ⛔ STOP - 用户确认环节:展示增量内容,等待确认
- 用户确认后,更新
doc/PRD.md(追加新功能章节) - 更新
doc/database-design.md(如有新表) - 更新
sql/schema.sql(追加新表 DDL)
⛔ STOP - 用户确认模板(必须停止等待):
📋 增量需求确认:
【新增功能模块】
- {模块名称}: {功能描述}
【新增页面】
| 页面 | 路由 | 文件名 | 说明 |
|------|------|--------|------|
| {页面1} | {路由1} | {文件1} | {说明1} |
【新增/修改数据表】
| 表名 | 操作 | 说明 |
|------|------|------|
| {表1} | 新增/修改 | {说明} |
【与现有功能的关联】
- {关联说明}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⛔ 请确认以上增量内容是否符合预期?
- 输入 "确认" 继续下一步
- 输入修改意见,我将调整后重新确认
⚠️ 等待您的回复,不会自动继续...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
输出物:
doc/PRD.md- 更新(追加新功能章节)doc/database-design.md- 更新(如有新表)sql/schema.sql- 更新(追加新表)
检查点I-2:增量内容已获用户确认,相关文档已更新
阶段I-3:原型更新
调用 Skill: prototype-design
执行步骤:
- 读取现有
prototype/css/styles.css,继承设计风格 - 读取现有
prototype/js/mock-data.js,了解数据结构 - 生成新页面原型(继承现有风格)
- 更新
prototype/index.html导航 - 更新
prototype/js/mock-data.js(追加新模块数据)
输出物:
prototype/{新页面}.html- 新增页面prototype/index.html- 更新导航prototype/js/mock-data.js- 追加数据
检查点I-3:新页面已生成,导航已更新,风格与现有页面一致
阶段I-4:任务追加
参考规则: task-splitting
执行步骤:
- 为新功能生成开发任务
- 追加到现有任务清单(标记为新增)
- 调用
api-documentationskill 更新 API 文档(如有新接口) - 更新
doc/func.md功能清单
输出物:
doc/frontend-tasks.md- 追加新任务doc/backend-tasks.md- 追加新任务doc/api/{模块}-api.md- 新增 API 文档doc/func.md- 更新功能清单
检查点I-4(最终验证):所有增量文档已更新
迭代完成总结模板
🎉 需求迭代完成!
【本次迭代内容】
- 新增模块: {模块名称}
- 新增页面: {N} 个
- 新增接口: {M} 个
- 新增数据表: {K} 个
【更新的文件清单】
📝 doc/PRD.md
📝 doc/database-design.md
📝 doc/func.md
📝 doc/frontend-tasks.md
📝 doc/backend-tasks.md
✅ prototype/{新页面}.html
✅ doc/api/{模块}-api.md
...
【下一步建议】
1. 预览新增原型页面
2. 按任务清单开始开发
🛠️ 开发执行模式(3阶段)
适用场景: 开发 PRD 中已定义但状态为"待开发"的功能模块
┌────────────────────────────────────────────────────────────────────────────────┐
│ 开发执行工作流 3 阶段 │
├────────────────────────────────────────────────────────────────────────────────┤
│ │
│ [D-1] 开发准备 ──→ [D-2] 代码实现 ──→ [D-3] 状态更新 │
│ ↓ ↓ ↓ │
│ 📖 读取任务清单 ⛔ 用户确认方案 更新 func.md │
│ ↓ ↓ ↓ │
│ 检查点D-1 检查点D-2 🎉 开发完成 │
│ │
└────────────────────────────────────────────────────────────────────────────────┘
开发执行阶段指南
阶段D-1:开发准备
任务: 分析任务清单,确认开发范围
执行步骤:
- 读取
doc/func.md,确认目标功能状态为"待开发" - 读取
doc/frontend-tasks.md和doc/backend-tasks.md,找到相关任务 - 读取
doc/api/{模块}-api.md,了解接口规范 - 读取
prototype/{页面}.html,了解 UI 设计 - 展示开发方案,等待用户确认
⛔ STOP - 开发方案确认模板(必须停止等待):
🛠️ 开发方案确认:
【目标功能】{功能模块名称}
【当前状态】待开发 → 开发中
【涉及任务】
前端任务:
- {F-x.x} {任务名称} - {预计工时}
- {F-x.x} {任务名称} - {预计工时}
后端任务:
- {B-x.x} {任务名称} - {预计工时}
- {B-x.x} {任务名称} - {预计工时}
【涉及文件】
前端:
- src/views/{模块}/{页面}.vue
- src/api/{模块}.ts
- src/stores/{模块}.ts
后端:
- app/api/{模块}.py
- app/models/{模块}.py
- app/schemas/{模块}.py
【API 接口】
| 方法 | 路径 | 说明 |
|------|------|------|
| GET | /api/{模块} | {说明} |
| POST | /api/{模块} | {说明} |
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⛔ 请确认以上开发方案:
- 输入 "确认" 开始开发
- 输入 "仅前端" 只开发前端
- 输入 "仅后端" 只开发后端
- 输入修改意见
⚠️ 等待您的回复,不会自动继续...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
检查点D-1:用户已确认开发方案
阶段D-2:代码实现
任务: 按任务清单实现代码
执行步骤:
- 更新
doc/func.md中功能状态为"开发中" - 按任务清单顺序实现代码
- 遵循
doc/func.md中的开发规范 - 参考原型页面实现 UI
- 按 API 文档实现接口
代码实现原则:
- 先检查是否有可复用的现有代码
- 遵循项目命名规范
- 添加必要的注释
- 实现完整的错误处理
检查点D-2:代码实现完成,无语法错误
阶段D-3:状态更新
任务: 更新功能状态和文档
执行步骤:
- 更新
doc/func.md中功能状态为"已完成" - 更新 API 接口清单状态
- 输出开发完成总结
开发完成总结模板:
🎉 功能开发完成!
【完成功能】{功能模块名称}
【状态变更】待开发 → 已完成
【完成的任务】
前端:
✅ {F-x.x} {任务名称}
✅ {F-x.x} {任务名称}
后端:
✅ {B-x.x} {任务名称}
✅ {B-x.x} {任务名称}
【创建/修改的文件】
✅ {文件路径1}
✅ {文件路径2}
📝 doc/func.md - 更新功能状态
【下一步建议】
1. 运行项目验证功能
2. 进行前后端联调
3. 继续开发下一个功能模块
关键原则(通用)
- 每个阶段必须通过检查点验证后才能进入下一阶段
- 创建文件前必须检查是否已存在,避免重复生成
- 遇到 ⛔ STOP 标记必须停止等待用户输入,禁止自动继续
- 调用其他 Skill 获取详细规范
- 优先使用工具创建文件,避免跨平台命令兼容问题
- 开发前必须更新 func.md 状态为"开发中",完成后更新为"已完成"
- 原型阶段必须生成 PRD 中定义的所有页面
协作 Skills
本 Skill 在执行过程中会调用以下 Skills:
| Skill | 调用阶段 | 用途 |
|---|---|---|
database-design |
阶段2 | 生成数据库设计文档和 SQL |
prototype-design |
阶段3、I-3 | 生成原型页面 |
api-documentation |
阶段5、I-4 | 生成 API 文档 |
协作 Rules
| Rule | 调用阶段 | 用途 |
|---|---|---|
task-splitting |
阶段4、I-4 | 任务拆分规范 |
快速启动
使用 project-bootstrap skill 启动项目:[项目名称]
项目类型:[管理后台/移动端H5/小程序/API服务]
核心功能:
1. [功能1]
2. [功能2]
3. [功能3]
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?