[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MXHKPTSKQ8T76B8VYA9VKF":3,"skill-same:01M6MXHKPTSKQ8T76B8VYA9VKF":54},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":22,"linkOnly":23,"markdownContent":24,"markdownBody":25,"frontMatter":26,"refName":27,"commitSha":28,"skillDirectory":29,"forksCount":30,"repositoryHtmlUrl":31,"repositoryHomepageUrl":6,"ownerHtmlUrl":32,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":33,"install":34,"resources":47},"01M6MXHKPTSKQ8T76B8VYA9VKF","architecture-designer",null,"OpenLogos architecture-designer 方法论 Skill","miniidealab\u002Fopenlogos","miniidealab","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F4251156?v=4","01M6MX6BM454XESZCRPBQQHKRT","FredHuang","01M6MX6BR4417H4QA658D4GW9X",581,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Flogos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fworkbuddy-plugin-template\u002Fskills\u002Farchitecture-designer\u002FSKILL.md",[],[19,20,21],"architecture","designer","architecture designer","2026-11-10 10:12:30",false,"---\nname: \"architecture-designer\"\ndescription: \"OpenLogos architecture-designer 方法论 Skill\"\n---\n# Skill: Architecture Designer\n\n> 在逐场景的技术实现之前，建立项目的技术全局视图：系统架构、技术选型、部署约束和非功能性约束。完整部署方案由 `deployment-designer` Skill 在 Phase 3 Step 3 产出。\n\n## 触发条件\n\n- 用户要求设计技术架构、做技术选型或规划系统架构\n- 用户提到 \"Phase 3 Step 0\"、\"架构设计\"、\"技术方案\"\n- Phase 2 产品设计文档已完成，需要开始 Phase 3\n- 用户想要确定技术栈或部署约束\n\n## 核心能力\n\n1. 读取 Phase 1 需求文档和 Phase 2 产品设计文档，理解产品全貌\n2. 基于产品复杂度和场景特征，推荐适合的系统架构\n3. 为每项技术选型提供选型理由和替代方案对比\n4. 绘制系统架构图（Mermaid）和部署约束图\n5. 明确部署方案的输入边界：运行环境、依赖服务、部署目标、外部服务测试策略\n6. 更新 `logos-project.yaml` 的 `tech_stack` 字段\n\n## 与 Phase 1\u002F2 的衔接\n\n架构设计是 Phase 2（产品设计）到 Phase 3（技术实现）的桥梁。它的输入来自 Phase 1\u002F2，输出影响 Phase 3 所有后续步骤：\n\n| 输入（来自 Phase 1\u002F2） | 输出（影响 Phase 3 后续步骤） |\n|------------------------|------------------------------|\n| 场景清单和复杂度 | 系统边界划分 → 时序图的参与方 |\n| 非功能性需求（性能、安全） | 技术选型约束 → API 设计决策 |\n| 产品交互方式（Web\u002FMobile\u002FAPI） | 前端技术栈 → 原型实现方式 |\n| 数据量和访问模式 | 数据库选型 → DB 设计 |\n| 第三方服务依赖（支付、邮件等） | 集成方式 → 时序图中的外部参与方 |\n\n## 执行步骤\n\n### Step 1: 理解产品全貌\n\n读取以下文档，建立对项目的整体认知：\n\n- **需求文档**（Phase 1）：产品定位、核心场景、约束与边界\n- **产品设计文档**（Phase 2）：信息架构、页面结构、交互复杂度\n- **已有的 `logos-project.yaml`**：当前 `tech_stack` 中是否已有初始选型\n\n重点提取：\n- 核心场景数量和复杂度\n- 是否有实时性需求（WebSocket、SSE）\n- 是否有后台任务（定时任务、消息队列）\n- 第三方服务依赖清单\n- 用户规模预期\n\n### Step 2: 确定系统架构\n\n根据产品复杂度选择架构模式：\n\n**简单项目**（个人 SaaS、工具类产品）：\n- 单体架构 + 单数据库\n- 架构概要可以用一段文字 + 一张简图\n\n**中等项目**（团队 SaaS、多角色系统）：\n- 前后端分离 + 单体后端 + 单数据库\n- 可能需要对象存储、缓存等辅助服务\n\n**复杂项目**（多服务、高并发、多端）：\n- 微服务 \u002F 模块化单体\n- 需要详细的架构决策记录（ADR）\n\n**⚠️ Mermaid flowchart \u002F graph 语法安全（强制）**：\n- 节点标签默认使用 `ID[\"标签文本\"]`，尤其是标签包含 `\u002F`、`(`、`)`、`\u003C`、`>`、`:`、`#`、`{}`、`[]`、空格、中文、API 路径、端口、技术栈组合或 `\u003Cbr\u002F>` 时。\n- 正确：`PROXY[\"\u002Fvoice\u002Fapi 代理\"]`、`API[\"API Server\u003Cbr\u002F>Node.js\"]`、`DB[\"PostgreSQL :5432\"]`。\n- 错误：`PROXY[\u002Fvoice\u002Fapi 代理]`，因为 `[\u002F` 会被 Mermaid 解析为平行四边形形状语法，标签内再出现 `\u002F` 时容易导致解析失败。\n- 多行标签使用 `\u003Cbr\u002F>`，整段文本仍放在同一对双引号内：`API[\"HTTP API\u003Cbr\u002F>\u002Fvoice\u002Fapi\"]`。\n- 子图名称含空格、中文或特殊字符时必须加引号：`subgraph \"Voice Service\"`。\n- 只有明确需要 Mermaid 形状语义时才使用 `ID[(Database)]`、`ID[\u002FInput\u002F]` 等形状语法；普通说明文本不要借用形状语法。\n\n用 Mermaid 绘制系统架构图：\n\n```mermaid\ngraph TB\n    subgraph \"Frontend\"\n        Web[\"Web App - Next.js\"]\n    end\n    subgraph \"Backend\"\n        API[\"API Server - Node.js\"]\n        Worker[\"Background Worker\"]\n    end\n    subgraph \"Data\"\n        DB[\"PostgreSQL\"]\n        Cache[\"Redis\"]\n        S3[\"Object Storage\"]\n    end\n    subgraph \"External\"\n        Auth[\"Supabase Auth\"]\n        Email[\"SendGrid\"]\n    end\n\n    Web -->|REST API| API\n    API --> DB\n    API --> Cache\n    API --> S3\n    API --> Auth\n    Worker --> DB\n    Worker --> Email\n```\n\n### Step 3: 技术选型\n\n为每个技术维度给出选型和理由：\n\n```markdown\n| 维度 | 选型 | 理由 | 备选方案 |\n|------|------|------|---------|\n| 语言 | TypeScript | 前后端统一、类型安全 | Go（性能优先时） |\n| 前端框架 | Next.js 15 | SSR + RSC、生态成熟 | Astro（内容站）、Nuxt（Vue 生态） |\n| 后端框架 | Hono | 轻量、边缘优先、TS 原生 | Express（生态）、Fastify（性能） |\n| 数据库 | PostgreSQL | 功能丰富、JSONB、RLS | MySQL（简单场景） |\n| 认证 | Supabase Auth | 开箱即用、RLS 集成 | NextAuth（自托管） |\n| 部署约束 | Vercel + Supabase | 零运维、自动扩容 | AWS（自主控制） |\n```\n\n**注意**：本步骤只定义部署约束和部署目标，不写完整发布步骤。完整部署方案必须由 `deployment-designer` 输出到 `logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F3-deployment\u002F`。\n\n**选型原则**：\n- 优先选择团队已熟悉的技术\n- 在无明显差异时，选择社区更大的方案\n- 选型理由必须关联到具体的产品需求或约束\n\n### Step 4: 非功能性约束\n\n明确关键的非功能性要求：\n\n- **性能目标**：核心 API 响应时间、页面加载时间\n- **安全要求**：认证方式、数据加密、CORS 策略\n- **可扩展性**：预期用户规模、数据增长估算\n- **可观测性**：日志、监控、告警方案\n- **开发体验**：本地开发环境、CI\u002FCD 流程\n\n### Step 5: 外部依赖与测试策略\n\n梳理项目的所有外部服务依赖，为每个依赖确定编排测试阶段的隔离策略。此步骤的产出直接影响 Phase 3 Step 3（编排测试）能否顺利执行。\n\n1. 从架构图和时序图参与方中识别外部依赖（邮件、短信、验证码、支付、OAuth 等）\n2. 与用户确认每个依赖的测试策略\n\n可选的测试策略：\n\n| 策略 | 说明 | 典型场景 |\n|------|------|---------|\n| `test-api` | 测试环境提供后门 API | 邮件\u002F短信验证码 |\n| `fixed-value` | 特定测试数据使用固定值 | 测试手机号固定验证码 |\n| `env-disable` | 环境变量关闭该功能 | 图形验证码、滑块 |\n| `mock-callback` | 编排中主动调用模拟回调 | 支付回调、Webhook |\n| `mock-service` | 本地 mock 服务替代 | OAuth Provider |\n\n如果项目没有外部服务依赖（如纯 CLI 工具），可跳过此步骤。\n\n### Step 6: 更新 logos-project.yaml\n\n将确认的技术选型写入 `logos-project.yaml` 的 `tech_stack` 字段，将外部依赖和测试策略写入 `external_dependencies` 字段，确保后续所有 Skill 和 AI 工具都能读取到统一的技术栈和测试约定。\n\n```yaml\nexternal_dependencies:\n  - name: \"邮件服务\"\n    provider: \"SendGrid\"\n    used_in: [\"S01-用户注册\", \"S03-忘记密码\"]\n    test_strategy: \"test-api\"\n    test_config: \"GET \u002Fapi\u002Ftest\u002Flatest-email?to={email}\"\n```\n\n**同时根据技术选型填写 `skip_phases`**，告知 phase 检测逻辑跳过本模块不需要的阶段：\n\n| 项目类型 | 建议 skip_phases |\n|---------|----------------|\n| 标准 Web \u002F API 项目 | 不填（全走） |\n| 有本地数据库、无 HTTP API（SQLite 桌面应用、Electron） | `[api, scenario]` |\n| 无数据库、无 HTTP API（CLI 工具、前端库、纯计算工具） | `[api, database, scenario]` |\n| 有 HTTP API、无数据库（无状态代理服务） | `[database]` |\n\n```yaml\nmodules:\n  - id: core\n    name: 核心功能\n    lifecycle: initial\n    skip_phases: [api, scenario]   # 根据实际技术选型填写，无需跳过时删除此行\n```\n\n**判断依据**：\n- 无 HTTP API → skip `api` 和 `scenario`（API 编排测试依赖 HTTP API）\n- 无任何数据库 → skip `database`\n- 有 SQLite \u002F 本地数据库 → 保留 `database`（仍需设计 schema）\n\n### Step 7: 交接部署方案设计\n\n架构设计完成后，必须向后续 `deployment-designer` Skill 交接以下信息：\n\n- 技术栈：语言、框架、数据库、运行时、包管理器\n- 部署目标：本地、测试、预发、生产中的哪些环境需要覆盖\n- 运行依赖：数据库、缓存、对象存储、第三方服务、消息队列\n- 配置与密钥来源：环境变量、密钥管理方式、不可提交配置\n- 数据迁移方式：迁移工具、初始化数据、回滚要求\n- 健康检查入口：页面、API、CLI 命令或进程检查方式\n- smoke 设计输入：部署后必须验证的最小核心链路\n\n交接完成后，建议下一步提示：\n\n```text\n继续进入 Phase 3 Step 3：使用 deployment-designer 输出部署方案和 smoke 测试方案。\n```\n\n## 输出规范\n\n- 架构概要文档：`logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F1-architecture\u002Fcore-01-architecture-overview.md`（架构文件全局唯一，后续修改始终在此文件上更新，不新建文件）\n- 架构图使用 Mermaid 格式\n- 技术选型使用表格格式，每项必须有理由\n- 更新 `logos-project.yaml` 的 `tech_stack` 和 `external_dependencies` 字段\n- 如项目确定无需部署，必须在架构文档中说明原因，并建议在 `logos-project.yaml` 中设置对应模块的 `deployment_required: false`\n- 简单项目允许精简输出（不强制所有章节）\n\n## 实践经验\n\n- **不要过度设计**：独立开发者做 SaaS，单体 + PostgreSQL + Vercel 够用就行，不要上来就微服务\n- **选型理由比选型本身重要**：写清楚\"为什么选 X\"比\"选了 X\"更有价值，因为项目演进时需要重新评估\n- **架构图是时序图的前提**：架构图中的系统组件就是后续时序图的参与方，两者必须一致\n- **tech_stack 是 AI 的锚**：后续 AI 生成代码时会读取 `logos-project.yaml` 的 `tech_stack`，选型不准确会导致生成的代码无法使用\n- **非功能性约束宁可先宽后紧**：初期不要定太严格的性能目标，随着实际数据再收紧\n- **测试策略必须在架构阶段决定**：验证码、支付等外部依赖的测试方案如果等到编排测试时才想，往往发现没有预留后门 API，导致编排测试无法全自动执行\n\n## 推荐提示词\n\n以下提示词可以直接复制给 AI 使用：\n\n- `帮我设计技术架构`\n- `基于产品设计帮我做技术选型`\n- `帮我画系统架构图`\n- `帮我确定技术栈并更新 logos-project.yaml`\n\n## ⚠️ 收尾步骤（强制）：更新 resource_index\n\n完成本 Skill 的所有文档产出后，**必须**：\n\n1. 将架构文档追加写入 `logos\u002Flogos-project.yaml` 的 `resource_index`：\n\n```yaml\nresource_index:\n  # ...已有条目...\n  - path: logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F1-architecture\u002F\u003C文件名>.md\n    desc: 系统架构概要。涉及技术栈选型、系统组件划分、非功能性约束时必读。\n```\n\n2. 同步更新 `logos\u002Flogos-project.yaml` 的 `tech_stack` 和 `external_dependencies` 字段（这是本 Skill 的核心产出之一）。\n\n3. **（强制）梳理并预写入场景清单**：\n\n   根据架构文档、需求文档和产品设计文档，整理出本项目的完整核心业务场景列表，向用户逐一确认后，将其写入 `logos\u002Flogos-project.yaml` 的 `scenarios` 字段：\n\n   ```yaml\n   scenarios:\n     - id: S01\n       name: \u003C场景名称>\n     - id: S02\n       name: \u003C场景名称>\n     # ...\n   ```\n\n   **确认要点**：\n   - 场景清单是否覆盖了所有核心用户旅程？\n   - 是否有遗漏的边界场景或管理后台场景？\n   - 场景编号是否按业务优先级排序？\n\n   此步骤产出的 `scenarios` 字段将作为 `scenario-architect` Skill 的输入基础，直接影响后续阶段的完成判断。**若此步骤跳过，`scenario-architect` Skill 开始时将强制要求补填。**\n\n**不执行收尾步骤将导致后续 AI 在场景建模和代码生成时无法读取架构决策，产生技术栈不一致的代码。**\n","# Skill: Architecture Designer\n\n> 在逐场景的技术实现之前，建立项目的技术全局视图：系统架构、技术选型、部署约束和非功能性约束。完整部署方案由 `deployment-designer` Skill 在 Phase 3 Step 3 产出。\n\n## 触发条件\n\n- 用户要求设计技术架构、做技术选型或规划系统架构\n- 用户提到 \"Phase 3 Step 0\"、\"架构设计\"、\"技术方案\"\n- Phase 2 产品设计文档已完成，需要开始 Phase 3\n- 用户想要确定技术栈或部署约束\n\n## 核心能力\n\n1. 读取 Phase 1 需求文档和 Phase 2 产品设计文档，理解产品全貌\n2. 基于产品复杂度和场景特征，推荐适合的系统架构\n3. 为每项技术选型提供选型理由和替代方案对比\n4. 绘制系统架构图（Mermaid）和部署约束图\n5. 明确部署方案的输入边界：运行环境、依赖服务、部署目标、外部服务测试策略\n6. 更新 `logos-project.yaml` 的 `tech_stack` 字段\n\n## 与 Phase 1\u002F2 的衔接\n\n架构设计是 Phase 2（产品设计）到 Phase 3（技术实现）的桥梁。它的输入来自 Phase 1\u002F2，输出影响 Phase 3 所有后续步骤：\n\n| 输入（来自 Phase 1\u002F2） | 输出（影响 Phase 3 后续步骤） |\n|------------------------|------------------------------|\n| 场景清单和复杂度 | 系统边界划分 → 时序图的参与方 |\n| 非功能性需求（性能、安全） | 技术选型约束 → API 设计决策 |\n| 产品交互方式（Web\u002FMobile\u002FAPI） | 前端技术栈 → 原型实现方式 |\n| 数据量和访问模式 | 数据库选型 → DB 设计 |\n| 第三方服务依赖（支付、邮件等） | 集成方式 → 时序图中的外部参与方 |\n\n## 执行步骤\n\n### Step 1: 理解产品全貌\n\n读取以下文档，建立对项目的整体认知：\n\n- **需求文档**（Phase 1）：产品定位、核心场景、约束与边界\n- **产品设计文档**（Phase 2）：信息架构、页面结构、交互复杂度\n- **已有的 `logos-project.yaml`**：当前 `tech_stack` 中是否已有初始选型\n\n重点提取：\n- 核心场景数量和复杂度\n- 是否有实时性需求（WebSocket、SSE）\n- 是否有后台任务（定时任务、消息队列）\n- 第三方服务依赖清单\n- 用户规模预期\n\n### Step 2: 确定系统架构\n\n根据产品复杂度选择架构模式：\n\n**简单项目**（个人 SaaS、工具类产品）：\n- 单体架构 + 单数据库\n- 架构概要可以用一段文字 + 一张简图\n\n**中等项目**（团队 SaaS、多角色系统）：\n- 前后端分离 + 单体后端 + 单数据库\n- 可能需要对象存储、缓存等辅助服务\n\n**复杂项目**（多服务、高并发、多端）：\n- 微服务 \u002F 模块化单体\n- 需要详细的架构决策记录（ADR）\n\n**⚠️ Mermaid flowchart \u002F graph 语法安全（强制）**：\n- 节点标签默认使用 `ID[\"标签文本\"]`，尤其是标签包含 `\u002F`、`(`、`)`、`\u003C`、`>`、`:`、`#`、`{}`、`[]`、空格、中文、API 路径、端口、技术栈组合或 `\u003Cbr\u002F>` 时。\n- 正确：`PROXY[\"\u002Fvoice\u002Fapi 代理\"]`、`API[\"API Server\u003Cbr\u002F>Node.js\"]`、`DB[\"PostgreSQL :5432\"]`。\n- 错误：`PROXY[\u002Fvoice\u002Fapi 代理]`，因为 `[\u002F` 会被 Mermaid 解析为平行四边形形状语法，标签内再出现 `\u002F` 时容易导致解析失败。\n- 多行标签使用 `\u003Cbr\u002F>`，整段文本仍放在同一对双引号内：`API[\"HTTP API\u003Cbr\u002F>\u002Fvoice\u002Fapi\"]`。\n- 子图名称含空格、中文或特殊字符时必须加引号：`subgraph \"Voice Service\"`。\n- 只有明确需要 Mermaid 形状语义时才使用 `ID[(Database)]`、`ID[\u002FInput\u002F]` 等形状语法；普通说明文本不要借用形状语法。\n\n用 Mermaid 绘制系统架构图：\n\n```mermaid\ngraph TB\n    subgraph \"Frontend\"\n        Web[\"Web App - Next.js\"]\n    end\n    subgraph \"Backend\"\n        API[\"API Server - Node.js\"]\n        Worker[\"Background Worker\"]\n    end\n    subgraph \"Data\"\n        DB[\"PostgreSQL\"]\n        Cache[\"Redis\"]\n        S3[\"Object Storage\"]\n    end\n    subgraph \"External\"\n        Auth[\"Supabase Auth\"]\n        Email[\"SendGrid\"]\n    end\n\n    Web -->|REST API| API\n    API --> DB\n    API --> Cache\n    API --> S3\n    API --> Auth\n    Worker --> DB\n    Worker --> Email\n```\n\n### Step 3: 技术选型\n\n为每个技术维度给出选型和理由：\n\n```markdown\n| 维度 | 选型 | 理由 | 备选方案 |\n|------|------|------|---------|\n| 语言 | TypeScript | 前后端统一、类型安全 | Go（性能优先时） |\n| 前端框架 | Next.js 15 | SSR + RSC、生态成熟 | Astro（内容站）、Nuxt（Vue 生态） |\n| 后端框架 | Hono | 轻量、边缘优先、TS 原生 | Express（生态）、Fastify（性能） |\n| 数据库 | PostgreSQL | 功能丰富、JSONB、RLS | MySQL（简单场景） |\n| 认证 | Supabase Auth | 开箱即用、RLS 集成 | NextAuth（自托管） |\n| 部署约束 | Vercel + Supabase | 零运维、自动扩容 | AWS（自主控制） |\n```\n\n**注意**：本步骤只定义部署约束和部署目标，不写完整发布步骤。完整部署方案必须由 `deployment-designer` 输出到 `logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F3-deployment\u002F`。\n\n**选型原则**：\n- 优先选择团队已熟悉的技术\n- 在无明显差异时，选择社区更大的方案\n- 选型理由必须关联到具体的产品需求或约束\n\n### Step 4: 非功能性约束\n\n明确关键的非功能性要求：\n\n- **性能目标**：核心 API 响应时间、页面加载时间\n- **安全要求**：认证方式、数据加密、CORS 策略\n- **可扩展性**：预期用户规模、数据增长估算\n- **可观测性**：日志、监控、告警方案\n- **开发体验**：本地开发环境、CI\u002FCD 流程\n\n### Step 5: 外部依赖与测试策略\n\n梳理项目的所有外部服务依赖，为每个依赖确定编排测试阶段的隔离策略。此步骤的产出直接影响 Phase 3 Step 3（编排测试）能否顺利执行。\n\n1. 从架构图和时序图参与方中识别外部依赖（邮件、短信、验证码、支付、OAuth 等）\n2. 与用户确认每个依赖的测试策略\n\n可选的测试策略：\n\n| 策略 | 说明 | 典型场景 |\n|------|------|---------|\n| `test-api` | 测试环境提供后门 API | 邮件\u002F短信验证码 |\n| `fixed-value` | 特定测试数据使用固定值 | 测试手机号固定验证码 |\n| `env-disable` | 环境变量关闭该功能 | 图形验证码、滑块 |\n| `mock-callback` | 编排中主动调用模拟回调 | 支付回调、Webhook |\n| `mock-service` | 本地 mock 服务替代 | OAuth Provider |\n\n如果项目没有外部服务依赖（如纯 CLI 工具），可跳过此步骤。\n\n### Step 6: 更新 logos-project.yaml\n\n将确认的技术选型写入 `logos-project.yaml` 的 `tech_stack` 字段，将外部依赖和测试策略写入 `external_dependencies` 字段，确保后续所有 Skill 和 AI 工具都能读取到统一的技术栈和测试约定。\n\n```yaml\nexternal_dependencies:\n  - name: \"邮件服务\"\n    provider: \"SendGrid\"\n    used_in: [\"S01-用户注册\", \"S03-忘记密码\"]\n    test_strategy: \"test-api\"\n    test_config: \"GET \u002Fapi\u002Ftest\u002Flatest-email?to={email}\"\n```\n\n**同时根据技术选型填写 `skip_phases`**，告知 phase 检测逻辑跳过本模块不需要的阶段：\n\n| 项目类型 | 建议 skip_phases |\n|---------|----------------|\n| 标准 Web \u002F API 项目 | 不填（全走） |\n| 有本地数据库、无 HTTP API（SQLite 桌面应用、Electron） | `[api, scenario]` |\n| 无数据库、无 HTTP API（CLI 工具、前端库、纯计算工具） | `[api, database, scenario]` |\n| 有 HTTP API、无数据库（无状态代理服务） | `[database]` |\n\n```yaml\nmodules:\n  - id: core\n    name: 核心功能\n    lifecycle: initial\n    skip_phases: [api, scenario]   # 根据实际技术选型填写，无需跳过时删除此行\n```\n\n**判断依据**：\n- 无 HTTP API → skip `api` 和 `scenario`（API 编排测试依赖 HTTP API）\n- 无任何数据库 → skip `database`\n- 有 SQLite \u002F 本地数据库 → 保留 `database`（仍需设计 schema）\n\n### Step 7: 交接部署方案设计\n\n架构设计完成后，必须向后续 `deployment-designer` Skill 交接以下信息：\n\n- 技术栈：语言、框架、数据库、运行时、包管理器\n- 部署目标：本地、测试、预发、生产中的哪些环境需要覆盖\n- 运行依赖：数据库、缓存、对象存储、第三方服务、消息队列\n- 配置与密钥来源：环境变量、密钥管理方式、不可提交配置\n- 数据迁移方式：迁移工具、初始化数据、回滚要求\n- 健康检查入口：页面、API、CLI 命令或进程检查方式\n- smoke 设计输入：部署后必须验证的最小核心链路\n\n交接完成后，建议下一步提示：\n\n```text\n继续进入 Phase 3 Step 3：使用 deployment-designer 输出部署方案和 smoke 测试方案。\n```\n\n## 输出规范\n\n- 架构概要文档：`logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F1-architecture\u002Fcore-01-architecture-overview.md`（架构文件全局唯一，后续修改始终在此文件上更新，不新建文件）\n- 架构图使用 Mermaid 格式\n- 技术选型使用表格格式，每项必须有理由\n- 更新 `logos-project.yaml` 的 `tech_stack` 和 `external_dependencies` 字段\n- 如项目确定无需部署，必须在架构文档中说明原因，并建议在 `logos-project.yaml` 中设置对应模块的 `deployment_required: false`\n- 简单项目允许精简输出（不强制所有章节）\n\n## 实践经验\n\n- **不要过度设计**：独立开发者做 SaaS，单体 + PostgreSQL + Vercel 够用就行，不要上来就微服务\n- **选型理由比选型本身重要**：写清楚\"为什么选 X\"比\"选了 X\"更有价值，因为项目演进时需要重新评估\n- **架构图是时序图的前提**：架构图中的系统组件就是后续时序图的参与方，两者必须一致\n- **tech_stack 是 AI 的锚**：后续 AI 生成代码时会读取 `logos-project.yaml` 的 `tech_stack`，选型不准确会导致生成的代码无法使用\n- **非功能性约束宁可先宽后紧**：初期不要定太严格的性能目标，随着实际数据再收紧\n- **测试策略必须在架构阶段决定**：验证码、支付等外部依赖的测试方案如果等到编排测试时才想，往往发现没有预留后门 API，导致编排测试无法全自动执行\n\n## 推荐提示词\n\n以下提示词可以直接复制给 AI 使用：\n\n- `帮我设计技术架构`\n- `基于产品设计帮我做技术选型`\n- `帮我画系统架构图`\n- `帮我确定技术栈并更新 logos-project.yaml`\n\n## ⚠️ 收尾步骤（强制）：更新 resource_index\n\n完成本 Skill 的所有文档产出后，**必须**：\n\n1. 将架构文档追加写入 `logos\u002Flogos-project.yaml` 的 `resource_index`：\n\n```yaml\nresource_index:\n  # ...已有条目...\n  - path: logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F1-architecture\u002F\u003C文件名>.md\n    desc: 系统架构概要。涉及技术栈选型、系统组件划分、非功能性约束时必读。\n```\n\n2. 同步更新 `logos\u002Flogos-project.yaml` 的 `tech_stack` 和 `external_dependencies` 字段（这是本 Skill 的核心产出之一）。\n\n3. **（强制）梳理并预写入场景清单**：\n\n   根据架构文档、需求文档和产品设计文档，整理出本项目的完整核心业务场景列表，向用户逐一确认后，将其写入 `logos\u002Flogos-project.yaml` 的 `scenarios` 字段：\n\n   ```yaml\n   scenarios:\n     - id: S01\n       name: \u003C场景名称>\n     - id: S02\n       name: \u003C场景名称>\n     # ...\n   ```\n\n   **确认要点**：\n   - 场景清单是否覆盖了所有核心用户旅程？\n   - 是否有遗漏的边界场景或管理后台场景？\n   - 场景编号是否按业务优先级排序？\n\n   此步骤产出的 `scenarios` 字段将作为 `scenario-architect` Skill 的输入基础，直接影响后续阶段的完成判断。**若此步骤跳过，`scenario-architect` Skill 开始时将强制要求补填。**\n\n**不执行收尾步骤将导致后续 AI 在场景建模和代码生成时无法读取架构决策，产生技术栈不一致的代码。**\n",{"name":5,"description":7},"master","abf55fdedadaeb660f928aa7258b9ec35d4ab003","logos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fworkbuddy-plugin-template\u002Fskills\u002Farchitecture-designer",9,"https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos","https:\u002F\u002Fgithub.com\u002Fminiidealab","2026-10-18 11:36:11",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add miniidealab\u002Fopenlogos --skill architecture-designer",{"tool":40,"command":41},"bunx","bunx skills add miniidealab\u002Fopenlogos --skill architecture-designer",{"tool":43,"command":44},"pnpm","pnpm dlx skills add miniidealab\u002Fopenlogos --skill architecture-designer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Flogos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fworkbuddy-plugin-template\u002Fskills\u002Farchitecture-designer\u002FSKILL.md",true,[48],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"SKILL.en.md","REFERENCE","参考文档",10130,"https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Flogos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fworkbuddy-plugin-template\u002Fskills\u002Farchitecture-designer\u002FSKILL.en.md",[55,101,113,122,130,139],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":80,"publishedAt":22},"01M6MXX45142DGRFD9ZYPT5YC9","ui-ux-pro-max","UI\u002FUX design intelligence. 67 styles, 96 palettes, 57 font pairings, 25 charts, 13 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn\u002Fui). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI\u002FUX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient. Integrations: shadcn\u002Fui MCP for component search and examples.","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fui-ux-pro-max\u002FSKILL.md",[61,66,69,72,77],{"categoryNo":62,"categoryName":63,"taxonomyType":64,"taxonomyTypeDesc":65},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":67,"categoryName":68,"taxonomyType":64,"taxonomyTypeDesc":65},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":70,"categoryName":71,"taxonomyType":64,"taxonomyTypeDesc":65},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":78,"categoryName":79,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000033","数据分析师",[81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100],"ui ux","pro","max","ui ux pro max","ui","ux","projects","mode","card","app","tsx","fix","improve","Tailwind","Charts","Animation","design","actions","MCP","search",{"skillNo":102,"name":103,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":109,"publishedAt":22},"01M6MXWY8HJV93BBR8FPNJXAMV","test-writer","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-writer\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":64,"taxonomyTypeDesc":65},"01JBSEEDCAT000000000000008","测试与质量",[110,111,112],"writer","test writer","test",{"skillNo":114,"name":115,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":119,"publishedAt":22},"01M6MXWSAMN9AD3T8F6N099ZGY","test-orchestrator","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-orchestrator\u002FSKILL.md",[118],{"categoryNo":107,"categoryName":108,"taxonomyType":64,"taxonomyTypeDesc":65},[120,121,112],"orchestrator","test orchestrator",{"skillNo":123,"name":124,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":22},"01M6MXWN29FY7K9ASMFRSPWQCN","slice-planner","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fslice-planner\u002FSKILL.md",[],[128,129],"slice planner","planner",{"skillNo":131,"name":132,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":22},"01M6MXWFR1C1V66NSRTAM1FZPR","scenario-architect","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fscenario-architect\u002FSKILL.md",[],[136,137,138],"architect","scenario","scenario architect",{"skillNo":140,"name":141,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":22},"01M6MXWD6ZCGPT4FDT580S8K96","project-init","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fproject-init\u002FSKILL.md",[],[145,146,147],"project init","init","project"]