ai-spec-tool 0.1.2 → 0.1.4

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

@@ -1,249 +0,0 @@
-# Architecture File Generator (Spec) — 精简强化版（修订｜Modules 版）
-
-## 0) 生成目标（不可变）
-
-* 输出文件：`./docs/global/architecture.md`
-* 格式：Markdown
-* 语言：中文
-* 核心目的：
-  **强约束 AI 的代码生成行为，使其严格遵守模块划分、依赖方向与代码落点规则**
-* 禁止讨论：
-
-  * 具体框架
-  * 具体库
-  * 具体实现代码
-* 允许讨论：
-
-  * 架构形态
-  * 模块职责
-  * 依赖边界
-  * 文件与目录落点规则
-
----
-
-## 0.1 前置依赖（强制）
-
-* `docs/global/vision.md`
-
-### 流程（不可跳过）
-
-1. 读取并理解 `vision.md`
-2. 若缺失 → **只允许输出以下内容**：
-
-```
-缺少依赖 [docs/global/vision.md]
-回复「Y」开始创建依赖。
-```
-
-3. 若存在 → 继续后续流程
-
----
-
-## 1) 启动语（固定，不可修改）
-
-> 现在开始创建项目架构（Architecture）。
-> 我会一步一步问你问题，你只需要按问题回答即可。
-> 在开始前，我会先读取并提炼 vision.md 作为上下文依据。
-
----
-
-## Q1. 技术栈选择（Framework Set）
-
-> ⚠️ 本题用于确定本项目的**框架组合**，以约束 AI 后续产出一致性。
-> 允许选择 **1–3 个框架** 组成组合（例如「前端 + 后端」），
-> **每个条目必须是单一框架**，禁止在同一条目中拼接多个框架（例如「X + Y」）。
-
-### 系统建议（一次性给出）
-
-基于 `vision.md` 判定交付形态后，系统给出 1–2 组框架组合备选，并对每个备选用 **2–4 句**说明：
-
-* 适合点（为什么匹配目标 / 迭代速度 / 风险）
-* 代价点（会带来什么约束或复杂度）
-* 适用边界（本项目哪些范围用它）
-
-输出格式（固定）：
-
-**方案 A：框架组合**
-
-* 前端：<框架名>（目录：`/projects/<frontend>`）
-* 后端：<框架名>（目录：`/projects/<backend>`）
-* 其他（可选）：<框架名>（目录：`/projects/<other>`）
-* 互通方式：<高层次说明，例如：契约驱动 / API 约定 / 共享协议文件>
-
-* 优点：…
-* 缺点：…
-* 适用边界：…
-
-**方案 B：框架组合（可选）**
-
-* 前端：<框架名>（目录：`/projects/<frontend>`）
-* 后端：<框架名>（目录：`/projects/<backend>`）
-* 其他（可选）：<框架名>（目录：`/projects/<other>`）
-* 互通方式：<高层次说明，例如：契约驱动 / API 约定 / 共享协议文件>
-
-* 优点：…
-* 缺点：…
-* 适用边界：…
-
-### 用户选择（只需回答一个字母）
-
-> 请选择框架组合：A / B
-> 或：C) 我自行指定（写：交付形态 + 框架组合 + 各自目录）
-
----
-
-## Q2. 分层与职责（Layered Model）— 建议结构（核心参考）
-
-> ⚠️ 本题用于为本项目建立**推荐的模块类型划分**，
-> 作为后续依赖规则与代码落点的基础参考。
-
-### 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) 修改（请直接改）
-
----
-
-## 最终输出结构（固定）
-
-```md
-# 项目架构（Architecture）
-
-## 架构形态
-## 技术栈选择
-## 分层与职责
-## 依赖规则（结构化定义，供 AI 使用）
-```yaml
-layer_rules: ...
-```
-## 目录与落点规则
-## 跨项目互通规则
-## 禁止事项
-```
-
----
-
-## 输出后续动作（强制）
-
-在完成 `architecture.md` 生成后：
-
-1. 判断「技术栈选择」是否**包含前端技术栈**
-2. 若是前端：
-   - 必须询问用户是否要继续执行 `ui-architecture-gen.md`
-   - 若用户同意：继续进入 UI 规范生成流程
-3. 若非前端：直接结束

package/assets/.agents/skills/rules-creator/assets/naming-rule-gen.md

@@ -1,77 +0,0 @@
-# Naming Rule File Generator (Spec)
-
-## 0) 生成目标（不可变，不询问用户）
-- 输出文件：./docs/global/naming-rule.md
-- 输出格式：Markdown
-- 语言：中文为主
-
----
-
-## 1) 交互入口（优先确认默认方案）
-
-### 1.0 默认方案确认（必须最先执行）
-
-在开始任何详细询问前，**先询问用户一句话**：
-
-> 现在开始创建命名规范\n是否使用默认方案？
-
-并同时简要展示默认方案内容：
-
-- 文件 / 目录：kebab-case
-- 变量 / 函数：camelCase
-- 类 / 构造类型：PascalCase
-- 缩写策略：允许常见缩写（API / URL / DB / ID）
-
-回答「Y」或「N」
-
-#### 用户响应处理规则
-- 若用户回答「Y/y/是 / 使用默认 / OK」：
-  - 直接使用默认推荐值
-  - 跳过所有后续询问
-  - 进入生成流程（第 3 节）
-- 若用户回答「N/n/否 / 自定义 / 调整」：
-  - 进入第 1.1 节，逐项询问
-
----
-
-## 1.1 必问项（仅在用户拒绝默认方案时执行）
-
-请依次询问以下问题，用户只需回复选项编号或关键字：
-
-**Q1. 文件 / 目录命名风格**
-- A) kebab-case（推荐）
-- B) snake_case
-- C) camelCase（不推荐）
-- D) PascalCase（不推荐）
-
-**Q2. 变量 / 函数命名风格**
-- A) camelCase（推荐）
-- B) snake_case
-- C) kebab-case（不推荐）
-
-**Q3. 类 / 构造类型命名风格**
-- A) PascalCase（推荐）
-- B) camelCase
-- C) snake_case
-
-**Q4. 缩写策略（防止风格漂移）**
-- A) 不允许随意缩写（必须写全）
-- B) 允许常见缩写（API / URL / DB / ID）
-
----
-
-## 1.2 用户回答不足时的处理
-- 若只回答部分问题：继续追问未回答项
-- 若回答“随便 / 你定”：使用默认推荐值，并在生成结果中说明
-- 避免开放式问题，始终优先使用选项
-
----
-
-## 2) 默认推荐值（与 1.0 展示内容保持一致）
-- 文件 / 目录：kebab-case
-- 变量 / 函数：camelCase
-- 类 / 构造类型：PascalCase
-- 缩写策略：允许常见缩写（API / URL / DB / ID）
-- 测试文件：*.test.ts / *.spec.ts
-- React 组件：PascalCase.tsx
-- Hook：useXxx

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

@@ -1,332 +0,0 @@
-# UI 规范生成器（适合非 UI 专业）
-
-## 1) 开场说明（固定）
-
-> 我们要建立一套 UI 规范，让后续设计与开发都一致。
-> 我会一步步提问，你按自己的想法回答即可。
-
----
-
-## Q1. 你想要什么风格（我会整理成具体设定）
-
-<输出以下内容>
-> 你可以用以下方式告诉我风格方向：
-> A) 描述想要的 UI 风格（关键词）
-> B) 提供想参考的网站链接
-> C) 提供参考截图
-<输出以上内容>
-
-说明：
-- 若提供网站，仅作为风格参考，不复制具体内容
-- 若提供截图，仅作为风格参考，不复刻具体布局
-- 若仅提供关键词，需补充：氛围、情绪、密度（紧凑/舒展）
-- 若有不想要的风格或气质，请列出 1–3 条 (非必要)
-
-### 系统整理（你确认后才会继续）
-
-系统必须基于用户线索整理出以下资讯，并请用户确认：
-- 主色与辅助色倾向（如：冷色/暖色、饱和/低饱和）
-- 明暗基调（浅色为主 / 深色为主 / 双模式）
-- 字体风格倾向（严谨 / 中性 / 活泼 / 极简）
-- 圆角偏好（小/中/大）
-- 阴影倾向（无/轻/中/强）
-- 动效倾向（无/少量/明显）
-
-确认方式：
-> A) 接受  
-> B) 修改（请直接改）
-
----
-
-## Q2. 需要哪些「文字/背景/状态」层级
-
-> 这一步是为了避免后续样式缺漏，请确认模板是否适用。
-
-我会根据 Q1 的风格线索给出一份 **排版建议**，包含：
-
-- 文字层级：标题 / 副标题 / 正文 / 辅助 / 禁用
-- 背景层级：画布 / 表面 / 强调
-- 交互状态：默认 / 悬停 / 按下 / 禁用 / 焦点
-- 反馈语义：成功 / 警告 / 错误 / 信息
-
-确认方式：
-> A) 接受  
-> B) 调整（请直接改）
-
----
-
-## Q3. 页面排版方向（我会给建议）
-
-我会根据 Q1 的风格线索给出一份 **排版建议**，包含：
-
-- 页面类型倾向（营销/内容/应用型/混合/...）
-- 页面内容整体会偏「紧凑」还是「留白多」？（紧凑/中等/舒展/...）
-- 页面内容想怎么分成几块并排？（例如：整页一列、左右两列、更多栏位...）
-- 内容区域通常最大到多宽？（例如 1200/1440/不限制...）
-- 主要的内容会以哪种形式排列？（例如：单列往下、两列并排、卡片一块块、混合...）
-
-确认方式：
-> A) 接受  
-> B) 调整（请直接改）
-
----
-
-## Q4. 不同屏幕怎么显示（我会给建议）
-
-我会根据 Q1 的风格线索给出一份 **多屏幕建议**，包含：
-
-- 需要区分几种屏幕尺寸（建议 4–6）
-- 优先照顾手机还是电脑（小屏优先 / 桌面优先）
-- 小屏时导航要怎么出现？（比如：收起来点一下再展开 / 从侧边滑出来 / 底部按钮列）
-- 小屏时内容要怎么挪动或收起来？（比如：改成一列、折叠起来、必要时隐藏）
-- 小屏必须保留哪些内容、哪些可隐藏
-
-确认方式：
-> A) 接受  
-> B) 调整（请直接改）
-
----
-
-## Q5. 需要覆盖哪些页面与交互（我会给建议）
-
-我会根据 Q1 的风格线索给出一份 **覆盖建议**，包含：
-
-- 页面类型（首页/列表/详情/表单/空状态/错误页等）
-- 常见操作方式会有哪些？（例如：导航、筛选、搜索、翻页、主要行动按钮）
-- 主要行动按钮通常放在哪里？（例如：页面顶部、右上角、底部、固定在画面上）
-- 主要组件组合方式（卡片/区块/分栏/时间线）
-
-确认方式：
-> A) 接受  
-> B) 调整（请直接改）
-
----
-
-## Q6. 无障碍基础规范（可选）
-
-> 是否要建立无障碍基础规范？
-> A) 是（立即生成）
-> B) 否（未来再补齐）
-
-说明：
-- 若选择 A：生成固定内容的 `./docs/global/ui/accessibility.md`
-- 若选择 B：跳过本文件
-
----
-
-## 2) 颜色/字体/间距等基础规范（Design Tokens）
-
-你**必须**生成符合以下结构的 `design-tokens.md`：
-
-```md
-# Design Tokens
-
-## 基础 Tokens
-
-### 颜色（Base Colors）
-- color.base.<name>.<scale>
-
-### 字体（Typography）
-- font.family.primary
-- font.size.<scale>
-- font.weight.<scale>
-- line.height.<scale>
-
-### 间距（Spacing）
-- space.<scale>
-
-### 圆角（Radius）
-- radius.<scale>
-
-### 阴影（Shadow）
-- shadow.<scale>
-
-### 动效（Motion）
-- motion.duration.<scale>
-- motion.easing.<name>
-
----
-
-## 语义 Tokens
-
-### 文字
-- color.text.primary
-- color.text.secondary
-- color.text.muted
-- color.text.disabled
-
-### 背景
-- color.bg.canvas
-- color.bg.surface
-- color.bg.elevated
-- color.bg.accent
-
-### 边框
-- color.border.default
-- color.border.subtle
-- color.border.focus
-
-### 交互
-- color.interactive.default
-- color.interactive.hover
-- color.interactive.active
-- color.interactive.disabled
-
-### 反馈
-- color.feedback.success
-- color.feedback.warning
-- color.feedback.error
-- color.feedback.info
-```
-
----
-
-## 3) 生成规则（硬规则）
-
-* 基础 Tokens 以“中性可复用”为核心
-* 语义 Tokens 必须映射到基础 Tokens
-* 颜色需提供 5–9 个刻度（如 50–900）
-* 字体、间距、圆角、阴影、动效需提供 4–8 个刻度
-* 若用户提供参考网站，需总结其风格特征并转化为 tokens
-* 所有 tokens **必须使用统一命名规范**
-* Layout / 不同屏幕规则里的间距与字号 **必须引用 design-tokens 的命名**，不得出现未定义的新数值
-
----
-
-## 4) 输出要求（固定）
-
-* 必须生成并保存 `./docs/global/ui/design-tokens.md`
-* 不得将文件内容直接输出在对话中
-* 对话中只允许输出：
-
-> 已完成 Design Tokens 文件的生成：  
-> `<文件名>`（需为可点击超链接）
-
----
-
-## 5) 页面排版与不同屏幕规范（Layout + Responsive）
-
-你**必须**生成并保存 `./docs/global/ui/layout-and-responsive.md`，结构如下：
-
-```md
-# Layout + Responsive 规范
-
-## 布局策略
-## 栅格系统
-## 容器与内容宽度
-## 间距与对齐
-## 典型布局结构
-## 断点定义
-## 侧重手机或电脑
-## 导航在小屏的处理
-## 关键区块的重排规则
-## 字体与间距缩放规则
-```
-
----
-
-## 6) 常见页面与交互规则（Patterns）
-
-你**必须**生成并保存 `./docs/global/ui/patterns.md`，结构如下：
-
-```md
-# UI Patterns
-
-## 页面模式
-## 交互模式
-## 组件组合规则
-## 空状态与错误态
-```
-
----
-
-## 7) 无障碍基础规范（固定内容模板）
-
-若用户选择建立，必须使用以下固定结构与内容生成：
-
-```md
-# Accessibility Baseline
-
-## 目标
-- 保证核心内容可被键盘与屏幕阅读器访问
-- 保证文本与背景对比度满足基础可读性
-
-## 键盘可用性
-- 所有可交互元素必须可聚焦
-- 焦点顺序需符合视觉阅读顺序
-- 必须提供可见的焦点样式
-
-## 语义与标注
-- 交互控件必须使用语义化元素或等效标注
-- 图片必须提供替代文本
-- 表单元素必须有可识别的标签
-
-## 颜色与对比
-- 文字与背景对比度需至少达到 4.5:1（大字号可适当放宽）
-- 不得仅以颜色传达关键信息
-
-## 动效与可控性
-- 动效应可被降低或关闭
-- 不得使用强闪烁或易引发不适的效果
-
-## 反馈与错误提示
-- 错误信息必须可被读取与理解
-- 错误状态需提供明确的恢复路径
-```
-
-## 8) 最终输出要求（固定）
-
-1.文件输出
-* 必须生成并保存以下文件：
-  - `./docs/global/ui/design-tokens.md`
-  - `./docs/global/ui/layout-and-responsive.md`
-  - `./docs/global/ui/patterns.md`
-  - `./docs/global/ui/module-ui-types.md`
-* 若用户选择建立 Accessibility Baseline，还需生成：
-  - `./docs/global/ui/accessibility.md`
-* 不得将文件内容直接输出在对话中
-* 格式：Markdown
-* 语言：中文
-
-2.对话输出
-* 对话中只允许输出：
-> 已完成 UI 规范文件的生成：  
-> 1.`design-tokens.md`  
-> 2.`layout-and-responsive.md`  
-> 3.`patterns.md`
-> 4.`module-ui-types.md`
-> 5.`accessibility.md`（若有建立）
-* 禁止输出：
-  * 具体组件实现
-  * 具体框架代码
-  * 具体 CSS 选择器与样式规则
-
----
-
-## 9) UI Module Types 标记（强制）
-
-在生成 UI 规范时，必须读取 `./docs/global/architecture.md` 的分层/模块分类，
-并输出一份 **UI 显示组件类型清单**，用于后续生成 Component Rules。
-
-文件：`./docs/global/ui/module-ui-types.md`，结构如下：
-
-```md
-# UI Module Types
-
-## 说明
-- 本文件用于标记哪些 module type 属于「UI 显示组件」
-- plan-executor 将据此判断哪些模块需要生成 Component Rules
-
-## UI 显示组件类型
-- <ModuleTypeA>
-- <ModuleTypeB>
-```
-
----
-
-## 10) 后续询问（固定）
-
-在完成以上所有 UI 规范与输出后，**必须询问用户是否执行 `ui-template-gen`**：
-> 是否执行范例界面生成（ui-template-gen）？
-> A) 是（继续执行）
-> B) 否（结束）