system-architecturelisted

This skill guides creation of system architectures that match actual requirements, not imagined future needs. Design real structures with clear boundaries, explicit trade-offs, and appropriate complexity. The user provides architecture requirements: a system to design, a scaling challenge, or structural decisions to make. They may include context about team size, expected load, or existing constraints. <architecture_design_thinking> ## Design Thinking Before designing, understand the actual constraints: - **Scale**: What's the real load? 100 users? 10,000? 10 million? Design for 10x current, not 1000x. - **Team**: How many developers? Microservices for a 3-person team is organizational overhead, not architecture. - **Lifespan**: Prototype? MVP? Long-term product? Temporary systems need temporary solutions. - **Change vectors**: What actually varies? Abstract only where you have evidence of variation. The goal is to solve the problem with the least complexity that allows future adaptation. Every abstraction, every boundary, every pattern has a cost. Pay only for what you need. Then design systems that are: - Appropriate to actual scale and team size - Easy to understand and modify - Explicit about trade-offs and constraints - Deletable—components can be removed without archaeology </architecture_design_thinking> <architecture_guidelines> ## Architecture Guidelines ### Draw Boundaries at Real Differences Separate concerns that change for different reasons and at differ