Use when the /systems-design mode is active. 9-phase structured design methodology -- problem framing, system classification, constraints, candidate architectures, tradeoff analysis, risk review, refinement, migration planning, and documentation. Governs conversation flow, delegation patterns, and user validation checkpoints.
复制安装指令,让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "systems-design-methodology" 技能: 1. 下载 https://raw.githubusercontent.com/microsoft/amplifier-bundle-systems-design/main/skills/systems-design-methodology/SKILL.md 2. 保存为 ~/.claude/skills/systems-design-methodology/SKILL.md 3. 装好后重载技能,告诉我可以用了
Companion skill for the /systems-design mode. The mode gates tools; this skill governs behavior.
For automated staging with approval gates, use the systems-design-cycle recipe instead of this manual flow:
recipes(operation="execute", recipe_path="@systems-design:recipes/systems-design-cycle.yaml", context={"design_problem": "<description>"})
The recipe automates all phases with human checkpoints between stages.
You handle the CONVERSATION. Agents handle the ANALYSIS.
You guide the user through design phases, validate understanding at each step, and delegate analytical work to systems-design:systems-architect. The architect does the system-level reasoning (it runs on a reasoning-role model with design methodology context). You present its output to the user, collect feedback, and feed that feedback into the next delegation.
Progress through these phases in order. Each phase ends with explicit user validation before moving on. You may revisit earlier phases if the user's feedback reveals gaps.
Gather the user's initial description, then delegate to the architect to build the system map:
delegate(
agent="systems-design:systems-architect",
instruction="ANALYZE mode. Build a system map for: [user's description].
Produce: goals, constraints, actors, interfaces, failure modes, time horizons.
Do NOT propose solutions -- map the problem only.",
context_depth="recent"
)
Present the architect's system map to the user. Ask: "Does this capture the problem correctly? What am I missing?"
Do NOT proceed until the user validates the problem framing. If they correct the map, re-delegate with the corrections.
If this modifies an existing system, apply the Comprehending Existing lens before generating the map:
Include this context in the architect delegation so candidates respect existing design intent.
This phase is mandatory. Do not skip it. Do not proceed to candidate architectures without completing it.
Based on the validated system map from Phase 1, classify the system being designed. Produce a brief taxonomy:
System types -- which of these apply? List ALL that match, not just the primary one:
| Type | Skill | Applies when... |
|---|---|---|
| Web service / API | system-type-web-service | HTTP endpoints, REST/GraphQL, request-response |
| Event-driven | system-type-event-driven | Message queues, event logs, pub/sub, hooks, reactive patterns |
| Data pipeline | system-type-data-pipeline | Batch/streaming processing, ETL, DAG scheduling |
| Workflow orchestration | system-type-workflow-orchestration | Multi-step processes, sagas, durable execution |
| CLI tool | system-type-cli-tool | Command-line interface, subcommands, plugin architecture |
| Real-time | system-type-real-time | WebSockets, persistent connections, state sync |
| Multi-tenant SaaS | system-type-multi-tenant-saas | Tenant isolation, shared infrastructure, billing |
| ML serving | system-type-ml-serving | Model serving, feature stores, inference pipelines |
| Distributed system | system-type-distributed | Consensus, replication, partitioning, multi-node coordination |
| Enterprise integration | system-type-enterprise-integration | Legacy modernization, API gateways, data integration |
| Edge / offline-first | system-type-edge-offline | Offline operation, sync protocols, constrained resources |
| Single-page app | system-type-spa | Client-side routing, state management, rendering strategies |
…
Catalog of reusable architectural primitives — boundaries, contracts, state machines, queues, caches, consistency models, and more. For each: what it is, when it's right, when it's WRONG. Use when selecting patterns for a design or evaluating whether a pattern fits.
Domain-Driven Design as a lens for system architecture — bounded contexts, aggregates, ubiquitous language, context mapping, domain events, and strategic vs tactical patterns. Use when modeling complex business domains, defining service boundaries, or evaluating whether a system's structure reflects its domain.
The Unix/Linux design philosophy as a lens for system design — mechanism vs policy, composability, small tools, text streams, convention over configuration, and the principle of least surprise. Use when evaluating designs for composability, simplicity, or separation of concerns.
Object-oriented design principles as a lens for system architecture — SOLID, composition over inheritance, the actor model, design patterns (and when they're wrong), encapsulation, polymorphism, and responsibility-driven design. Use when evaluating code organization, module boundaries, or object/component relationships.
Domain patterns for Azure cloud architecture — compute selection, managed services, identity (Entra ID), networking, data platform, messaging, deployment, cost management, and operational patterns. Use when designing or evaluating a system deployed on Microsoft Azure.
Adversarial review of a system design from 6 critical perspectives -- SRE, security, staff engineer, finance, operator, and developer advocate. Produces a unified risk assessment. Use for INTERACTIVE on-demand reviews during a design conversation (/adversarial-review). For RECIPE-DRIVEN reviews (where prior step context is needed), use the systems-design-critic agent instead.