@zmice/zc 0.1.1 → 0.2.1

package/vendor/packages/toolkit/src/content/skills/git-workflow-and-versioning/body.md

@@ -0,0 +1,319 @@
+# Git 工作流与版本管理
+
+## 概述
+
+Git 是你的安全网。把提交当存档点，把分支当沙箱，把历史当文档。AI Agent 高速生成代码的环境下，规范的版本控制是保持变更可管理、可审查、可回滚的核心机制。
+
+## 何时使用
+
+始终使用。所有代码变更都经过 git。
+
+## 核心原则
+
+### 主干开发（推荐）
+
+保持 `main` 始终可部署。在短生命周期的 feature 分支上工作，1-3 天内合回。长期存活的开发分支是隐性成本 — 它们会分叉、产生合并冲突、延迟集成。DORA 研究持续表明，主干开发与高效能工程团队强相关。
+
+```
+main ──●──●──●──●──●──●──●──●──●──  （始终可部署）
+        ╲      ╱  ╲    ╱
+         ●──●─╱    ●──╱    ← 短生命周期 feature 分支（1-3 天）
+```
+
+这是推荐的默认策略。使用 gitflow 或长期分支的团队可以调整原则（原子提交、小变更、描述性消息）以适配自己的分支模型 — 提交纪律比具体的分支策略更重要。
+
+- **开发分支是成本。** 分支每多存活一天，合并风险就多一分。
+- **发布分支可以接受。** 当需要稳定发布版本而 main 继续前进时。
+- **Feature Flag > 长期分支。** 优先使用 flag 部署未完成的功能，而非在分支上放几周。
+
+### 1. 早提交，勤提交
+
+每个成功的增量都应有自己的提交。不要积累大量未提交的变更。
+
+```
+工作模式：
+  实现切片 → 测试 → 验证 → 提交 → 下一个切片
+
+不要这样：
+  实现所有功能 → 祈祷能跑 → 一个巨大提交
+```
+
+提交是存档点。如果下一个变更出了问题，你可以立即回到上一个已知正常的状态。
+
+### 2. 原子提交
+
+每个提交只做一件逻辑上完整的事：
+
+```
+# 好的：每个提交自包含
+git log --oneline
+a1b2c3d feat: 添加任务创建接口及校验
+d4e5f6g feat: 添加任务创建表单组件
+h7i8j9k feat: 表单对接 API 并添加加载状态
+m1n2o3p test: 添加任务创建测试（单元 + 集成）
+
+# 差的：所有东西混在一起
+git log --oneline
+x1y2z3a 添加任务功能、修侧边栏、更新依赖、重构工具函数
+```
+
+## 3. 描述性消息
+
+提交消息解释 *为什么*，而非仅仅描述 *做了什么*：
+
+```
+# 好的：解释意图
+feat: 注册接口添加邮箱格式校验
+
+防止无效邮箱格式写入数据库。
+在路由处理层使用 Zod schema 校验，与 auth.ts 中现有校验模式一致。
+
+# 差的：描述 diff 中显而易见的内容
+更新 auth.ts
+```
+
+**格式：**
+```
+<type>: <中文简述>
+
+<可选的详细说明，解释"为什么"而非"做了什么">
+```
+
+**类型前缀：**
+- `feat` — 新功能
+- `fix` — Bug 修复
+- `refactor` — 既不修 bug 也不加功能的代码重构
+- `test` — 添加或更新测试
+- `docs` — 仅文档变更
+- `chore` — 工具链、依赖、配置
+
+### 4. 关注点分离
+
+不要把格式化变更和行为变更混在一起。不要把重构和新功能混在一起。每种变更应独立提交，最好也是独立的 PR：
+
+```
+# 好的：关注点分离
+git commit -m "refactor: 提取校验逻辑到共享工具模块"
+git commit -m "feat: 注册流程添加手机号校验"
+
+# 差的：关注点混杂
+git commit -m "重构校验并添加手机号字段"
+```
+
+**重构和功能开发分开提交。** 重构和功能是两种不同的变更 — 分开提交。这使每个变更更容易审查、回滚和在历史中理解。小清理（如重命名变量）可以酌情包含在功能提交中。
+
+### 5. 控制变更规模
+
+目标每次提交/PR 约 100 行。超过 1000 行的变更应拆分。参见 `code-review-and-quality` 中的拆分策略。
+
+```
+~100 行  → 容易审查，容易回滚
+~300 行  → 单个逻辑变更可以接受
+~1000 行 → 必须拆分为更小的变更
+```
+
+## 分支策略
+
+### Feature 分支
+
+```
+main（始终可部署）
+  │
+  ├── feature/task-creation    ← 每个分支一个功能
+  ├── feature/user-settings    ← 并行开发
+  └── fix/duplicate-tasks      ← Bug 修复
+```
+
+- 从 `main`（或团队默认分支）创建分支
+- 保持分支短生命周期（1-3 天内合并）— 长期分支是隐性成本
+- 合并后删除分支
+- 优先使用 Feature Flag 而非长期分支来管理未完成的功能
+
+### 分支命名
+
+```
+feature/<简短描述>   → feature/task-creation
+fix/<简短描述>       → fix/duplicate-tasks
+chore/<简短描述>     → chore/update-deps
+refactor/<简短描述>  → refactor/auth-module
+```
+
+## Git Worktree 并行开发
+
+当多个 AI Agent 需要并行工作时，使用 git worktree 同时运行多个分支：
+
+```bash
+# 为 feature 分支创建 worktree
+git worktree add ../project-feature-a feature/task-creation
+git worktree add ../project-feature-b feature/user-settings
+
+# 每个 worktree 是独立目录，各自有自己的分支
+# Agent 可以并行工作互不干扰
+ls ../
+  project/              ← main 分支
+  project-feature-a/    ← task-creation 分支
+  project-feature-b/    ← user-settings 分支
+
+# 完成后合并并清理
+git worktree remove ../project-feature-a
+```
+
+优势：
+- 多个 Agent 可以同时工作在不同功能上
+- 无需切换分支（每个目录有自己的分支）
+- 实验失败时直接删除 worktree — 不会丢失任何东西
+- 变更相互隔离，直到显式合并
+
+## 存档点模式
+
+```
+Agent 开始工作
+    │
+    ├── 做了一个变更
+    │   ├── 测试通过？ → 提交 → 继续
+    │   └── 测试失败？ → 回退到上次提交 → 调查
+    │
+    ├── 做了另一个变更
+    │   ├── 测试通过？ → 提交 → 继续
+    │   └── 测试失败？ → 回退到上次提交 → 调查
+    │
+    └── 功能完成 → 所有提交形成干净的历史
+```
+
+这个模式意味着你永远不会丢失超过一个增量的工作。如果 Agent 走偏了，`git reset --hard HEAD` 就能回到上一个成功状态。
+
+## 变更摘要
+
+每次修改后提供结构化摘要。这使审查更容易，记录范围纪律，暴露意外变更：
+
+```
+变更内容:
+- src/routes/tasks.ts: 为 POST 端点添加校验中间件
+- src/lib/validation.ts: 添加 TaskCreateSchema（使用 Zod）
+
+未修改（有意为之）:
+- src/routes/auth.ts: 有类似校验缺口但不在本次范围内
+- src/middleware/error.ts: 错误格式可优化（单独任务）
+
+潜在关注点:
+- Zod schema 为严格模式 — 会拒绝多余字段，请确认是否预期行为
+- zod 作为依赖添加（72KB gzipped）— package.json 中已存在
+```
+
+这个模式能尽早发现错误假设，给审查者提供清晰的变更地图。“未修改”部分尤其重要 — 它展示了你的范围纪律。
+
+## 提交前检查
+
+每次提交前：
+
+```bash
+# 1. 检查即将提交的内容
+git diff --staged
+
+# 2. 确保没有密钥泄露
+git diff --staged | grep -i "password\|secret\|api_key\|token"
+
+# 3. 运行测试
+npm test
+
+# 4. 运行 lint
+npm run lint
+
+# 5. 类型检查
+npx tsc --noEmit
+```
+
+使用 git hooks 自动化：
+
+```json
+// package.json（使用 lint-staged + husky）
+{
+  "lint-staged": {
+    "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
+    "*.{json,md}": ["prettier --write"]
+  }
+}
+```
+
+## 分支收尾
+
+提交纪律解决的是“如何安全前进”，分支收尾解决的是“何时正式结束”。一个 branch 在以下条件同时成立前，不算真正完成：
+
+- 变更已经过本任务要求的验证
+- branch 的最终去向已经明确
+- 不再需要的 branch / worktree 已清理
+
+常见结束状态：
+
+- **直接合入** — 适合短生命周期分支；合入目标分支后立即删除
+- **开 PR 等待审查** — 推送 branch，附带验证证据，PR 合并后删除 branch
+- **暂时保留** — 只在有明确后续任务、责任人和截止时间时成立
+- **丢弃实验** — 记录结论后删除 branch 或清理 worktree，不让失败方案长期悬挂
+
+如果你需要具体的 merge / keep / discard / cleanup 判定，转到 `branch-finish-and-cleanup`。
+
+## 生成文件处理
+
+- **提交生成文件** 仅在项目需要时（如 `package-lock.json`、Prisma 迁移）
+- **不提交** 构建产物（`dist/`、`.next/`）、环境文件（`.env`）、IDE 配置（`.vscode/settings.json`，除非共享）
+- **配置 `.gitignore`** 覆盖：`node_modules/`、`dist/`、`.env`、`.env.local`、`*.pem`
+
+## 使用 Git 调试
+
+```bash
+# 查找哪个提交引入了 bug
+git bisect start
+git bisect bad HEAD
+git bisect good <已知正常的提交>
+# Git 二分检出中点；在每个点运行测试来缩小范围
+
+# 查看最近的变更
+git log --oneline -20
+git diff HEAD~5..HEAD -- src/
+
+# 查找谁最后修改了某行
+git blame src/services/task.ts
+
+# 搜索提交消息关键词
+git log --grep="校验" --oneline
+```
+
+## 常见借口
+
+| 借口 | 现实 |
+|------|------|
+| “等功能做完再提交” | 一个巨大提交无法审查、调试或回滚。每个切片都提交。 |
+| “提交消息无所谓” | 消息就是文档。未来的你（和未来的 Agent）需要理解改了什么以及为什么。 |
+| “回头再 squash” | Squash 会破坏开发叙事。从一开始就做干净的增量提交。 |
+| “分支太麻烦” | 短生命周期分支是免费的，能防止工作冲突。长期分支才是问题 — 1-3 天内合并。 |
+| “回头再拆分” | 大变更更难审查、部署风险更高、更难回滚。提交前拆分，不要事后。 |
+| “不需要 .gitignore” | 直到带生产密钥的 `.env` 被提交。立即配置。 |
+
+## 危险信号
+
+- 大量未提交的变更在累积
+- 提交消息像 “fix”、“更新”、“杂项”
+- 格式化变更和行为变更混在一起
+- 项目没有 `.gitignore`
+- 提交了 `node_modules/`、`.env` 或构建产物
+- 长期分支与 main 严重分叉
+- 在共享分支上 force-push
+
+## 提交检查清单
+
+每次提交前确认：
+
+- [ ] 提交只做一件逻辑上完整的事
+- [ ] 消息解释了“为什么”，遵循 type 规范
+- [ ] 提交前测试通过
+- [ ] diff 中没有密钥
+- [ ] 没有把格式化变更和行为变更混在一起
+- [ ] `.gitignore` 覆盖了标准排除项
+
+## 分支结束检查清单
+
+- [ ] branch 的目标去向已明确：merge、PR、保留或删除
+- [ ] 合入或关闭前的验证证据已准备好
+- [ ] 合并后的 branch 会被删除，不会长期滞留
+- [ ] 关联 worktree 在任务结束后同步清理
+- [ ] 保留中的 branch 有明确后续动作，而不是“先放着”

package/vendor/packages/toolkit/src/content/skills/git-workflow-and-versioning/meta.yaml

@@ -0,0 +1,21 @@
+kind: skill
+name: git-workflow-and-versioning
+title: Git 工作流
+description: Git 工作流规范。在进行任何代码变更时使用。包括提交、分支、冲突解决，以及多并行流的组织方式。
+tier: recommended
+audience: default
+stability: stable
+suggests:
+  - skill:branch-finish-and-cleanup
+  - skill:verification-before-completion
+platforms:
+  - qwen
+  - codex
+  - qoder
+source:
+  upstream: agent-skills
+  strategy: adapted
+  origin_name: git-workflow-and-versioning
+  origin_path: skills/git-workflow-and-versioning/SKILL.md
+  origin_id: skill:git-workflow-and-versioning
+  notes: 结合上游 Git 工作流规范、本仓库原子提交要求，以及分支收尾闭环整理。

package/vendor/packages/toolkit/src/content/skills/idea-refine/body.md

@@ -0,0 +1,173 @@
+# Idea Refine
+
+Refines raw ideas into sharp, actionable concepts worth building through structured divergent and convergent thinking.
+
+## How It Works
+
+1.  **Understand & Expand (Divergent):** Restate the idea, ask sharpening questions, and generate variations.
+2.  **Evaluate & Converge:** Cluster ideas, stress-test them, and surface hidden assumptions.
+3.  **Sharpen & Ship:** Produce a concrete markdown one-pager moving work forward.
+
+## Usage
+
+This skill is primarily an interactive dialogue. Invoke it with an idea, and the agent will guide you through the process.
+
+```bash
+# Optional: Initialize the ideas directory
+bash /mnt/skills/user/idea-refine/scripts/idea-refine.sh
+```
+
+**Trigger Phrases:**
+- "Help me refine this idea"
+- "Ideate on [concept]"
+- "Stress-test my plan"
+
+## Output
+
+The final output is a markdown one-pager saved to `docs/ideas/[idea-name].md` (after user confirmation), containing:
+- Problem Statement
+- Recommended Direction
+- Key Assumptions
+- MVP Scope
+- Not Doing list
+
+## Detailed Instructions
+
+You are an ideation partner. Your job is to help refine raw ideas into sharp, actionable concepts worth building.
+
+### Philosophy
+
+- Simplicity is the ultimate sophistication. Push toward the simplest version that still solves the real problem.
+- Start with the user experience, work backwards to technology.
+- Say no to 1,000 things. Focus beats breadth.
+- Challenge every assumption. "How it's usually done" is not a reason.
+- Show people the future — don't just give them better horses.
+- The parts you can't see should be as beautiful as the parts you can.
+
+### Process
+
+When the user invokes this skill with an idea (`$ARGUMENTS`), guide them through three phases. Adapt your approach based on what they say — this is a conversation, not a template.
+
+#### Phase 1: Understand & Expand (Divergent)
+
+**Goal:** Take the raw idea and open it up.
+
+1. **Restate the idea** as a crisp "How Might We" problem statement. This forces clarity on what's actually being solved.
+
+2. **Ask 3-5 sharpening questions** — no more. Focus on:
+   - Who is this for, specifically?
+   - What does success look like?
+   - What are the real constraints (time, tech, resources)?
+   - What's been tried before?
+   - Why now?
+
+   Use the `AskUserQuestion` tool to gather this input. Do NOT proceed until you understand who this is for and what success looks like.
+
+3. **Generate 5-8 idea variations** using these lenses:
+   - **Inversion:** "What if we did the opposite?"
+   - **Constraint removal:** "What if budget/time/tech weren't factors?"
+   - **Audience shift:** "What if this were for [different user]?"
+   - **Combination:** "What if we merged this with [adjacent idea]?"
+   - **Simplification:** "What's the version that's 10x simpler?"
+   - **10x version:** "What would this look like at massive scale?"
+   - **Expert lens:** "What would [domain] experts find obvious that outsiders wouldn't?"
+
+   Push beyond what the user initially asked for. Create products people don't know they need yet.
+
+**If running inside a codebase:** Use `Glob`, `Grep`, and `Read` to scan for relevant context — existing architecture, patterns, constraints, prior art. Ground your variations in what actually exists. Reference specific files and patterns when relevant.
+
+Read `frameworks.md` in this skill directory for additional ideation frameworks you can draw from. Use them selectively — pick the lens that fits the idea, don't run every framework mechanically.
+
+#### Phase 2: Evaluate & Converge
+
+After the user reacts to Phase 1 (indicates which ideas resonate, pushes back, adds context), shift to convergent mode:
+
+1. **Cluster** the ideas that resonated into 2-3 distinct directions. Each direction should feel meaningfully different, not just variations on a theme.
+
+2. **Stress-test** each direction against three criteria:
+   - **User value:** Who benefits and how much? Is this a painkiller or a vitamin?
+   - **Feasibility:** What's the technical and resource cost? What's the hardest part?
+   - **Differentiation:** What makes this genuinely different? Would someone switch from their current solution?
+
+   Read `refinement-criteria.md` in this skill directory for the full evaluation rubric.
+
+3. **Surface hidden assumptions.** For each direction, explicitly name:
+   - What you're betting is true (but haven't validated)
+   - What could kill this idea
+   - What you're choosing to ignore (and why that's okay for now)
+
+   This is where most ideation fails. Don't skip it.
+
+**Be honest, not supportive.** If an idea is weak, say so with kindness. A good ideation partner is not a yes-machine. Push back on complexity, question real value, and point out when the emperor has no clothes.
+
+#### Phase 3: Sharpen & Ship
+
+Produce a concrete artifact — a markdown one-pager that moves work forward:
+
+```markdown
+# [Idea Name]
+
+## Problem Statement
+[One-sentence "How Might We" framing]
+
+## Recommended Direction
+[The chosen direction and why — 2-3 paragraphs max]
+
+## Key Assumptions to Validate
+- [ ] [Assumption 1 — how to test it]
+- [ ] [Assumption 2 — how to test it]
+- [ ] [Assumption 3 — how to test it]
+
+## MVP Scope
+[The minimum version that tests the core assumption. What's in, what's out.]
+
+## Not Doing (and Why)
+- [Thing 1] — [reason]
+- [Thing 2] — [reason]
+- [Thing 3] — [reason]
+
+## Open Questions
+- [Question that needs answering before building]
+```
+
+**The "Not Doing" list is arguably the most valuable part.** Focus is about saying no to good ideas. Make the trade-offs explicit.
+
+Ask the user if they'd like to save this to `docs/ideas/[idea-name].md` (or a location of their choosing). Only save if they confirm.
+
+### Anti-patterns to Avoid
+
+- **Don't generate 20+ ideas.** Quality over quantity. 5-8 well-considered variations beat 20 shallow ones.
+- **Don't be a yes-machine.** Push back on weak ideas with specificity and kindness.
+- **Don't skip "who is this for."** Every good idea starts with a person and their problem.
+- **Don't produce a plan without surfacing assumptions.** Untested assumptions are the #1 killer of good ideas.
+- **Don't over-engineer the process.** Three phases, each doing one thing well. Resist adding steps.
+- **Don't just list ideas — tell a story.** Each variation should have a reason it exists, not just be a bullet point.
+- **Don't ignore the codebase.** If you're in a project, the existing architecture is a constraint and an opportunity. Use it.
+
+### Tone
+
+Direct, thoughtful, slightly provocative. You're a sharp thinking partner, not a facilitator reading from a script. Channel the energy of "that's interesting, but what if..." -- always pushing one step further without being exhausting.
+
+Read `examples.md` in this skill directory for examples of what great ideation sessions look like.
+
+## Red Flags
+
+- Generating 20+ shallow variations instead of 5-8 considered ones
+- Skipping the "who is this for" question
+- No assumptions surfaced before committing to a direction
+- Yes-machining weak ideas instead of pushing back with specificity
+- Producing a plan without a "Not Doing" list
+- Ignoring existing codebase constraints when ideating inside a project
+- Jumping straight to Phase 3 output without running Phases 1 and 2
+
+## Verification
+
+After completing an ideation session:
+
+- [ ] A clear "How Might We" problem statement exists
+- [ ] The target user and success criteria are defined
+- [ ] Multiple directions were explored, not just the first idea
+- [ ] Hidden assumptions are explicitly listed with validation strategies
+- [ ] A "Not Doing" list makes trade-offs explicit
+- [ ] The output is a concrete artifact (markdown one-pager), not just conversation
+- [ ] The user confirmed the final direction before any implementation work

package/vendor/packages/toolkit/src/content/skills/idea-refine/meta.yaml

@@ -0,0 +1,17 @@
+kind: skill
+name: idea-refine
+title: 想法细化
+description: 迭代式细化想法。通过结构化的发散与收敛过程澄清方向，适用于点子尚模糊、方案需要比较，或希望在进入规格阶段前先把核心思路打磨清楚时。
+tier: recommended
+audience: default
+stability: stable
+suggests:
+  - skill:brainstorming-and-design
+platforms:
+  - qwen
+  - codex
+  - qoder
+source:
+  upstream: superpowers
+  strategy: inspired
+  notes: 吸收上游发散收敛式思考方法，并按本仓库中文命令体系暴露。

package/vendor/packages/toolkit/src/content/skills/incremental-implementation/body.md

@@ -0,0 +1,43 @@
+# 增量实现
+
+## 何时使用
+
+- 实现任何跨多个文件的改动
+- 按计划逐项交付功能切片
+- 做重构，但又必须保持系统持续可运行
+- 你已经开始想“一次写完再看”的时候
+
+不适用于边界已经极小的单函数改动。
+
+## 输入前提
+
+- 已有任务列表或清晰的实现目标
+- 已知道本次切片的范围边界
+- 愿意在每个切片后立即测试、验证、提交
+
+## 执行步骤
+
+1. 先选最小的完整切片，不要一次吞整段功能
+2. 只改当前任务需要的范围，避免顺手扩散
+3. 每个切片都完成 `Implement -> Test -> Verify -> Commit`
+4. 保持系统始终可构建、可测试、可回退
+5. 一个切片结束后，再进入下一个切片
+
+## 成功标准
+
+- 每个切片只解决一个逻辑问题
+- 每次切片完成后系统都是绿色状态
+- 没有把重构、功能、配置改动混成一团
+- 实现遵守简单优先和外科式修改原则
+
+## 相关原则
+
+- 简单优先，不为未来需求提前抽象
+- 只改当前任务需要的最小范围
+- 遇到失败先停下来验证，不继续堆代码
+
+## 与其他技能的衔接
+
+- 接在 `planning-and-task-breakdown` 之后
+- 与 `test-driven-development` 配合执行红绿重构
+- 每个切片结束后由 `verification-before-completion` 兜底验证

package/vendor/packages/toolkit/src/content/skills/incremental-implementation/meta.yaml

@@ -0,0 +1,20 @@
+kind: skill
+name: incremental-implementation
+title: 增量实现
+description: 以增量切片方式交付变更。适用于任何跨多个文件的功能或改动，通过实现、测试、验证、提交的薄切片循环保持系统始终可运行、可验证。
+tier: core
+audience: default
+stability: stable
+suggests:
+  - skill:engineering-principles
+platforms:
+  - qwen
+  - codex
+  - qoder
+source:
+  upstream: agent-skills
+  strategy: adapted
+  origin_name: incremental-implementation
+  origin_path: skills/incremental-implementation/SKILL.md
+  origin_id: skill:incremental-implementation
+  notes: 延续上游的单切片交付思想，并与本仓库 TDD 习惯对齐

package/vendor/packages/toolkit/src/content/skills/multi-perspective-review/body.md

@@ -0,0 +1,52 @@
+# 多视角评审
+
+## 何时使用
+
+- Spec 或 Plan 写完、实现还没开始时
+- 架构决策牵涉产品、工程、设计和开发体验多个面向时
+- 团队觉得方案“好像没问题”，但还没经过压力测试时
+- 需要尽早发现范围、体验或维护性盲区时
+
+## 输入前提
+
+- 已有可评审的规格、计划或方案草案
+- 愿意在实现前先暴露问题
+- 接受同一个方案需要经过多种视角拷问
+- 明确这里评审的是“计划态假设”，不是实现后的真实走查
+
+## 执行步骤
+
+1. 用 **产品视角** 检查是否在解决正确问题
+2. 用 **工程视角** 检查架构、状态、失败模式和测试策略
+3. 用 **设计视角** 检查交互、可用性、响应式和无障碍
+4. 用 **DevEx 视角** 检查计划中的集成成本、配置复杂度、文档前提、学习曲线和维护负担
+5. 把四个视角发现的问题改写成可执行的修订项、约束或验收标准
+6. 汇总结论，明确需要修订的点，再决定是否进入实现
+
+## 边界说明
+
+- 这里的 DevEx 只评估“实现前是否想清楚”，不替代实现后的真实安装和上手走查
+- 如果代码已经落地，需要确认 getting started、安装链和首次成功路径是否真的成立，转到 `developer-experience-audit`
+- 不要把这里当成发布前体验签收清单；它的价值是提前暴露盲点，而不是事后补测
+
+## 成功标准
+
+- 方案不再只从工程角度自证合理
+- 关键风险能在写代码前暴露
+- 每个视角都有具体 concern，而不是泛泛评价
+- DevEx 问题被表达为计划假设、约束或验收条件，而不是模糊感受
+- 最终结论可以明确是 `GO / REVISE / NO-GO`
+
+## 相关原则
+
+- 越早发现问题，修复成本越低
+- 单一视角的“没问题”不算通过
+- 评审输出必须能转化为具体修订动作
+- 计划态评审与实现后实测必须分相位处理
+
+## 与其他技能的衔接
+
+- 常接在 `spec-driven-development` 或 `planning-and-task-breakdown` 之后
+- 评审通过后再进入 `incremental-implementation`
+- 实现完成后，如需验证 DevEx 假设是否成立，继续进入 `developer-experience-audit`
+- 产品或架构争议较大时，可结合 `product-owner` 和 `architect`

package/vendor/packages/toolkit/src/content/skills/multi-perspective-review/meta.yaml

@@ -0,0 +1,18 @@
+kind: skill
+name: multi-perspective-review
+title: 多视角评审
+description: 在实现前从产品、工程、设计和开发者体验四个视角审视 Spec 或 Plan。适用于架构决策、跨团队变更或任何单一视角容易遗漏风险的场景，不替代实现后的真实 DevEx 实测。
+tier: recommended
+audience: advanced
+stability: stable
+suggests:
+  - skill:planning-and-task-breakdown
+  - skill:developer-experience-audit
+platforms:
+  - qwen
+  - codex
+  - qoder
+source:
+  upstream: toolkit-original
+  strategy: curated
+  notes: 本仓库为提升方案审视完整性补充的多视角评审能力；其中 DevEx 视角明确限定为实现前评审，真实落地后的体验审计由 developer-experience-audit 承担。