@haaaiawd/anws 2.3.0 → 2.4.1

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

@@ -1,183 +1,186 @@
----
-
-## name: craft-authoring
-description: 执行 /craft 时必读。提供 Workflow / Skill / Prompt 骨架与质量护栏。以判断准绳替代堆砌步骤。
-
-# Craft Authoring - 脚手架与自检
-
-本 skill 承接 `/craft` 中“如何写成”的细节。  
-`/craft` 给方向，这里给落地。方向如果没有落地，会变成口号；落地如果没有方向，会变成机械动作。
-
-## 全局写作协议
-
-1. 禁止使用 emoji。
-2. 允许拟人叙事，但语气必须克制、理性、专业。
-3. 使用短句，每句表达单一语义。
-4. 每个 Step 固定回答：做什么 / 为什么 / 怎么验收。
-5. 先给意义，再给规则，再给验证。禁止只写漂亮话。
-
-**判断准绳**：
-
-- 好文档让执行者更清醒、更稳定、更可复现。
-- 坏文档让执行者更兴奋，却更依赖临场发挥。
-
----
-
-## Workflow 骨架（最小可用）
-
-```markdown
----
-description: [一句话说明用途]
----
-
-# /name
-
-<phase_context>
-你是 **[角色]**。
-**使命**：...
-**能力**：...
-**限制**：...
-**与用户的关系**：...
-**Output Goal**: `路径`
-</phase_context>
-
----
-
-## CRITICAL 写作约束
-
-> [!IMPORTANT]
-> 写作约束由 `/craft` 主 workflow 统一定义，此处不重复展开。
-
----
-
-## Step 1: [标题]
-
-### 做什么
-...
-
-### 为什么
-...
-
-### 怎么验收
-- ...
-- ...
-
----
-
-<completion_criteria>
-- [可验证完成标准]
-</completion_criteria>
-```
-
-## Skill 骨架（description 必须是触发条件）
-
-```markdown
----
-name: kebab-name
-description: 当 [具体触发场景] 时加载。[能力概括]
----
-
-# 标题
-
-## 做什么
-...
-
-## 为什么
-...
-
-## 怎么验收
-- 输入契约：...
-- 输出契约：...
-```
-
-**description 忌**：泛化能力标签。  
-**description 宜**：明确触发场景与边界。
-
-**判断准绳**：  
-一个好的 description 像门禁，不像标语。  
-它要决定“何时进入”，也要决定“何时不进入”。
-
-## Prompt 骨架
-
-```markdown
-# 标题
-
-## 做什么
-...
-
-## 为什么
-...
-
-## 怎么验收
-- 约束：...
-- 输出格式：...
-```
-
-## 防护语法速查
-
-
-| 机制                      | 用途     |
-| ----------------------- | ------ |
-| `[!IMPORTANT]`          | 不可跳过节点 |
-| `## CRITICAL`           | 边界醒目   |
-| `你**必须**`               | 强制动作   |
-| `<completion_criteria>` | 完成定义   |
-
-
-重要约束至少写清：做什么、为什么、偏航信号。
-
-## 填充内容（Step 5 等价）
-
-用 `sequential-thinking` 组织 3-5 个 thought，覆盖目标、易错点、每步 I/O、调研结论落点。
-
-质量快检：
-
-- 章节是否单问题回答
-- 约束是否写明为什么
-- 输出是否可验证
-
-**判断准绳**：  
-如果一个段落不能告诉执行者“该做什么”，它就是噪声。  
-如果一个段落不能告诉执行者“为何如此”，它就是命令。  
-如果一个段落不能告诉执行者“如何验证”，它就是祈祷。
-
-## 验证清单（输出前）
-
-结构：
-
-- frontmatter
-- `phase_context`（workflow 场景）
-- `CRITICAL` 块
-- `<completion_criteria>`
-
-内容：
-
-- 路径与命名正确
-- 触发条件清晰
-- 输入输出契约完整
-- 失败信号可被外部观察
-
-## 评分闸门（发布前）
-
-发布前必须执行静态评分：
-
-- 读取 `references/PROMPT_QUALITY_RUBRIC.md`
-- 生成 `references/SCORECARD_TEMPLATE.md` 对应的评分卡
-- 输出 Tier（T0/T1/T2/T3）与七维加权得分
-
-硬门规则：
-
-- 若触发 Hard Fail Gate，结论必须为 `Infeasible`
-- 若未触发 Hard Fail 且总分 < 4.0，必须回炉一次再评分
-
-## 自我批评（输出前最后一道）
-
-用 `sequential-thinking` 做 3-5 个 thought：
-
-- 用户会卡在哪一步
-- AI 可能跳过哪条约束
-- 哪一节仍存在多问题混写
-- 修复后再交付
-
-最后问自己一句：  
-如果这份文档真的会被反复执行，你敢不敢为它的后果负责？
+---
+name: craft-authoring
+description: 执行 /craft 时必读。提供 Workflow / Skill / Prompt 骨架与质量护栏。以判断准绳替代堆砌步骤。
+---
+
+# Craft Authoring - 脚手架与自检
+
+本 skill 承接 `/craft` 中“如何写成”的细节。  
+`/craft` 给方向，这里给落地。方向如果没有落地，会变成口号；落地如果没有方向，会变成机械动作。
+
+## 全局写作协议
+
+1. 禁止使用 emoji。
+2. 允许拟人叙事，但语气必须克制、理性、专业。
+3. 使用短句，每句表达单一语义。
+4. 每个 Step 固定回答：做什么 / 为什么 / 怎么验收。
+5. 先给意义，再给规则，再给验证。禁止只写漂亮话。
+
+**判断准绳**：
+
+- 好文档让执行者更清醒、更稳定、更可复现。
+- 坏文档让执行者更兴奋，却更依赖临场发挥。
+
+> **与 `output-contract` 的分工**：本节只定义 Workflow / Skill / Prompt **撰写脚手架**；持久化报告的共用 spec、父子委派与单写者规则见 **`.agents/skills/output-contract/SKILL.md`**。  
+> **与 CLI 安装清单的分工**：哪些路径会随 `anws init` 复制、registry 与 **`BUNDLE_POLICY`** 边界见 **`references/BUNDLE_POLICY.md`**。
+
+---
+
+## Workflow 骨架（最小可用）
+
+```markdown
+---
+description: [一句话说明用途]
+---
+
+# /name
+
+<phase_context>
+你是 **[角色]**。
+**使命**：...
+**能力**：...
+**限制**：...
+**与用户的关系**：...
+**Output Goal**: `路径`
+</phase_context>
+
+---
+
+## CRITICAL 写作约束
+
+> [!IMPORTANT]
+> 写作约束由 `/craft` 主 workflow 统一定义，此处不重复展开。
+
+---
+
+## Step 1: [标题]
+
+### 做什么
+...
+
+### 为什么
+...
+
+### 怎么验收
+- ...
+- ...
+
+---
+
+<completion_criteria>
+- [可验证完成标准]
+</completion_criteria>
+```
+
+## Skill 骨架（description 必须是触发条件）
+
+```markdown
+---
+name: kebab-name
+description: 当 [具体触发场景] 时加载。[能力概括]
+---
+
+# 标题
+
+## 做什么
+...
+
+## 为什么
+...
+
+## 怎么验收
+- 输入契约：...
+- 输出契约：...
+```
+
+**description 忌**：泛化能力标签。  
+**description 宜**：明确触发场景与边界。
+
+**判断准绳**：  
+一个好的 description 像门禁，不像标语。  
+它要决定“何时进入”，也要决定“何时不进入”。
+
+## Prompt 骨架
+
+```markdown
+# 标题
+
+## 做什么
+...
+
+## 为什么
+...
+
+## 怎么验收
+- 约束：...
+- 输出格式：...
+```
+
+## 防护语法速查
+
+
+| 机制                      | 用途     |
+| ----------------------- | ------ |
+| `[!IMPORTANT]`          | 不可跳过节点 |
+| `## CRITICAL`           | 边界醒目   |
+| `你**必须**`               | 强制动作   |
+| `<completion_criteria>` | 完成定义   |
+
+
+重要约束至少写清：做什么、为什么、偏航信号。
+
+## 填充内容（Step 5 等价）
+
+用 `sequential-thinking` 组织 3-5 个 thought，覆盖目标、易错点、每步 I/O、调研结论落点。
+
+质量快检：
+
+- 章节是否单问题回答
+- 约束是否写明为什么
+- 输出是否可验证
+
+**判断准绳**：  
+如果一个段落不能告诉执行者“该做什么”，它就是噪声。  
+如果一个段落不能告诉执行者“为何如此”，它就是命令。  
+如果一个段落不能告诉执行者“如何验证”，它就是祈祷。
+
+## 验证清单（输出前）
+
+结构：
+
+- frontmatter
+- `phase_context`（workflow 场景）
+- `CRITICAL` 块
+- `<completion_criteria>`
+
+内容：
+
+- 路径与命名正确
+- 触发条件清晰
+- 输入输出契约完整
+- 失败信号可被外部观察
+
+## 评分闸门（发布前）
+
+发布前必须执行静态评分：
+
+- 读取 `references/PROMPT_QUALITY_RUBRIC.md`
+- 生成 `references/SCORECARD_TEMPLATE.md` 对应的评分卡
+- 输出 Tier（T0/T1/T2/T3）与七维加权得分
+
+硬门规则：
+
+- 若触发 Hard Fail Gate，结论必须为 `Infeasible`
+- 若未触发 Hard Fail 且总分 < 4.0，必须回炉一次再评分
+
+## 自我批评（输出前最后一道）
+
+用 `sequential-thinking` 做 3-5 个 thought：
+
+- 用户会卡在哪一步
+- AI 可能跳过哪条约束
+- 哪一节仍存在多问题混写
+- 修复后再交付
+
+最后问自己一句：  
+如果这份文档真的会被反复执行，你敢不敢为它的后果负责？

package/templates/.agents/skills/craft-authoring/references/BUNDLE_POLICY.md

@@ -0,0 +1,42 @@
+# 模板 Bundle 契约（CLI · 发货模板）
+
+本文定义 **安装边界**：哪些文件由 CLI 复制；产品与 CLI 仅维护 **一套** `RESOURCE_REGISTRY`。**`zh` / `en`** 只决定从 **`templates/`** 或 **`templates_en/`** 取同源相对路径的文案，不是两套并行产品权威。  
+修改 **`lib/manifest.js`** 的登记项 = **显式改变**用户侧安装集合，须在 **发版说明** 中写明。
+
+---
+
+## 1. CLI 复制的唯一来源
+
+| 机制 | 说明 |
+|------|------|
+| **`RESOURCE_REGISTRY`** | `lib/manifest.js` 中的数组；**唯一**驱动 `anws init` / `anws update` 写入用户项目的路径集合（经各 IDE target 投影）。 |
+| **`TEMPLATE_ROOT`** / **`TEMPLATE_ROOT_EN`** | `src/anws/templates/` 与 `src/anws/templates_en/`（见 `lib/resources`）。**`resolveCanonicalPath(rel, templateLocale)`** 在 **`zh`** 时读 `templates/`；在 **`en`** 时优先 `templates_en/` 下同相对路径，不存在则回退 `templates/`。 |
+| **校验** | `scripts/check-canonical-templates.js`：registry 中每条 `source` 必须在 **`templates/`** 下存在且为普通文件。 |
+
+未出现在 **`RESOURCE_REGISTRY`** 中的相对路径——即使躺在 **`templates/`** 目录里——**默认不会被 CLI 安装**。例如 **`nexus-query/`** 等仅作仓库维护、未登记时，CLI 不发货；以 **registry + 本文件** 为准。
+
+---
+
+## 2. `templateLocale`：`templates/` 与 `templates_en/`
+
+- **`templates/`**：npm 包内默认中文文案树，亦是 **registry 路径的存在性校验根**。
+- **`templates_en/`**：英文镜像；`install-lock` 中 **`templateLocale: en`** 时，init/update 从 **`templates_en/`** 读取同源 **相对路径**，缺失条目回退 **`templates/`**。
+- 维护时 **同一组 `source` 相对路径** 在中英文树之间 **语义对齐**，避免 EN-only 漂移。
+
+---
+
+## 3. 与 `/craft`、output-contract 的分工
+
+| 文档 / Skill | 管什么 |
+|----------------|--------|
+| **`craft-authoring`（本仓库 SKILL）** | Workflow / Skill / Prompt **撰写脚手架**与评分闸门。 |
+| **`output-contract`** | 执行期 **落盘 spec**、**委派与单写者**。 |
+| **本文 `BUNDLE_POLICY`** | **谁会被 CLI 安装**、locale 选根规则、registry **决策记录**。 |
+
+---
+
+## 4. 瘦身与后续工作（建议顺序）
+
+1. **登记缺口**：若 **`templates/`** 里某路径应随 CLI 发货但未在 registry，**要么登记要么删磁盘冗余**，避免「仓库有、用户永远没有」。
+2. **重复收敛**：各 reviewer / workflow 中与 **`output-contract`**、**`BUNDLE_POLICY`** 重复的段落，改为 **一句引用**。
+3. **大块 skill**（如 **`system-architect`**）：模板示例与 ADR 镜像表 **外链** 单一真源，再谈体积收敛或大合并。