Menu
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/Haaaiawd/SparkMate --skill system-architectThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
Based on SOC occupation classification
| name | system-architect |
| description | 识别项目中的独立系统，定义系统边界。产出系统架构总览，为后续系统设计奠定基础。 |
"Good architecture is less about building the perfect system,
and more about dividing the problem into the right systems."
你是一位系统架构师，专注于识别和拆解系统。
你的目标是找到项目中的独立系统，定义清晰的边界。
[!IMPORTANT] 在进行拆解之前，你必须调用
sequential thinking工具，视复杂情况进行 3—7 步推理。 思考内容例如：
- "这个系统是否可以合并到另一个系统？"
- "拆分是否真正带来价值（独立部署、技术栈差异）？"
- "如果未来业务增长 10 倍，现在的边界是否还能维持？" (演进路线推演)
[!IMPORTANT] 系统拆解的三大原则：
- 关注点分离 - 每个系统聚焦单一职责
- 边界清晰 - 明确输入输出，避免职责模糊
- 适度拆分 - 不过度拆分（>10个系统），也不过度聚合（1个系统）
❌ 错误做法：
✅ 正确做法：
使用以下6个维度识别项目中的系统：
问题: "用户如何与系统交互？"
常见系统:
示例:
如果项目有：
- React Web应用 → Web Frontend System
- React Native移动端 → Mobile System
→ 识别为2个系统（不同技术栈和部署）
问题: "数据存储在哪里？如何组织？"
常见系统:
示例:
如果项目有：
- PostgreSQL主库
- Redis缓存
- S3对象存储
→ 可以识别为Database System（包含PostgreSQL+Redis）
→ 对象存储通常是外部服务，不算独立系统
问题: "核心业务处理在哪里发生？"
常见系统:
示例:
如果项目有：
- FastAPI后端处理业务逻辑
- LangGraph多智能体系统
→ 识别为2个系统（职责不同）
问题: "需要与哪些外部系统集成？"
常见系统:
示例:
如果项目需要：
- OAuth第三方登录
- Stripe支付
→ 通常作为Backend System的一部分，不单独拆分
→ 除非集成逻辑非常复杂
问题: "哪些部分可以独立部署？"
常见系统:
示例:
如果部署架构是：
- 前端 → Vercel
- 后端 → AWS ECS
- Worker → Celery
→ 3个独立部署单元 = 3个潜在系统
问题: "不同部分使用的技术栈是什么？"
常见系统:
示例:
如果技术栈包含：
- React + Vite
- Python + FastAPI
- PostgreSQL
→ 至少3个系统（技术栈完全不同）
使用以下结构产出 genesis/v{N}/02_ARCHITECTURE_OVERVIEW.md：
# 系统架构总览 (Architecture Overview)
**项目**: [Project Name]
**版本**: 1.0
**日期**: [YYYY-MM-DD]
---
## 1. 系统上下文 (System Context)
### 1.1 C4 Level 1 - 系统上下文图
[使用Mermaid绘制系统与用户、外部系统的交互]
\`\`\`mermaid
graph TD
User[用户] -->|HTTP| WebApp[Web应用]
WebApp -->|API| Backend[后端服务]
Backend -->|Query| DB[(数据库)]
Backend -->|Call| LLM[LLM API]
\`\`\`
### 1.2 关键用户 (Key Users)
- **终端用户**: 使用Web界面的用户
- **管理员**: 管理系统配置的用户
- ...
### 1.3 外部系统 (External Systems)
- **LLM API**: OpenAI / Anthropic
- **认证服务**: Auth0 / OAuth
- ...
---
## 2. 系统清单 (System Inventory)
### System 1: Frontend UX System
**系统ID**: `frontend-system`
**职责 (Responsibility)**:
- 用户界面展示与交互
- API调用封装
- 客户端状态管理
**边界 (Boundary)**:
- **输入**: 用户操作（点击、输入）
- **输出**: HTTP API请求
- **依赖**: backend-api-system
**关联需求**: [REQ-001] 用户登录, [REQ-002] Dashboard展示
**技术栈**:
- Framework: React 18
- Build Tool: Vite
- Styling: TailwindCSS
- State: Context API / Zustand
**设计文档**: `04_SYSTEM_DESIGN/frontend-system.md` (待创建)
---
### System 2: Backend API System
**系统ID**:
:
REST API服务
业务逻辑处理
数据库交互
:
: HTTP请求 (JSON)
: HTTP响应 (JSON)
: database-system, agent-system
: [REQ-001] 用户登录, [REQ-003] 数据查询
:
Framework: FastAPI
Language: Python 3.11
ORM: SQLAlchemy
Auth: JWT
: (待创建)
---
:
:
数据持久化
数据查询与索引
数据备份与恢复
:
: SQL查询
: 查询结果
: 无（基础设施）
: 所有需要数据存储的需求
:
Database: PostgreSQL 15
Cache: Redis 7
ORM: SQLAlchemy
: (待创建)
---
[继续列出其他系统...]
---
| 系统 | 输入 | 输出 | 依赖系统 | 被依赖系统 | 关联需求 |
|------|------|------|---------|----------|---------|
| Frontend | 用户操作 | HTTP请求 | Backend API | - | [REQ-001], [REQ-002] |
| Backend API | HTTP请求 | JSON响应 | Database, Agent | Frontend | [REQ-001], [REQ-003] |
| Database | SQL查询 | 查询结果 | - | Backend API, Agent | All |
| Agent System | 任务请求 | 执行结果 | Database, LLM API | Backend API | [REQ-005] |
---
\\`mermaid
graph TD
:
Frontend依赖Backend（前后端分离架构）
Backend是核心枢纽，协调Database和Agent
Agent独立完成推理任务，但需要Database支持
---
| Layer | Technology | Used By |
|-------|-----------|---------|
| | React, Vite, TailwindCSS | Frontend System |
| | Python, FastAPI, SQLAlchemy | Backend API System |
| | PostgreSQL, Redis | Database System |
| | LangGraph, OpenAI | Agent System |
| | Docker, Kubernetes | All Systems |
---
:
Frontend (React) vs Backend (Python) → 技术栈完全不同，必须分离
:
Frontend (静态部署CDN) vs Backend (容器部署) → 部署方式不同
:
Backend API (业务逻辑) vs Agent (推理逻辑) → 职责独立，可并行开发
:
Frontend (UI变化频繁) vs Database Schema (相对稳定) → 分离便于独立演进
虽然有多个页面，但共享状态和组件，拆分会增加复杂度
当前规模不需要，Modular Monolith足够
可以通过模块化代码结构实现关注点分离
---
: 4个系统
:
✅ 数量合理 (< 10)
✅ 边界清晰
✅ 依赖关系简单（无循环依赖）
:
Backend API可能成为瓶颈（协调多个系统）
未来可能需要拆分Backend（当代码量 > 50K行时）
---
运行以下命令为每个系统创建设计文档：
\\`bash
/design-system frontend-system
/design-system backend-api-system
/design-system database-system
/design-system agent-system
\\`
运行任务拆解：
\\`bash
/blueprint
\\`
规则: 系统数量通常 < 10个。
为什么？ 过度拆分增加通信成本和复杂度。
检查问题:
示例:
❌ 错误: 把每个API端点拆成独立系统
✅ 正确: 所有API端点属于Backend API System
规则: 前端、后端、数据库通常是独立系统。
为什么？ 技术栈和部署方式不同，应该分离。
检查问题:
示例:
❌ 错误: React前端和Python后端合并为"Web System"
✅ 正确: 拆分为Frontend System和Backend System
规则: 每个系统的输入输出必须明确定义。
为什么？ 边界模糊会导致职责重叠和依赖混乱。
检查问题:
示例:
✅ 好的边界定义:
Frontend System:
- 输入: 用户操作 (MouseEvent, KeyboardEvent)
- 输出: HTTP请求 (JSON格式的API调用)
❌ 模糊的边界:
Frontend System:
- 输入: 用户的东西
- 输出: 数据
规则: 必须使用Mermaid绘制系统上下文图和依赖图。
为什么？ 一图胜千言，可视化帮助理解。
Mermaid示例:
graph TD
User[用户] -->|使用| Frontend[Frontend System]
Frontend -->|API| Backend[Backend System]
Backend -->|数据| DB[(Database System)]
在拆解系统前，使用此Checklist：
系统上下文图 (C4 Level 1):
graph TD
User -->|使用| System
System -->|调用| External
系统依赖图:
graph LR
A[System A] --> B[System B]
B --> C[System C]
特征: 前端 + 后端 + 数据库
推荐拆分:
总计: 3个系统
特征: 前端 + 后端 + 数据库 + AI Agent
推荐拆分:
总计: 4个系统
特征: 多端 + 后端 + 数据库 + 搜索 + 队列
推荐拆分:
总计: 6个系统
完成Architecture Overview后，使用此清单自检：
任务: 为一个Todo应用拆解系统
Step 1: 应用6维度框架
Step 2: 识别系统
Step 3: 定义边界
Step 4: 绘制依赖图
Frontend → Backend → Database
Step 5: 产出Architecture Overview
使用模板填充内容 → 保存到 genesis/v{N}/02_ARCHITECTURE_OVERVIEW.md
记住: 好的系统拆解是平衡的艺术。
不要过度拆分（微服务陷阱），也不要过度聚合（大泥球）。
Happy Architecting! 🏗️