bojunC
38c5a466cd
- 创建 monorepo 结构（Turborepo） - 初始化前端项目（Next.js + TypeScript + Tailwind CSS） - 初始化后端项目（NestJS + TypeScript） - 配置开发工具（ESLint, Prettier, VS Code） - 创建项目文档（README, 开发规范） Closes #1
332 lines
8.8 KiB
Markdown
332 lines
8.8 KiB
Markdown
---
|
||
name: gitea-init-project
|
||
description: 初始化项目，创建 Gitea 仓库和 Issues
|
||
arguments:
|
||
- name: requirements_file
|
||
description: requirements 文件路径（可选，支持相对路径。如果不指定，将自动查找最相关的 requirements.md）
|
||
required: false
|
||
- name: repo_name
|
||
description: 仓库名称（可选，如果不提供则从 requirements.md 读取）
|
||
required: false
|
||
---
|
||
|
||
读取 requirements.md，分析需求，拆分为 Issues，并创建 Gitea 仓库。
|
||
|
||
## 工作流程
|
||
|
||
### 第一步：选择需求文档
|
||
|
||
#### 情况 1：用户指定了文件路径
|
||
|
||
如果用户提供了 `requirements_file` 参数：
|
||
1. 检查文件是否存在
|
||
2. 如果存在，直接使用该文件
|
||
3. 如果不存在，提示错误并退出
|
||
|
||
#### 情况 2：用户未指定文件路径
|
||
|
||
自动查找最合适的 requirements.md：
|
||
|
||
**步骤 2.1: 搜索所有 requirements.md 文件**
|
||
```bash
|
||
# 搜索项目中所有的 requirements*.md 文件
|
||
find . -type f -name "*requirements*.md" 2>/dev/null
|
||
```
|
||
|
||
**步骤 2.2: 分析 Git 历史**
|
||
```bash
|
||
# 获取每个文件的 Git 历史
|
||
for file in $(find . -type f -name "*requirements*.md"); do
|
||
# 最后修改时间
|
||
last_modified=$(git log -1 --format="%at" "$file" 2>/dev/null || echo "0")
|
||
|
||
# 修改次数
|
||
commit_count=$(git log --oneline "$file" 2>/dev/null | wc -l)
|
||
|
||
# 最后修改者
|
||
last_author=$(git log -1 --format="%an" "$file" 2>/dev/null || echo "Unknown")
|
||
|
||
echo "$file|$last_modified|$commit_count|$last_author"
|
||
done
|
||
```
|
||
|
||
**步骤 2.3: 评分和选择**
|
||
|
||
基于以下因素计算评分：
|
||
- **最近修改时间**（权重 40%）：最近修改的文件得分更高
|
||
- **修改次数**（权重 30%）：修改次数多说明文档更完善
|
||
- **文件位置**（权重 20%）：根目录的文件优先级更高
|
||
- **文件内容**（权重 10%）：内容更丰富的文件优先
|
||
|
||
选择评分最高的文件。
|
||
|
||
**步骤 2.4: 内容相似度检查（可选）**
|
||
|
||
如果找到多个文件且评分接近，进行内容相似度分析：
|
||
1. 读取每个文件的前 100 行
|
||
2. 比较项目名称、描述等关键信息
|
||
3. 选择内容最完整的文档
|
||
|
||
#### 示例输出
|
||
|
||
```
|
||
🔍 搜索需求文档
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
|
||
找到 3 个 requirements 文件：
|
||
• ./requirements.md (评分: 85)
|
||
• ./docs/requirements-v2.md (评分: 78)
|
||
• ./archive/requirements-old.md (评分: 45)
|
||
|
||
✅ 选择最相关的文档: ./requirements.md
|
||
|
||
📊 选择依据:
|
||
• 最后修改: 2 天前
|
||
• 修改次数: 5 次
|
||
• 文件位置: 根目录
|
||
• 文件大小: 132 行
|
||
```
|
||
|
||
### 第二步：读取需求文档
|
||
|
||
1. 使用 Read 工具读取选定文件的内容
|
||
2. 如果文件不存在或无法读取，提示用户先运行 `/gitea-start` 创建需求文档
|
||
|
||
### 第二步：解析需求文档
|
||
|
||
解析以下信息：
|
||
- **项目基本信息**：名称、描述、类型
|
||
- **核心功能**：列出所有核心功能点
|
||
- **技术栈**：
|
||
- 编程语言
|
||
- 框架（前端/后端）
|
||
- 数据库
|
||
- 其他工具
|
||
- **功能模块**：识别所有功能模块
|
||
- **依赖关系**：模块间的依赖关系
|
||
- **开发里程碑**：开发阶段和任务
|
||
|
||
### 第三步：拆分 Issues
|
||
|
||
根据需求拆分为以下类型的 Issues：
|
||
|
||
#### 1. 项目基础设置 Issue
|
||
- 标题：`[基础] 项目初始化和环境配置`
|
||
- 内容：
|
||
- 初始化项目结构
|
||
- 配置开发环境
|
||
- 设置依赖管理
|
||
- 配置代码规范工具
|
||
- 标签：`基础`, `优先级:高`
|
||
- 优先级：1
|
||
|
||
#### 2. 数据模型/架构 Issue
|
||
- 标题：`[架构] 数据模型设计和数据库初始化`
|
||
- 内容：
|
||
- 设计核心数据模型
|
||
- 创建数据库 schema
|
||
- 设置 ORM/数据访问层
|
||
- 标签：`架构`, `优先级:高`
|
||
- 依赖：项目基础设置
|
||
- 优先级：2
|
||
|
||
#### 3. 核心功能 Issues
|
||
- 为每个核心功能创建一个 Issue
|
||
- 标题格式：`[功能] {功能名称}`
|
||
- 内容包含：
|
||
- 功能描述
|
||
- 实现要点
|
||
- 验收标准
|
||
- 标签：`功能`, `优先级:中`
|
||
- 依赖：数据模型
|
||
|
||
#### 4. 增强功能 Issues
|
||
- 为增强功能创建 Issues
|
||
- 标题格式：`[增强] {功能名称}`
|
||
- 标签：`增强`, `优先级:低`
|
||
- 依赖：核心功能
|
||
|
||
#### 5. 测试 Issue
|
||
- 标题：`[测试] 单元测试和集成测试`
|
||
- 内容：
|
||
- 单元测试（覆盖率 > 80%）
|
||
- 集成测试
|
||
- E2E 测试
|
||
- 标签：`测试`, `优先级:高`
|
||
- 依赖：核心功能
|
||
- 优先级：n-1
|
||
|
||
#### 6. 文档 Issue
|
||
- 标题：`[文档] API 文档和用户文档`
|
||
- 内容：
|
||
- API 文档
|
||
- 用户手册
|
||
- 部署文档
|
||
- 标签：`文档`, `优先级:中`
|
||
- 依赖：所有功能
|
||
- 优先级：n
|
||
|
||
### 第四步：确定依赖关系
|
||
|
||
分析 Issues 之间的依赖关系：
|
||
1. **项目基础设置** → 无依赖
|
||
2. **数据模型** → 依赖项目基础设置
|
||
3. **核心功能** → 依赖数据模型
|
||
4. **增强功能** → 依赖核心功能
|
||
5. **测试** → 依赖核心功能
|
||
6. **文档** → 依赖所有功能
|
||
|
||
在 Issue 描述中添加依赖标记：
|
||
```markdown
|
||
## 依赖关系
|
||
- 前置 Issue: #1, #2
|
||
- 阻塞 Issue: 无
|
||
```
|
||
|
||
### 第五步：创建 Gitea 仓库
|
||
|
||
依据 `.claude/commands/gitea/API-QUICK-REFERENCE.md` 文档中的仓库操作指南创建或更新仓库。
|
||
|
||
### 第六步：创建 Issues
|
||
|
||
依据 `.claude/commands/gitea/API-QUICK-REFERENCE.md` 文档中的 Issue 操作指南为每个拆分的 Issue 创建 Issue。
|
||
|
||
### 第七步：创建项目看板（可选）
|
||
|
||
如果需要，依据 `.claude/commands/gitea/API-QUICK-REFERENCE.md` 文档中的项目看板操作指南创建项目看板来跟踪进度。
|
||
|
||
## 配置要求
|
||
|
||
需要的环境变量（从 .env 文件读取）：
|
||
- `GITEA_URL`: Gitea 实例地址
|
||
- `GITEA_TOKEN`: API 访问令牌
|
||
- `GITEA_OWNER`: 仓库所有者
|
||
|
||
## Issue 标签系统
|
||
|
||
创建以下标签：
|
||
- **类型**：基础、架构、功能、增强、测试、文档
|
||
- **优先级**：优先级:高、优先级:中、优先级:低
|
||
- **状态**：进行中、已阻塞、待审核
|
||
|
||
## 使用示例
|
||
|
||
### 示例 1: 使用默认查找
|
||
|
||
```bash
|
||
/gitea:init-project
|
||
```
|
||
|
||
输出：
|
||
```
|
||
🔍 搜索需求文档
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
|
||
找到 2 个 requirements 文件：
|
||
• ./requirements.md (评分: 92)
|
||
• ./docs/requirements-v1.md (评分: 67)
|
||
|
||
✅ 选择最相关的文档: ./requirements.md
|
||
|
||
📦 初始化项目：任务管理器
|
||
|
||
✅ 读取需求文档
|
||
✅ 解析需求：发现 4 个核心功能，3 个功能模块
|
||
✅ 拆分为 8 个 Issues
|
||
✅ 创建/更新仓库：chen/task-manager
|
||
✅ 创建 8 个 Issues
|
||
✅ 创建项目看板
|
||
|
||
📋 Issues 列表：
|
||
#1 [基础] 项目初始化和环境配置
|
||
#2 [架构] 数据模型设计和数据库初始化
|
||
#3 [功能] 任务的增删改查
|
||
#4 [功能] 任务状态管理
|
||
#5 [功能] 任务分类与标签
|
||
#6 [功能] 数据统计与可视化
|
||
#7 [测试] 单元测试和集成测试
|
||
#8 [文档] API 文档和用户文档
|
||
|
||
🔗 依赖关系：
|
||
#2 → 依赖 #1
|
||
#3-6 → 依赖 #2
|
||
#7 → 依赖 #3-6
|
||
#8 → 依赖 #3-7
|
||
|
||
✨ 项目初始化完成！
|
||
```
|
||
|
||
### 示例 2: 指定 requirements 文件
|
||
|
||
```bash
|
||
/gitea:init-project docs/requirements-v2.md
|
||
```
|
||
|
||
输出：
|
||
```
|
||
📁 使用指定的需求文档: docs/requirements-v2.md
|
||
|
||
📦 初始化项目：在线商城系统
|
||
|
||
✅ 读取需求文档
|
||
...
|
||
```
|
||
|
||
### 示例 3: 指定 requirements 文件和仓库名
|
||
|
||
```bash
|
||
/gitea:init-project docs/requirements.md my-custom-repo
|
||
```
|
||
|
||
## 错误处理
|
||
|
||
- 如果找不到任何 requirements.md 文件，提示用户创建
|
||
- 如果指定的文件不存在，显示错误并列出可用的文件
|
||
- 如果 Gitea API 调用失败，显示错误信息并建议检查配置
|
||
- 如果仓库已存在，询问是否更新 Issues
|
||
|
||
## 智能选择算法
|
||
|
||
### 评分公式
|
||
|
||
```
|
||
总分 = 时间分 × 0.4 + 修改次数分 × 0.3 + 位置分 × 0.2 + 内容分 × 0.1
|
||
```
|
||
|
||
其中：
|
||
- **时间分**（0-100）：
|
||
- 最近 1 天内修改: 100
|
||
- 1-7 天前修改: 80
|
||
- 7-30 天前修改: 60
|
||
- 30 天前修改: 40
|
||
|
||
- **修改次数分**（0-100）：
|
||
- 10 次以上: 100
|
||
- 5-10 次: 80
|
||
- 2-5 次: 60
|
||
- 1 次: 40
|
||
|
||
- **位置分**（0-100）：
|
||
- 根目录: 100
|
||
- docs/ 目录: 80
|
||
- 其他一级子目录: 60
|
||
- 更深层次的目录: 40
|
||
|
||
- **内容分**（0-100）：
|
||
- 基于文件行数和内容丰富度
|
||
|
||
## 注意事项
|
||
|
||
1. **原子性**：每个 Issue 应该是一个最小可部署单元
|
||
2. **可测试性**：每个功能 Issue 应该有明确的验收标准
|
||
3. **依赖清晰**：明确标注依赖关系，避免循环依赖
|
||
4. **优先级合理**：按照依赖关系和重要程度排序
|
||
5. **可追溯性**：Issue 描述中引用 requirements.md 的相关部分
|
||
|
||
## 下一步
|
||
|
||
初始化完成后，可以：
|
||
1. 使用 `/gitea-start-scheduler` 启动自动化工作流
|
||
2. 使用 `/gitea-status` 查看项目状态
|
||
3. 使用 `/gitea-process-issue <number>` 手动处理单个 Issue
|