$ loading_
Use when the /systems-design-review mode is active. 7-step design review methodology -- understand the design, classify the system, evaluate against codebase, adversarial analysis, tradeoff validation, synthesis, and action items. Governs conversation flow, delegation patterns, and user validation checkpoints.
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "systems-design-review-methodology" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/amplifier-bundle-systems-design/main/skills/systems-design-review-methodology/SKILL.md 2. 保存为 ~/.claude/skills/systems-design-review-methodology/SKILL.md 3. 装好后重载技能，告诉我可以用了
Companion skill for the /systems-design-review mode. The mode gates tools; this skill governs behavior.
For automated staging with approval gates, use the systems-design-review recipe instead of this manual flow:
recipes(operation="execute", recipe_path="@systems-design:recipes/systems-design-review.yaml", context={"target_path": "<path>"})
The recipe automates reconnaissance, classification, multi-perspective analysis, and report generation with human checkpoints between stages.
You handle the CONVERSATION. Agents handle the ANALYSIS.
You guide the user through the review, synthesize findings, and facilitate decisions. For deep analysis work, delegate to systems-design:systems-design-critic or use the adversarial-review skill.
Before any critique, reconstruct the designer's reasoning:
Apply the Comprehending Existing lens:
Understanding original intent prevents reviews that recommend "fixing" things the designer already considered and deliberately chose.
Ask: "Is this the complete design, or is there additional context I should know about?"
This step is mandatory. Do not skip it. Do not proceed to analysis without completing it.
Based on what you learned in Step 1, classify the system under review. 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 |
| Peer-to-peer | system-type-peer-to-peer | P2P topologies, NAT traversal, decentralized coordination |
| Azure-hosted | system-type-azure | Azure compute, identity, networking, managed services |
Design philosophies -- which does the system claim or embody?
| Philosophy | Skill | Applies when... |
|---|---|---|
| Linux/Unix | design-philosophy-linux | Mechanism vs policy, composability, small sharp tools |
| Domain-driven | design-philosophy-domain-driven | Bounded contexts, ubiquitous language, aggregates |
…
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.