enterprise-architecture-standardslisted

Use for EVERY non-trivial piece of code, service, database schema, or integration the agent builds — new services, new endpoints, schema changes, refactors, and anything described as "production," "enterprise," "scalable," or "for a large team." Applies technical/system architecture, database architecture, sound algorithmic and coding principles, microservices and integration patterns, resilience/reliability patterns, and performance/scalability practices at the standard expected from senior engineering teams at large companies. Trigger proactively whenever the user asks to design, architect, build, scale, or refactor a system, service, database, or API, or asks how "properly built" or "enterprise-grade" software should look — even without those exact words, e.g. "add a new service," "design the schema for X," "how should these services talk to each other," "this needs to handle more load."
techfleetworks/enterprise-software-AI-skills · ★ 0 · API & Backend · score 70

Install: claude install-skill techfleetworks/enterprise-software-AI-skills

# Enterprise Architecture & Engineering Standards ## Why this exists Most systems don't fail because nobody knew the right pattern — they fail because the right pattern wasn't applied consistently under deadline pressure. This skill makes architectural rigor the default rather than something bolted on after a system already has scaling problems, data integrity bugs, or an unmaintainable service boundary. It complements (doesn't replace) `bdd-comprehensive-testing` and `owasp-secure-coding-bdd`: those cover behavior verification and security; this one covers whether the system is actually well-designed — the right shape, the right data model, the right resilience posture, the right performance characteristics — before those tests even get written. ## The workflow ### Step 1: Classify what's being built Different work calls for different reference files. Identify which of these apply — most substantial tasks touch more than one: - **New service or system boundary** (a new microservice, a new bounded context, splitting a monolith) → `references/software-architecture-styles.md` + `references/microservices-patterns.md` - **Database schema, data model, or persistence choice** (new tables, new data store, migration, sharding) → `references/database-architecture.md` - **Any non-trivial function, class, or module** (the actual code, regardless of scale) → `references/coding-principles.md` - **Service-to-service communication, external integration, or public/internal API** → `ref