architecture-patternslisted

Document system design decisions with mapped user flows, coupling analysis, failure modes, and explicit non-goals, proving the architecture can survive under unexpected conditions. Use when designing systems, evaluating structural changes, or reviewing architecture decisions. Proactively suggest when coupling analysis reveals circular dependencies, god objects, or hidden shared state.
synaptiai/synapti-marketplace · ★ 5 · AI & Automation · score 70

Install: claude install-skill synaptiai/synapti-marketplace

# Architecture Patterns Domain skill for system design, structural evaluation, and architecture decisions. ## Iron Law **DESIGN ARCHITECTURE FROM FUNCTIONALITY, NOT TO FUNCTIONALITY. If you can't trace a component to a user flow, delete it.** Architecture serves user flows. Not the other way around. ## Prerequisite: Map Flows First Before designing ANYTHING, enumerate flows. Track each design activity as a task: ``` TaskCreate("Map user/admin/system flows", "Enumerate all flows before designing components") TaskCreate("Coupling analysis", "Check imports, circular deps, god objects, hidden coupling") TaskCreate("Design proposal", "Components, responsibilities, dependencies, data flow") TaskCreate("Decision documentation", "Context, options, trade-offs, decision, consequences") ``` 1. **User flows** — what does the user do, step by step? 2. **Admin flows** — what does the operator/admin do? 3. **System flows** — what happens automatically (cron, webhooks, events)? Each flow is a sequence: trigger → steps → outcome. Every component must serve at least one flow. TaskUpdate("Map user/admin/system flows", status: "completed") after all flows enumerated. ## C4 Model Views Navigate the right level of abstraction: | Level | Shows | When to Use | |-------|-------|-------------| | **Context** | System + external actors | Starting a new project, explaining to stakeholders | | **Containers** | Deployable units (services, DBs, queues) | Designing infrastructure, choosing tech