architecture
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese/architecture
/architecture
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Create an Architecture Decision Record (ADR) or evaluate a system design.
如果你看到不熟悉的占位符或需要查看已连接的工具，请参阅CONNECTORS.md。
创建架构决策记录（ADR）或评估系统设计。
Usage
用法
/architecture $ARGUMENTS/architecture $ARGUMENTSModes
模式
Create an ADR: "Should we use Kafka or SQS for our event bus?"
Evaluate a design: "Review this microservices proposal"
System design: "Design the notification system for our app"
See the system-design skill for detailed frameworks on requirements gathering, scalability analysis, and trade-off evaluation.
创建ADR："我们应该为事件总线使用Kafka还是SQS？"
评估设计："评审这个微服务提案"
系统设计："为我们的应用设计通知系统"
如需了解需求收集、可扩展性分析和权衡评估的详细框架，请查看system-design技能。
Output — ADR Format
输出 — ADR格式
markdown
undefinedmarkdown
undefinedADR-[number]: [Title]
ADR-[number]: [Title]
Status: Proposed | Accepted | Deprecated | Superseded
Date: [Date]
Deciders: [Who needs to sign off]
状态: 提议中 | 已接受 | 已弃用 | 已取代
日期: [Date]
决策者: [需要签字确认的人员]
Context
背景
[What is the situation? What forces are at play?]
[当前情况是什么？存在哪些影响因素？]
Decision
决策
[What is the change we're proposing?]
[我们提议做出什么改变？]
Options Considered
考虑的选项
Option A: [Name]
选项A: [名称]
| Dimension | Assessment |
|---|---|
| Complexity | [Low/Med/High] |
| Cost | [Assessment] |
| Scalability | [Assessment] |
| Team familiarity | [Assessment] |
Pros: [List]
Cons: [List]
| 维度 | 评估 |
|---|---|
| 复杂度 | [低/中/高] |
| 成本 | [评估结果] |
| 可扩展性 | [评估结果] |
| 团队熟悉度 | [评估结果] |
优点: [列表]
缺点: [列表]
Option B: [Name]
选项B: [名称]
[Same format]
[相同格式]
Trade-off Analysis
权衡分析
[Key trade-offs between options with clear reasoning]
[选项之间的关键权衡及明确理由]
Consequences
影响
- [What becomes easier]
- [What becomes harder]
- [What we'll need to revisit]
- [哪些事情会变得更简单]
- [哪些事情会变得更困难]
- [我们需要重新审视的内容]
Action Items
行动项
- [Implementation step]
- [Follow-up]
undefined- [实施步骤]
- [跟进事项]
undefinedIf Connectors Available
当连接器可用时
If ~~knowledge base is connected:
- Search for prior ADRs and design docs
- Find relevant technical context
If ~~project tracker is connected:
- Link to related epics and tickets
- Create implementation tasks
如果已连接知识库：
- 搜索过往的ADR和设计文档
- 查找相关技术背景
如果已连接项目追踪工具：
- 关联相关的史诗和工单
- 创建实施任务
Tips
提示
- State constraints upfront — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer.
- Name your options — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives.
- Include non-functional requirements — Latency, cost, team expertise, and maintenance burden matter as much as features.
- 提前说明约束条件 — "我们需要在2周内交付"或"必须支持10K rps"会影响回答的方向。
- 为你的选项命名 — 即使你倾向于某一个选项，明确列出替代方案会让我给出更均衡的分析。
- 包含非功能性需求 — 延迟、成本、团队专业知识和维护负担与功能需求同样重要。