npx claudepluginhub incubyte/ai-plugins --plugin beeThis skill uses the workspace's default tool permissions.
**Use when:** Scripts, utilities, CLI tools, small services with minimal business logic, CRUD with no rules beyond validation.
Designs software architecture and selects patterns like layered, clean, and hexagonal based on project size, team, and needs. Includes checklists for decisions on monoliths vs. microservices.
Provides architectural patterns like Layered (N-Tier), MVC, event-driven, microservices, CQRS for designing feature implementations and system architecture.
Advises on .NET app architectures via questionnaire on domain complexity, team size, lifetime, compliance, integrations. Recommends Vertical Slice, Clean, DDD+Clean, or Modular Monolith.
Share bugs, ideas, or general feedback.
Use when: Scripts, utilities, CLI tools, small services with minimal business logic, CRUD with no rules beyond validation.
Structure: Functions or modules organized by feature. No layers, no ports.
Tradeoff: Fastest to build. Hardest to extend if complexity grows. Refactor to layers when it hurts, not before.
Use when: Web apps, APIs, most CRUD-heavy applications. The default for Rails, Django, Express, Spring.
Structure: Route -> Controller (thin, delegates) -> Service (business logic) -> Model/Repository (data).
Dependency direction: Controller depends on Service, Service depends on Model. Never the reverse.
Tradeoff: Familiar, well-tooled, lots of examples. Services can grow large as business logic gets complex. At that point, consider extracting a domain layer.
Use when: Complex domain logic with many business rules. Multiple input channels (HTTP, CLI, events). Need to swap infrastructure (different DB, different API provider).
Structure: Pure domain core (zero external dependencies) -> Use cases (orchestration) -> Adapters (HTTP, DB, messaging).
Dependency direction: Everything points inward. Outer layers depend on inner layers. Inner layers know nothing about outer layers. Ports (interfaces) define the boundaries.
Tradeoff: More structure upfront. Trivially testable domain. Worth it when business rules are complex. Overkill for simple CRUD.
The cardinal rule: inner layers never import from outer layers.
Violations of this rule create coupling that makes testing hard and changes expensive.
You Aren't Gonna Need It. Before creating any abstraction, ask:
The rule: Extract an interface when the second implementation arrives. Not before.
Why this matters for AI: AI loves generating interfaces, abstract factories, and strategy patterns. It will create IUserRepository, UserRepositoryImpl, UserRepositoryFactory for a single Postgres query. Push back. Use the concrete class. Extract when you need to.
Warranted abstractions:
Unwarranted abstractions: