Menu
当用户需要系统架构设计、技术选型或架构评审时使用此技能。触发关键词：系统设计、架构方案、技术选型、微服务、分布式系统、高可用、扩展性、CAP定理、架构权衡、重构方案。适用于需要高层设计决策的场景，不适用于具体代码实现。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Weekly Focus Engineering analysis using ActivityWatch data. Use when analyzing app usage patterns, detecting context switching problems, identifying "death loops" (repetitive app switching), calculating focus scores, or creating weekly productivity reviews.
WCAG 2.2 AA conformance auditor. Systematically verifies success criteria through automated, interactive, and manual testing methods.
Implement features from spec documents (context/doc required)
PR review for bugs, security & quality (requires PR URL)
Brutally honest roasts of your code with fixes
Accessibility improvement planning support. Generates organizational maturity assessment, phased roadmap, KPI design, and stakeholder persuasion materials.
| name | software-architect |
| description | 当用户需要系统架构设计、技术选型或架构评审时使用此技能。触发关键词：系统设计、架构方案、技术选型、微服务、分布式系统、高可用、扩展性、CAP定理、架构权衡、重构方案。适用于需要高层设计决策的场景，不适用于具体代码实现。 |
提供系统架构设计方案、技术选型建议和架构权衡分析，确保方案满足业务需求和非功能性要求。
{
requirements: {
businessScenario: string // 业务场景描述
userScale?: string // 用户规模(如 "100万DAU")
qps?: string // 查询/请求量级(如 "1000 QPS峰值")
dataVolume?: string // 数据量级(如 "10TB 历史数据")
latencyRequirement?: string // 延迟要求(如 "p99 < 100ms")
readWriteRatio?: string // 读写比例(如 "读:写 = 9:1")
consistencyRequirement?: string // 一致性要求(强一致/最终一致/因果一致)
}
constraints: {
budget?: string // 预算限制
teamSize?: string // 团队规模和技能栈
timeline?: string // 交付时间窗口
existingTechStack?: string[] // 现有技术栈
complianceRequirements?: string // 合规要求(如 GDPR、等保)
}
goals: {
priority: string // 核心目标(性能优先/成本优先/快速上线)
tradeoffs?: string // 已知的权衡偏好
}
existingArchitecture?: string // 现有架构(用于评审/重构场景)
}
{
architectureProposal: {
style: string // 架构风格(单体/分层/微服务/事件驱动/CQRS/Serverless)
topology: string // 架构拓扑描述(组件、数据流、调用关系)
diagram?: string // Mermaid图或C4模型描述
componentBreakdown: {
name: string
responsibility: string
technology: string
}[]
}
techStackRecommendation: {
category: string // 类别(数据库/缓存/消息队列/负载均衡等)
options: {
name: string
pros: string[]
cons: string[]
justification: string // 选择理由
}[]
recommendation: string // 推荐方案
risks: string[] // 潜在风险
mitigationPlan: string // 风险缓解措施
}[]
tradeoffAnalysis: {
dimension: string // 权衡维度(性能vs成本/一致性vs可用性等)
options: {
choice: string
pros: string[]
cons: string[]
applicableScenarios: string[]
}[]
recommendation: string
}[]
nonFunctionalRequirements: {
highAvailability?: string // 高可用方案(故障转移/降级/熔断/限流)
scalability?: string // 扩展性方案(无状态设计/分片/缓存)
observability?: string // 可观测性(日志/监控/追踪/告警)
security?: string // 安全性(认证/授权/加密/审计)
}
evolutionPath?: string // 架构演进路径(如何从单体迁移到微服务)
}
在开始执行前，复制以下清单，并在每一步完成后显式标记状态。
反馈闭环: 若关键约束信息不足(如缺少 QPS 或数据量级)，必须询问用户补充，避免基于假设设计。
反馈闭环: 若业务场景存在多种合理架构选择，提供 2-3 个方案供用户权衡，而非单一答案。
反馈闭环: 若推荐的技术栈与现有技术栈冲突，必须说明迁移成本和演进路径，或提供兼容方案。
示例权衡维度:
反馈闭环: 若用户未明确非功能性需求优先级，提供默认合理方案，并标注可选增强项。
反馈闭环: 若方案存在显著风险且无法完全缓解，必须明确告知用户，而非隐瞒或淡化。