ai-project-manage-cli 2.0.26 → 3.0.1

package/templates/skills/prd-sync/updated-requirement-template.md

@@ -1,39 +0,0 @@
-# [需求标题]（修订稿）
-
-**修订说明**（可选）
-
-- 基于评审日期 / 评审记录：简要一句
-- 本次合并的要点：1～3 条 bullet
-
----
-
-## 背景与目标
-
-（合并原文与用户补充信息中明确补充/修正的表述）
-
-## 范围
-
-- **包含**：
-- **不包含**：（若**补充信息**或原文中明确收窄/排除）
-
-## 需求说明
-
-### 需求点 1：[名称]
-
-（将原文与补充信息合并后的**可执行描述**写清：角色、场景、规则、口径、边界）
-
-### 需求点 2：…
-
-## 非功能与约束（若有）
-
-（性能、权限、兼容、埋点等——仅当原文或补充信息涉及）
-
-## 待确认
-
-仅当**用户自己在补充信息里**留下未拍板事项、或写明「待定」「再议」等时列出（可选章节，可整节省略）：
-
-- [ ] （用户未决口径摘要）— 用户原话或简要归纳
-
----
-
-若用户只需要「替换某几段」而非全文，可仅在回复中给出**修改后的完整段落** + 简短「相对原文的变更摘要」，不必机械填满所有章节。

package/templates/skills/prd-testcase/SKILL.md

@@ -1,82 +0,0 @@
----
-name: prd-testcase
-description: 基于需求文档为其生成测试用例，当用户在明确要求调用本技能时使用，输入参数是 requirementId。
----
-
-# 从需求文档生成手工测试用例
-
-## 触发条件
-
-用户在对话中明确要求使用本技能。
-
-## 输入
-
-- **requirementId**：需求 ID
-
-## 输出
-
-1. 手工测试用例文档：`.apm/workitems/<requirementId>/testcase.md`
-
----
-
-## 执行流程
-
-1. **拉取需求与评论（使用 CLI）**：执行 `apm get requirement <requirementId>`，获取需求文档。
-
-### 2. 提取需求点
-- 需求点是唯一真理：所有测试点、口径、阈值、边界与禁止项必须从需求清单提炼。
-- 将需求拆分为可追踪条目并编号：`REQ-001`、`REQ-002`、`REQ-003`...
-
-### 3. 先做覆盖设计（严格模式）
-
-- **需求正向覆盖（强制）**：每个 `REQ` 至少映射 1 条测试用例（`REQ -> TC`）。
-- **用例逆向追踪（强制）**：每条 `TC` 必须回指至少 1 个 `REQ`（`TC -> REQ`）。
-- **场景维度覆盖（强制）**：每个 `REQ` 至少覆盖以下三类场景：
-  - 正向场景（主流程成功）
-  - 边界场景（阈值/长度/上下限/临界值）
-  - 异常场景（非法输入/失败分支/缺失前置条件）
-- 按上述规则先形成覆盖矩阵，再进入写作：
-  - 需求覆盖矩阵：`REQ -> TC[]`
-  - 用例追踪矩阵：`TC -> REQ[]`
-
-### 4. 生成手工测试用例（正文平铺）
-
-- 依据需求清单归纳可测场景，生成 `test_case.md`。
-- **靶心优先级（强制，避免“先射箭再画靶”）**：
-  - **最高优先级：需求清单（requirements/PRD）**。用例的“口径/阈值/不得改变的规则/显示范围/不做什么”等验收结论，必须优先从需求清单可读出的表述提炼。
-  - **第二优先级：产品能力清单 CAP**。用例的“目标入口/目标组件区域”必须以 CAP 的 `入口锚点（强制）` 与 `UI 识别锚点（强制）` 为准；若用例目标落在其它相似页面/表格组件上，应视为冲突，必须改写用例以落到 CAP 指定区域。
-- **入口锚点补全（强制，引用产品能力清单）**：
-  - 若仓库存在 `.apm/product-capability-inventory/`，则对每条用例的“目标 UI 区域”执行 CAP 对齐：
-    1. 从 `.apm/product-capability-inventory/<系统名>/index.md` 的「能力条目目录表」中，基于需求点标题/关键术语选择最匹配的 `CAP-xxx`（仅选一个最匹配的）。
-    2. 打开对应 `.apm/product-capability-inventory/<系统名>/CAP-xxx.md`，读取字段 `入口锚点（强制）` 与 `UI 识别锚点（强制）`。
-    3. 将 `入口锚点（强制）` 作为“导航来源”，把它转译为用例中的 **操作步骤**（至少覆盖：菜单/抽屉标题/Tab/子页签/目标区域的进入）。
-    4. 将 `UI 识别锚点（强制）` 作为“断言来源”，在 **预期结果**中至少包含 1 条与 `UI 识别锚点（强制）` 对应的可断言检查（例如：表头列名/关键按钮文案/区域标题等），并确保步骤中确实进入了该区域。
-  - 若找不到合适 CAP 或 CAP 缺失上述必填字段，则回退到“保守定位”：
-    - 用例操作步骤必须显式包含：菜单路径/页面标题 或 抽屉标题 或 Tab 文案 + 目标区域至少两列表头/关键按钮文案（从需求清单提炼），并用预期结果体现可断言点。
-- **testcase.md 格式与结构（强制）**：正文平铺用例、`case_id` 以及缩进/编号规则等全部约束，严格遵循同目录 [`reference.md`](./reference.md)。
-- 将整份 Markdown 写入固定路径：`.apm/workitems/<requirementId>/testcase.md`
-- 在文末追加覆盖校验小节（强制）：
-  - `## 覆盖校验`
-  - `### 需求覆盖矩阵（REQ -> TC）`
-  - `### 用例追踪矩阵（TC -> REQ）`
-  - `### 场景维度检查`（逐条 REQ 标记正向/边界/异常是否覆盖）
-
-### 5. 导入测试用例到系统
-
-- **命令**（在仓库根目录执行）：`apm set testcase <requirementId>`
----
-
-## 依赖与约定
-
-- **输出结构**：仅遵循 `reference.md` 的用例文档格式规范
-- **完整示例**：见 [reference.md](reference.md)
----
-
-## 成功标准
-
-- 手工测试用例文档已生成到约定路径（`.apm/workitems/<requirementId>/testcase.md`）
-- 文档格式与结构完全符合同目录 `reference.md`（正文平铺用例、`case_id` 与缩进/编号规则）。
-- 每条用例均为 **操作步骤 + 预期结果** 的精简形态，便于生成 **前端 E2E** 用例脚本
-- 需求覆盖率为 100%（无未覆盖 REQ）
-- 无孤儿用例（每条 TC 均可追溯到至少 1 条 REQ）
-- 每条 REQ 至少覆盖正向、边界、异常三类场景

package/templates/skills/prd-testcase/reference.md

@@ -1,44 +0,0 @@
-# 手工测试用例格式参考（正文平铺）
-
-## 文档层级约定
-
-- **文首**：使用 **`# 测试用例`** 作为标题，后续直接进入正文用例
-- **正文**：仅用 **`### <优先级>:<具体标题>(<case_id>)`** 平铺用例
-- **正文用例字段**：在每个 `### <优先级>:<标题>(<case_id>)` 标题后，**紧跟**两类字段：
-  - `- 测试类型：端到端测试|单元测试|集成测试`（必填）
-  - `- 数据依赖：...`（可选；仅当需要在测试脚本运行前额外准备数据/状态时填写，否则可省略）
-- **正文预期结果**：格式与 **操作步骤** 一致，使用 **编号列表**（`- 预期结果:` 下一行写 `  1.` `  2.` …，**两个空格**缩进），**不要**用制表符 Tab 单独顶格一段
-- **case_id**：全文递增 **`TC-001`、`TC-002`、…**；
-
-## 完整结构示例
-
-````markdown
-# 测试用例
-
-### P0: 列表顶部展示新增入口(TC-001)
-- 测试类型：端到端测试
-- 操作步骤：
-  1. 使用具备回款列表访问权限的账号登录
-  2. 进入「回款列表」页面
-- 预期结果:
-  1. 页面顶部展示「新增回款」按钮
-
-### P0: 点击新增打开表单(TC-002)
-- 测试类型：端到端测试
-- 操作步骤：
-  1. 在回款列表页点击「新增回款」
-- 预期结果:
-  1. 出现含金额与日期的表单
-
-### P1: 默认按约定字段降序(TC-003)
-- 操作步骤：
-  1. 进入月度回款任务明细列表页
-- 预期结果:
-  1. 列表按约定字段降序，首行符合规则
-````
-
-## 从需求到用例的映射
-
-- 从需求条目或需求句提炼可测试点；**不必**为每个需求条目单独建章节
-- **操作步骤** 写成可翻译为 E2E 动作序列的编号列表
-- **预期结果** 写成 **可自动化断言** 的编号列表

package/templates/skills/product-capability-inventory/SKILL.md

@@ -1,131 +0,0 @@
----
-name: product-capability-inventory
-description: 仅在用户明确表达要更新或同步产品能力清单（.apm/product-capability-inventory）时使用——例如明确说更新能力清单、同步清单、初始化/维护 CAP 文档、更新产品说明书（指本清单）。泛泛提及 CAP、产品文档或读清单时不要自动启用。
----
-
-# 产品能力清单维护
-
-## 何时启用本技能（必须）
-
-- **启用**：用户**明确表达**要**更新、初始化或同步**仓库内产品能力清单（`.apm/product-capability-inventory/`，即本仓库的「产品说明书」落地位置），或同义表述（如「同步能力清单」「把 CAP 文档跟上代码」）。
-- **不启用**：仅实现需求、评审、浏览代码、或对话里顺带提到 CAP/能力清单但**没有更新清单的意图**时，**不要**按本技能去改文档；需要时只读现有 `.apm/` 即可。
-
-落地数据在 `.apm/product-capability-inventory/`。**目录树、各文件职责、`index.md` / `CAP-*.md` 的章节与字段、链接格式** 等一律见独立文档 **[`目录规范.md`](./目录规范.md)**（初始化与补全时按该文档施工；更新时新增/改写条目亦须符合其中格式）。**`使用说明书.md`** 从同目录模板 **[`使用说明书.md`](./使用说明书.md)** 复制到 `.apm/product-capability-inventory/`。
-
-本技能的核心目标是避免“**需求入口写的是 A，但代码改到 B**”这类错误：为每个 CAP 强制维护 **入口锚点 + UI 识别锚点 + 实现锚点** 三件套，并在生成 spec/实现前做映射校验。
-
-## 工作流程
-
-在用户已明确要处理产品能力清单的前提下，按顺序判断：
-
-1. **是否存在清单根目录**  
-   若仓库中**不存在**路径 `.apm/product-capability-inventory/`（未创建该文件夹），则**必须**走 **「场景 1：初始化」**：在该路径下按 **[`目录规范.md`](./目录规范.md)** **一次性建好目录树**，并写入与各文件职责匹配的初始 Markdown（内容可占位，但结构、文件名、小节须齐全）。
-
-2. **目录已存在**  
-   若 `.apm/product-capability-inventory/` 已存在，但缺少总览 `README.md`、**`使用说明书.md`**、或缺少某系统子目录下的 `index.md` 等 **[`目录规范.md`](./目录规范.md)** 所要求的文件，则**补建缺失部分**（等同初始化中对应步骤；`使用说明书.md` 缺失时从技能目录模板**复制**），仍遵守该文档中的目录与结构要求。
-
-3. **结构已完整**  
-   若 `.apm/product-capability-inventory/` 已存在且具备规范要求的文件，且用户明确要**更新或同步**清单时，走 **「场景 2：更新」**（见后文）：以**本分支相对上线基线（如 `main`/`master`）的代码变更**为依据，补齐或调整能力条目与术语，并写变更记录。
-
-## 使用说明（给谁用）
-
-| 角色         | 用法                                                                                               |
-| ------------ | -------------------------------------------------------------------------------------------------- |
-| 产品 / 评审  | 用 `index.md` 核对「系统已有能力」；新需求写清关联 CAP 或缺口。                                    |
-| 研发 / AI    | 实现前读相关 `CAP-*.md`；需要改清单时，仅在用户明确说要同步/更新清单后，再按本技能 **更新** 清单。 |
-| 写 spec / 测 | 先 **PRD → CAP** 对照，再写验收与用例。                                                            |
-
-## 场景 1：初始化（无 `.apm/product-capability-inventory` 或结构不完整）
-
-**何时进入本场景**
-
-- 仓库中**不存在**目录 `.apm/product-capability-inventory/`，或
-- 该目录存在但**缺少** [`目录规范.md`](./目录规范.md) 所要求的 `README.md`、**`使用说明书.md`**、或某系统子目录下缺少 `index.md`。
-
-**动作（按顺序执行）**
-
-1. 若不存在 `.apm/product-capability-inventory/`，**创建该目录**。
-2. **放置使用说明书**：将 **`.apm/skills/product-capability-inventory/使用说明书.md`** **复制**为 **`.apm/product-capability-inventory/使用说明书.md`**（内容保持与模板一致；若目标文件已存在且非空，可跳过覆盖，除非用户要求重置）。
-3. 创建 `.apm/product-capability-inventory/README.md`：写明用途，包含 **子系统列表** 表格（可占位），并含指向 **`[使用说明书.md](./使用说明书.md)`** 的链接或一句引导。
-4. 选定 `<系统名>`，创建 `.apm/product-capability-inventory/<系统名>/index.md`，且 **[`目录规范.md`](./目录规范.md)** 中 **`index.md` 各章节**均已出现（表格可空、须有句说明或一行初始化记录）。
-5. 若可从代码识别菜单/路由（如 `apps/fe/src/router/menus.tsx`），至少草拟 **1 个** `CAP-*.md` 示例，并在 `index.md` 的 **能力条目目录** 表中登记一行。
-6. 在总览 `README.md` 的子系统列表中增加指向 `<系统名>/index.md` 的链接。
-7. 告知用户：清单已按 **[`目录规范.md`](./目录规范.md)** 初始化；**勿**使用已废弃路径 `.apm/capability/`。
-
-**禁止**：把密钥写入文档；实现索引用仓库内路径即可。
-
-## 场景 2：目录已存在时的更新（仅在有明确意图时）
-
-仅在用户**明确表达**要更新或同步产品能力清单时执行（例如「同步能力清单」「更新 CAP」「按本分支上线内容更新清单」）。**不要**在未收到此类明确指令时自动改清单。
-
-更新时按下面顺序执行（**以本分支拟上线代码为准**，基线一般为 `main`/`master` 或与用户指定的对比分支；用 `git log`、`git diff <base>...HEAD`、变更文件列表等理解「本次会随分支上线什么」）。
-
-### 1. 理解本次上线的代码（本分支 commit 的代码）
-
-- 对比**当前分支**与**上线基线分支**（默认 `main` 或 `master`，以仓库默认分支为准）之间的 **commit 与 diff**。
-- 关注：前端路由/菜单、页面与交互、后端模块与接口、权限与数据范围、配置或环境相关行为等**用户可见或可感知**的变化。
-
-### 2. 提取可写入能力条目的要点
-
-- 将变更归纳为**能力粒度**的条目：新入口/新流程、行为变化、新依赖、下线或移除的能力等。
-- 每条要点应对应或归入某个 **CAP**（同一域下合并相关小改动，避免碎片 CAP）。
-
-### 3. 补齐能力条目（按格式；可增、可改、可删）
-
-- **新增**：对本次上线**新增**的用户可见能力，按 **[`目录规范.md`](./目录规范.md)** 中 `CAP-*.md` 的字段**新建** `CAP-<域>-<序号>.md`，并在对应系统 `index.md` 的 **能力条目目录** 表中增加一行（含关键词与链接）。
-- **更新**：对已有 CAP 覆盖的能力，若入口、主流程、前置条件、实现索引等随本分支变化，**修改**对应 `CAP-*.md` 表格内容，并视情况更新 **跨能力依赖**。
-- **删除**：若本分支**已删除**某段产品代码且**不再提供**该能力，可**删除**对应 `CAP-*.md` 文件，并在 `index.md` 的 **能力条目目录** 中移除该行；不删文件而在该 CAP 内标注「已下线」并在目录表注明。
-- 全文格式、链接规则仍遵守 **[`目录规范.md`](./目录规范.md)**（含其中「格式说明」）。
-
-**CAP 字段规范（强制）**：每个 `CAP-*.md` 必须包含并维护以下锚点（缺一则视为“不可用于约束 AI”的 CAP，需要先补齐再推进 spec/实现）：  
-- **入口锚点**：用“用户路径”把入口写死（菜单/抽屉/Tab/表格等层级），避免同名组件/表格被误选。  
-- **UI 识别锚点**：2～5 个可验证信号（标题/表头列名/关键文案/`data-testid`），用于在 spec 与测试中确认“就是这个区域”。  
-- **实现锚点**：允许修改的落点范围（前端文件/组件、后端模块/接口）。后续任何实现与修复必须优先落在这个范围内，否则先判定为“入口不确定/映射不通过”，不要直接改代码。
-
-### 4. 术语与口径（易混淆业务点）
-
-- 若本次上线引入或变更了**易混淆的术语、统计口径、业务规则**（与纯技术重构无关），在对应系统 `index.md` 的 **术语与口径** 表中**增补或修订**行（术语、定义、易混点）。
-
-### 5. 变更记录与元信息
-
-- 在对应系统 `index.md` 的 **变更记录** 表中**追加一行**：
-  - **日期**：更新当日（或用户指定日期）；
-  - **版本**：在 **元信息** 中递增文档版本（如 v0.4 → v0.5），与本行一致或在本行摘要中说明；
-  - **变更摘要**：概括本分支对清单的改动（如新增/调整/下线哪些 CAP、术语变更要点）；
-  - **作者**：填写**当前 Git 分支名称**（`git branch --show-current` 或等价方式），用于与上线分支追溯。
-- 若本次还新增 **系统/模块子目录**，在 `.apm/product-capability-inventory/README.md` 的 **子系统列表** 中增加一行。
-
-### 6. 一致性检查
-
-- 入口 URL、菜单与权限描述须与代码一致（如本仓库前端 `basename` `/contract-payment-collection`，以 `menus.tsx`、`MainLayout`、`getMenus` 等为准）。
-
-### 7. 生成 spec 的强制“入口锚点”流程（用于防改错页面）
-
-当用户要“根据需求生成 spec”（或你将要进入实现/测试闭环）时，必须先执行**映射校验**，再写 spec 正文：
-
-1. 输出一张 **「需求点 → CAP 映射表」**（写在 spec 或生成日志均可），每行至少包含：  
-   - 需求点（标题或 REQ ID）  
-   - 命中的 **CAP ID**  
-   - **入口锚点**（从 CAP 拿）  
-   - **UI 识别锚点**（从 CAP 拿，至少 2 个）  
-   - **实现锚点**（从 CAP 拿：允许修改文件/模块范围）
-2. **拒绝条件**：若任一需求点无法映射到 CAP，或 CAP 缺少上述锚点字段，必须标记为“需补充 CAP/入口锚点”，停止继续生成实现性 spec（只能输出待澄清项/待补充项）。
-3. spec 正文中应把入口锚点写成显式小节（例如“Scope/Entry anchor”），确保后续 code-test-fix 循环不会把修复落到错误入口。
-
-**不强制**：若本分支仅为**未触达任何用户可见行为**的纯重构，可在变更记录写「无能力清单变更」或跳过正文修改（仍可按需只 bump 版本或省略本次记录，与用户约定一致即可）。
-
-## 更新逻辑（决策表）
-
-| 变更类型                       | 更新对象                                                        |
-| ------------------------------ | --------------------------------------------------------------- |
-| 新菜单/新路由                  | 新 CAP 或扩展现有 CAP 的入口/主流程；`index.md` 目录表 + 关键词 |
-| 新接口/新模块                  | `CAP-*.md` 实现索引；必要时术语表                               |
-| 权限/数据范围变化              | `index.md` 角色与数据范围；相关 CAP 前置条件                    |
-| 跨模块依赖（导入依赖业务员等） | `index.md` 跨能力依赖表                                         |
-| 环境依赖（SMTP、MinIO）        | 对应 CAP 前置条件或术语                                         |
-
-## Guardrails
-
-- **删除与下线**：若代码已移除对应能力，按「场景 2」可删除 CAP 或在条目标注「已下线」，并同步 `index.md` 目录表与变更记录；勿让清单描述仍像功能可用。
-- 不编造未在代码中出现的路由或 API；不确定时查 `menus.tsx`、对应 controller。
-- **优先补文档再写代码**：当入口不明确（同名表格/组件多处存在）时，先补 `product-capability-inventory` 的入口锚点与 UI 识别锚点，再生成 spec/实现。

package/templates/skills/product-capability-inventory/template.md

@@ -1,80 +0,0 @@
-# 产品能力清单（模板）
-
-> **用途**：记录「系统里已经有什么」，供 PRD / spec / AI 生成实现时引用，减少「沿用现有流程」但模型不知道指哪里的问题。  
-> **维护**：产品与研发共担；**有行为变更的迭代必须同步更新**对应条目或版本说明。  
-> **命名**：下文 `[CAP-xxx]` 为稳定 ID，PRD 可写「依赖 CAP-xxx」。
-
-
-## 0. 元信息
-
-| 字段 | 说明 |
-|------|------|
-| 产品 / 子系统 | |
-| 文档版本 | `v1.0.0` / 日期 |
-| 上次评审 | 人名 + 日期 |
-| 关联仓库路径 | 可选，如 `apps/fe`、`servers/be` |
-
-
-## 1. 角色与数据范围
-
-| 角色 / 维度 | 说明 | 备注 |
-|---------------|------|------|
-| 例如：超管 / 普通用户 | 能力差异概要 | |
-| 数据范围（公司、项目可见性） | | 与权限模型一致 |
-
-
-## 1.b 能力条目目录（仅写在各系统 `index.md`）
-
-> 用于索引本目录下有哪些 `CAP-*.md`，**不要**把 §2 的整段正文贴在这里。
-
-| CAP ID | 短名称 / 关键词 | 详文 |
-|--------|------------------|------|
-| CAP-xxx-01 | （便于 PRD / 检索） | [CAP-xxx-01](CAP-xxx-01.md) |
-
-
-## 2. 能力条目（按域分组）
-
-每条建议固定结构，便于检索与 PRD 引用。
-
-### 2.x [CAP-领域-序号] 能力短名称
-
-| 项 | 内容 |
-|----|------|
-| **一句话** | 用户能完成什么目标 |
-| **入口** | 菜单路径 / URL 模式 / 移动端路由（描述“去哪里找得到”） |
-| **入口锚点（强制）** | 用“用户路径”把入口写死（例如：`项目列表 → 编辑抽屉 → 收款 → 回款记录 → 明细表`），用于避免改错页面 |
-| **UI 识别锚点（强制）** | 2～5 个可验证信号：页面标题/模块标题/表格表头列名/关键文案/`data-testid`（至少 2 个），用于确认“就是这个区域” |
-| **前置条件** | 登录、权限、数据存在性等 |
-| **主流程** | 3～7 步，可编号 |
-| **结束状态** | 成功后的数据或页面状态 |
-| **与外部/邮件/任务** | 若涉及异步、配置依赖，写一句（如 SMTP） |
-| **已知限制** | 本期不做、配额、浏览器要求等 |
-| **实现锚点（强制，研发填）** | 允许修改的“落点范围”：前端文件/组件名、后端模块/接口（可选行号或函数名）；用于约束 AI 改动范围 |
-| **反例（可选但推荐）** | 1～3 条“不要改的地方/不要发生的行为”（例如“不要改 B 页面同名表格”“不要删除旧图表”） |
-| **关联历史需求** | REQ ID / 飞书文档链接（可选） |
-
----
-
-## 3. 跨能力依赖与复用关系
-
-| 能力 A | 依赖 / 复用 | 能力 B | 说明 |
-|--------|----------------|--------|------|
-| [CAP-…] | 复用审批状态 | [CAP-…] | 一句话 |
-
-（用于回答「和原来一样」到底指哪条链路。）
-
-可与 **§4、§5 一并写在各系统目录的 `index.md`** 中，无需单独文件。
-
-## 4. 术语与口径
-
-| 术语 | 定义 | 易混点 |
-|------|------|--------|
-| | | |
-
----
-
-## 5. 变更记录
-
-| 日期 | 版本 | 变更摘要 | 作者 |
-|------|------|----------|------|
-| | | | |

package/templates/skills/product-capability-inventory//344/275/277/347/224/250/350/257/264/346/230/216/344/271/246.md

@@ -1,36 +0,0 @@
-# 产品能力清单 — 使用说明
-
-> 本文件由仓库初始化清单时从 **`.apm/skills/product-capability-inventory/使用说明书.md`** 复制到此处；可直接编辑本副本以补充团队约定，无需回写技能目录。
-
-## 本目录是什么
-
-`docs/product-capability-inventory/` 存放**产品能力清单**：用结构化文档说明「系统里已经有哪些能力、入口在哪、流程与口径是什么」，便于产品评审、写需求、写 spec 与测试对齐，也便于研发与 AI 实现时引用。
-
-- **不是**需求文档：需求描述「要改什么」；清单描述「当前世界长什么样」。
-- **与代码的关系**：清单应随上线代码同步更新；维护流程见技能。
-
-## 怎么读
-
-1. 打开本目录下的 **`README.md`**：查看有哪些**子系统/模块**子目录。
-2. 进入某一子系统目录（如 `<系统名>/`），先读 **`index.md`**：元信息、角色与数据范围、**能力条目目录**（CAP ID 列表）、跨能力依赖、术语与口径、变更记录。
-3. 对感兴趣的能力，打开同目录下的 **`CAP-xxx.md`**：该能力的详述（入口、前置条件、主流程、实现索引等）。
-
-**CAP ID**：形如 `CAP-<域>-<序号>`，在 PRD 中可写「依赖 CAP-xxx」以引用稳定条目。
-
-## 目录里常见文件
-
-| 文件 | 作用 |
-|------|------|
-| `README.md`（本目录根下） | 总览与子系统列表 |
-| `使用说明书.md` | 本说明（阅读指引） |
-| `<系统名>/index.md` | 该系统的清单入口与索引 |
-| `<系统名>/CAP-*.md` | 单条能力详文 |
-
-## 谁维护、如何更新
-
-- **产品 / 研发**：在迭代或上线前，按团队约定将清单与代码、口径对齐。
-- **更新方式**：由具备权限的同事按技能 **product-capability-inventory** 中的流程执行（初始化、按分支变更更新 CAP 与术语等）；变更记录中会标注分支名等信息以便追溯。
-
----
-
-*模板版本：与技能目录中 `使用说明书.md` 同源；若团队有固定补充段落，可写在本文件副本末尾。*

package/templates/skills/product-capability-inventory//347/233/256/345/275/225/350/247/204/350/214/203.md

@@ -1,58 +0,0 @@
-# 产品能力清单 — 目录规范
-
-## 根路径与总览文件
-
-- **根目录**：`.apm/product-capability-inventory/`  
-  所有产品能力清单文档的根。其下**不**把「总览」与「某系统详情」混在一个文件里；系统级内容放在子目录中。
-
-- **`.apm/product-capability-inventory/使用说明书.md`（阅读指引，来自模板）**
-
-  - **来源**：初始化时从技能目录 **`.apm/skills/product-capability-inventory/使用说明书.md`** **原样复制**到上述路径（文件名固定为 `使用说明书.md`）。
-  - **作用**：面向产品/研发/读者的**使用说明**，与总览 `README.md` 分工：`README.md` 列子系统入口；`使用说明书.md` 说明如何阅读清单、CAP 含义、维护入口指向技能。
-  - 团队可在 `.apm/` 下的副本中增删段落；技能目录中的文件作为**模板母版**，下次新仓库初始化时仍从母版复制。
-
-- **`.apm/product-capability-inventory/README.md`（总览）**
-  - 说明本目录用途：按系统/模块分子目录，**各子目录入口为该系统下的 `index.md`**；建议增加一句指向 **`[使用说明书.md](./使用说明书.md)`**。
-  - 包含一张 **「子系统列表」** 表格，列至少包含：**目录（链接到 `<系统名>/index.md`）**、**说明**。新初始化时可只有一行占位或一行真实条目。
-
-## 系统子目录与命名
-
-- **子目录名**：`.apm/product-capability-inventory/<系统或模块名>/`  
-  使用可读的文件夹名（如本仓库示例 `contract-payment-collection`）。**一个业务系统或模块对应一个子目录**；跨系统能力在各自 `index.md` 里用「跨能力依赖」表描述关系。
-
-- **该系统内允许的文件类型**：
-  - **`index.md`**：必填，**该系统清单的唯一入口**，所有索引类信息集中在此文件。
-  - **`CAP-*.md`**：每条业务能力一篇，**文件名必须与 CAP ID 完全一致**，例如 `CAP-PROJ-01.md` 对应 ID `CAP-PROJ-01`。
-  - **不要**为同一系统再拆「横向」的多个索引文件（例如单独的 glossary.md 替代 `index.md` 中的术语表）；术语、变更记录、能力目录表均在 `index.md` 内用章节区分。
-
-## `index.md`（系统入口）
-
-初始化或补全 `index.md` 时，**章节、表头与表格样式以同目录 [`template.md`](./template.md) 为准**，不在此重复展开：
-
-- 依次包含 **§0 元信息、§1 角色与数据范围、§1.b 能力条目目录、§3 跨能力依赖、§4 术语与口径、§5 变更记录**；同一文件内**顺序可微调，不得缺项**。
-- **§1.b** 只出现在 `index.md`：索引本目录下有哪些 `CAP-*.md`；**勿**把 **§2** 的单条能力正文整段贴进 `index.md`（§2 对应独立文件 `CAP-*.md`，见下节）。
-- **变更记录**表中「作者」列：更新场景下填 **当前 Git 分支名**。
-
-## `CAP-*.md`（单条能力详文）
-
-- **CAP ID** 与文件名一致：`CAP-<域缩写>-<序号>`，全仓库唯一；PRD 可写「依赖 CAP-xxx」。
-- **表格字段与表头**：完全按 [`template.md`](./template.md) **§2**（「### 2.x …」下那张表）填写；标题可用 `### CAP-领域-序号 短名称` 等形式，与同目录文件名对应。
-- 同目录链到其他 CAP 用相对路径；文末或文内可加 `[← 返回索引](index.md)`。
-
-## 目录树示意
-
-```text
-.apm/product-capability-inventory/
-  README.md                          # 总览：用途 + 子系统列表表 + 链到使用说明书
-  使用说明书.md                      # 从技能目录「使用说明书.md」模板复制，阅读指引
-  <系统或模块名>/
-    index.md                         # 该系统唯一入口：元信息、角色、能力目录、依赖、术语、变更记录
-    CAP-<域>-<序号>.md               # 单条能力详文，文件名 = CAP ID
-```
-
-## 格式说明（Markdown 与链接）
-
-- **Markdown 表格**：与 [`template.md`](./template.md) 及现有 `index.md`、`CAP-*.md` 保持一致。
-- **链接**：同目录内 CAP 用相对路径 `[CAP-xxx](CAP-xxx.md)`；返回索引用 `[← 返回索引](index.md)`。
-
-**字段级写法一律以 [`template.md`](./template.md) 为准**；**以本文的目录树与 `index.md` / `CAP` 分工（上两节）为准**。