microsoft/amplifier-bundle-systems-design.

adversarial-review

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.

architecture-primitives

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.

design-philosophy-domain-driven

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.

design-philosophy-linux

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.

design-philosophy-object-oriented

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.

system-type-azure

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.

system-type-cli-tool

Domain patterns for CLI tools and developer SDKs — command structure, configuration layering, plugin architecture, distribution, backward compatibility, shell integration, and failure modes. Use when designing or evaluating command-line tools, developer platforms, or SDK libraries.

system-type-data-pipeline

Domain patterns for data pipeline architecture — batch processing, stream processing, ETL/ELT, DAG scheduling, data quality, schema evolution, backfill strategies, and failure modes. Use when designing or evaluating data pipelines, ETL systems, or streaming data infrastructure.

system-type-distributed

Foundational patterns for distributed systems — consensus, consistency models, replication, partitioning, clock synchronization, distributed transactions, and failure modes. Use when designing or evaluating any system that spans multiple nodes, processes, or failure domains.

system-type-edge-offline

Domain patterns for edge computing and offline-first systems — sync protocols, conflict resolution under partition, local-first architecture, constrained resources, intermittent connectivity, and failure modes. Use when designing or evaluating mobile apps, IoT systems, field-deployed software, or any system that must work without reliable network access.

system-type-enterprise-integration

Domain patterns for enterprise integration — legacy modernization, strangler fig, anti-corruption layers, API gateways, canonical data models, event-carried state transfer, and failure modes. Use when designing or evaluating integration between existing enterprise systems, legacy modernization, or multi-system orchestration.

system-type-event-driven

Domain patterns for event-driven and message-based systems — pub/sub, event sourcing, CQRS, sagas, delivery guarantees, schema evolution, and failure modes. Use when designing or evaluating systems built around events, messages, or asynchronous workflows.

system-type-ml-serving

Domain patterns for ML/AI serving and training systems — model serving, feature stores, training pipelines, experiment tracking, A/B testing, GPU scheduling, and failure modes. Use when designing or evaluating machine learning infrastructure, model serving platforms, or AI-powered product features.

system-type-multi-tenant-saas

Domain patterns for multi-tenant SaaS platforms — tenant isolation models, data partitioning, noisy neighbor mitigation, per-tenant configuration, billing metering, and failure modes. Use when designing or evaluating SaaS products that serve multiple customers from shared infrastructure.

system-type-peer-to-peer

Domain patterns for peer-to-peer system architecture — network topologies, NAT traversal, peer discovery, data distribution, consistency without central authority, identity and trust, and incentive mechanisms. Use when designing or evaluating a decentralized, peer-to-peer, or mesh-networked system.

system-type-real-time

Domain patterns for real-time and collaborative systems — persistent connections, state synchronization, conflict resolution, presence, fan-out, and failure modes. Use when designing or evaluating chat systems, collaborative editors, live dashboards, gaming backends, or any system with bidirectional real-time communication.

system-type-spa

Domain patterns for single-page application architecture — client-side routing, state management, rendering strategies, authentication, performance, and offline support. Use when designing or evaluating a browser-based SPA, progressive web app, or rich client-side application.

system-type-web-service

Domain patterns for web service architecture — API design (REST/GraphQL/gRPC), scaling, data layer, observability, failure modes, and anti-patterns. Use when designing or evaluating a web service, API, or request/response system.

system-type-workflow-orchestration

Domain patterns for workflow orchestration systems — long-running processes, state machines, saga coordination, human-in-the-loop gates, retry and timeout hierarchies, and failure modes. Use when designing or evaluating workflow engines, job orchestrators, or multi-step business process systems.

systems-design-methodology

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.

systems-design-review-methodology

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.

tradeoff-analysis

Structured tradeoff analysis methodology — the 8-dimension comparison frame, tradeoff matrix template, and common tradeoff patterns. Use when evaluating design alternatives, comparing technology choices, or when the answer is 'it depends.'