diff --git a/skills_library/all/sdlc-repo-standard/SKILL.md b/skills_library/all/sdlc-repo-standard/SKILL.md index 4ad5751..e35b0f6 100644 --- a/skills_library/all/sdlc-repo-standard/SKILL.md +++ b/skills_library/all/sdlc-repo-standard/SKILL.md @@ -92,3 +92,12 @@ projects/{项目名}/docs/01-design/modules/{模块名}/ - 每个阶段检查交付件已受控提交 - develop: 必须检查机构 `apps/{应用名}/`、`modules/{模块名}/` 对应仓库有 git commit - 每个阶段检查 `{应用名}_spec.json` 是否随进度更新 + +### 项目复盘（PM，项目完结后的回顾任务） +- **落点**: `projects/{项目名}/docs/02-retrospective/retrospective.md` +- **内容结构**（五段，缺一不合格）: + 1. 统计：问题总数 / 可复用数 / 提议数；重做次数、冒泡次数、Bug 数、工期 + 2. 问题清单：逐条列出（类型：冒泡/退回/缺口/Bug，问题，解决方法） + 3. 提议清单：每条提议的名称 + 目标技能（修改哪个/新建） + 4. 未提提议的问题及理由（一次性问题写明为何不可复用） + 5. 结论：本项目沉淀的可复用经验一句话总结 diff --git a/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md b/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md index 4c0dd25..24436e9 100644 --- a/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md +++ b/skills_library/pipelines/sdlc_general/roles/agent.pm/role/SKILL.md @@ -23,3 +23,26 @@ capability: task_capability ## 应遵守的规范（审核/派发前先 load_skill 加载对应全文，不要凭记忆瞎写） - `project-directory-spec`：各阶段交付件落点路径（检查交付件是否在正确位置） - `sdlc-repo-standard`：各阶段交付件的内容格式与产出行为准则 + +## 项目复盘（项目完结后的回顾任务，task_kind='retrospective'） + +项目执行完（最后一个任务 review_complete）后，你会收到一个「项目复盘」任务。目标：把本项目遇到的问题和处理方法沉淀为技能提议，让同类问题在下个项目被预防。 + +### 流程 + +1. 调 `project_retrospective_data` 工具拿结构化素材（四类问题源已合并：冒泡问题+解决方法、退回重做+意见、编排缺口、Bug+修复说明），不要自己拼 SQL 查。 +2. 逐条判定**可复用性**： + - **可复用**（跨项目可能再发生，如「Flask 框架误用」「字段类型映射错误」「部署声称 200 未实测」）→ 生成技能提议 + - **一次性**（本项目特有的业务理解偏差、需求歧义等）→ 只写进复盘报告，不提提议 + - 复盘报告必须写明「未提提议的问题及理由」，判定质量可被人工复核 +3. 每条可复用问题生成一个提议，调 `propose_skill(name, description, content)`： + - **定位目标技能**：对照问题发生角色（develop 的问题 → agent.develop 或 QC 的 review-develop）+ 现有技能，判断是修改现有技能还是新建 + - content 是 SKILL.md 草稿，**头部标目标**：`` 或 `` + - content 强制四段：**触发条件 / 问题现象 / 根因 / 检查或处理方法**（从素材的 solution 提炼）。缺段的草稿 = 低质量提议，会被审核直接拒 +4. **去重**：提交前说明目标+要点；同目标同要点的问题只提一条提议（多个实例合并成一条，实例写进现象段）。 +5. 产出复盘报告：落盘 `projects/{项目}/docs/02-retrospective/retrospective.md`，内容 = 问题总数/可复用数/提议清单（含提议名）/未提议问题及理由/统计（重做次数/冒泡次数/Bug数/工期）。作为复盘任务的交付件提交。 + +### 纪律 + +- 提议只是草稿（进技能管理的建议列表，待人工审核），**不直接改技能库**——技能库是源头，改写必须走审核。 +- 复盘就事论事：问题归因到「规范/流程缺了什么」，不归咎到某个 agent 个体；提议内容写「下次怎么防」，不写「谁犯了错」。 diff --git a/skills_library/pipelines/sdlc_general/roles/agent.qc/review-design/SKILL.md b/skills_library/pipelines/sdlc_general/roles/agent.qc/review-design/SKILL.md index 96fe43a..4719ecb 100644 --- a/skills_library/pipelines/sdlc_general/roles/agent.qc/review-design/SKILL.md +++ b/skills_library/pipelines/sdlc_general/roles/agent.qc/review-design/SKILL.md @@ -1,39 +1,68 @@ --- name: review-design -description: QC 审查系统设计师（agent.design）产出的检查清单——架构/ui-design 落盘、模块划分与依赖、数据库设计（字段类型映射/无外键/编码字典）。触发：审查 design 阶段交付件。 +description: QC 审查系统设计师（agent.design）产出的检查协议——A组需求覆盖矩阵（硬门禁：每个原始需求点至少一个功能覆盖）+B组设计专家维度（划分/数据库/架构合理性）+C组合规，契合度=10×通过项/总项，>9.5 放行。触发：审查 design 阶段交付件。 capability: task_capability --- # 审查系统设计师（agent.design）产出 -被查对象：agent.design。审查其产出时逐项核对，任一项不合格即 review_reject 并列出问题。 +被查对象：agent.design。 -## 一、应用级设计落盘（对照 project-directory-spec + web-application-spec + module-development-spec） +## 审查流程（先构建核对项，再逐项判定，最后算分） -- 对照 `project-directory-spec`： - - `projects/{项目}/docs/01-design/architecture.md`（架构 + 模块划分 + 模块间依赖 + 开发顺序） - - `projects/{项目}/docs/01-design/ui-design.md`（视觉风格/布局/交互模式） -- **应用与模块关系（关键，对照 web-application-spec + module-development-spec）**： - - 应用是唯一部署单元：一个应用 = 一个入口（`app/{应用名}.py`）= 一个端口。architecture.md 必须写明 app 清单——一个项目有几个 app 由 designer 按「部署单元/功能聚合/用户边界」划分，明确这是【单体应用】还是【多个应用】，并写出每个 app 的划分理由，**不能把功能模块设计成独立服务/微服务** - - 模块不是独立部署单元：每个模块是应用内的 Python 包，通过 `load_{module}()` 挂载到应用，**无独立 app.py / 端口 / Dockerfile / 服务** - - 目录结构：机构 `apps/{应用名}/`（应用仓库）+ `modules/{模块名}/`（模块仓库）。若只有模块仓库没有应用仓库，或模块仓库里带了 app.py / Dockerfile → 退回（违反 module-development-spec） - - 若 architecture.md 出现"四模块服务""每模块一个端口/容器"等设计 → 退回：这是把功能模块错误设计成微服务 +1. **收集**：读原始需求、设计交付件；用 `list_features` 查功能清单（覆盖矩阵的数据基础）。 +2. **构建核对项清单**：A 组（需求覆盖，硬门禁）+ B 组（设计专家维度）+ C 组（合规）。 +3. **逐项判定**：每项只输出 过/不过 + 证据。 +4. **算分**：契合度 = 10 × 通过项数 / 总项数（保留两位小数）。 +5. **决策**：契合度 > 9.5 且 A 组无未过项 → review_approve；否则 review_reject。 + **A 组任一核对项不过 = 必退**（需求覆盖是硬门禁），即使总分 > 9.5 也不放行。 -## 二、模块级设计落盘 +## 必读文件 -- 每个模块：`projects/{项目}/docs/01-design/modules/{模块名}.md`（模块清单）+ `{模块名}/design.md`（数据设计/CRUD/处理逻辑）+ `{模块名}/skill/SKILL.md`（模块技能文档） -- 模块划分 + 模块间依赖 + 开发顺序明确，PM 据此派发 develop 任务 -- 基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）不列为待开发模块 +- 原始需求：`projects/{项目}/docs/00-requirement/requirement-spec.md` +- 设计交付件：`projects/{项目}/docs/01-design/architecture.md`、`ui-design.md`、`modules/{模块名}.md` 及 `{模块名}/design.md` +- 路径权威来源：先 load_skill 加载 `project-directory-spec` -## 三、数据库设计（对照 database-design 规范） +## A 组：需求覆盖矩阵（硬门禁） -- **字段类型映射**：字段语义→类型是否正确（名称 str 255、金额 double 18/2、状态 str 16、业务日期 date 等） -- **抽象类型**：禁原生类型 varchar/bigint/boolean/int(11)，一律 str/int/double/timestamp/date/text -- **无外键**：表间不建 FOREIGN KEY，关联靠字段存 id + codes 段声明 -- **编码字典**：枚举字段（状态/类型）进 appcodes/appcodes_kv，init/data.json 定义，cond 用 parentid= -- **表定义四段式**：models 表定义 summary/fields/indexes/codes 格式（design 阶段产出 DDL 设计） +1. 从原始需求抽取**原始需求点清单**（#1、#2……，与需求分析阶段同源，若需求分析交付件里有编号清单则沿用）。 +2. 用 `list_features` 取全部功能点（含 description）。 +3. 构建覆盖矩阵：**每个原始需求点必须至少被一个功能点覆盖**（功能点的名称/描述能对应到该需求点的语义）。 + - 任一需求点零覆盖 → 该项不过，且必退。退回意见指明「需求点 #N 无任何功能覆盖」。 +4. 反向核对：每个功能点必须能追溯回至少一个需求点。无追溯的功能点列为「镀金待说明」项——不直接判不过，但要求设计师说明理由（说明缺失才算不过）。 +5. 覆盖矩阵整体输出进核对记录（需求点 × 覆盖功能点），供人工复核。 -## 四、真实性核查方法 +## B 组：设计专家维度 -- 用 read_file / list_files 验证 architecture.md/ui-design.md/modules 真实落盘 -- 核对模块划分是否覆盖需求全部业务域，依赖顺序是否合理 +6. **应用/模块划分**（对照技能映射表加载）： + - 应用是唯一部署单元：一个应用 = 一个入口（app/{应用名}.py）= 一个端口；architecture.md 写明 app 清单 + 单体/多应用划分理由。把功能模块设计成独立服务/微服务/独立端口 → 不过。 + - 模块是应用内 Python 包，无独立 app.py / 端口 / Dockerfile。 +7. **数据库设计**（对照技能映射表加载）： + - 字段语义→抽象类型映射正确（名称 str 255、金额 double 18/2、状态 str 16、业务日期 date） + - 禁原生类型 varchar/bigint/boolean/int(11) + - 表间无外键，关联靠字段存 id + codes 段声明 + - 枚举字段进编码字典（appcodes/appcodes_kv，init/data.json 定义） + - 表定义四段式（summary/fields/indexes/codes） +8. **架构合理性逐项**（把主观判断转成「有无论证」的机械核对）： + - 模块间依赖方向无环、开发顺序可行（依赖在前、被依赖在后） + - 设计说明写明**预期数据量/并发量及对应选型理由**——写不出规模假设 = 不过（无论证的架构选型不采信） + - 无微服务化倾向（「每模块一个端口/容器」类设计 = 不过） + +## C 组：合规项 + +9. **文档落点**：architecture.md / ui-design.md / modules/{模块}.md + {模块}/design.md 齐全（对照 project-directory-spec）。 +10. **模块清单明确**：模块划分 + 模块间依赖 + 开发顺序明确（PM 据此派发 develop 任务）；基础模块（apppublic/sqlor/ahserver/accounting/appbase/rbac）不列为待开发模块。 + +## 技能映射表（按核对内容必载，不凭记忆） + +| 核对内容 | 必载技能 | +|----------|----------| +| 文档落点/路径 | project-directory-spec | +| 应用/模块划分 | web-application-spec、module-development-spec | +| 数据库设计 | database-design | +| 需求覆盖矩阵 | 无需技能，用 list_features + 原始需求原文 | + +## 输出要求 + +- review_approve 的 comment：`契合度 X.XX（通过 n/总 m），需求覆盖 100%` + 核对摘要。 +- review_reject 的 questions：逐条 `[#编号] 位置：…… 问题：…… 改法：……`；A 组未过项必须置顶并标注「硬门禁」。 diff --git a/skills_library/pipelines/sdlc_general/roles/agent.qc/review-develop/SKILL.md b/skills_library/pipelines/sdlc_general/roles/agent.qc/review-develop/SKILL.md index 76b197c..4a9f0a3 100644 --- a/skills_library/pipelines/sdlc_general/roles/agent.qc/review-develop/SKILL.md +++ b/skills_library/pipelines/sdlc_general/roles/agent.qc/review-develop/SKILL.md @@ -1,18 +1,42 @@ --- name: review-develop -description: QC 审查开发工程师（agent.develop）产出的检查清单——模块目录结构、表定义四段式、CRUD 格式、代码语法/禁项/注册接线/sqlor API、RBAC/i18n。触发：审查 develop 阶段交付件。 +description: QC 审查开发工程师（agent.develop）产出的检查协议——交付件类型驱动的技能映射表（表定义/CRUD/dspy/UI/注册各载对应规范技能）+逐项机械核对，契合度=10×通过项/总项，>9.5 放行。触发：审查 develop 阶段交付件。 capability: task_capability --- # 审查开发工程师（agent.develop）产出 -被查对象：agent.develop。审查其产出时逐项机械检查，任一项不合格即 review_reject 并列出问题。 +被查对象：agent.develop。 + +## 审查流程（先构建核对项，再逐项判定，最后算分） + +1. **判交付类型**（见下），用 list_files / read_file 实际看文件，不凭交付说明。 +2. **按技能映射表 load_skill 加载对应规范技能**，然后按技能规范逐项构建核对项清单。 +3. **逐项机械判定**：每项只输出 过/不过 + 证据（文件路径/行号/grep 结果）。第六章应用脚手架硬门禁项任一不过 = 必退（即使总分 > 9.5）。 +4. **算分**：契合度 = 10 × 通过项数 / 总项数（保留两位小数）。 +5. **决策**：契合度 > 9.5 且无硬门禁未过项 → review_approve（comment 附分数与核对摘要）；否则 review_reject（questions 逐条 `[#编号] 位置：…… 问题：…… 改法：……`）。 **先判交付类型，再选检查章节**： - 交付**业务模块**（Python 包，机构 `modules/{模块名}/`）→ 查第一~五章 - 交付**应用脚手架**（机构 `apps/{应用名}/`，有 `app/{应用名}.py` 入口）→ 查**第六章**（硬门禁）+ 第四、五章 - 两者都交 → 两套都查 +## 技能映射表（按交付件内容必载，不凭记忆选技能） + +| 交付件内容 | 必载技能 | +|------------|----------| +| 目录结构/注册接线 | module-development-spec | +| models/*.json 表定义 | database-table-definition-spec | +| json/*.json CRUD | crud-definition-spec | +| *.dspy 文件 | dspy-file-implementation-spec | +| *.ui 页面 | web-application-spec | +| RBAC 路径注册 | rbac-permission-initialization-pattern | +| 应用脚手架（第六章） | web-application-spec | +| 跨宿主复用模块（交付声明跨宿主时） | cross-app-module-reuse | +| 文档落点 | project-directory-spec | + +映射表是活文档：新规范技能入库时须同步更新本表。 + ## 一、模块目录结构（对照 module-development-spec） - 包目录 = 模块名（`{模块名}/{模块名}/`），不是 src/ diff --git a/skills_library/pipelines/sdlc_general/roles/agent.qc/review-requirement/SKILL.md b/skills_library/pipelines/sdlc_general/roles/agent.qc/review-requirement/SKILL.md index 2e1fc1b..4293cfc 100644 --- a/skills_library/pipelines/sdlc_general/roles/agent.qc/review-requirement/SKILL.md +++ b/skills_library/pipelines/sdlc_general/roles/agent.qc/review-requirement/SKILL.md @@ -1,35 +1,49 @@ --- name: review-requirement -description: QC 审查需求分析师（agent.requirement）产出的检查清单——功能清单是否落库 sd_features、需求文档路径、应用部署单元、部署环境需求。触发：审查 requirement 阶段交付件。 +description: QC 审查需求分析师（agent.requirement）产出的检查协议——先构建核对项清单（原始需求逐条契合+合规项），逐项机械判定，契合度=10×通过项/总项，>9.5 放行。触发：审查 requirement 阶段交付件。 capability: task_capability --- # 审查需求分析师（agent.requirement）产出 -被查对象：agent.requirement。审查其产出时逐项核对，任一项不合格即 review_reject 并列出问题。 +被查对象：agent.requirement。 -## 一、功能清单是否真实落库（关键，别只信文档） +## 审查流程（先构建核对项，再逐项判定，最后算分） -- 用 `list_features` 查 sd_features：需求是否已拆解成功能点（propose_feature 落库） -- **sd_features 应有 ≥1 条记录**（需求拆解出来的功能点），状态 proposed/approved -- 若功能清单只在文档里写了、sd_features 却是 0 条 → 退回：功能未用 propose_feature 真实落库 -- 功能点应覆盖需求全部业务域（如组织人事/薪酬/招聘三大域都要有对应 feature） +1. **收集**：用 read_file 读原始需求与交付件（见下方「必读文件」）；用 `list_features` 查功能清单落库情况。 +2. **构建核对项清单**：按 A 组 + B 组列出全部核对项（每项编号，机械可判定 过/不过）。 +3. **逐项判定**：每项只输出 过/不过 + 证据（文件路径/章节位置/缺失说明），不做主观评价。 +4. **算分**：契合度 = 10 × 通过项数 / 总项数（保留两位小数）。 +5. **决策**：契合度 > 9.5 → review_approve（comment 附分数与核对摘要）；否则 review_reject（questions 逐条列出未过项：编号、位置、问题、改法）。 -## 二、需求文档落点 +## 必读文件 -- 对照 `project-directory-spec`：需求规格说明书 `projects/{项目}/docs/00-requirement/requirement-spec.md` -- 需求评审记录 `projects/{项目}/docs/00-requirement/requirement-review.md` +- 原始需求：`projects/{项目}/docs/00-requirement/requirement-spec.md`（需求规格说明书）+ 需求采集任务的原始输入（任务描述/用户上传材料） +- 需求分析交付件：`projects/{项目}/docs/00-requirement/` 下分析产出（需求细化/功能化描述） +- 路径权威来源：先 load_skill 加载 `project-directory-spec`，不要凭记忆找路径 -## 三、应用划分（design 职责，requirement 不产出） +## A 组：原始需求逐条契合（主体核对项） -- requirement 阶段**不划分 app、不产出 apps/{应用名}.md 或 {应用名}_spec.json**（app 划分是 design 阶段的架构决策，见 design 角色技能） -- 若 requirement 越权划分了 app 或产出了 app 说明文件 → 退回 +1. 从原始需求中抽取**原始需求点清单**（编号列明：#1、#2……）。需求点 = 用户明确要的功能/业务/约束，不是文档里的修饰语。抽取结果写进核对记录（供人工复核抽取是否漏项）。 +2. 逐条核对需求分析交付件是否**响应**了每个需求点。判定锚点（满足才算响应）： + - 有该需求点的功能化描述（做什么、给谁用） + - 有输入/输出或交互边界说明 + - 有验收口径（怎么算做完/做对） + - **只复述需求原文、没有功能化展开 = 不过**（空泛响应） +3. 每个需求点一个核对项。若某需求点在交付件中被拆成多个功能分别响应，算过；若被遗漏或合并后丢失语义，算不过。 -## 四、部署环境需求明确 +## B 组：合规项 -- 测试/生产环境的资源规格、依赖服务、端口、环境变量、高可用、备份、域名证书、监控告警是否写清 +4. **功能清单真实落库**：用 `list_features` 查 sd_features——应 ≥1 条记录（状态 proposed 或之后），且功能点覆盖全部业务域（如三大业务域都要有对应 feature）。只在文档里写了、库里 0 条 → 不过。 +5. **文档落点**：需求文档在 `project-directory-spec` 规定的路径（对照技能，不凭记忆）。 +6. **部署环境需求明确**：测试/生产环境的资源规格、依赖服务、端口、环境变量、高可用、备份、监控告警是否写清。空泛写「按标准配置」= 不过。 +7. **无越权划分**：requirement 阶段不划分 app、不产出 apps/{应用名}.md（app 划分是 design 职责）。越权 → 不过。 -## 五、真实性核查方法 +## 真实性核查（所有核对项通用） -- 用 list_features / 查 sd_features 表验证功能清单真实落库 -- 用 read_file / list_files 验证文档真实落盘，不只看交付说明的文字声明 +- 用 list_features / read_file / list_files 验证「真实落库/落盘」，不只信交付说明的文字声明。 + +## 输出要求 + +- review_approve 的 comment：`契合度 X.XX（通过 n/总 m）` + 核对摘要。 +- review_reject 的 questions：逐条 `[#编号] 位置：…… 问题：…… 改法：……`，精确到原始需求点编号，让需求分析师拿到就能改。 diff --git a/skills_library/pipelines/sdlc_general/roles/agent.qc/role/SKILL.md b/skills_library/pipelines/sdlc_general/roles/agent.qc/role/SKILL.md index 8110884..dd0988e 100644 --- a/skills_library/pipelines/sdlc_general/roles/agent.qc/role/SKILL.md +++ b/skills_library/pipelines/sdlc_general/roles/agent.qc/role/SKILL.md @@ -9,18 +9,25 @@ capability: task_capability ## 职责 对每个交付件做合规 + 质量检查，不合规 `review_reject` 退回重做，并逐条列出问题清单（指出具体哪一项、哪个文件、错在哪、该怎么改）。 -## 审查方法：一个被查对象一个技能 +## 审查方法：一个被查对象一个技能 + 统一评分协议 -审查某角色的产出时，先 load_skill 加载对应的审查清单技能，按清单逐项检查，不要凭记忆： +审查某角色的产出时，先 load_skill 加载对应的审查清单技能，按其中的核对项清单逐项检查，不要凭记忆： | 被查角色 | 审查技能 | 查什么 | |---|---|---| -| agent.requirement | `review-requirement` | 功能清单落库、需求文档、应用部署单元 | -| agent.design | `review-design` | 架构、模块划分、数据库设计 | -| agent.develop | `review-develop` | 模块目录、表定义、CRUD、代码质量 | +| agent.requirement | `review-requirement` | 原始需求逐条契合、功能清单落库、应用部署单元 | +| agent.design | `review-design` | 需求覆盖矩阵（硬门禁）、架构、模块划分、数据库设计 | +| agent.develop | `review-develop` | 技能映射表驱动：表定义/CRUD/dspy/UI/注册、代码质量 | | agent.test | `review-test` | 测试计划/用例落库、真实执行、Bug | | agent.deploy_test / deploy_prod | `review-deploy` | 部署配置、文档、真实部署 | +**统一评分协议（所有审查技能共用）**： +1. 先构建核对项清单（每项机械可判定 过/不过），再逐项判定，最后算分 +2. 契合度 = 10 × 通过项数 / 总项数（保留两位小数）；**> 9.5 放行** +3. 不放行时退回意见 = 未过项清单（编号、位置、问题、改法），直接构成重做指令 +4. 审查技能的 comment/questions 必须带分数与逐项结果，供人工抽查复核 +5. 硬门禁项（需求覆盖、应用脚手架禁项等）任一不过 = 必退，不受总分影响 + ## 通用检查（所有交付件） - **路径/命名/格式**：对照 `project-directory-spec`（load_skill 拿权威路径），交付文件必须在正确位置 - **内容质量**：完整、可量化、可验收、无空泛套话、无重大缺陷