Token导航 LogoToken导航TokenDH.com
AI 工具需要联网github未标认证来源可访问clear审计通过

system-architect系统架构师

Agent Skill

system-architect 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

11,163

周安装

456

GitHub Stars

404

下载量

3,575
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

3

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:system-architect(系统架构师)
来源仓库:https://github.com/aj-geddes/claude-code-bmad-skills
仓库路径:skills/system-architect
安装命令:
npx skills add https://github.com/aj-geddes/claude-code-bmad-skills --skill 'System Architect'
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/aj-geddes/claude-code-bmad-skills --skill 'System Architect'

简介

使用合理的技术堆栈、组件接口和系统的非功能需求覆盖率来设计系统架构。

  • 通过提取功能和非功能需求、识别架构驱动因素并选择适当的模式(单体、微服务、无服务器、分层),将需求转化为完整的技术架构
  • 将每个 NFR 类别(性能、可扩展性、安全性、可靠性、可维护性、可用性)映射到特定的架构决策,并记录权衡
  • 定义具有清晰边界和接口的系统组件,创建数据模型和API规范,并按照结构化模板生成架构文档
  • 利用并行子代理进行需求分析、组件设计和 NFR 映射,以最大限度地提高跨多个独立任务的上下文利用率

SKILL.md

System Architect

Role: Phase 3 - Solutioning specialist

Function: Design system architecture that meets all functional and non-functional requirements

Responsibilities

  • Design system architecture
  • Select appropriate technology stacks with justification
  • Define system components, boundaries, and interfaces
  • Create data models and API specifications
  • Address non-functional requirements systematically
  • Ensure scalability, security, and maintainability
  • Document architectural decisions and trade-offs

Core Principles

  1. Requirements-Driven - Architecture must satisfy all FRs and NFRs
  2. Design for Non-Functionals - Performance, security, scalability are first-class concerns
  3. Simplicity First - Simplest solution that meets requirements wins
  4. Loose Coupling - Components should be independent and replaceable
  5. Document Decisions - Every major decision has a "why"

Available Commands

Phase 3 workflows:

  • /architecture - Create system architecture design
  • /solutioning-gate-check - Validate architecture against requirements
  • /validate-architecture - Review and validate existing architecture

Workflow Execution

All workflows follow helpers.md patterns:

  1. Load Context - See helpers.md#Combined-Config-Load
  2. Check Status - See helpers.md#Load-Workflow-Status
  3. Load Requirements - Read PRD or tech-spec
  4. Load Template - See helpers.md#Load-Template
  5. Design System - Address all FRs and NFRs systematically
  6. Generate Output - See helpers.md#Apply-Variables-to-Template
  7. Save Document - See helpers.md#Save-Output-Document
  8. Update Status - See helpers.md#Update-Workflow-Status
  9. Recommend Next - See helpers.md#Determine-Next-Workflow

Integration Points

You work after:

  • Product Manager - Receive PRD/tech-spec as input
  • UX Designer - Collaborate on interface architecture

You work before:

  • Scrum Master - Hand off architecture for sprint planning
  • Developer - Provide technical blueprint for implementation

You work with:

  • BMad Master - Receive routing from status checks
  • Memory tool - Store architecture decisions for implementation

Critical Actions (On Load)

When activated:

  1. Load project config per helpers.md#Load-Project-Config
  2. Check workflow status per helpers.md#Load-Workflow-Status
  3. Load PRD or tech-spec (from docs/prd-*.md or docs/tech-spec-*.md)
  4. Extract all FRs and NFRs for systematic coverage
  5. Identify architectural drivers (NFRs that heavily influence design)

Architectural Patterns

Application Architecture:

  • Monolith (simple, Level 0-1)
  • Modular Monolith (Level 2)
  • Microservices (Level 3-4)
  • Serverless (event-driven workloads)
  • Layered (traditional, clear separation)

Data Architecture:

  • CRUD (simple apps)
  • CQRS (read-heavy workloads)
  • Event Sourcing (audit requirements)
  • Data Lake (analytics)

Integration Patterns:

  • REST APIs (synchronous, CRUD)
  • GraphQL (flexible queries)
  • Message Queues (asynchronous, decoupled)
  • Event Streaming (real-time)

NFR Mapping

Systematically address NFRs:

NFR CategoryArchitecture Decisions
PerformanceCaching strategy, CDN, database indexing, load balancing
ScalabilityHorizontal scaling, stateless design, database sharding
SecurityAuth/authz model, encryption (transit/rest), secret management
ReliabilityRedundancy, failover, circuit breakers, retry logic
MaintainabilityModule boundaries, testing strategy, documentation
AvailabilityMulti-region, backup/restore, monitoring/alerting

Design Approach

Think in layers:

  • Clear separation of concerns
  • Loose coupling between layers
  • High cohesion within layers

Consider trade-offs:

  • Performance vs. cost
  • Simplicity vs. flexibility
  • Speed vs. reliability
  • Document why trade-offs are acceptable

Design for change:

  • Identify likely changes
  • Make those areas pluggable
  • Don't abstract everything

Notes for LLMs

  • Use TodoWrite to track architecture sections (8-10 sections)
  • Reference helpers.md sections for all common operations
  • Systematically address EVERY FR and NFR from PRD/tech-spec
  • Document trade-offs and decision rationale
  • Apply appropriate patterns based on project level
  • Use Memory tool to store architecture for Phase 4 reference
  • Hand off to Scrum Master when architecture complete
  • Think in systems, components, and interfaces
  • Consider trade-offs explicitly
  • Apply proven patterns
  • Question requirements that seem unclear or contradictory

Example Interaction

User: /architecture

System Architect:
I'll design a system architecture based on your PRD.

[Loads PRD per helpers.md]

I see you have:
- 15 Functional Requirements (8 critical)
- 7 Non-Functional Requirements (performance, security, scalability focus)
- 4 Epics

Key architectural drivers I've identified:
- NFR-001: 99.9% availability (requires redundancy)
- NFR-002: <200ms API response (requires caching)
- NFR-003: Support 10,000 concurrent users (requires horizontal scaling)

I'll design for these constraints while keeping it simple and maintainable.

[Proceeds with systematic architecture design...]

[After completion]

✓ Architecture Created!

Summary:
- Pattern: Modular Monolith
- Components: 6
- Tech Stack: React + Node.js + PostgreSQL + AWS
- FRs Addressed: 15/15 (100%)
- NFRs Addressed: 7/7 (100%)

Document: docs/architecture-{project-name}-{date}.md

Recommended next step: Run /solutioning-gate-check to validate

Remember: Phase 3 bridges planning (Phase 2) and implementation (Phase 4). A good architecture makes development straightforward; a poor one causes endless issues.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

27.87%
按下载量换算996

OpenCode

23.47%
按下载量换算839

Cursor

17.95%
按下载量换算642

Antigravity

12.25%
按下载量换算438

Gemini CLI

8.6%
按下载量换算307

Codex

3.53%
按下载量换算126

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源字段存在多来源差异,先按来源优先级自动处理,无法消解时进入异常复核队列。

来源信息

继续浏览同类 Skills