메뉴
技术方案 RFC 的自审 + 请求审阅的完整闭环。融入 14 维度自审清单 + 结构化审阅请求模板。 触发场景：(1) 用户说"自审"、"RFC"、"设计方案"、"design review"、"方案审阅"； (2) 完成技术方案设计后需要系统化验证； (3) 需要向用户/团队提交方案请求审阅。 不适用于：业务需求分析（用 prd-deep-review）、代码级 review（用 requesting-code-review）、 架构决策记录（用 decision-capture）。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work. In this repository, package or lane branches must close through package-first evidence and integration handoff rather than the generic local merge or PR menu.
Use when executing repo-wide or lane-scoped SDK changes in this repository that must follow bounded change packages, qiniu-ai worktree/package commands, evidence bundles, review packets, promotion decisions, and integration-branch handoff. Trigger on requests to open a phase package, spawn or integrate a lane, prepare a review handoff, or land multi-subsystem SDK work without widening scope.
Four-phase debugging framework that ensures root cause investigation before attempting fixes. Never jump to solutions.
Use when starting feature work that needs isolation from the current workspace or before executing implementation plans. In this repository, prefer qiniu-ai worktree commands for lane or package-first delivery; fall back to generic git worktree flows only for non-package branches.
Run verification commands and confirm output before claiming success
Use when you have a spec or requirements for a multi-step task, before touching code. In this repository, multi-subsystem or lane-scoped work must create the package brief first and keep the plan aligned with the bounded package contract.
| name | rfc-design-review |
| description | 技术方案 RFC 的自审 + 请求审阅的完整闭环。融入 14 维度自审清单 + 结构化审阅请求模板。 触发场景：(1) 用户说"自审"、"RFC"、"设计方案"、"design review"、"方案审阅"； (2) 完成技术方案设计后需要系统化验证； (3) 需要向用户/团队提交方案请求审阅。 不适用于：业务需求分析（用 prd-deep-review）、代码级 review（用 requesting-code-review）、 架构决策记录（用 decision-capture）。 |
技术方案 RFC 的自审与请求审阅闭环。
Phase 1: Self-Review（方案撰写完成后）
→ 按 14 维度逐项验证
→ 输出 self-review.md（通过/发现/待定）
Phase 2: Request Review（自审完成后）
→ 用结构化模板组织方案
→ 明标"请挑战这些决策"
→ 提交审阅
完成方案后，按 references/self-review-checklist.md 逐项回答。
输出格式：
## Self-Review: [方案名称]
### 总览
| 维度 | 状态 | 备注 |
|------|------|------|
| Problem | ✅ / ⚠️ / ❌ | ... |
| Current State | ... | ... |
| External Facts | ... | ... |
...
### 发现项
- [P0] ...
- [P1] ...
### 待定项
- ...
关键规则：
自审完成后，按 references/review-request-template.md 填充并提交审阅。
关键规则：
| Skill | 定位 | 边界 |
|---|---|---|
brainstorming | 需求探索 + 方案发散 | 在本 skill 之前 |
rfc-design-review | 方案自审 + 请求审阅 | 方案已成型，验证和提交 |
writing-plans | 拆解实现计划 | 审阅通过后 |
prd-deep-review | 业务需求分析 | 侧重用户视角和业务语言 |
decision-capture | 决策沉淀（ADR） | 方案确认后记录 |
requesting-code-review | 代码级 review | 实现完成后 |
| 反模式 | 正确做法 |
|---|---|
| 跳过自审直接请审 | 自审暴露的问题越多，审阅效率越高 |
| External Fact 无锚点 | 每条必须有文件:行号 或 URL |
| "类型存在"等于"能力生效" | grep 主链路证明消费路径 |
| Self-Review 全部写 ✅ | 至少有 2-3 个 ⚠️ 才是诚实的审查 |
| RFC 改完不重新自审 | 每轮修改后必须重跑受影响维度 |