architext 0.0.3 → 0.0.5

package/dist/templates/zh/skills/archi-decompose-roadmap/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: archi-decompose-roadmap
-description: Architext 任务分解专家。五步分解法：先标定项目类型校准基建清单，再双视角提取业务 Task 和 Infra 任务，NFR 横切关注点归并入 goal（不独立成任务），建立真实依赖链并输出并行批次。产出符合 Tier 1 Schema 的 roadmap.json 任务，作为 `/archi.plan` 的输入契约。用于任何需要生成或追加 Roadmap 任务的场景。
+type: subagent
+description: Architext 任务分解专家。五步分解法：先标定项目类型校准基建清单，再双视角提取业务 Task 和 Infra 任务，识别 Polish 打磨任务，NFR 横切关注点按权重决定注入或独立，建立真实依赖链并输出并行批次。任务通过 ID 前缀（INF/FEAT/POLISH/EDIT）编码类型，tag 字段承载业务领域标签。产出符合 Tier 1 Schema 的 roadmap.json 任务，作为 `/archi.plan` 的输入契约。
 ---
 
 # Roadmap 任务分解
@@ -13,10 +14,10 @@ Brief → [本 Skill] → roadmap.json 任务
                    /archi.plan <task-id>
                    读: vision.md + map.json + tech_stack.md
                    写: spec.md（行为规格/验收标准）
-                       ui.md（任务 UI 范围声明）[?UI]
+                       仅ui项目: ui.md（任务 UI 范围声明）
                        plan.json（可执行步骤 + 测试用例 checkbox）
                    也更新: map.json / dictionary.json / data_snapshot.json
-                   视觉参考: [[__DOCS_DIR__]]/global/ui_context.md [?UI]
+                   仅ui项目: 视觉参考: [[__DOCS_DIR__]]/global/ui_context.md
                             ↓
                    /archi.code → 读 spec.md + ui.md + plan.json → 写代码
 ```
@@ -45,17 +46,17 @@ Brief → [本 Skill] → roadmap.json 任务
 | 项目类型 | 脚手架须包含（除通用构建工具链外） |
 |:---|:---|
 | Web SPA / PWA | 路由骨架（如 React Router）+ 全局 App Shell（布局 / Provider / 主题注入） |
-| 全栈 Web（SSR/SSG）| 路由约定（loader/action/页面）+ API Routes 层 + 全局布局 + Auth Session 管理（Cookie/JWT）；[?UI] 主题注入 |
+| 全栈 Web（SSR/SSG）| 路由约定（loader/action/页面）+ API Routes 层 + 全局布局 + Auth Session 管理（Cookie/JWT）；仅ui项目: 主题注入 |
 | CLI 工具 | logger 模块 + AppError 处理层 + 命令注册入口 |
-| API 服务（REST / GraphQL）| 路由层 + 中间件层 + DB 连接层 + 全局错误处理；[?GraphQL] Schema 定义层 + DataLoader |
+| API 服务（REST / GraphQL）| 路由层 + 中间件层 + DB 连接层 + 全局错误处理；仅GraphQL项目 Schema 定义层 + DataLoader |
 | 移动端 App（原生/跨平台）| 导航骨架（React Navigation / Go Router）+ 平台适配层（iOS/Android 权限、原生模块）+ 环境配置（dev/staging/prod）|
 | 小程序 | 页面路由配置 + 全局 app.js/ts + 请求封装层 |
 | 浏览器扩展 | manifest.json（V2/V3）+ Background Service Worker + Content Script 注入层 + 消息总线（background ↔ content ↔ popup）+ Popup/Options 页入口 |
 | 桌面端 App（单机）| 主进程入口（Electron main / Tauri main.rs）+ IPC 通信桥 + 系统级能力（托盘、热键）+ 原生文件系统封装 |
 | Web + 桌面端（Hybrid）| Web 脚手架基础 + 桌面运行时集成（Tauri/Electron）+ 系统级能力（托盘、全局热键、系统通知）；**桌面集成须独立拆分为 INF 子任务**（OS 差异大、与 Web 技术栈完全不同，不适用 Step 2 的"同期执行合并"规则） |
 | 库 / SDK / NPM 包 | 双产物配置（CJS + ESM）+ 公共 API 入口（barrel index.ts）+ 类型声明生成（.d.ts）+ Changelog / 版本工具链；**禁建业务 Task，仅 INF 层** |
-| 实时 / 协作型 App | WebSocket 服务层 + 事件 Schema 定义（共享类型）+ 房间/会话管理基础；[?CRDT] 冲突解决层 |
-| AI Agent / MCP 工具 | LLM 客户端抽象层（provider 无关）+ Prompt 模板管理 + Tool/Function Calling Schema + 对话状态 / Memory 管理；[?MCP] MCP 协议适配器 |
+| 实时 / 协作型 App | WebSocket 服务层 + 事件 Schema 定义（共享类型）+ 房间/会话管理基础；仅CRDT项目） 冲突解决层 |
+| AI Agent / MCP 工具 | LLM 客户端抽象层（provider 无关）+ Prompt 模板管理 + Tool/Function Calling Schema + 对话状态 / Memory 管理；仅MCP项目） MCP 协议适配器 |
 
 **操作（两个输出）**：
 1. **注入 Step 2 INF-01**：将对应类型的脚手架清单写入 INF-01 描述。
@@ -117,9 +118,15 @@ Brief → [本 Skill] → roadmap.json 任务
 
     > `/archi.plan` 执行中若预估 spec.md Scenario > 6 或 plan.json Phase > 4，须暂停并提示用户返回 `/archi.scope` 重新拆分，禁强行塞进单一任务。
 
-**DoD 格式**：`完成后，用户可 <可验证的用户行为>；边界：<明确不做的事>`
+**DoD 格式**（按任务类型）：
 
-> DoD 是 `/archi.plan` 生成 spec.md 验收标准和 plan.json 测试用例的基准。须精准描述用户可感知结果，禁写实现细节（文件路径、函数名、测试命令由 plan 阶段决定）。
+| 任务类型 | goal 格式 |
+|:---|:---|
+| `FEAT-xx` | `完成后，用户可 <可验证的用户行为>；边界：<明确不做的事>` |
+| `INF-xx` | `完成后，<基础设施产出物描述>，通过 <验证命令> 验证；边界：<明确不做的事>` |
+| `POLISH-xx` | `完成后，<质量指标> 从 <基线> 提升至 <目标>；边界：<明确不做的事>` |
+
+> DoD 是 `/archi.plan` 生成 spec.md 验收标准和 plan.json 测试用例的基准。FEAT 任务须描述用户可感知结果；INF 任务须描述基础设施产出物和验证方式；POLISH 任务须描述可量化的质量目标。禁写实现细节（文件路径、函数名、测试命令由 plan 阶段决定）。
 
 以下情况归属父任务，禁独立成条：**轻量**结果页 / 完成页、空状态页、确认弹窗。
 
@@ -136,10 +143,10 @@ Brief → [本 Skill] → roadmap.json 任务
 | Infra 类型 | 判断标准 |
 |:---|:---|
 | 项目脚手架 / 全局 Schema / 类型定义 | 所有业务 Task 均依赖；须覆盖 Step 0 标定的项目类型清单 |
-| 共享核心引擎（打字引擎、规则引擎等） | 满足以下**任一**条件：① 2 个以上业务 Task 直接调用；② 纯逻辑层、可独立单元测试、与 UI 完全解耦。`tag: Core` |
+| 共享核心引擎（打字引擎、规则引擎等） | 满足以下**任一**条件：① 2 个以上业务 Task 直接调用；② 纯逻辑层、可独立单元测试、与 UI 完全解耦。ID 仍用 `INF-xx`（本质是基础设施），`tag` 可标注为业务域标签（如 `Core`、`Engine`） |
 | 第三方集成层 | 多个业务 Task 复用同一外部服务 |
 
-**Core 任务规划契约**：`tag: Core` 任务的 `description` 末尾须声明主要导出接口（函数签名或关键 interface 名称）。
+**共享引擎规划契约**：共享核心引擎类 INF 任务的 `description` 末尾须声明主要导出接口（函数签名或关键 interface 名称）。
 下游 Task 的 `/archi.plan` 会话可直接对接该接口，无需读上游实现，保障跨任务规划的一致性与可预测性。
 
 **Infra 任务粒度原则：避免微粒化，但禁止跨层堆积**：
@@ -181,20 +188,31 @@ Brief → [本 Skill] → roadmap.json 任务
 
 ---
 
-### Step 3 · NFR 过滤
+### Step 3 · NFR 过滤与 Polish 任务识别
+
+横切关注点按**工作量权重**决定处理方式：轻量级注入 goal，重量级独立成 `POLISH-xx` 任务。
 
-以下类型**禁独立成任务**：注入首个实现该能力的任务 `goal` 末尾（`[NFR] <说明>`）；其余受影响任务仅在 NFR 清单中标注。`/archi.plan` 执行时会将 NFR 注入对应的 spec.md 约束章节。
+> **"首个任务"定义**（用于 NFR 注入）：在依赖链中，`deps` 仅含 INF 层（无业务前置依赖）且最早涉及该 NFR 能力的任务。同层（同 Batch）有多个候选时，取 ID 最小的那个。
 
-> **"首个任务"定义**：在依赖链中，`deps` 仅含 INF 层（无业务前置依赖）且最早涉及该 NFR 能力的任务。同层（同 Batch）有多个候选时，取 ID 最小的那个。
+**判定标准**：
+
+| 信号 | 处理 |
+|:---|:---|
+| 仅需业务 Task 内"顺手做"（如用 i18n key 替代硬编码） | **NFR 注入** — 写入首个相关任务 goal 末尾 `[NFR] <说明>` |
+| 需独立基础设施搭建（如集成 next-intl、创建翻译文件体系） | **INF 任务** — 建 `INF-xx`，Phase 1 |
+| 需跨功能专项工作，且验收可独立度量（如 Lighthouse ≥ 90、全面 a11y 审计） | **POLISH 任务** — 建 `POLISH-xx`，Phase 3 |
 
-| 类型 | 常见形式 | 注意 |
+**按类型对照**：
+
+| 类型 | 轻量级 → NFR 注入 | 重量级 → 独立任务 |
 |:---|:---|:---|
-| 国际化 | i18n、多语言、翻译文案 | — |
-| 视觉主题（配置型） | 品牌色 Token、Tailwind 主题色、CSS 变量定义 | NFR，注入脚手架任务 |
-| 视觉主题（功能型） | 深色/浅色切换按钮、OS 偏好检测、主题持久化 | **非 NFR**，须建立独立业务 Task（有用户可见行为） |
-| 动效风格规范 | 页面切换方式、过渡时长约定 | NFR，注入首个含动效的 Task goal |
-| 性能优化 | 懒加载、虚拟列表、缓存策略 | — |
-| 可访问性 | A11y、键盘导航、屏幕阅读器 | — |
+| 国际化 | 业务 Task 内用 i18n key | 集成 i18n 框架 + 翻译文件结构 → `INF-xx`；全量翻译覆盖 + 语言切换 UI → `POLISH-xx` |
+| 视觉主题（配置型） | 品牌色 Token 注入脚手架 | — |
+| 视觉主题（功能型） | — | 深色/浅色切换 + OS 偏好检测 → `FEAT-xx`（有用户可见行为） |
+| 动效风格 | 过渡时长约定注入首个含动效 Task | — |
+| 性能优化 | 单个 Task 内的懒加载/缓存 | 跨功能专项优化（首屏 < 2s、包体积目标）→ `POLISH-xx` |
+| 可访问性 | 单个 Task 内的 ARIA 属性 | 全面 a11y 审计 + 修复 → `POLISH-xx` |
+| 打包分发 | — | 桌面端打包 + 自动更新配置 → `POLISH-xx` |
 
 ---
 
@@ -208,22 +226,38 @@ Brief → [本 Skill] → roadmap.json 任务
 
 ## 任务规则
 
-1. **ID 生成**：沿用已有 Roadmap 编号水位，从各前缀最大值 +1 起；全新项目从 `INF-01` / `FEAT-01` 起。
+1. **ID 前缀与任务类型**：
+
+   ID 前缀是任务类型的**唯一标识**，`/archi.plan` 根据前缀选择 spec 验收格式。
+
+   | ID 前缀 | 任务类型 | 含义 | Phase 归属 |
+   |:---|:---|:---|:---|
+   | `INF-xx` | Infrastructure | 基础设施：脚手架、Schema、工具链、第三方集成 | Phase 1 |
+   | `FEAT-xx` | Feature | 业务功能：用户可感知的行为 | Phase 2 |
+   | `POLISH-xx` | Quality | 质量打磨：性能优化、全面 i18n、a11y 审计、打包分发 | Phase 3 |
+   | `EDIT-xx` | Edit | 修改已有功能（仅增量追加模式） | 与被修改任务同 Phase |
+
+   沿用已有 Roadmap 编号水位，从各前缀最大值 +1 起；全新项目从 `INF-01` / `FEAT-01` 起。
 
-2. **Phase 归属**：
+2. **Phase 结构**：
 
-   | 任务类型 | Phase |
-   |:---|:---|
-   | 项目脚手架、Schema、全局类型 | Phase 1 (Infrastructure) |
-   | 共享核心引擎（Step 2 识别） | Phase 1 (Infrastructure) |
-   | 业务 Task | Phase 2 (Core Features) |
-   | EDIT-xxx（修改已有功能） | 与被修改任务同 Phase |
+   | Phase | ID | 名称 | 内容 |
+   |:---|:---|:---|:---|
+   | Phase 1 | `phase-infra` | Infrastructure | INF-xx 任务（脚手架、数据层、认证、API 骨架等） |
+   | Phase 2 | `phase-core` | Core Features | FEAT-xx 任务（业务功能） |
+   | Phase 3 | `phase-polish` | Polish & Launch | POLISH-xx 任务（质量优化、打包分发）；Brief 无打磨需求时省略此 Phase |
 
-3. **设计决策注入**：Brief 中已有设计决策 → 注入对应任务 `goal` 末尾：`[用户预设] <内容>`；同一条决策禁在多任务重复。`/archi.plan` 将其视为不可更改的硬约束，直接写入 spec.md，不再提问。
+3. **tag 字段 = 业务领域标签**：
 
-4. **EDIT 任务**：需修改已有功能 → 创建 `EDIT-xxx`（`tag: Edit`），goal 注明修改范围；仅增量追加模式下使用。
+   `tag` 用于标注任务所属的**业务领域**（如 `Core`、`Community`、`Auth`、`Data`），自由文本，由 Brief 内容决定。
 
-5. **Slug 命名**：`slug` 即 `tasks/<slug>/` 文件夹名，须清晰表达任务内容，格式为 `Pascal_Snake_Case`（如 `Typing_Engine_Core`）。每个任务对应唯一一个 task 子目录，禁重名。
+   > **注意**：`tag` 不决定任务类型 — 任务类型由 ID 前缀决定。例如 `FEAT-05`（`tag: Community`）的任务类型是 Feature 而非 Community。
+
+4. **设计决策注入**：Brief 中已有设计决策 → 注入对应任务 `goal` 末尾：`[用户预设] <内容>`；同一条决策禁在多任务重复。`/archi.plan` 将其视为不可更改的硬约束，直接写入 spec.md，不再提问。
+
+5. **EDIT 任务**：需修改已有功能 → 创建 `EDIT-xxx`，goal 注明修改范围；仅增量追加模式下使用。
+
+6. **Slug 命名**：`slug` 即 `tasks/<slug>/` 文件夹名，须清晰表达任务内容，格式为 `Pascal_Snake_Case`（如 `Typing_Engine_Core`）。每个任务对应唯一一个 task 子目录，禁重名。
 
 ---
 
@@ -234,10 +268,10 @@ Brief → [本 Skill] → roadmap.json 任务
   "id": "FEAT-01",
   "title": "Task Title In English",
   "status": "pending | blocked",
-  "description": "<1-2 句说明这个任务要构建什么、覆盖哪些范围。Core 任务须在末尾声明主要导出接口>",
+  "description": "<1-2 句说明这个任务要构建什么、覆盖哪些范围。共享引擎类任务须在末尾声明主要导出接口>",
   "goal": "完成后，用户可 <可验证的用户行为>；边界：<明确不做的事>",
   "deps": ["INF-01"],
-  "tag": "Infra | Core | Feature | Edit",
+  "tag": "<业务领域标签，自由文本。如 Core, Community, Auth, Data, UI 等>",
   "slug": "Task_Title_Snake_Case"
 }
 ```
@@ -254,28 +288,7 @@ Brief → [本 Skill] → roadmap.json 任务
 
 产出三部分数据：
 
-**① 任务数据**（直接对应 `roadmap.json` 的 phases/tasks 结构）：
-
-```json
-{
-  "phases": [
-    {
-      "id": "phase-1",
-      "name": "Infrastructure",
-      "tasks": [
-        { "id": "INF-01", "title": "...", "status": "pending", "description": "...", "goal": "...", "deps": [], "tag": "Infra", "slug": "..." }
-      ]
-    },
-    {
-      "id": "phase-2",
-      "name": "Core Features",
-      "tasks": [
-        { "id": "FEAT-01", "title": "...", "status": "blocked", "description": "...", "goal": "...", "deps": ["INF-01"], "tag": "Feature", "slug": "..." }
-      ]
-    }
-  ]
-}
-```
+**① 任务数据**：直接对应 `roadmap.json` 的 `phases[].tasks[]` 结构，每个 task 遵循上方 Task JSON Schema。phases 按 `phase-infra` → `phase-core` → `phase-polish` 排列。
 
 **② NFR 归并清单**（须随任务数据一并返回给调用方；调用方写入 roadmap 时追加为 `nfr` 顶层字段；`/archi.plan` 的 `step_1_load` 须读取此清单）：
 
@@ -290,4 +303,5 @@ Layer 0 ║ INF-01
 Layer 1 ║ INF-02 · INF-03              ← 均依赖 INF-01
 Layer 2 ║ FEAT-01 · FEAT-02            ← 各自依赖 INF-02 / INF-03
 Layer 3 ║ FEAT-03                      ← 依赖 FEAT-01
+Layer 4 ║ POLISH-01 · POLISH-02        ← 依赖相关 FEAT 任务
 ```

package/dist/templates/zh/skills/archi-design-patterns/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: archi-design-patterns
+type: specialist
+description: Architext 技术方案结构化模式库。定义四种核心机制描述模式（State Machine / Pipeline / Decision Matrix / Protocol）的标准格式与自检清单，供 /archi.plan step_4 生成 design.md § 2 时引用，亦供 /archi.code step_5 审计实现与设计一致性时引用。
+---
+
+# 技术方案结构化模式库
+
+## 系统流程定位
+
+```
+/archi.plan step_4_generate → design.md § 2
+    ↓
+[本 Skill] 模式选择 → 格式生成 → 自检
+    ↓
+design.md § 2 Core Mechanisms 内容
+```
+
+> **Skill 的职责边界**：
+> - 负责：模式选择指南、各模式的标准表格格式、自检清单
+> - 不负责：design.md 的整体结构（见 `design.template.md`）、参数/不变量/故障模式（见模板 §§ 3-5）
+
+---
+
+## 模式选择指南
+
+根据机制特征选取 ≥1 个模式。同一功能可组合多个（如连接管理用 State Machine + 消息处理用 Pipeline）。
+
+| 机制特征 | 推荐模式 | 典型场景 |
+|:---|:---|:---|
+| 有离散状态集合与状态间转移 | **State Machine** | 连接管理、工作流引擎、组件生命周期、认证流程 |
+| 数据/请求经过有序处理步骤 | **Pipeline** | 消息解码链、中间件栈、数据转换管道、请求拦截器 |
+| 行为取决于多条件组合 | **Decision Matrix** | 权限判定、策略路由、降级规则、特性开关 |
+| 两个或多个组件间有定义好的消息交换 | **Protocol** | 客户端-服务端通信、进程间 IPC、事件总线、Worker 消息 |
+
+**执行流程**: 选定模式 → 填写对应标准格式 → **立即执行自检** → 有未通过项须修补后重检 → 全部通过再进入下一个机制。
+
+---
+
+## 模式 A: State Machine
+
+### 标准格式
+
+**States (状态集)**:
+
+| 状态 | 含义 | 进入条件 |
+|:---|:---|:---|
+| `idle` | [初始/空闲] | [初始化完成 或 主动断开] |
+| `connecting` | [连接建立中] | [发起连接请求] |
+| `connected` | [已连接] | [收到 open 事件] |
+| ... | ... | ... |
+
+**Transitions (转移表)**:
+
+| From | → To | Guard (触发条件) | Action (副作用) |
+|:---|:---|:---|:---|
+| `idle` | `connecting` | [用户触发连接] | [创建 Socket 实例] |
+| `connecting` | `connected` | [收到 open 事件] | [启动心跳, 清空重试计数] |
+| `connecting` | `disconnected` | [超时 或 error 事件] | [记录错误, 递增重试计数] |
+| ... | ... | ... | ... |
+
+### 自检清单
+
+| # | 检查项 | 验证方法 |
+|:---|:---|:---|
+| 1 | **完整性**: 无死锁 | 每个状态至少一条出边 |
+| 2 | **可达性**: 无孤岛 | 每个非初始状态至少一条入边 |
+| 3 | **终止性**: 有退出路径 | 存在终态或稳态循环 |
+| 4 | **确定性**: 无歧义转移 | 同一状态的出边 Guard 互斥 |
+| 5 | **异常覆盖**: 非 Happy Path Only | 每个非终态都有 error/timeout 出边 |
+
+---
+
+## 模式 B: Pipeline
+
+### 标准格式
+
+| Step | Input | Process | Output | On Error |
+|:---|:---|:---|:---|:---|
+| 1. [步骤名] | [输入类型] | [处理逻辑] | [输出类型] | [丢弃/重试/中止/降级] |
+| 2. [步骤名] | [上一步 Output] | [处理逻辑] | [输出类型] | [错误处理] |
+| ... | ... | ... | ... | ... |
+
+### 自检清单
+
+| # | 检查项 | 验证方法 |
+|:---|:---|:---|
+| 1 | **类型链**: 无断裂 | Step N Output = Step N+1 Input |
+| 2 | **错误处理**: 无静默吞错 | 每步都有 On Error |
+| 3 | **幂等标注**: 重试安全性明确 | 标注哪些步骤可安全重试、哪些有副作用 |
+| 4 | **可恢复性**: 可安全终止 | 任意 Step 错误后可恢复或安全退出 |
+
+---
+
+## 模式 C: Decision Matrix
+
+### 标准格式
+
+| 条件 A | 条件 B | 条件 C | → 行为 | 备注 |
+|:---|:---|:---|:---|:---|
+| [值1] | [值1] | [值1] | [行为] | |
+| [值1] | [值1] | [值2] | [行为] | |
+| [值1] | [值2] | * | [行为] | *=任意值 |
+| * | * | * | [兜底行为] | 未匹配时默认处理 |
+
+### 自检清单
+
+| # | 检查项 | 验证方法 |
+|:---|:---|:---|
+| 1 | **穷举性**: 无遗漏 | 所有条件值组合已覆盖（* 通配未列举组合） |
+| 2 | **无歧义**: 单一命中 | 同一输入只命中一行（优先级从上到下，或条件互斥） |
+| 3 | **兜底行**: 有默认处理 | 最后一行为 * 通配 |
+| 4 | **可测试**: 可构造用例 | 每行可构造测试输入验证 |
+
+---
+
+## 模式 D: Protocol
+
+### 标准格式
+
+**参与方**: [Component A] ↔ [Component B]
+
+| Seq | Sender → Receiver | Message | Payload | Expected Response | Timeout |
+|:---|:---|:---|:---|:---|:---|
+| 1 | [A → B] | `[消息名]` | {[字段: 类型]} | `[响应名]` {[字段: 类型]} | [Ns → 超时处理] |
+| 2 | [B → A] | `[消息名]` | {[字段: 类型]} | 无 (单向推送) | - |
+| ... | ... | ... | ... | ... | ... |
+
+### 自检清单
+
+| # | 检查项 | 验证方法 |
+|:---|:---|:---|
+| 1 | **配对性**: 有去有回 | 需要响应的消息都定义了 Response + Timeout |
+| 2 | **类型明确**: 无 any | 每个 Payload 字段有具体类型 |
+| 3 | **顺序依赖**: 前置声明 | 标注哪些消息必须在哪些之后 |
+| 4 | **并发安全**: 有策略 | 多消息并发时说明处理策略（队列/丢弃/合并） |
+
+---
+
+> **中间产物**：此 Skill 为子程序，产出机制描述 + 自检结果后控制权交还调用方（step_4_generate 或 step_5_audit），继续后续流程。

package/dist/templates/zh/skills/archi-feature-relations/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: archi-feature-relations
+type: reviewer
+description: featureRelations 联动处理器。在独立上下文中处理 map.json featureRelations 的注册/检查/清理操作，确保聚合型 Task 与其来源的联动关系正确维护。
+---
+
+# featureRelations 联动处理器
+
+## 系统流程定位
+
+```
+/archi.* step_N → Verify 阶段
+    ↓
+[本 Skill] 接收模式参数 → 处理 featureRelations → 返回结果
+    ↓
+主 Agent Signoff（确认联动提示）
+```
+
+> **Skill 的职责边界**：
+> - 负责：featureRelations 的注册/检查/清理三种操作
+> - 不负责：修改业务代码、修改 spec/plan 文档
+
+---
+
+## 模式与行为
+
+### 模式 `register` (调用方: plan, inherit)
+
+判断当前 Task 是否属于「聚合型 Task」，若是则在 `map.json` featureRelations 中追加记录。
+
+**聚合型 Task 判定标准**:
+- 核心职责是**列举、汇总或动态反映**其他一类 Task
+- 代码特征: 遍历/枚举/动态加载同类模块（`for (const cmd of allCommands)`、`Object.values(registry)`、读取目录后动态 import）
+- 描述特征: "汇总所有页面入口"、"注册所有路由"、"列出所有命令"
+
+**Action**:
+1. 分析 Task 的 spec/goal 描述
+2. 判定是否为聚合型
+3. 若是 → 追加 featureRelations 条目:
+   ```json
+   {
+     "aggregator": "<Task ID 或文件路径>",
+     "sources": "<来源范围描述>",
+     "evidence": "<依据>",
+     "checkNote": "此类 Task 新增或删除时，检查 <aggregator> 是否需要同步"
+   }
+   ```
+4. 若非聚合型 → 输出 `NOT AGGREGATOR`，跳过
+
+### 模式 `check` (调用方: scope, code)
+
+将当前 Task 与 featureRelations 的 sources 字段做语义对比，输出联动提示。
+
+**Action**:
+1. 读取 `map.json` 的 `featureRelations` 数组
+2. `featureRelations` 为空 → 输出 `NO RELATIONS`，跳过
+3. 将本次任务/实现的功能与各条 `sources` 做语义对比
+4. 命中时输出联动提示
+
+### 模式 `cleanup` (调用方: remove)
+
+删除被移除 Task 相关的 featureRelations 条目，检查影响范围。
+
+**Action**:
+1. 读取 `map.json` 的 `featureRelations` 数组
+2. 查找 aggregator 或 sources 中引用了被移除 Task 的条目
+3. 评估移除影响:
+   - 被移除的是 aggregator → 删除整条记录
+   - 被移除的是 source 之一 → 更新 sources 描述，提示检查 aggregator 是否需调整
+4. 输出影响报告
+
+---
+
+## 输出格式
+
+### register 模式
+
+```
+### Feature Relations: register
+
+RESULT: AGGREGATOR REGISTERED
+- aggregator: <ID>
+- sources: <描述>
+- evidence: <依据>
+```
+
+或: `RESULT: NOT AGGREGATOR — 本 Task 非聚合型，跳过`
+
+### check 模式
+
+```
+### Feature Relations: check
+
+HITS:
+- [aggregator] — [checkNote]
+
+NO HITS: [无命中的 relations]
+```
+
+或: `NO RELATIONS — featureRelations 为空`
+
+### cleanup 模式
+
+```
+### Feature Relations: cleanup
+
+REMOVED:
+- [被删除的条目]
+
+UPDATED:
+- [sources 被更新的条目]
+
+IMPACT: [影响说明]
+```
+
+---
+
+> **中间产物**：此 Skill 为审查型子程序，产出结果后控制权交还调用方。

package/dist/templates/zh/skills/archi-interview-protocol/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: archi-interview-protocol
+type: specialist
 description: Architext 补充访谈协议。规范信息缺口的提问方式：选择题优先、AI 推荐 + [推荐] 标注、[Z] 自定义兜底、AI+/AI- 完整分析、选项说明描述具体行为。产出标准 Q-table 和 INPUT 提示行，供 /archi.start、/archi.scope、/archi.plan 的补充确认步骤引用。
 ---
 
@@ -19,7 +20,7 @@ description: Architext 补充访谈协议。规范信息缺口的提问方式：
 > - 负责：问题如何提（格式/规则/语气）
 > - 不负责：问什么内容（由调用方的缺口列表决定）、用户回答后如何处理（由调用方决定）
 
-## 调用方与触发条件
+## 调用模式
 
 | 调用方 | 触发步骤 | 触发条件 | 问题数上限 |
 |:---|:---|:---|:---|