@haaaiawd/anws 2.2.1 → 2.2.3

package/templates/.agents/skills/concept-modeler/SKILL.md

@@ -1,176 +1,179 @@
----
-name: concept-modeler
-description: 当用户需求模糊、术语不清晰时使用。通过交互式追问澄清领域概念，提取实体、流程和暗物质。由 /genesis Step 1 调用。
----
-
-# 领域建模师 (Domain Modeler)
-
-> "如果你描述不清楚，你就造不出来。" —— Eric Evans
-
-本技能通过**交互式追问**将用户的"感觉词"转化为清晰的领域模型。
-
----
-
-## 🎯 使命与定位
-
-**这个技能是什么**: 通过与用户交互，澄清模糊需求，建立领域模型（实体、流程、暗物质）。
-
-**何时调用**:
-- `/genesis` Step 1: 需求澄清阶段
-- 用户需求使用模糊术语（"同步"、"列表"、"管理"）
-- 需要建立 Ubiquitous Language
-
-**何时不调用**:
-- 需求已经清晰、术语已定义
-- 纯技术实现讨论（无需领域建模）
-
----
-
-## ⚠️ 核心原则
-
-> [!IMPORTANT]
-> **一次只问一个问题，不一次性输出所有问题。**
->
-> **为什么？** 用户一次只能思考一个问题。逐个追问能获得更准确的答案，也避免用户被问题淹没。
-
----
-
-## 🧭 交互流程 (Interactive Process)
-
-### Step 1: 扫描模糊区域
-
-**目标**: 识别需求中的模糊术语和缺失信息。
-
-> [!IMPORTANT]
-> 你**必须**先扫描用户需求，识别以下类别的模糊点：
->
-> | 类别 | 检查问题 |
-> | :--- | :--- |
-> | **实体模糊** | "列表"是什么？`Wishlist`？`ShoppingCart`？`TodoList`？ |
-> | **动词模糊** | "同步"是单向/双向？实时/批量？失败策略？ |
-> | **暗物质** | 用户只描述 Happy Path——错误处理？持久化？认证？ |
-> | **边界模糊** | 谁能访问？数据量多大？并发要求？ |
-
-**内部产出**: 生成候选问题队列（最多 5 个），按影响排序。**不输出队列**。
-
----
-
-### Step 2: 交互式追问循环
-
-**目标**: 逐个澄清模糊点，每次只问一个问题。
-
-> [!IMPORTANT]
-> **追问规则**：
-> - 最多问 **5 个问题**
-> - 每个问题必须是**多选题**或**短回答（≤5 词）**
-> - 每次只输出**一个问题**
-
-#### 2.1 多选题格式
-
-对于有多种明确选项的问题：
-
-```markdown
-**推荐:** 选项 B - 实时双向同步能保证数据一致性，适合用户多设备场景。
-
-| 选项 | 描述 |
-| :--- | :--- |
-| A | 单向同步（仅上传） |
-| B | 实时双向同步 |
-| C | 批量定时同步 |
-| 自定义 | 提供简短描述（≤5 词） |
-
-回复选项字母（如 "B"），说 "yes" 或 "推荐" 接受推荐，或提供自定义答案。
-```
-
-#### 2.2 短回答格式
-
-对于需要用户自定义的问题：
-
-```markdown
-**建议:** 用户愿望清单 - 这是电商场景最常见的术语。
-
-格式: 简短回答（≤5 词）。说 "yes" 或 "建议" 接受建议，或提供你的答案。
-```
-
-#### 2.3 停止条件
-
-停止追问当：
-- 所有关键模糊点已澄清
-- 用户说 "done"、"好了"、"继续"
-- 已问满 5 个问题
-
----
-
-### Step 3: 增量更新模型
-
-**目标**: 每次获得答案后，立即更新领域模型。
-
-> [!IMPORTANT]
-> **每个答案接受后立即更新**，不要等所有问题结束。
-
-**更新规则**：
-1. 实体澄清 → 更新 `entities` 列表
-2. 动词澄清 → 更新 `flows` 列表
-3. 暗物质识别 → 更新 `missing_components` 列表
-4. 术语统一 → 记录到 `glossary`
-
----
-
-## 📤 输出格式
-
-**输出路径**: `.anws/v{N}/concept_model.json`
-
-```json
-{
-  "glossary": {
-    "Wishlist": "用户的愿望清单，可添加商品但不直接结算",
-    "Sync": "实时双向同步，保证多设备数据一致"
-  },
-  "entities": [
-    { "name": "Wishlist", "type": "聚合根", "necessity": "必须", "description": "用户的愿望清单" },
-    { "name": "WishlistItem", "type": "实体", "necessity": "必须", "description": "愿望清单中的商品项" }
-  ],
-  "flows": [
-    { "from": "User", "action": "添加", "to": "Wishlist", "data": "Product ID", "trigger": "用户点击" },
-    { "from": "Wishlist", "action": "同步", "to": "RemoteServer", "data": "全量数据", "mode": "实时双向" }
-  ],
-  "missing_components": [
-    { "component": "同步冲突解决", "category": "错误处理", "priority": "高", "reason": "多设备同时修改" },
-    { "component": "离线队列", "category": "可靠性", "priority": "中", "reason": "网络断开时暂存操作" }
-  ],
-  "clarifications": [
-    { "question": "同步是实时的还是批量的？", "answer": "实时双向同步" }
-  ]
-}
-```
-
----
-
-## 🛡️ 老师傅守则
-
-1. **不要假设**: 永远不要假设你理解了用户的词汇。追问确认。
-2. **一次一个**: 用户一次只能思考一个问题。不要输出问题列表。
-3. **推荐优先**: 给出推荐选项 + 理由，让用户更容易决策。
-4. **增量更新**: 每个答案立即写入文件，避免上下文丢失。
-5. **术语统一**: 一旦确定术语，全程使用该术语，避免同义词。
-6. **工具优先提问**: 如果当前环境提供 `ask question` 等结构化提问工具，优先使用工具发起问题，而不是让用户手动输入整段回复。
-
----
-
-## 📋 完成标准
-
-<completion_criteria>
-- ✅ 澄清了关键模糊术语（记录到 glossary）
-- ✅ 识别了核心实体和关系
-- ✅ 发现了用户没说的暗物质组件
-- ✅ 领域模型保存到 `.anws/v{N}/concept_model.json`
-- ✅ 用户确认术语理解正确
-</completion_criteria>
-
----
-
-## Collaboration
-
-*   **Before**: 用户提供的模糊需求描述
-*   **After**: `spec-writer` 基于澄清后的需求生成 PRD
-*   **Synergy**: 你的领域模型为后续架构设计提供清晰的术语基础
+---
+
+## name: concept-modeler
+
+description: 当用户需求模糊、术语不清晰时使用。通过交互式追问澄清领域概念，提取实体、流程和暗物质。由 /genesis Step 1 调用。
+
+# 领域建模师 (Domain Modeler)
+
+> "如果你描述不清楚，你就造不出来。" —— Eric Evans
+
+本技能通过**交互式追问**将用户的"感觉词"转化为清晰的领域模型。
+
+---
+
+## 使命与定位
+
+**这个技能是什么**: 通过与用户交互，澄清模糊需求，建立领域模型（实体、流程、暗物质）。
+
+**何时调用**:
+
+- `/genesis` Step 1: 需求澄清阶段
+- 用户需求使用模糊术语（"同步"、"列表"、"管理"）
+- 需要建立 Ubiquitous Language
+
+**何时不调用**:
+
+- 需求已经清晰、术语已定义
+- 纯技术实现讨论（无需领域建模）
+
+---
+
+## 核心原则
+
+> [!IMPORTANT]
+> **一次只问一个问题，不一次性输出所有问题。**
+>
+> **为什么？** 用户一次只能思考一个问题。逐个追问能获得更准确的答案，也避免用户被问题淹没。
+
+---
+
+## 交互流程 (Interactive Process)
+
+### Step 1: 扫描模糊区域
+
+**目标**: 识别需求中的模糊术语和缺失信息。
+
+> [!IMPORTANT]
+> 你**必须**先扫描用户需求，识别以下类别的模糊点：
+>
+>
+> | 类别       | 检查问题                                          |
+> | -------- | --------------------------------------------- |
+> | **实体模糊** | "列表"是什么？`Wishlist`？`ShoppingCart`？`TodoList`？ |
+> | **动词模糊** | "同步"是单向/双向？实时/批量？失败策略？                        |
+> | **暗物质**  | 用户只描述 Happy Path——错误处理？持久化？认证？                |
+> | **边界模糊** | 谁能访问？数据量多大？并发要求？                              |
+>
+
+**内部产出**: 生成候选问题队列（最多 5 个），按影响排序。**不输出队列**。
+
+---
+
+### Step 2: 交互式追问循环
+
+**目标**: 逐个澄清模糊点，每次只问一个问题。
+
+> [!IMPORTANT]
+> **追问规则**：
+>
+> - 最多问 **5 个问题**
+> - 每个问题必须是**多选题**或**短回答（≤5 词）**
+> - 每次只输出**一个问题**
+
+#### 2.1 多选题格式
+
+对于有多种明确选项的问题：
+
+```markdown
+**推荐:** 选项 B - 实时双向同步能保证数据一致性，适合用户多设备场景。
+
+| 选项 | 描述 |
+| :--- | :--- |
+| A | 单向同步（仅上传） |
+| B | 实时双向同步 |
+| C | 批量定时同步 |
+| 自定义 | 提供简短描述（≤5 词） |
+
+回复选项字母（如 "B"），说 "yes" 或 "推荐" 接受推荐，或提供自定义答案。
+```
+
+#### 2.2 短回答格式
+
+对于需要用户自定义的问题：
+
+```markdown
+**建议:** 用户愿望清单 - 这是电商场景最常见的术语。
+
+格式: 简短回答（≤5 词）。说 "yes" 或 "建议" 接受建议，或提供你的答案。
+```
+
+#### 2.3 停止条件
+
+停止追问当：
+
+- 所有关键模糊点已澄清
+- 用户说 "done"、"好了"、"继续"
+- 已问满 5 个问题
+
+---
+
+### Step 3: 增量更新模型
+
+**目标**: 每次获得答案后，立即更新领域模型。
+
+> [!IMPORTANT]
+> **每个答案接受后立即更新**，不要等所有问题结束。
+
+**更新规则**：
+
+1. 实体澄清 → 更新 `entities` 列表
+2. 动词澄清 → 更新 `flows` 列表
+3. 暗物质识别 → 更新 `missing_components` 列表
+4. 术语统一 → 记录到 `glossary`
+
+---
+
+## 输出格式
+
+**输出路径**: `.anws/v{N}/concept_model.json`
+
+```json
+{
+  "glossary": {
+    "Wishlist": "用户的愿望清单，可添加商品但不直接结算",
+    "Sync": "实时双向同步，保证多设备数据一致"
+  },
+  "entities": [
+    { "name": "Wishlist", "type": "聚合根", "necessity": "必须", "description": "用户的愿望清单" },
+    { "name": "WishlistItem", "type": "实体", "necessity": "必须", "description": "愿望清单中的商品项" }
+  ],
+  "flows": [
+    { "from": "User", "action": "添加", "to": "Wishlist", "data": "Product ID", "trigger": "用户点击" },
+    { "from": "Wishlist", "action": "同步", "to": "RemoteServer", "data": "全量数据", "mode": "实时双向" }
+  ],
+  "missing_components": [
+    { "component": "同步冲突解决", "category": "错误处理", "priority": "高", "reason": "多设备同时修改" },
+    { "component": "离线队列", "category": "可靠性", "priority": "中", "reason": "网络断开时暂存操作" }
+  ],
+  "clarifications": [
+    { "question": "同步是实时的还是批量的？", "answer": "实时双向同步" }
+  ]
+}
+```
+
+---
+
+## 老师傅守则
+
+1. **不要假设**: 永远不要假设你理解了用户的词汇。追问确认。
+2. **一次一个**: 用户一次只能思考一个问题。不要输出问题列表。
+3. **推荐优先**: 给出推荐选项 + 理由，让用户更容易决策。
+4. **增量更新**: 每个答案立即写入文件，避免上下文丢失。
+5. **术语统一**: 一旦确定术语，全程使用该术语，避免同义词。
+6. **工具优先提问**: 如果当前环境提供 `ask question` 等结构化提问工具，优先使用工具发起问题，而不是让用户手动输入整段回复。
+
+---
+
+## 完成标准
+
+- 澄清了关键模糊术语（记录到 glossary） -  识别了核心实体和关系 -  发现了用户没说的暗物质组件 -  领域模型保存到 `.anws/v{N}/concept_model.json` -  用户确认术语理解正确
+
+---
+
+## Collaboration
+
+- **Before**: 用户提供的模糊需求描述
+- **After**: `spec-writer` 基于澄清后的需求生成 PRD
+- **Synergy**: 你的领域模型为后续架构设计提供清晰的术语基础
+

package/templates/.agents/skills/craft-authoring/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: craft-authoring
+description: 执行 /craft 时必读：提供 Workflow / Skill / Prompt 的脚手架模板、防护语法、填充与验证清单；长模板与自检细节不在 craft workflow 内重复，一律以本 skill 为准。
+---
+
+# Craft Authoring — 脚手架与自检
+
+本 skill 承接 **`/craft` workflow** 中「怎么写」的细节；`/craft` 只保留仪式与步骤路由。**禁止**在 workflow 里复述本节全文。
+
+## Workflow 骨架（最小可用）
+
+```markdown
+---
+description: [一句话，列表展示用]
+---
+
+# /name
+
+<phase_context>
+你是 **[角色]**。
+**使命**：…
+**能力**：…
+**限制**：…
+**原则**：…
+**与用户的关系**：…
+**Output Goal**: `路径`
+</phase_context>
+
+---
+
+## CRITICAL …
+
+> [!IMPORTANT]
+> **为什么**：…
+> - …
+> - …
+
+---
+
+## Step 1: …
+
+**目标**：…
+
+> [!IMPORTANT]
+> 你**必须**… **为什么？** …
+
+**思考引导**:
+1. …
+2. …
+
+---
+
+<completion_criteria>
+- …
+</completion_criteria>
+```
+
+## Skill 骨架（description 必须是触发条件）
+
+```markdown
+---
+name: kebab-name
+description: 当 [具体触发场景] 时加载。[一句话能力概括]
+---
+
+# 标题
+
+## 硬边界 / 原则
+…
+
+## 输入 / 输出契约
+…
+```
+
+**description 忌**：泛泛「我能处理 PDF」；**宜**：「当用户要读取/编辑 PDF 时」。
+
+## Prompt 骨架
+
+```markdown
+# 标题
+
+## 角色
+…
+
+## 任务
+…
+
+## 约束
+…
+
+## 输出格式
+…
+```
+
+## 防护语法速查
+
+
+| 机制                      | 用途       |
+| ----------------------- | -------- |
+| `[!IMPORTANT]`          | 不可跳过节点   |
+| `##  CRITICAL`        | 边界醒目     |
+| `你**必须**`               | 强制动作     |
+| 具体引导问题                  | 替代「好好想想」 |
+| `<completion_criteria>` | 完成定义     |
+
+
+重要约束建议包含：**做什么 / 为什么 / 违反时长什么样**。
+
+## 填充内容（Step 5 等价）
+
+用 `sequential-thinking` 组织 **3–5 个 thought**，覆盖：目标、最易错点、每步 I/O、引导问题、模板复用、调研结论如何打入文档。
+
+**质量扫一眼**：目标是否逐步清晰、约束是否有「为什么」、是否有输出模板、关键处有 / 对照（如需）。
+
+## 验证清单（输出前）
+
+**结构**：frontmatter、`phase_context`（workflow）、CRITICAL 块、每步有目标、`<completion_criteria>`。
+
+**内容**：路径含 `.anws/v{N}/` 若适用、kebab-case、工具调用语法正确。
+
+## 自我批评（输出前最后一道）
+
+用 `sequential-thinking` **3–5 thought**：用户会在哪卡住？AI 可能在哪偷懒跳过？与 `/challenge` 级质量相比缺什么？随后迭代修复再交付。