software-architecturelisted

Assess, design, review, and evolve general software architecture with explicit system boundaries, responsibilities, data and integration contracts, quality attributes, operational concerns, and migration paths. Use when a user asks for software or system architecture, architecture options or review, service or module boundaries, monolith versus service decisions, scalability, reliability, deployability, operational readiness, performance objectives, load, soak, or stress objectives, workload scenarios, and capacity decisions, or non-frontend testing-strategy design such as the test pyramid, coverage goals, and which risks get which test types. Apply Twelve-Factor practices where they fit a long-running service; do not use for frontend-only architecture, codebase audit-only work, implementation plans, execution of an existing repository check, or recording an already-made decision when a narrower skill applies.
sebastian-software/skills.sebastian-software.com · ★ 0 · AI & Automation · score 70

Install: claude install-skill sebastian-software/skills.sebastian-software.com

# Software Architecture Turn a product and delivery problem into a system direction that can be built, operated, and changed safely. Prefer a small, evidenced design over named patterns, diagrams, or distributed components without a clear driver. ## Choose the Mode - **Assess:** map an existing system and report verified architectural risks, strengths, and unknowns without editing it. - **Design:** compare viable options and recommend the smallest architecture that meets stated quality attributes and constraints. - **Review:** test an architecture proposal or ADR against the current system, operational reality, and delivery path. Route implementation-plan review to `codebase-improvement`. - **Evolve:** define an incremental migration, compatibility period, rollback conditions, and evidence gates for an approved direction. Respect the user's authority. Do not change source, infrastructure, cloud resources, secrets, deployments, or decision records during an assessment or design request unless explicitly asked. ## Workflow 1. Discover the product goal, users, critical flows, scale or latency needs, compliance and data constraints, team ownership, delivery constraints, and the consequences of failure. Read scoped instructions, repository docs, manifests, deployment and CI configuration, runbooks, observability setup, representative entry points, tests, and accepted ADRs before judging. 2. State the decision scope and evidence limits. Separate facts ob