$npx -y skills add omnigentx/jarvis --skill software-architectureArchitecture design patterns, ADR templates, and quality rules. Use when SA needs to design systems, review code architecture, or write ADRs.
| 1 | # Software Architecture |
| 2 | |
| 3 | ## Core Principles |
| 4 | |
| 5 | ### Clean Architecture & DDD |
| 6 | - Domain-driven design with ubiquitous language |
| 7 | - Separate domain entities from infrastructure |
| 8 | - Keep business logic independent of frameworks |
| 9 | |
| 10 | ### SOLID |
| 11 | - **Single Responsibility** — one reason to change per module |
| 12 | - **Open/Closed** — extend, don't modify |
| 13 | - **Liskov Substitution** — subtypes must be substitutable |
| 14 | - **Interface Segregation** — specific interfaces over general |
| 15 | - **Dependency Inversion** — depend on abstractions |
| 16 | |
| 17 | ## Code Quality Rules |
| 18 | |
| 19 | - **Early returns** over nested conditions (max 3 levels) |
| 20 | - **Functions** under 50 lines |
| 21 | - **Files** under 200 lines — split if longer |
| 22 | - **Library-first** — search for existing solutions first |
| 23 | - **Rule of Three** — abstract only when pattern proven 3+ times |
| 24 | |
| 25 | ## Anti-Patterns |
| 26 | |
| 27 | - ❌ NIH syndrome — use libraries for auth/state/validation |
| 28 | - ❌ Premature optimization — measure first |
| 29 | - ❌ YAGNI — don't build for imaginary requirements |
| 30 | - ❌ God objects — no files with 50+ unrelated functions |
| 31 | - ❌ Generic names: `utils`, `helpers`, `common` |
| 32 | |
| 33 | ## ADR Template |
| 34 | |
| 35 | ```markdown |
| 36 | # ADR-[N]: [Decision Title] |
| 37 | ## Status: Proposed | Accepted | Deprecated |
| 38 | ## Context: [What problem are we solving?] |
| 39 | ## Decision: [What we chose and why] |
| 40 | ## Consequences: [Trade-offs and impacts] |
| 41 | ``` |
| 42 | |
| 43 | ## Diagrams (Mermaid) |
| 44 | |
| 45 | The dashboard renders Mermaid blocks inline. Pick the right shape for the question: |
| 46 | |
| 47 | - **Component / context** — `flowchart` (LR or TB): |
| 48 | |
| 49 | ```mermaid |
| 50 | flowchart LR |
| 51 | Client --> API[(API Gateway)] |
| 52 | API --> AuthSvc |
| 53 | API --> OrderSvc |
| 54 | OrderSvc --> DB[(Postgres)] |
| 55 | ``` |
| 56 | |
| 57 | - **Interaction over time** — `sequenceDiagram`: |
| 58 | |
| 59 | ```mermaid |
| 60 | sequenceDiagram |
| 61 | participant U as User |
| 62 | participant A as API |
| 63 | participant D as DB |
| 64 | U->>A: POST /orders |
| 65 | A->>D: INSERT |
| 66 | D-->>A: id |
| 67 | A-->>U: 201 Created |
| 68 | ``` |
| 69 | |
| 70 | - **Data shape / aggregate boundaries** — `classDiagram` or `erDiagram`. |
| 71 | |
| 72 | Embed at most one diagram per ADR — pick the view that makes the decision |
| 73 | unambiguous. Skip if a paragraph already does the job. |
| 74 | |
| 75 | ## References |
| 76 | |
| 77 | | Topic | File | |
| 78 | |-------|------| |
| 79 | | System design process | [SYSTEM_DESIGN.md](references/SYSTEM_DESIGN.md) | |
| 80 | | Meeting protocol | [MEETING_PROTOCOL.md](references/MEETING_PROTOCOL.md) | |