菜单
系统架构决策与设计文档：Design Doc（含 Alternatives Considered 强制段）、ADR、结构影响分析。用于多模块、存量系统改造、共享边界、高风险集成、重大技术选型。不管前端技术栈和视觉表达（那是 frontend-design-research 的事）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
前端代码生成前或评审时的反 slop 硬门禁。扫十条作者硬判断的视觉红线——Inter 字体、紫/蓝 AI 渐变（Lila Ban）、3 列等宽卡片、纯黑
阶段 2 试吃——对 4-5 个该领域设计优秀的真实网站跑六维机械拆解（形 / 色 / 字 / 构 / 质 / 动），综合成本项目 design.md 初稿。六维是上位骨架，DOM 量化工作流 + 动效采访 5 类是落地肌肉。每次一站，保护上下文。不做前轮/后轮深度采访（那是 frontend-interview-dualround）、不做视觉锚定三件套（那是 frontend-visual-reference）、不写最终交付的 design.md（那是 frontend-design-writer）、不做组件库 / 动效资产库选型（那部分由 frontend-design-writer 的 §11 Resources 段 + 项目级 components.json 决定）。触发：新项目六维调研、整站重做、前端方向大迭代。
代码已经跑起来后（阶段 7 迭代微调）的设计评审横切——用户看到具体页面涌现审美反馈时使用：三段式追问（定位→对标→量化）把"感觉不对"翻译成可执行改动项，"选择题化"让用户做选择题而不是填空题，参数外显 Tweaks 让不确定的参数暴露成可调旋钮，所有修正反写回 design.md。覆盖 design-review（视觉对标）、design-content（文案与信息层级）、design-harden（边缘状态加固）三种子模式。**仅用于代码已生成后**——代码前的"感觉"引导走 frontend-interview-dualround 的后轮采访；纯调研走 frontend-design-research；写 design.md 走 frontend-design-writer。
阶段 1-7 持续维护的 design.md 主写手——把调研（六维试吃）+ 双轮深度采访 + 视觉锚定三件套 + 动效实现 prompt 集全部压缩为 Agent 可执行的设计契约。kun 版 15 段三轮写作顺序（原 12 段 + 新增 §12 Moodboard Prompt / §13 Page Mockup Prompt / §14 Motion Prompts 三段视觉锚定引用）。同时维护 DESIGN-LANGUAGE.md（低频）+ design.md（高频）+ MOTION-SPEC.md（中频）三份。不用于调研本身（那是 frontend-design-research）、不用于从零搭 knowledge/ 骨架（那是 req-suite:project-spec）、不用于单 token 微调（直接编辑即可）、不用于生成微观动效实现 prompt（那是 frontend-motion-prompt-writer）。
前端国际化（i18n）的综合规划与执行指南——做国际性网站、多语言架构、补多语言、翻译质量验证、字体跨语言统一、路由 / SEO / 字符串提取 / 动态切换等 i18n 相关任务时用。本 skill 按"运行时 / 翻译内容 / 视觉"三层正交模型路由：先定位用户的 i18n 痛点在哪一层，再走对应决策流；翻译内容层默认走三段流水线（机翻 → AI 本地人审 → 人工兜底）+ subagent 并行化（locale × persona × domain）。触发：用户说"做国际性网站""加多语言""补英文版""做 i18n""多语言网站的 SEO""路由用子路径还是子域名""本地化翻译""文化陷阱""AI 扮演当地人审翻译""字体跨语言不统一""语言切换器怎么做""字符串提取"。不用于纯单语言产品（没有国际化意图的就别套）、不用于纯翻译任务不涉及前端（那是纯文案）、不用于 RTL 排版深度实现（附录里有清单但不是本 skill 主场，目标市场不含中东时直接跳过）。
产品设计师视角的双轮深度采访横切——前轮（阶段 1 需求后）建产品边界 + 主语言收敛，后轮（阶段 3 Moodboard 选定后）拔架构 + section + 文案调性 + 交互路径。五类引导式提问：前轮是定位/用户/反向/资源/时间；后轮是架构/section/文案调性/交互路径/反向细节。角色显式从"前端设计师"切到"产品设计师"，选择题优先+开放题兜底，一次问 3-5 个不批量甩 20 个。产出反写回 design.md。触发：新项目启动 brief 模糊、六维调研完成但未定稿、用户说"帮我问清楚这个产品""我脑子里有个想法但说不清"。不用于代码后纠偏（那是 frontend-design-review 的三段式追问）、不用于需求判定机械门禁（那是 req-suite:requirement-clarifier）。
| name | system-design |
| description | 系统架构决策与设计文档：Design Doc（含 Alternatives Considered 强制段）、ADR、结构影响分析。用于多模块、存量系统改造、共享边界、高风险集成、重大技术选型。不管前端技术栈和视觉表达（那是 frontend-design-research 的事）。 |
本技能处理"系统怎么切"的问题：模块边界、数据流向、存储选型、API 契约、依赖拓扑、扩展点。
核心方法论：Alternatives Considered 强制 + trade-off 诚实。没有 alternatives 段的 Design Doc 是推销文档，不是设计文档。
req-suite:project-spec 路由过来frontend-design-researchfrontend-design-research从 req-suite:project-spec 获取：
knowledge/product-specs/PRODUCT-BRIEF.md（目标结果 + 非目标）knowledge/references/research-*.md（调研结果，如有）1. 结构影响分析 → 2. Design Doc / ADR → 3. 更新 ARCHITECTURE.md
回答这些问题：
根据决策规模选用：
核心段（按社区最佳实践）：
| 段 | 写什么 | 质量标准 |
|---|---|---|
| Context | 背景事实 + 相关链接，不写观点 | 3-5 行，读完知道为什么在讨论这件事 |
| Goals / Non-goals | 要达成什么、明确不追求什么 | 可验证的 bullet 列表 |
| Proposed Design | 方案概述 + 关键架构图 | Agent 读完能开始实现 |
| Alternatives Considered | 考虑过的其他方案 + 每个的 trade-off | 这是核心。没有这段的 doc 是推销文档 |
| Risks & Mitigations | 已知风险和应对 | 每条 risk 有对应 mitigation |
| Success Criteria | 怎么判断方案成功 | 可测量、可验证 |
规模：1-3 页小方案，5-10 页大方案。超过 10 页说明该拆。
产出写入 knowledge/design-docs/DESIGN-DOC-[标题].md。
适用于具体技术选择、配置决策、依赖选型。
# ADR-NNN: [决策标题]
## Status
Proposed | Accepted | Superseded by ADR-NNN | Deprecated
## Context
[驱动这个决策的背景力量、约束、需求]
## Decision
[选了什么、怎么做]
## Consequences
[好的后果 + 坏的后果 + trade-off]
一个文件一个决策，不合并。不修改已 Accepted 的 ADR，用新 ADR 替代。
产出写入 knowledge/design-docs/ADR-NNN-[标题].md。
将稳定的结构事实写入项目根的 ARCHITECTURE.md（不是 knowledge/ 下的）：模块拓扑、关键依赖、数据流向。只写事实，不写决策理由（理由住在 Design Doc / ADR 里）。
两个 skill 是正交子域，不是上下层：
| 本 skill 管 | frontend-design-research 管 |
|---|---|
| 模块边界、数据流、存储、API 契约 | 主语言、参考案例、动效采访、视觉 token |
| 依赖拓扑、扩展点 | 前端技术栈（框架/路由/状态/构建） |
| 跨层集成协议 | 组件库路由、动效资产库 |
边界冲突裁决：
| 触发 | 知识库条目 | 路径 |
|---|---|---|
| 结构影响分析 | 架构分层思考框架 | ~/note/01-AI工程/项目方案方法/架构分层思考框架.md |
| 多方案对比 | 方案对比指南 | ~/note/01-AI工程/项目方案方法/方案对比指南.md |
| 上游方法论 | req-project-spec 方法论 | ~/note/01-AI工程/Agent系统/方法/02-需求与项目方案/从需求到项目方案：req-project-spec 方法论.md |