Guide system design decisions including design-from-functionality, coupling analysis, and C4 model thinking. Use when designing systems, evaluating structural changes, or reviewing architecture decisions.
From flownpx claudepluginhub synaptiai/synapti-marketplace --plugin flowThis skill is limited to using the following tools:
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Domain skill for system design, structural evaluation, and architecture decisions.
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.
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")
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.
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 stack |
| Components | Modules within a container | Designing internal structure, reviewing coupling |
| Code | Classes, functions, interfaces | Implementation decisions, code review |
Rule: Start at the highest relevant level. Zoom in only when needed. Most design discussions happen at Components level.
TaskUpdate("Coupling analysis", status: "in_progress")
Check actual dependencies, not assumed ones:
# Find imports and dependencies
grep -rn "import\|require\|from " --include="*.{ts,js,tsx,jsx,py,rb}" -l
# Check for circular dependencies
# Look for A imports B AND B imports A patterns
Red flags:
Dependencies should flow ONE direction:
UI → Application → Domain → Infrastructure
↓
External APIs
TaskUpdate("Coupling analysis", status: "completed")
TaskUpdate("Decision documentation", status: "in_progress")
For each architectural decision, document:
| Field | Content |
|---|---|
| Context | What's the situation? What forces are at play? |
| Options | 2-4 distinct approaches (not just "do it" vs "don't") |
| Trade-offs | Pros and cons per option with evidence |
| Decision | Which option and why |
| Consequences | What changes? What new constraints? What risks accepted? |
TaskUpdate("Decision documentation", status: "completed") Use TaskList to confirm all design activities resolved before proceeding to implementation.
Before proposing new architecture, check what exists:
# What patterns does the codebase already use?
ls -la src/ app/ lib/
grep -r "class \|module \|interface " --include="*.{ts,js,py,rb}" | head -20
git log --oneline --all -- "src/*/index.*" | head -10
Rule: Follow existing patterns unless there's a documented reason to diverge. Consistency beats novelty.
| Anti-Pattern | Symptom | Fix |
|---|---|---|
| Design before mapping flows | Components that serve no user action | Map flows first, then design |
| Pattern from trends | Using microservices because "everyone does" | Choose patterns from requirements |
| Premature abstraction | Interfaces with one implementation | YAGNI. Concrete first, abstract when needed |
| Astronaut architecture | 5 layers for a CRUD app | Match complexity to actual requirements |
| Copy-paste architecture | Same structure regardless of problem | Each system is different. Design for THIS problem. |
| Excuse | Response |
|---|---|
| "We might need this later" | YAGNI. Build for now, extend when needed. The cost of removing is lower than maintaining unused code. |
| "This is best practice" | Best practice for WHOM? Show the requirement it serves. |
| "Let's add an abstraction layer" | For what? One implementation behind an interface is overhead, not architecture. |
| "We need to future-proof this" | You can't predict the future. Build for today, refactor when requirements change. |
| "Let's use microservices" | For a team of 3? Monolith first. Split when you have evidence of scaling needs. |