Software Architecture
Keep solo-built apps aligned with Clean Architecture, DDD, and reusable-library habits whenever an agent writes or reviews code.
Overview
Software Architecture is a journey-wide agent skill that guides Clean Architecture– and DDD-aligned coding and design—usable whenever a solo builder needs quality-focused structure before or while shipping features.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill software-architectureWhat is this skill?
- Clean Architecture and Domain-Driven Design as the default mental model for new code
- Library-first rule: search npm, SaaS, and APIs before writing custom helpers
- Early-return style, deduplication, and split files past ~80 LOC components / ~200 LOC files
- Arrow functions and small composable modules over long nested conditionals
- Applies to write, design, and analyze-code tasks across the stack
- Decompose components or functions longer than about 80 lines; split files longer than about 200 lines of code
Adoption & trust: 2.9k installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want agents to produce maintainable code and sane module boundaries, but prompts drift toward one-off helpers, deep nesting, and oversized files.
Who is it for?
Indie builders who want one skill to gate agent output on structure, reuse, and readability across backend and full-stack work.
Skip if: Pure visual or marketing-only tasks with no code, or teams that already enforce a fixed internal framework the skill would fight.
When should I use this skill?
Users want to write code, design architecture, or analyze code in any software-development-related task.
What do I get? / Deliverables
The agent applies shared architecture principles, library-first choices, and decomposition rules so new code and reviews match a consistent quality bar.
- Architecture-aligned implementation or refactor suggestions
- Code review notes grounded in stated style and library-first rules
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Shape a throwaway prototype’s folders and domain names so a later full build does not need a rewrite.
Implement API handlers with layers and library-first dependencies instead of custom retry or validation stacks.
Analyze a PR for duplication, oversized components, and missing abstractions before merge.
Refactor a hotfix path using early returns and smaller modules without breaking domain boundaries.
How it compares
Use as ongoing architecture-and-style guardrails instead of ad-hoc “write clean code” chat reminders without DDD or library-first checks.
Common Questions / FAQ
Who is software-architecture for?
Solo and indie developers using Claude Code, Cursor, or similar agents who ship SaaS, APIs, or CLIs and want Clean Architecture and DDD habits baked into every coding session.
When should I use software-architecture?
During Build when implementing or refactoring; in Ship when reviewing or hardening code; in Operate when analyzing production fixes; and anytime the task is write, design, or analyze software—not only large system redesigns.
Is software-architecture safe to install?
It is procedural guidance only—no extra network or secret access by default. Review the Security Audits panel on this Prism page before trusting any community skill in your repo.
SKILL.md
READMESKILL.md - Software Architecture
# Software Architecture Development Skill This skill provides guidance for quality focused software development and architecture. It is based on Clean Architecture and Domain Driven Design principles. ## Code Style Rules ### General Principles - **Early return pattern**: Always use early returns when possible, over nested conditions for better readability - Avoid code duplication through creation of reusable functions and modules - Decompose long (more than 80 lines of code) components and functions into multiple smaller components and functions. If they cannot be used anywhere else, keep it in the same file. But if file longer than 200 lines of code, it should be split into multiple files. - Use arrow functions instead of function declarations when possible ### Best Practices #### Library-First Approach - **ALWAYS search for existing solutions before writing custom code** - Check npm for existing libraries that solve the problem - Evaluate existing services/SaaS solutions - Consider third-party APIs for common functionality - Use libraries instead of writing your own utils or helpers. For example, use `cockatiel` instead of writing your own retry logic. - **When custom code IS justified:** - Specific business logic unique to the domain - Performance-critical paths with special requirements - When external dependencies would be overkill - Security-sensitive code requiring full control - When existing solutions don't meet requirements after thorough evaluation #### Architecture and Design - **Clean Architecture & DDD Principles:** - Follow domain-driven design and ubiquitous language - Separate domain entities from infrastructure concerns - Keep business logic independent of frameworks - Define use cases clearly and keep them isolated - **Naming Conventions:** - **AVOID** generic names: `utils`, `helpers`, `common`, `shared` - **USE** domain-specific names: `OrderCalculator`, `UserAuthenticator`, `InvoiceGenerator` - Follow bounded context naming patterns - Each module should have a single, clear purpose - **Separation of Concerns:** - Do NOT mix business logic with UI components - Keep database queries out of controllers - Maintain clear boundaries between contexts - Ensure proper separation of responsibilities #### Anti-Patterns to Avoid - **NIH (Not Invented Here) Syndrome:** - Don't build custom auth when Auth0/Supabase exists - Don't write custom state management instead of using Redux/Zustand - Don't create custom form validation instead of using established libraries - **Poor Architectural Choices:** - Mixing business logic with UI components - Database queries directly in controllers - Lack of clear separation of concerns - **Generic Naming Anti-Patterns:** - `utils.js` with 50 unrelated functions - `helpers/misc.js` as a dumping ground - `common/shared.js` with unclear purpose - Remember: Every line of custom code is a liability that needs maintenance, testing, and documentation #### Code Quality - Proper error handling with typed catch blocks - Break down complex logic into smaller, reusable functions - Avoid deep nesting (max 3 levels) - Keep functions focused and under 50 lines when possible - Keep files focused and under 200 lines of code when possible ## When to Use This skill is applicable to execute the workflow or actions described in the overview. ## Limitations - Use this skill only when the task clearly matches the scope described above. - Do not treat the output as a substitute for environment-specific validation, testing, or expert review. - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criter