ai-spec-tool 0.1.2 → 0.1.3

package/assets/.agents/skills/rules-creator/assets/architecture-gen.md

@@ -1,225 +1,59 @@
-# Architecture File Generator (Spec) — 精简强化版（修订｜Modules 版）
+# Architecture File Generator (Spec) — Multi-Project
 
 ## 0) 生成目标（不可变）
-
-* 输出文件：`./docs/global/architecture.md`
-* 格式：Markdown
-* 语言：中文
-* 核心目的：
-  **强约束 AI 的代码生成行为，使其严格遵守模块划分、依赖方向与代码落点规则**
-* 禁止讨论：
-
-  * 具体框架
-  * 具体库
-  * 具体实现代码
-* 允许讨论：
-
-  * 架构形态
-  * 模块职责
-  * 依赖边界
-  * 文件与目录落点规则
-
----
-
-## 0.1 前置依赖（强制）
-
-* `docs/global/vision.md`
-
-### 流程（不可跳过）
-
-1. 读取并理解 `vision.md`
-2. 若缺失 → **只允许输出以下内容**：
-
-```
-缺少依赖 [docs/global/vision.md]
-回复「Y」开始创建依赖。
-```
-
-3. 若存在 → 继续后续流程
+- 输出文件（每个 project 各一份）：
+  - `./docs/architecture/<project>/architecture.md`
+  - `./docs/architecture/<project>/layer_rules.yaml`
+- 输出格式：Markdown + YAML
+- 语言：中文
+- **rules-creator 不做任何依赖检查**
 
 ---
 
-## 1) 启动语（固定，不可修改）
+## 1) Project 发现与确认（强制）
 
-> 现在开始创建项目架构（Architecture）。
-> 我会一步一步问你问题，你只需要按问题回答即可。
-> 在开始前，我会先读取并提炼 vision.md 作为上下文依据。
+1. 扫描 `/projects/*`：
+   - 若存在一个或多个目录：列为候选 project（名称=目录名）
+   - 若不存在或为空：必须询问用户本仓库要建立哪些 project
+2. 对每个 project，询问：
+   - 类型（frontend / backend / other）
+   - 框架（单一框架名）
+   - code_root（默认 `/projects/<project>`）
+3. 用户确认后，生成对应的 `docs/architecture/<project>/` 文件
 
 ---
 
-## Q1. 技术栈选择（Framework Set）
-
-> ⚠️ 本题用于确定本项目的**框架组合**，以约束 AI 后续产出一致性。
-> 允许选择 **1–3 个框架** 组成组合（例如「前端 + 后端」），
-> **每个条目必须是单一框架**，禁止在同一条目中拼接多个框架（例如「X + Y」）。
-
-### 系统建议（一次性给出）
-
-基于 `vision.md` 判定交付形态后，系统给出 1–2 组框架组合备选，并对每个备选用 **2–4 句**说明：
-
-* 适合点（为什么匹配目标 / 迭代速度 / 风险）
-* 代价点（会带来什么约束或复杂度）
-* 适用边界（本项目哪些范围用它）
-
-输出格式（固定）：
-
-**方案 A：框架组合**
-
-* 前端：<框架名>（目录：`/projects/<frontend>`）
-* 后端：<框架名>（目录：`/projects/<backend>`）
-* 其他（可选）：<框架名>（目录：`/projects/<other>`）
-* 互通方式：<高层次说明，例如：契约驱动 / API 约定 / 共享协议文件>
+## 2) 架构内容（每个 project 都需完成）
 
-* 优点：…
-* 缺点：…
-* 适用边界：…
+### Q1. 架构形态与职责
+系统给出建议，用户确认/修改：
+- 本 project 的职责范围
+- 与其他 project 的协作边界
 
-**方案 B：框架组合（可选）**
+### Q2. 分层与职责（Layered Model）
+系统生成建议分层（按该 project 类型），用户确认/修改：
+- 每层职责
+- 允许的模块类型
 
-* 前端：<框架名>（目录：`/projects/<frontend>`）
-* 后端：<框架名>（目录：`/projects/<backend>`）
-* 其他（可选）：<框架名>（目录：`/projects/<other>`）
-* 互通方式：<高层次说明，例如：契约驱动 / API 约定 / 共享协议文件>
+### Q3. 依赖规则（结构化 YAML）
+系统生成 `layer_rules.yaml`，必须覆盖所有层级：
+- 字段：`from / allow / forbid / notes`
+- `allow/forbid` 互斥且穷尽
 
-* 优点：…
-* 缺点：…
-* 适用边界：…
+### Q4. 目录与落点规则
+明确本 project 的目录落点与边界
 
-### 用户选择（只需回答一个字母）
+### Q5. 跨项目互通规则（若存在多个 project）
+说明互通方式、契约落点、修改边界、版本兼容策略
 
-> 请选择框架组合：A / B
-> 或：C) 我自行指定（写：交付形态 + 框架组合 + 各自目录）
+### Q6. 禁止事项（Extra Forbids）
+3–6 条可判定的禁止规则
 
 ---
 
-## Q2. 分层与职责（Layered Model）— 建议结构（核心参考）
+## 3) 输出结构（固定）
 
-> ⚠️ 本题用于为本项目建立**推荐的模块类型划分**，
-> 作为后续依赖规则与代码落点的基础参考。
-
-### Step 1：系统生成模块建议（必须）
-
-系统需基于以下依据动态生成模块模型：
-
-* Q1 选择的框架组合（按各框架分别给出模块类型建议）
-* `vision.md` 描述的产品目标与复杂度
-* 当前阶段对可维护性与演进速度的需求
-
-系统将给出一组**推荐的分层类型**，用于说明各层职责边界与协作关系。
-
-**以下为一组示例模块类型（仅作为范例）：**
-
-* Adapter：负责对接并隔离外部系统，作为内部调用的统一入口
-* Core：提供与业务无关的基础能力或通用功能
-* Service：承载主要业务流程与状态规则
-* ComponentLogic：负责组件级逻辑与状态组织，不涉及展示
-* ComponentView：负责组件的展示结构与交互呈现
-* Component：组合逻辑模块与视图模块，形成可复用的组件单元
-
-> 实际模块名称、数量与职责可根据项目需求进行调整，但应保持职责单一、边界清晰、依赖方向明确。
-
----
-
-### Step 2：用户确认
-
-> 对这份「分层与职责建议」：
-> A) 接受作为当前项目的模块划分参考
-> B) 调整（可修改模块名称、职责描述或合并 / 拆分模块）
-
----
-
-## Q3. 依赖规则（Dependency Rules）— 结构化强制规则
-
-### Step 1：系统生成依赖规则（必须）
-
-系统必须输出**结构化依赖规则**（YAML），并覆盖所有层级：
-
-* 使用字段：`from / allow / forbid / notes`
-* `allow/forbid` 只接受分层名称（Adapter/Core/Service/ComponentLogic/ComponentView/Component）
-* `allow` 与 `forbid` 必须互斥且穷尽
-* 必须覆盖所有层级，保证可被 AI 直接解析
-
----
-
-### Step 2：用户确认
-
-> 对这份「依赖规则（结构化）」：
-> A) 接受
-> B) 修改（请直接改文字）
-
----
-
-## Q4. 目录与落点规则（Project Layout Rules）
-
-> ⚠️ 本题必须结合：
->
-> * 当前专案实际目录结构
-> * Q1 选定的技术栈方向
-> * Q2 模块模型
-> * Q3 模块依赖规则
-
-### Step 1：系统生成草案（必须）
-
-系统需提供：
-
-1. **目录与落点清单**（每条目录只负责一种职责）
-2. **一句总规则**：所有模块必须落在对应目录，不得跨目录落点
-3. **跨框架互通落点规则**：明确契约/接口/共享协议的落点位置与修改边界
-
----
-
-## Q4.1 跨项目互通规则（Inter-Project Rules）
-
-> ⚠️ 本题用于明确 `/projects` 下多个工程之间的协作边界与互通方式，
-> 以避免实现时出现重复定义、协议不一致或跨工程越界修改。
-
-### Step 1：系统生成草案（必须）
-
-系统需提供：
-
-1. **互通方式清单**：每一组 project 之间如何互通（API / 契约 / 共享协议等）
-2. **契约落点位置**：协议或接口定义文件放在哪里（例如 `/projects/<frontend>/...` 或 `/projects/<backend>/...` 或共享目录）
-3. **修改边界**：哪些工程可修改、哪些只能读取
-4. **版本与兼容**（若适用）：协议变更时的兼容策略
-
-### Step 2：用户确认
-
-> 对这份「跨项目互通规则」：
-> A) 接受
-> B) 修改（请直接改）
-
----
-
-### Step 2：用户确认
-
-> 对这份「目录与模块落点规则」：
-> A) 接受
-> B) 修改（请直接改）
-
----
-
-## Q5. 禁止事项（Extra Forbids）
-
-> ⚠️ 本题用于补充 **不属于依赖矩阵** 的特殊禁令，
-> 例如业务裁决位置、状态机归属、SSOT 写入边界等。
-
-### Step 1：系统生成草案（必须）
-
-系统需提供 **3–6 条**「特殊禁令」，要求：
-
-* 不重复 `layer_rules` 已覆盖的依赖方向限制
-* 禁令必须是可判定的行为约束（可被 executor 核对）
-* 语气必须为「禁止」或「不得」
-
-### Step 2：用户确认
-
-> 对这份「禁止事项」：
-> A) 接受
-> B) 修改（请直接改）
-
----
-
-## 最终输出结构（固定）
+`architecture.md` 结构：
 
 ```md
 # 项目架构（Architecture）
@@ -236,14 +70,29 @@ layer_rules: ...
 ## 禁止事项
 ```
 
+`layer_rules.yaml` 结构：
+```yaml
+layer_rules:
+  - from: <Layer>
+    allow: [<Layer>, ...]
+    forbid: [<Layer>, ...]
+    notes: <optional>
+```
+
 ---
 
-## 输出后续动作（强制）
+## 4) 对话输出（唯一允许的文字输出）
+
+<<<
+已完成 Architecture 文件的生成：  
+`<文件名>`（需为可点击超链接）
 
-在完成 `architecture.md` 生成后：
+已完成 Layer Rules 文件的生成：  
+`<文件名>`（需为可点击超链接）
 
-1. 判断「技术栈选择」是否**包含前端技术栈**
-2. 若是前端：
-   - 必须询问用户是否要继续执行 `ui-architecture-gen.md`
-   - 若用户同意：继续进入 UI 规范生成流程
-3. 若非前端：直接结束
+【下一步】请选择一项：
+1. 若包含前端 project → 生成 UI 规范（ui-architecture）
+2. 生成通用规范（conventions）或术语表（glossary）
+3. 进入计划生成（plan）
+请回复：1/2/3
+>>>

package/assets/.agents/skills/rules-creator/assets/conventions-gen.md

@@ -0,0 +1,85 @@
+# Conventions File Generator (Spec)
+
+## 0) 生成目标（不可变）
+- 输出文件：`./docs/_shared/conventions.md`
+- 输出格式：Markdown
+- 语言：中文为主
+- **rules-creator 不做任何依赖检查**
+
+---
+
+## 1) 交互入口（必须逐步询问）
+
+依序询问并确认：
+1. 项目目标与范围（做什么 / 不做什么）
+2. 成功标准（可验证）
+3. 文档与 spec 的写作约束（是否禁止实现细节）
+4. 命名规范（文件/目录/变量/类）
+5. 依赖表达方式（引用 layer rules / architecture 的方式）
+6. 状态文件规则（`.processing.md` / `.done.md` 的含义与使用时机）
+7. 计划执行流程（Plan → Project-Plan → Module-Plan → Spec-Executor）
+
+每题都需要用户确认（A 接受 / B 修改）。
+
+---
+
+## 2) 输出结构（固定）
+
+```md
+# 通用规范（Conventions）
+
+## 项目目标与范围
+## 成功标准
+## 文档与 Spec 书写规范
+## 命名规范
+## 依赖表达方式
+## 状态文件规则
+## 计划执行流程
+```
+
+### 计划执行流程（固定要求）
+- 生成多个 `project-plan.md` 后：先给出每个 project 的简短摘要，询问是否修改，确认后继续。
+- 生成多个 `<module>-plan.md` 后：先给出每个 module 的简短摘要，询问是否修改，确认后才可进入 spec-executor。
+- 所有多题澄清必须标注进度：`问题[当前/总数]`。
+- 所有关键流程阶段必须标注进度：`流程[当前/总数]`。
+- 优先使用 `docs/plan/index.yaml` 作为计划索引；若不存在再扫描目录。
+- 生成 plan / project-plan / module-plan 后应产出对应 `summary.md` 以降低后续读取成本。
+- summary 文件路径建议：
+  - `docs/plan/<plan-id>/summary.md`
+  - `docs/plan/<plan-id>/projects/<project>/summary.md`
+  - `docs/plan/<plan-id>/projects/<project>/modules/<module>.summary.md`
+- summary 模板参考：
+  - `assets/templates/summary-plan.md`
+  - `assets/templates/summary-project.md`
+  - `assets/templates/summary-module.md`
+- 若存在 Interface 规格书：
+  - 其路径必须写入 `plan.md / project-plan.md / module-plan.md`
+  - 最终写入每个 `module-spec.md` 的 frontmatter
+
+## 规格书优先规则
+- 当接口与 DB 细节讨论已清晰，可先生成 Interface 规格书，再进入 plan。
+
+## Interface 规格书
+- 位置：`docs/requirements/<spec-id>.md`
+- 索引：`docs/requirements/index.yaml`
+- 命名：`001-支付流程` 形式
+
+#### 进度标识示例（必须遵守）
+- `问题[1/4] 这次变更的目标是什么？`
+- `问题[2/4] 这次的成功标准有哪些？`
+- `流程[1/3] 读取 plan 并建立执行清单`
+- `流程[2/3] 生成 project-plan 与 module-plan`
+
+---
+
+## 3) 对话输出（唯一允许的文字输出）
+
+<<<
+已完成通用规范文件的生成：  
+`<文件名>`（需为可点击超链接）
+
+【下一步】请选择一项：
+1. 生成术语表（glossary）
+2. 生成系统架构（architecture）
+请回复：1/2
+>>>

package/assets/.agents/skills/rules-creator/assets/glossary-gen.md

@@ -0,0 +1,46 @@
+# Glossary File Generator (Spec)
+
+## 0) 生成目标（不可变）
+- 输出文件：`./docs/_shared/glossary.md`
+- 输出格式：Markdown
+- 语言：中文为主
+- **rules-creator 不做任何依赖检查**
+
+---
+
+## 1) 交互入口（必须逐步询问）
+
+请用户列出本项目关键术语（至少 8 个），并逐条确认：
+- 术语
+- 定义
+- 边界（包含/不包含）
+- 常见误用（可选）
+
+若用户给不全：你必须给出建议清单让用户挑选。
+
+---
+
+## 2) 输出结构（固定）
+
+```md
+# 术语表（Glossary）
+
+## 术语
+- **<Term>**：<定义>
+  - 范围：<包含/不包含>
+  - 常见误用：<可选>
+```
+
+---
+
+## 3) 对话输出（唯一允许的文字输出）
+
+<<<
+已完成术语表文件的生成：  
+`<文件名>`（需为可点击超链接）
+
+【下一步】请选择一项：
+1. 生成系统架构（architecture）
+2. 生成计划（plan）
+请回复：1/2
+>>>

package/assets/.agents/skills/rules-creator/assets/interface-gen.md

@@ -0,0 +1,62 @@
+# Interface Spec Generator (Spec)
+
+## 0) 生成目标（不可变）
+- 输出文件：`./docs/requirements/<spec-id>.md`
+- 索引文件：`./docs/requirements/index.yaml`
+- 输出格式：Markdown + YAML
+- 语言：中文为主
+- **rules-creator 不做任何依赖检查**
+
+---
+
+## 1) 命名规则（强制）
+- `<spec-id>` 采用 `001-支付流程` 这种格式
+- 递增 index 由 `docs/requirements/index.yaml` 决定
+
+---
+
+## 2) 内容范围（强制）
+此规格书允许实现细节，必须包含：
+- DB 设计（表、字段、索引、约束、迁移）
+- API/接口设计（路径、方法、参数、响应、状态码）
+- 关键流程与状态变更
+
+---
+
+## 3) 输出结构（固定）
+
+```md
+---
+spec_id: <spec-id>
+scope: <一句话范围>
+projects: [<project>, ...]
+created_at: <YYYY-MM-DD>
+---
+
+# 规格书（Interface）
+
+## 背景与目标
+## 数据库设计
+## 接口设计
+## 流程与状态
+## 边界与非目标
+```
+
+---
+
+## 4) 二次确认（强制）
+写完后输出一段摘要，让用户确认/修改。
+
+---
+
+## 5) 对话输出（唯一允许的文字输出）
+
+<<<
+已完成规格书文件的生成：  
+`<文件名>`（需为可点击超链接）
+
+【下一步】请选择一项：
+1. 进入计划生成（plan）
+2. 继续补充规格书
+请回复：1/2
+>>>