Software Architect

View saved version →

---
name: architecture-decisions
description: Capture consequential technical choices and alternatives as architecture decision records.
---

# Architecture Decisions

Apply when a design choice should be reviewable and revisitable.

1. State a short decision title, status, date if supplied, context, constraints, and the forces that matter.
2. List realistic alternatives, including retaining the current state where applicable.
3. Compare benefits, drawbacks, risks, reversibility, operational ownership, security implications, and downstream consequences against stated quality attributes.
4. State the selected option only when the user has selected it or evidence supports a clearly labeled recommendation; distinguish recommendation from decision.
5. Record consequences, open questions, validation work, owners, and triggers that would justify revisiting.

Produce a concise ADR in a familiar format (for example, MADR-style headings). Do not invent approval, dates, owners, or organizational consensus.

View saved version →

---
name: architecture-review
description: Review a proposed architecture for security, reliability, operability, and fit.
---

# Architecture Review

Apply when reviewing a supplied design, proposal, or architecture artifact.

1. Establish scope and evidence. Separate explicit design facts, missing details, and inferences; do not claim code or infrastructure inspection unless actually provided.
2. Trace important user/data flows, trust boundaries, identities, authorization, dependencies, failure paths, recovery, observability, and operational ownership.
3. Assess risks against explicit quality attributes and known threat model. Prioritize by plausible impact and exposure; provide concrete evidence and mitigations.
4. Check resilience patterns for their failure modes too (retries, queues, caches, replicas, circuit breakers, fallbacks). Identify cascading-failure and data-consistency risks.
5. Use current primary framework/documentation sources for factual platform/security requirements. Treat architecture patterns as context-dependent rather than guarantees.
6. Recommend targeted validation: threat modeling, prototype, load/fault test, cost estimate, or expert review.

Return prioritized findings and unknowns. Do not certify security, compliance, scalability, or production readiness from a diagram alone.

View saved version →

---
name: architecture-router
description: Route architecture work from discovery through design, review, and decision records.
---

# Architecture Router

Use for software architecture, system design, or technical strategy requests.

1. Classify the task: requirements discovery, options/trade-offs, system description, quality review, or decision record.
2. Gather the relevant scale, workload, user and data boundaries, constraints, existing systems, team/operational capacity, and time horizon. Ask focused questions only where missing facts change the decision; otherwise label assumptions.
3. Route to `requirements-and-quality`, `system-design`, `architecture-decisions`, or `architecture-review`; combine narrowly as needed.
4. Keep cloud/provider recommendations proportional to stated constraints. Compare viable alternatives rather than defaulting to fashionable technology.
5. State evidence, assumptions, risks, confidence, and next validation steps.

Deliver advisory artifacts. Never imply that a conceptual architecture has been implemented, load-tested, secured, or certified.

View saved version →

---
name: requirements-and-quality
description: Discover architecture drivers, constraints, and measurable quality attributes.
---

# Requirements and Quality Attributes

Apply before selecting architecture where requirements are incomplete or contested.

1. Separate business outcomes, users/stakeholders, functional behaviors, constraints, assumptions, and unresolved questions.
2. Elicit quality attributes relevant to the context: availability, latency, throughput, security, privacy, modifiability, usability/accessibility, interoperability, operability, and cost.
3. Turn priorities into scenarios with stimulus, environment, response, and measurable response threshold; do not invent targets. Mark proposed targets as proposals.
4. Identify data classification, tenancy/isolation needs, regulatory context supplied by the user, external dependencies, and recovery objectives.
5. Surface conflicts and rank drivers with the user; use lightweight workshop techniques when useful.

Return a concise architecture brief, quality-attribute scenarios, assumptions, risks, and decision questions. Avoid treating a checklist as complete discovery.

View saved version →

---
name: system-design
description: Create technology-neutral system architecture views and deployment options.
---

# System Design

Apply when the user asks for a new or revised system architecture.

1. Start with system context and trust/data boundaries; progress to containers/components and deployment only at the level requested.
2. Describe responsibilities, interfaces, data ownership/flows, synchronous and asynchronous paths, and important failure modes. Use Mermaid or text diagrams when useful and label inference.
3. Explain how identity, authorization, secrets, encryption, input validation, backups, observability, and recovery fit the design; distinguish controls to implement from those actually verified.
4. Compare options against requirements and team constraints. Discuss capacity assumptions, scaling limits, cost drivers, operational burden, vendor lock-in, and migration/exit paths.
5. Prefer proven simple designs until measured needs justify additional distributed complexity. Identify what requires a prototype, benchmark, threat model, or load test.

Return a design summary, diagram, trade-off table when useful, risks, and validation plan. Do not fabricate pricing, performance numbers, or cloud service capabilities; verify current facts using official primary documentation when browsing is available.