Initial commit
This commit is contained in:
16
commands/apply.md
Normal file
16
commands/apply.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
description: 实现plan任务
|
||||
---
|
||||
|
||||
**步骤**
|
||||
将这些步骤作为 TODO 逐个完成。
|
||||
|
||||
1. 阅读 `spec/plan/<id>/prd.md`和 `tasks.md` 以确认范围和验收标准。
|
||||
2. tasks中单个任务执行前,根据任务的需要按需加载规范
|
||||
3.1 api规范按需加载`src/api/CLAUDE.md`
|
||||
3.1 全局组件使用规范按需加载`src/components/CLAUDE.md`
|
||||
3.2 页面规范按需加载`src/views/CLAUDE.md`
|
||||
3.3 样式规范按需加载`src/styles/CLAUDE.md`
|
||||
3. 按顺序完成任务
|
||||
4. 在更新状态前确认完成情况 - 确保 `tasks.md` 中之前的项目都已完成。
|
||||
5. 在所有工作完成后更新检查清单,使每个任务标记为 `- [x]` 并反映实际情况。
|
||||
45
commands/fe-init-vue3.md
Normal file
45
commands/fe-init-vue3.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
description: 初始化分布式 CLAUDE.md 文档系统
|
||||
---
|
||||
|
||||
# 分布式 CLAUDE.md 文档生成系统
|
||||
|
||||
这个命令将为项目的每个关键目录创建专门的 CLAUDE.md 文档,实现模块化的知识管理。
|
||||
注意,这些文档是给后续的workflow /plan和/apply agent调用的,不需要给用户查看上手入门,不需要解释每个功能的作用,只需要让agent在后面抓取成为了记忆文件后,能够按照这个规范,生成一致的,功能性完备的代码!!!,这非常重要
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. 扫描 `src/` 目录结构,识别所有需要文档化的关键目录
|
||||
2. 为每个目录使用 fe-init-agent 子代理,并发式的创建分析并生成专门的 CLAUDE.md 文件
|
||||
|
||||
## Sub Agent 执行逻辑
|
||||
|
||||
### 每个 Sub Agent 将负责:
|
||||
|
||||
1. **目录分析**:深入分析指定目录的结构和内容
|
||||
2. **功能识别**:识别该目录的核心功能和用途
|
||||
3. **依赖分析**:分析该目录的依赖关系和被依赖关系
|
||||
4. **最佳实践提取**:从现有代码中提取最佳实践和使用模式
|
||||
5. **文档生成**:生成针对该目录的专门 CLAUDE.md 文件
|
||||
|
||||
### 目标目录映射
|
||||
|
||||
```
|
||||
src/
|
||||
├── api/ → src/api/CLAUDE.md (API 接口开发指南)
|
||||
├── components/ → src/components/CLAUDE.md (全局组件库文档)
|
||||
├── views/ → src/views/CLAUDE.md (页面开发指南)
|
||||
├── stores/ → src/stores/CLAUDE.md (状态管理指南)
|
||||
├── utils/ → src/utils/CLAUDE.md (工具函数库说明)
|
||||
├── hooks/ → src/hooks/CLAUDE.md (组合式 API 指南)
|
||||
├── styles/ → src/styles/CLAUDE.md (样式处理方案)
|
||||
├── routers/ → src/routers/CLAUDE.md (路由配置指南)
|
||||
└── layouts/ → src/layouts/CLAUDE.md (布局组件指南)
|
||||
```
|
||||
|
||||
## 注意事项
|
||||
|
||||
1. **现有项目分析**:深入分析现有代码,提取实际的使用模式
|
||||
2. **最佳实践**:从现有代码中识别并记录最佳实践
|
||||
3. **依赖关系**:明确各模块间的依赖关系
|
||||
4. **一致性**:确保所有文档的风格和规范一致
|
||||
22
commands/gen-api-code.md
Normal file
22
commands/gen-api-code.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
description: 根据接口文档使用mcp生成代码
|
||||
argument-hint: [yapi-url] [api-path] [type-path]
|
||||
---
|
||||
|
||||
# 参数说明
|
||||
|
||||
$ARGUMENTS 中的url参数为yapi的接口文档地址
|
||||
还需要代码生成后存放的位置,如果用户没有提供,需要提示用户传入
|
||||
也就是必须要传入接口文件的位置 和 yapi的url
|
||||
|
||||
## 注意事项
|
||||
|
||||
1. 如果本项目是ts类型的项目,则用户需要传入2个位置,一个是接口文件的位置,一个是接口的ts类型文件的位置
|
||||
2. 如果本项目是js类型的项目,则用户需要传入1接口文件的位置
|
||||
3. 如果yapi-get-interface-mcp mcp工具调用失败,终止流程,提示用户检查工具可用性
|
||||
|
||||
## 执行步骤
|
||||
|
||||
1. 调用 yapi-get-interface-mcp mcp,根据接口文档获取接口信息,随后获取api的规范 `src\api\CLAUDE.md`
|
||||
2. 根据接口信息和规范生成代码
|
||||
3. 将代码存储到用户指定位置
|
||||
36
commands/plan.md
Normal file
36
commands/plan.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
description: 创建前端页面的生成提案
|
||||
---
|
||||
|
||||
这个command的核心目的是给这个项目添加新的功能前,产生一个计划,指导agent按照plan进行开发
|
||||
从用户获取这次功能的
|
||||
|
||||
1. `原始用户需求`
|
||||
2. 修改/新增的功能具体文件路径
|
||||
3. 接口
|
||||
**步骤**
|
||||
|
||||
4. 生成`spec/plan/<change-id>`文件夹
|
||||
-change-id 根据用户的动作生成
|
||||
然后在文件夹内构建`prd.md`、`tasks.md`
|
||||
5. `prd.md`文件根据收到的`原始用户需求`,修改/新增的功能具体文件路径,使用的接口进行归纳整理,如果用户提供的信息比较少,让用户尽量提供更多的信息
|
||||
|
||||
6. 归纳完用户的信息后,读取`src/components/CLAUDE.md`和`src/views/CLAUDE.md`全局组件和页面的规范,然后写入到`prd.md`中
|
||||
使用模板:
|
||||
|
||||
```
|
||||
## 用户需求
|
||||
|
||||
## 关联页面文件
|
||||
|
||||
## 页面布局线框图
|
||||
|
||||
## 可以使用的接口
|
||||
|
||||
## 需要使用的组件
|
||||
|
||||
## 注意事项
|
||||
|
||||
```
|
||||
|
||||
8. 创建了`prd.md`后,生成`tasks.md`,将 `tasks.md`文件起草为一个有序的小型、可验证的工作项列表,这些工作项提供用户可见的进度,并突出显示依赖项或可并行的工作。不包括验证(测试、工具)。用户会独立发现并解决错误
|
||||
Reference in New Issue
Block a user