生成项目规范

---
name: 生成项目规范
description: 用于生成包含GEB文档系统的项目开发规范文件 project_rules.md。当用户需要创建或更新项目规范时使用。
---

你是一个资深的技术专家，请为当前项目生成一份项目规范文件 `project_rules.md`。

## 1. 核心要求
- 目标文件通常位于 `.trea/rules/project_rules.md` 或用户指定位置。
- **必须包含** 以下 GEB 文档系统的内容（请原样保留，不要修改）：

```markdown
## GEB 文档系统

<geb_core>
核心理念：

代码和文档必须同步：
- 代码是给机器执行的
- 文档是给人（包括 AI）理解的
- 两者必须保持一致

同步规则：
- 代码变了，文档必须跟着变
- 文档变了，必须反映代码的真实状态
- 不允许代码和文档不一致

提醒自己：我改代码时，文档在看着我。我写文档时，代码在检查我。
</geb_core>

<three_layers>
文档分三层：

L1 - 项目根目录的 /CLAUDE.md
作用：项目全局视图
内容：技术栈、目录结构、主要模块
更新时机：顶层架构变化、模块增删

L2 - 每个模块目录的 CLAUDE.md
作用：模块内部地图
内容：所有文件列表、每个文件的职责、对外接口
更新时机：文件增删、重命名、接口变化

L3 - 每个文件顶部的注释
作用：文件的说明书
内容：依赖什么、提供什么、在系统中的位置
更新时机：依赖变化、导出变化、职责变化

关系：L1 描述 L2，L2 描述 L3，L3 描述代码。
</three_layers>

<l1_format>
L1 文档格式（项目根目录 /CLAUDE.md）：

```markdown
# {项目名称} - {一句话说明这是什么项目}
技术栈：{A + B + C}

## 目录结构
- {目录名}/ - {这个目录是干什么的}
- {目录名}/ - {这个目录是干什么的}

## 配置文件
- {文件名} - {这个文件是干什么的}
```

要求：简洁、稳定、准确
</l1_format>

<l2_format>
L2 文档格式（模块目录 /{module}/CLAUDE.md）：

```markdown
# {模块名}/
> L2 | 父级: {上级目录的 CLAUDE.md 路径}

## 文件列表
- {文件名}.{后缀}: {干什么的}，{技术细节}，{关键信息}

[PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md
```

要求：
- 列出所有文件
- 一行描述一个文件
- 说清楚父级是谁
- 技术信息放前面
</l2_format>

<l3_format>
L3 文档格式（文件头部注释）：

```javascript
/**
 * [INPUT]: 依赖 {哪些模块/文件} 的 {什么功能}
 * [OUTPUT]: 对外提供 {什么函数/组件/类型/变量}
 * [POS]: {属于哪个模块} 的 {什么角色}，{和其他文件什么关系}
 * [PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md
 */
```

例子：
```javascript
/**
 * [INPUT]: 依赖 @/ui/tokens 的颜色配置，依赖 vue 的 ref/computed
 * [OUTPUT]: 提供 AvatarGenerator 组件和 useAvatarStyle hook
 * [POS]: components/avatar 的核心渲染器，被 UserProfile 和 CommentItem 使用
 * [PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md
 */
```

要求：
- INPUT 说清楚依赖
- OUTPUT 说清楚提供什么
- POS 说清楚自己是谁

强制规则：发现文件缺少这个头部，立即加上。
</l3_format>

<workflow>
工作流程：

改完代码后的检查流程：
1. 检查 L3：文件头部的说明和实际代码一致吗？不一致就更新
2. 检查 L2：文件有增删吗？职责变了吗？接口变了吗？有变化就更新
3. 检查 L1：模块有增删吗？技术栈变了吗？有变化就更新
4. 完成

进入新目录的流程：
1. 先读这个目录的 CLAUDE.md（有就读，没有就标记要创建）
2. 再读要改的文件的头部注释（有就理解，没有就先加上）
3. 开始干活
</workflow>

<forbidden>
绝对禁止的行为：

致命错误（必须立即停止）：
- 改了代码不检查文档
- 发现文件缺头部注释却继续工作
- 删了文件不更新 L2 的文件列表
- 新建模块不创建 L2 文档

严重错误（警告后必须修复）：
- 文件头部注释和代码不一致
- L2 文档的文件列表不完整
- L1 文档的目录结构过时
- 父级链接断了
</forbidden>

<bootstrap>
进入新项目时的操作：

你的任务是让项目长出完整的文档结构。

阶段 1 - 侦察：
- 检查有没有 /CLAUDE.md
- 扫描目录结构
- 识别模块边界

阶段 2 - 创建文档：
- 没有 L1 → 分析 package.json 或其他配置文件 → 创建 L1
- 没有 L2 → 列出文件，读前面几行推断用途 → 创建 L2
- 没有 L3 → 分析 import 和 export → 添加头部注释

阶段 3 - 正常工作：
- 文档准备好了 → 进入正常工作流程
- 每次改代码都检查文档
- 保持代码和文档同步
</bootstrap>

<verification>
文档标记验证：

L2 和 L3 文档必须包含这行：
```
[PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md
```

这是固定写法，经常会看到。这是文档系统正常运作的标志。
</verification>

<commitment>
守护承诺：

我是文档系统的守护者。
代码即文档，文档即代码。
维护三层完整，保持同步，拒绝不一致。
保持地图和地形同步，否则系统会迷失方向。
</commitment>
```

## 2. 其他内容生成规则
- **不生成** 具体的目录结构树（即不需要列出 `src/` 下的具体文件树），因为目录结构随项目变化较大。
- 需要包含通用的开发规范，如：
  - 技术栈说明
  - 核心原则（如使用 pnpm，中文注释等）
  - 代码风格与命名规范
  - 交互与沟通偏好
- 结合用户提供的额外要求进行补充。

## 3. 使用场景
- 项目初始化阶段。
- 规范更新阶段。

## 4. 执行逻辑
当用户调用此 Skill 时，请按以下步骤操作：

1.  **分析项目环境**：
    - 读取 `package.json` (如果存在) 以确定项目的具体技术栈（如 Vue 版本、UI 库、构建工具等）。
    - 确认项目根目录路径。
    - **扫描 Skills 目录**：读取 `.trea/skills/` 下的所有 Skill 定义，提取其 `name` 和 `description`。

2.  **生成内容**：
    - 基于 **GEB 文档系统** 的强制内容。
    - 结合项目实际技术栈补充“技术栈”、“代码风格”等部分。
    - 确保包含 `pnpm` 强制要求和中文注释要求。
    - **生成 Skills 说明章节**：在文档末尾添加 "## 5. 可用 Skills" 章节，列出当前项目所有可用 Skill 的名称、描述以及建议的调用时机。

3.  **写入文件**：
    - 目标路径默认为：`.trea/rules/project_rules.md` (请使用绝对路径)。
    - 使用 `Write` 工具写入生成的内容。

4.  **完成反馈**：
    - 告知用户文件已生成，并简要说明包含的核心规范及可用 Skills。