@captain_z/zsk-skills 1.0.0 → 1.0.2

package/README.md

@@ -4,26 +4,26 @@ ZNorth Standard Kit 的内容包：**46 颗原子 skill**，按领域分簇组
 
 ## 合规审查（ARCHITECTURE §4.4 硬指标）
 
-| 检查项 | 结果 | 说明 |
-| --- | --- | --- |
-| frontmatter 完整（`name` / `description` / `category` / `domain` / `tier` / `triggers`） | ✓ 46/46 | 结构化 lint 通过 |
-| `name` 以 `zsk:` 前缀，扁平 slug | ✓ 46/46 | 命名空间统一 |
-| `description` 以 `Use when…` 开头（trigger-optimized） | ✓ 46/46 | 触发匹配句式 |
-| `category` / `domain` / `tier` 枚举值合法 | ✓ 46/46 | stage/workflow/standard/resource/meta · core/optional |
-| `triggers` 数组非空 | ✓ 46/46 | 每颗至少 4 个关键词 |
-| 无硬编码项目名 / 技术栈（统一 `{{config.*}}` 占位符） | ✓ | harness-neutral |
-| `related:` 相对路径合法（build 已重写） | ✓ | 无孤儿引用 |
-| 单文件 ≤ 300 行 | ⚠ 41/46 | 5 个 frontend skill 超标（见技术债） |
+| 检查项                                                                                   | 结果    | 说明                                                  |
+| ---------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------- |
+| frontmatter 完整（`name` / `description` / `category` / `domain` / `tier` / `triggers`） | ✓ 46/46 | 结构化 lint 通过                                      |
+| `name` 以 `zsk:` 前缀，扁平 slug                                                         | ✓ 46/46 | 命名空间统一                                          |
+| `description` 以 `Use when…` 开头（trigger-optimized）                                   | ✓ 46/46 | 触发匹配句式                                          |
+| `category` / `domain` / `tier` 枚举值合法                                                | ✓ 46/46 | stage/workflow/standard/resource/meta · core/optional |
+| `triggers` 数组非空                                                                      | ✓ 46/46 | 每颗至少 4 个关键词                                   |
+| 无硬编码项目名 / 技术栈（统一 `{{config.*}}` 占位符）                                    | ✓       | harness-neutral                                       |
+| `related:` 相对路径合法（build 已重写）                                                  | ✓       | 无孤儿引用                                            |
+| 单文件 ≤ 300 行                                                                          | ⚠ 41/46 | 5 个 frontend skill 超标（见技术债）                  |
 
 **技术债**（不阻塞 CI，`tools/lint-frontmatter.ts` 当前降级 warn）：
 
-| 文件 | 行数 |
-| --- | --- |
-| `frontend/a11y-web/SKILL.md` | 370 |
-| `frontend/testing-web/SKILL.md` | 351 |
-| `frontend/nfr-web/SKILL.md` | 352 |
-| `frontend/security-web/SKILL.md` | 311 |
-| `frontend/performance-web/SKILL.md` | 305 |
+| 文件                                | 行数 |
+| ----------------------------------- | ---- |
+| `frontend/a11y-web/SKILL.md`        | 370  |
+| `frontend/testing-web/SKILL.md`     | 351  |
+| `frontend/nfr-web/SKILL.md`         | 352  |
+| `frontend/security-web/SKILL.md`    | 311  |
+| `frontend/performance-web/SKILL.md` | 305  |
 
 清理手法见 `memory/project_tech_debts_lint_frontmatter.md`；完成后把 `max-lines` 从 `warn` 升回 `error`。
 
@@ -37,44 +37,59 @@ zsk skill 是 LLM **按需自动触发**的资产：
 4. **手动触发**（可选）：会话中显式说 "用 `zsk:spec`"、"走 `zsk:feature` 工作流"，LLM 直接载入指定 skill
 
 **典型消费路径**（production，安装后）：
+
 - `~/.claude/skills/<domain>/<slug>/SKILL.md` — Claude Code
 - `~/.codex/skills/<domain>/<slug>/SKILL.md` — Codex
 - `@captain_z/zsk-skills/<domain>/<slug>/SKILL.md` — 通过 npm 读
 
 ## 领域总览
 
-| 领域 | skill 数 | 职责 |
-| --- | --- | --- |
-| `sdlc/` | 17 | 7 阶段 SDLC + 3 变更工作流 + task 执行框架 |
-| `frontend/` | 16 | React + Web 层实现规范 |
-| `quality/` | 5 | 跨栈质量原则 |
-| `design-handoff/` | 2 | 设计交付方法论 |
-| `system/` | 5 | 工程宪法级资源 |
-| `meta/` | 1 | 元信息 |
-| **总计** | **46** | |
+| 领域              | skill 数 | 职责                                       |
+| ----------------- | -------- | ------------------------------------------ |
+| `sdlc/`           | 17       | 7 阶段 SDLC + 3 变更工作流 + task 执行框架 |
+| `frontend/`       | 16       | React + Web 层实现规范                     |
+| `quality/`        | 5        | 跨栈质量原则                               |
+| `design-handoff/` | 2        | 设计交付方法论                             |
+| `system/`         | 5        | 工程宪法级资源                             |
+| `meta/`           | 1        | 元信息                                     |
+| **总计**          | **46**   |                                            |
 
 ## 安装套件（bundles.yaml）
 
-| name | skills | 场景 |
-| --- | --- | --- |
-| `sdlc-only` | 10 | 纯流程骨架（7 阶段 + 3 工作流），不涉及技术栈 |
-| `frontend-project`（推荐） | 29 | SDLC 10 + Frontend 16 + Quality 3 |
-| `frontend-with-design-handoff` | 31 | frontend-project + Figma 交付 2 |
-| `custom` | 交互 | 通过 `zsk add` 任意多选 |
+| name                           | skills | 场景                                          |
+| ------------------------------ | ------ | --------------------------------------------- |
+| `sdlc-only`                    | 10     | 纯流程骨架（7 阶段 + 3 工作流），不涉及技术栈 |
+| `frontend-project`（推荐）     | 29     | SDLC 10 + Frontend 16 + Quality 3             |
+| `frontend-with-design-handoff` | 31     | frontend-project + Figma 交付 2               |
+| `custom`                       | 交互   | 通过 `zsk add` 任意多选                       |
 
 <!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 46 skills -->
 
 <!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 46 skills -->
 
-<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 46 skills -->
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 47 skills -->
 
-<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 46 skills -->
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 47 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 47 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 47 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 47 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 47 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 47 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 47 skills -->
+
+<!-- Auto-generated by tools/catalog.ts — do not edit manually. Total: 47 skills -->
 
 ## Skill 清单（按领域）
 
 > 内容由 `tools/catalog.ts` 从各 SKILL.md frontmatter 生成。重生成：`pnpm catalog`。
 
-### `sdlc/` — SDLC · 7 阶段 + 3 变更工作流 + task 框架 (17)
+### `sdlc/` — SDLC · 7 阶段 + 3 变更工作流 + task 框架 (18)
 
 - **`zsk:proposal`** *[stage 1 · stage · core]*
   New-change framing (feature / bugfix / refactor) before spec work — why, success criteria, out-of-scope boundary, alternatives considered, and risks. Always the first stage of the 7-stage SDLC.
@@ -93,8 +108,8 @@ zsk skill 是 LLM **按需自动触发**的资产：
   触发：`implementing design` · `task by task delivery` · `local quality gates` · `smallest viable change`
 
 - **`zsk:reviewing`** *[stage 5 · stage · core]*
-  PR code review — self-checklist, reviewer checklist, Conventional Comments prefixes, technical-rigor-over-performative-agreement when receiving feedback, dispute escalation path. Stage 5 of the 7-stage SDLC. This is the code-view (does the diff look right); the contract-view is zsk:verify.
-  触发：`code review` · `PR review` · `conventional comments` · `receiving feedback`
+  PR 代码审查与 AI 多维审查核心规范。包含 Scope 偏移检测、置信度评估、多阶段审查（Two-Pass）、测试执行流分析以及基于红黄绿灯的判定协议。
+  触发：`code review` · `PR review` · `审查合并请求` · `review this PR`
 
 - **`zsk:verify`** *[stage 6 · stage · core]*
   Acceptance verification before merge — independent contract check, FR/NFR coverage, AC evidence, gate records, and verdict with reproducible proof. Stage 6 of the 7-stage SDLC.
@@ -144,6 +159,10 @@ zsk skill 是 LLM **按需自动触发**的资产：
   Behavior-preserving refactor discipline — Fowler catalog, characterization tests as baseline, small atomic commits, Parallel Change / Strangler Fig for large refactors. Enforces "behavior preserved" as a hard contract (any behavior change means it is not a refactor).
   触发：`refactor workflow` · `Fowler refactoring` · `characterization test` · `Parallel Change`
 
+- **`zsk:standard-dev-flow`** *[workflow · core]*
+  交互式标准开发工作流，包含 9 个核心节点（Prepare, Proposal, Spec, Design, Task, Coding, Review, Verify, Commit）。通过强门禁和 Sub-Agent 审查机制，保障高质量的开发落地。
+  触发：`standard dev flow` · `start a new feature workflow` · `execute enterprise workflow` · `9 node development`
+
 ### `frontend/` — Frontend · React + Web 层实现规范 (16)
 
 - **`zsk:spec-frontend`** *[stage 2 · stage · optional]*

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@captain_z/zsk-skills",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "description": "ZNorth Standard Kit — skill content package (SDLC + frontend + quality + design-handoff + system + meta)",
   "license": "MIT",
   "files": [

package/sdlc/reviewing/SKILL.md

@@ -1,9 +1,6 @@
 ---
 name: zsk:reviewing
-description: PR code review — self-checklist, reviewer checklist, Conventional
-  Comments prefixes, technical-rigor-over-performative-agreement when receiving
-  feedback, dispute escalation path. Stage 5 of the 7-stage SDLC. This is the
-  code-view (does the diff look right); the contract-view is zsk:verify.
+description: PR 代码审查与 AI 多维审查核心规范。包含 Scope 偏移检测、置信度评估、多阶段审查（Two-Pass）、测试执行流分析以及基于红黄绿灯的判定协议。
 category: stage
 domain: sdlc
 tier: core
@@ -17,181 +14,106 @@ related:
   - ../verify/SKILL.md
   - ../../frontend/review-frontend/SKILL.md
   - ../../quality/code-hygiene/SKILL.md
+  - ../../system/project-constraints-template/SKILL.md
 triggers:
   - code review
   - PR review
-  - conventional comments
-  - receiving feedback
-  - technical rigor
-  - self review checklist
+  - 审查合并请求
+  - review this PR
+  - check my diff
 ---
 
-# Stage 5: Reviewing
-
-> **阶段定位**：代码评审 - Code Review
-> **回答的问题**：**代码写对了吗**？可读、可维护、安全、契约一致、性能无隐患
-> **与 Verify 的边界**：Reviewing 看**代码视角**（diff 有没有问题），Verify 看**契约视角**（是否满足 Spec / AC / NFR）。两者**不能互相替代**。
-> **参考规范**：Google Engineering Practices（Code Review）、Conventional Comments
-> **吸收硬原则**：
-> - **技术严谨 > 性能式同意**（Superpowers `receiving-code-review`）— 分歧先验证技术事实
-> - **证据先于断言**（Superpowers `verification-before-completion`）— 声称"没问题"前先跑命令
-> **前端专属检查项**：TS / React / 视觉 / 三语 i18n 见 [`frontend/review-frontend.md`](../../frontend/review-frontend/SKILL.md)
-
-## Skill 映射
-
-| 场景 | Primary Skill |
-| --- | --- |
-| 提交评审 | `superpowers:requesting-code-review` |
-| 接收反馈 | `superpowers:receiving-code-review`（技术严谨，避免盲目同意） |
-| 自评 | `self-review` / `check` |
-| PR / MR 评审 | `review` / `merge-review` |
-| 第二意见 | `codex review` / `codex challenge` |
-| 大型评审 | `superpowers:code-reviewer`（子代理） |
-
-## 变更类型差异
-
-| 类型 | Review 侧重 |
-| --- | --- |
-| **Feature** | 契约一致（公开接口） + 测试金字塔 + 性能 hazard |
-| **Bugfix** | RCA 合理性 + 回归测试能复现 + 无相邻破坏 + Postmortem 触发判定 |
-| **Refactor** | 行为不变证据 + 原子 commit 粒度 + Parallel Change 正确 + 性能/体积对照 |
-
-## 标准流程
-
-```text
-Author: 自评清单 → 提 MR/PR → 主动列"想让 Reviewer 关注什么"
-                                                ↓
-Reviewer: 读 Spec/Design/tasks → 按评审清单扫 diff → 按 Conventional Comments 写评论
-                                                ↓
-Author: 按技术严谨原则回应 → 有分歧先验证事实 → 必要时更新 design.md ADR
-                                                ↓
-Reviewer: re-review → Approve / Request changes
-                                                ↓
-合并前检查：verify.md 的证据链已就绪 → 进入 verify 阶段
-```
-
-## 1. 自评清单（Author，推前必过）
-
-> 这是进入 Reviewer 视野前的"最后一道自滤"。凡打 ✅ 必须是已跑过 / 已看过的证据，不是"应该没问题"。
-
-### 通用
-- [ ] `docs/{module}/spec.md` / `design.md` / `tasks.md` 已更新
-- [ ] `lint` / `type-check` 零 error（`{{config.scripts.lint}}` / `{{config.scripts.type_check}}`）
-- [ ] `test` 通过 + 覆盖率达标（`{{config.scripts.test}}`；规范见 [`quality/testing-pyramid`](../../quality/testing-pyramid/SKILL.md)）
-- [ ] 无硬编码敏感信息（见 [`quality/security-owasp`](../../quality/security-owasp/SKILL.md)）
-- [ ] 回滚方案在 `design.md` 中可执行
-- [ ] Commit 信息遵循 Conventional Commits
-- [ ] PR 描述含"为什么做 + 怎么验证"
-
-> **前端项目补**：TS 红线 / React hooks 规则 / 视觉回归 / 三语 i18n 等 → 见 [`frontend/review-frontend`](../../frontend/review-frontend/SKILL.md)
-
-### Bugfix 专用
-- [ ] 有先红后绿的测试证据（Step 1 提交 + Step 2 提交分离可见）
-- [ ] RCA 指向单一根因，非"凑巧 work"
-- [ ] 相邻场景有回归用例
-
-### Refactor 专用
-- [ ] 对外契约零变化，已在 PR 描述列对照表
-- [ ] 每个 commit 原子且绿
-- [ ] 包体积变化 ≤ ±2%（有证据链接）
-
-## 2. Reviewer 评审清单（通用）
-
-### 契约一致性
-- [ ] 公开接口与 `spec.md` 一致
-- [ ] 没有悄悄扩大公开接口
-- [ ] 类型引自约定来源（见 `system/project-constraints-template`）
-
-### 边界与错误
-- [ ] loading / empty / error 都有处理
-- [ ] 异步取消 / 竞态处理
-- [ ] 网络失败 / 超时 / 权限不足 的 fallback
-
-### 测试覆盖
-- [ ] 金字塔三层按 `design.md` 的策略就位
-- [ ] Bugfix：复现测试确实能复现（`git checkout HEAD^` 应该失败）
-- [ ] Refactor：Characterization Test 基线未被删除
-
-### 安全 / 依赖
-- [ ] 无新增敏感信息硬编码
-- [ ] 新增依赖说明合理（用途 / 许可 / 体积）
-
-### 代码风格
-- [ ] 命名能自解释
-- [ ] 没有过度注释"WHAT"，注释只写"WHY"
-- [ ] 没有未被调用的新抽象（YAGNI）
-
-## 3. Conventional Comments（评论规约）
-
-评论前缀帮助 Author 快速分类优先级：
-
-| 前缀 | 含义 | 必须改？ |
-| --- | --- | --- |
-| `blocking:` | 阻塞合并，必须解决 | ✅ |
-| `issue:` | 潜在 bug / 风险 | 🟡 讨论 |
-| `question:` | 需要解释 | 🟡 回应 |
-| `suggestion:` | 可选改进 | ⚪ 可选 |
-| `nitpick:` | 风格挑剔 | ⚪ 可选 |
-| `praise:` | 亮点表扬 | ⚪ 无需改 |
+# Stage 5: Reviewing (代码审查)
+
+> **阶段定位**：代码与架构审查（Code & Architecture Review）
+> **目标**：以高置信度的客观标准发现代码缺陷、架构偏移和需求蔓延，防止劣质代码合入主干。
+> **核心原则**：
+> - **事实先行**：审查不仅看代码语法，更要对照 `spec.md` 验证意图。
+> - **置信度校准**：宁缺毋滥。高确定性问题亮红灯，猜测性建议必须降级。
+> - **全链路视角**：不放过任何一个未处理的错误流分支。
+
+## 🤖 AI 代码审查标准流 (AI Code Review Flow)
+
+当 Agent（或 Sub-Agent）被召唤进行代码审查时，必须**严格按顺序执行以下四个阶段**。不得跳过。
+
+### 阶段 1：Scope Drift Detection (需求偏移检测)
 
-示例：
+**核心目标**：检查“写的是不是要求的东西”——不夹带私货，不漏掉功能。
 
-```text
-blocking: 公开接口 onSelect 未在 spec.md 中声明，请求合并前在 spec 加入并重新评审。
+1. 读取 `spec.md` 和 `tasks.md`，提取出所有的目标项。
+2. 运行 `git diff` 对比变更。
+   - **重要约束**：必须优先读取 `project-config.md` 中的 `defaultBranch` 字段作为 base 分支。如果未配置，默认使用 `origin/main` 作为比对基础。
+3. 产出一份 **Scope Check 报告**：
+   - `[DONE]`：代码与目标严格匹配。
+   - `[NOT DONE]`：Spec 中要求的但在 diff 中找不到证据（Missing Requirements）。
+   - `[CREEP]`：diff 中出现了 Spec/Task 中根本没提到的重构或新功能（Scope Creep）。
+   - *（注意：Scope Creep 需要特别指明，由用户判断是正向的补充还是危险的蔓延）*
 
-suggestion: 这段依赖项过多的缓存，考虑拆成两个派生值；不影响合并。
-```
+### 阶段 2：Two-Pass Multi-Agent 审查 (两遍核心检查)
 
-## 4. Author 接收反馈（技术严谨 > 性能式同意）
+将审查分为两个独立视角（Agent 应分饰多角依次进行）。
 
-收到评论时**禁止**以下反模式：
+**Pass 1: Critical (致命问题审查 - P1级别)**
+- **SQL / 数据安全**：检查是否存在注入、数据越权、无 WHERE 条件的全表更新。
+- **并发与竞态**：检查是否存在共享可变状态、缺乏事务锁的资金/库存操作。
+- **契约破坏**：是否悄悄改变了对外公开 API 的出入参结构。
+- **红线违规**：是否引入了 `SYSTEM-SPEC.md` 中禁用的依赖或违背了 Import 起源规则。
 
-- "好的我改"——未理解评论就改
-- "应该没问题吧"——未验证事实就拒绝
-- "这个和这个 PR 无关"——实际影响 PR 合并的问题不能这么推
+**Pass 2: Compliance & Best Practices (合规与架构审查 - P2/P3级别)**
+- **代码结构**：是否存在魔法数字、强耦合、废弃代码未删。
+- **错误降级**：所有异常捕获是否有合理的降级策略（Fallback），网络错误对用户是否可见。
+- **特定领域检查**：对于前端代码，必须引用并符合 `frontend/review-frontend.md`。
 
-正确做法：
+### 阶段 3：Test Coverage Tracking (测试死角追踪)
 
-1. **先分类**：blocking / issue / suggestion / nitpick
-2. **有分歧先验证**：跑命令 / 读代码 / 查文档，用事实回应
-3. **修或不修都给理由**：`✅ 已修复` 或 `❌ 不接受，因为...（事实依据）`
-4. **升级到 Design**：如果评论触及架构决策，升级到 `design.md` 的 ADR 重新评审
+1. **画出执行流 (Mental Model)**：对于被改变的每一个核心函数，不仅要看正常流程，必须分析其“异常分支”（if-else, try-catch, 边界值）。
+2. **校验测试映射**：查找对应的测试代码，核对测试用例是否覆盖了步骤 1 中的异常分支。
+3. **输出 Gap (死角报告)**：如果某个条件分支（如服务端返回 500 时 UI 的处理）在 diff 中没有对应的单元测试/E2E测试覆盖，必须作为 `[TESTING GAP]` 显式列出。
 
-## 5. 第二意见（Codex / Sub-agent Review）
+### 阶段 4：Confidence Calibration 与红绿灯定论输出
 
-**何时请**：
+在给出最终的 Review 报告时，所有的发现（Findings）必须带上 **置信度评分 (Confidence: N/10)**。
 
-- 高风险改动（安全 / 数据 / 跨系统）
-- Author 自己发起 PR 时想先做独立审查
-- Reviewer 与 Author 持续分歧 → 引入第三方视角
+- **9-10 (确凿)**：通过阅读明确上下文确认的 Bug 或红线违背。
+- **7-8 (极大概率)**：高置信度模式匹配（如常见的性能泄漏点）。
+- **5-6 (存疑)**：可能是误报，需提示用户验证。
+- **< 5 (猜测)**：除非是 P0 级风险，否则不要在最终报告中扰民。
 
-**可用工具**：
+**输出格式**：`[SEVERITY] (confidence: N/10) filename:line — description`
 
-- `codex review` — OpenAI Codex 独立审查，pass/fail 门禁
-- `codex challenge` — 对抗式审查，尝试破坏代码
-- `superpowers:code-reviewer` 子代理 — 里程碑级审查
+#### 最终判定协议 (Verdict Protocol)
 
-**纪律**：第二意见是**参考**，不是**决策**。最终合并决定仍由 Author + Reviewer 达成。
+Agent 在完成四步后，必须输出以下三种颜色的最终判定：
 
-## 6. 分歧升级路径
+- 🟢 **PASS (通过)**：仅有少量拼写错误、格式建议，无阻碍性问题。可以进入 `Verify`。
+- 🟡 **PASS_WITH_CONCERNS (带条件通过)**：存在 Scope Creep（但无害）、低置信度的架构建议、或遗漏的非致命测试。给出列表，请求用户定夺。
+- 🔴 **FAIL / BLOCKED (拒绝)**：发现 P1 级 Critical 问题、置信度极高的未捕获异常、或大面积未完成的 `[NOT DONE]` 需求。必须回退到 Coding 进行修复。
 
-```text
-1. Author + Reviewer 讨论（评论区）
-   ↓ 仍分歧
-2. 引入 codex / 第二 Reviewer（事实澄清）
-   ↓ 仍分歧
-3. 升级到 design.md ADR（架构/风格的边界决策）
-   ↓ 仍分歧
-4. 模块负责人裁决 + 更新 SYSTEM-SPEC.md（系统级决策）
-```
+---
+
+## 👩‍💻 人类评审规约 (Human Reviewer Guidelines)
+
+### 发起者自查清单 (Author Pre-PR Checklist)
+> 💡 强烈建议 Author 在提交 PR 交给 AI 或其他人审查之前，先行对照以下精简清单自查，以节约 Review 成本。
 
-## 质量门禁（进入 `zsk:verify` 前）
+- [ ] 是否在本地运行了 `pnpm typecheck` 和 `pnpm lint` 且 0 报错？
+- [ ] 所有的改动是否都属于该 PR 的原始目标？(拒绝私带重构代码)
+- [ ] 核心 API 修改是否已经通知了潜在的调用方？
+- [ ] UI 变动是否已在明暗色、移动/桌面端自我验收？
+- [ ] 是否在 Commit Message 中正确链接了 Issue 编号？
 
-- [ ] 自评清单全绿
-- [ ] 所有 `blocking:` 评论已 resolved
-- [ ] 所有 `issue:` / `question:` 已给出书面回应
-- [ ] Reviewer Approve（至少 1 人，高风险改动 ≥ 2 人）
-- [ ] 合并轮次 ≤ 3（超出需复盘沟通效率）
-- [ ] 首轮 Review 在 1 个工作日内（SLA）
-- [ ] 有第二意见（高风险改动）
-- [ ] 前端项目：`frontend/review-frontend` 的检查项全过
+### 评审者话术映射
+如果是人类互相进行 Review，遵循 Conventional Comments 前缀以减少沟通成本：
+
+| 前缀 | 含义 | 对应 AI 判定 |
+| --- | --- | --- |
+| `blocking:` | 阻塞合并，必须解决。 | 对应 🔴 FAIL |
+| `issue:` | 潜在 bug 或风险点。 | 对应 🟡 CONCERNS |
+| `question:` | 逻辑看不懂，需要 Author 解释。 | 对应 🟡 CONCERNS |
+| `suggestion:`| 可选的重构或风格建议。 | 对应 🟢 PASS |
+| `praise:` | 写得非常好的地方，表扬！ | 对应 🟢 PASS |
+
+**接收反馈的“技术严谨”原则：**
+被 Review 的作者（Author）面对质疑时，**禁止用“应该没问题吧”来拒绝**。
+- 如果接受，回复 `✅ 已修复`。
+- 如果分歧，必须通过跑命令、读代码拿出事实证据：`❌ 不接受，因为测试 X 已经覆盖了该场景...`。

package/sdlc/standard-dev-flow/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: zsk:standard-dev-flow
+description: 交互式标准开发工作流，包含 9 个核心节点（Prepare, Proposal, Spec, Design, Task,
+  Coding, Review, Verify, Commit）。通过强门禁和 Sub-Agent 审查机制，保障高质量的开发落地。
+category: workflow
+domain: sdlc
+tier: core
+variants:
+  - feature
+  - bugfix
+  - refactor
+related:
+  - ../proposal/SKILL.md
+  - ../spec/SKILL.md
+  - ../design/SKILL.md
+  - ../task/SKILL.md
+  - ../coding/SKILL.md
+  - ../verify/SKILL.md
+  - ../../system/project-constraints-template/SKILL.md
+triggers:
+  - standard dev flow
+  - start a new feature workflow
+  - execute enterprise workflow
+  - 9 node development
+  - zsk standard workflow
+---
+
+# 交互式标准开发工作流 (Standard Dev Workflow)
+
+> **定位**：这是一套专为公司级开发或新项目设计的 **分节点交互式编排工作流 (Interactive Orchestrator Skill)**。遵循业界最佳实践，确保高内聚、低耦合以及严格的质量门禁。
+> **核心原则**：工作流分为 **9 个串行节点**。Agent **绝不允许跨节点越权执行**。在每个节点的任务完成后，Agent 必须停下来，询问用户是否可以进入下一个环节，并在得到明确肯定后方可继续。
+> **适用场景**：复杂功能的从头开发、需要高质量审查的重要迭代。
+
+## Agent 执行铁律 (The Golden Rules)
+
+作为执行该工作流的 Agent，你必须遵守：
+1. **单节点聚焦**：当前处于哪个阶段，就只能执行那个阶段的任务。禁止在 `Spec` 阶段直接去写代码。
+2. **多轮对话打磨**：一个节点内部可以进行多次对话（修改、澄清）。
+3. **显式放行 (Explicit Gate)**：每个节点的末尾，必须输出当前的最终产物，并询问：“当前节点产物已就绪，是否准许进入 [下一节点]？”
+4. **加载上下文**：全局系统约束 (`SYSTEM-SPEC.md`) 和工程配置 (`project-config.md`) 在启动时自动载入，贯穿整个流程。
+
+---
+
+## 9 节点流转逻辑 (The 9 Nodes)
+
+### Node 1: Prepare (准备与资源收集)
+- **目标**：准备开发资源，建立本次迭代的事实源（Source of Truth）。
+- **Agent 动作**：向用户索要初始输入，并将其统一整理保存到项目根目录的 `.raws/` 文件夹下。
+- **`.raws/` 命名规范**（必须遵守）：
+  - 需求文档 → `.raws/requirements.md`
+  - Figma 链接或导出 → `.raws/design-figma.json` 或 `.raws/design-figma.md`
+  - API 接口文档 → `.raws/api-spec.json` 或 `.raws/api-spec.md`
+  - 其他资料 → `.raws/<描述性名称>.<扩展名>`（使用小写 kebab-case，禁止空格）
+- **出口门禁**：所有必要的上下文资料已按规范落盘。向用户确认是否进入 `Proposal` 阶段。
+
+### Node 2: Proposal (提案阶段)
+- **目标**：对齐业务意图和范围边界。
+- **Agent 动作**：结合 `.raws/` 中的资料和 `SYSTEM-SPEC.md`，输出 `proposal.md`。必须明确 SMART 目标、备选方案和“不做什么（Out of scope）”。
+- **出口门禁**：用户确认 `proposal.md` 的内容无误。
+
+### Node 3: Spec (规格定义)
+- **目标**：确立行为契约。
+- **Agent 动作**：基于 Proposal 产出 `spec.md`。为功能需求（FR）、非功能需求（NFR，须继承自 SYSTEM-SPEC 基线）和验收标准（AC）进行编号。
+- **出口门禁**：用户确认 `spec.md` 的所有编号和验收条件清晰可测。
+
+### Node 4: Design (技术设计)
+- **目标**：给出实现方案映射。
+- **Agent 动作**：基于 Spec 产出 `design.md`。必须给出技术选型理由，并提供 `FR 编号 -> 代码模块路径` 的映射。受 `project-config.md` 路径约束。
+- **出口门禁**：用户对架构和技术实现方案没有异议。
+
+### Node 5: Task (任务拆解)
+- **目标**：将大需求拆分成可执行的原子任务。
+- **Agent 动作**：生成 `tasks.md`，按最小可行切片（Slice）列出具有前置依赖关系的任务组。
+- **出口门禁**：用户确认任务切分颗粒度合理，同意开始编码。
+
+### Node 6: Coding (编码执行)
+- **目标**：按任务清单写代码。
+- **Agent 动作**：严格按 `tasks.md` 逐步执行代码。每次引入依赖或改动时，自我审查是否违背了 `SYSTEM-SPEC.md` 中的禁忌清单和 Import 起源规则。
+- **触发 Review 的明确时机**（满足任一即停止编码，进入 Node 7）：
+  - 完成 `tasks.md` 中一个**独立功能切片**（同一 FR 编号下的全部原子 Task 均打钩）。
+  - 单轮改动累计超过 **10 个文件** 或 **300 行代码**。
+  - 任何引入新 npm 包的改动完成后。
+- **出口门禁**：Agent 主动停止编码，声明已进入 Node 7，用户无需手动提醒。
+
+### Node 7: Review (多视角审查)
+- **目标**：提高代码交付质量，排查隐患。
+- **Agent 动作**：参照 `zsk:reviewing` 技能的四阶段流程（Scope Drift → Two-Pass → Test Coverage → Confidence Verdict），扮演多视角 Sub-Agent 执行审查。
+- **输出产物**：最终给出以下三种评估之一：
+  - 🟢 **绿灯 (Green)**：无阻碍性问题，进入 Node 8 Verify。
+  - 🟡 **黄灯 (Yellow)**：存在建议项，列出清单，由用户决定是否修复后再 Review，或豁免放行。
+  - 🔴 **红灯 (Red)**：发现 P1 级 Critical 问题或高置信度严重缺陷。**自动回退 Node 6**，Agent 声明：“Review 发现阻塞性问题，回退至 Coding……”并重新列出需修改的 Task，重新进入 Coding → Review 循环，直至通过。
+- **出口门禁**：🟢 绿灯，或 🟡 用户明确豁免。🔴 红灯时禁止放行，必须回退至 Node 6。
+
+### Node 8: Verify (多维验收)
+- **目标**：以客观证据逐条验证 `spec.md` 中所有 AC 均已满足。
+- **Agent 动作**：
+  1. 从 `spec.md` 提取所有 `AC-XXX` 编号，逐条核对，输出：`AC-XXX: [PASS / FAIL] — 证据：<命令输出 / 截图 / 日志片段>`
+  2. 运行 `SYSTEM-SPEC.md § NFR 基线` 中所有命令并展示 Exit code（如 `pnpm typecheck`、`pnpm lint`、`pnpm build`）。
+  3. 若环境允许，调用高级工具（如 `Figma MCP` 进行 UI 还原度比对，或 `Computer Use` 模拟浏览器验证用户流）。
+- **出口门禁**：所有 AC 状态为 `PASS` 且 NFR 命令 Exit code = 0。任一 AC 为 `FAIL`，禁止进入 Node 9，回退 Node 6 修复。
+
+### Node 9: Commit (提交)
+- **目标**：版本封版。
+- **Agent 动作**：基于 Conventional Commits 规范，总结这一阶段的修改，自动生成 Commit Message。
+- **出口门禁**：询问用户是否可以执行 Git Commit（及 Push）。用户同意后，完成整个工作流。
+
+---
+
+## 启动口令范例
+
+> "启动 `zsk:standard-dev-flow` 流程。请先带我进入 Node 1 (Prepare)。我这边有一些 API 的 json 结构，你可以先保存到 `.raws/` 里。"