enterprisifier

Name: enterprisifier
Author: AdamBien

40stars10forks

How to install enterprisifier?

adambien/airails/enterprisifier

$npx -y skills add AdamBien/airails --skill enterprisifier

Installs into the current project.

Summary

Deliberately overengineer code by adding as many patterns, indirections, modules, anti-corruption layers, abstractions, and encapsulations as possible. Zero dependency on implementation. Use when asked to overengineer, enterprisify, enterprise-ify, abstract, add layers, add patte

Files · 1

View on GitHub

SKILL.md

1	# Overengineering
2
3	Transform any simple, working code into a maximally abstracted, pattern-saturated, enterprise-grade architecture. No line of implementation shall be directly reachable. Every concept gets its own module, interface, factory, and anti-corruption layer.
4
5	## Philosophy
6
7	- Never depend on implementation — all access goes through at least 3 layers of abstraction
8	- Every pattern is applicable — if a GoF pattern exists, use it, even if it adds no value
9	- More modules = more enterprise — a single class is a failure; a 47-class hierarchy is a feature
10	- Abstractions over results — the code doesn't need to be faster, just more abstract
11	- Future-proof everything — defend against requirements that will never come
12
13	## Mandatory Patterns to Apply
14
15	Apply ALL of the following to every piece of code, regardless of size or complexity:
16
17	### Structural Patterns (apply all)
18	1. Facade — wrap every public API in a facade
19	2. Proxy — add a proxy in front of every facade
20	3. Decorator — wrap every proxy in a decorator for cross-cutting concerns
21	4. Adapter — adapt every external type into an internal type
22	5. Bridge — separate every abstraction from its implementation
23	6. Composite — model everything as a tree, even single values
24	7. Flyweight — pool and share objects even when memory is not a concern
25
26	### Creational Patterns (apply all)
27	8. Abstract Factory — never use `new` directly; always go through a factory of factories
28	9. Builder — every object with more than zero fields gets a builder
29	10. Singleton — critical services are singletons, accessed through a registry
30	11. Prototype — support cloning on every entity, just in case
31	12. Factory Method — subclasses decide which class to instantiate
32
33	### Behavioral Patterns (apply all)
34	13. Strategy — every `if` statement becomes a strategy interface with injectable implementations
35	14. Observer — every state change fires events through an event bus
36	15. Command — every method call becomes a command object with undo support
37	16. Chain of Responsibility — every request passes through a chain of handlers
38	17. Mediator — components never talk directly; everything goes through a mediator
39	18. Memento — every object supports full state snapshots and rollback
40	19. State — every status field becomes a state machine with dedicated state classes
41	20. Template Method — every algorithm is a skeleton with overridable hook methods
42	21. Visitor — every operation on a structure is a separate visitor
43	22. Iterator — custom iterators for every collection, never use built-in for-each
44	23. Interpreter — configuration is a DSL parsed by an interpreter
45
46	### Enterprise / Architectural Patterns (apply all)
47	24. Anti-Corruption Layer (ACL) — between every module boundary, translate models through an ACL
48	25. Hexagonal Architecture — ports and adapters for every I/O boundary
49	26. Repository — data access goes through repository interfaces
50	27. Unit of Work — batch all changes into a unit of work
51	28. Specification — every query condition is a specification object
52	29. Domain Events — every mutation publishes a domain event
53	30. CQRS — separate read and write models completely, even for a single entity
54	31. Event Sourcing — store all state changes as an event log
55	32. Saga / Orchestrator — coordinate multi-step operations through a saga
56	33. Service Locator — register and locate services dynamically at runtime
57	34. DTO / Value Object separation — never pass a domain object across a boundary; always map to a DTO
58
59	### Layering Rules (mandatory)
60	35. Presentation Layer — accepts input, delegates to application layer
61	36. Application Layer — orchestrates use cases, delegates to domain layer
62	37. Domain Layer — pure business logic, zero dependencies on infrastructure
63	38. Infrastructure Layer — persistence, messaging, external systems
64	39. Anti-Corruption Layer — between each of the above layers
65
66	## Module Structure
67
68	For a single operation (e.g., `add(a, b)`), generate at minimum:
69
70	```
71	├── api/ # Public interfaces only
72	│ ├── AdditionService.java # Service interface
73	│ ├── AdditionRequest.java # Immutable request DTO
74	│ ├── AdditionResponse.java # Immutable response DTO
75	│ └── AdditionPort.java # Hexa

People who liked this also viewed

6 picks

Type

enterprisifier

40stars10forks

View on GitHub

How to install enterprisifier?

adambien/airails/enterprisifier

$npx -y skills add AdamBien/airails --skill enterprisifier

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Overengineering
2
3	Transform any simple, working code into a maximally abstracted, pattern-saturated, enterprise-grade architecture. No line of implementation shall be directly reachable. Every concept gets its own module, interface, factory, and anti-corruption layer.
4
5	## Philosophy
6
7	- Never depend on implementation — all access goes through at least 3 layers of abstraction
8	- Every pattern is applicable — if a GoF pattern exists, use it, even if it adds no value
9	- More modules = more enterprise — a single class is a failure; a 47-class hierarchy is a feature
10	- Abstractions over results — the code doesn't need to be faster, just more abstract
11	- Future-proof everything — defend against requirements that will never come
12
13	## Mandatory Patterns to Apply
14
15	Apply ALL of the following to every piece of code, regardless of size or complexity:
16
17	### Structural Patterns (apply all)
18	1. Facade — wrap every public API in a facade
19	2. Proxy — add a proxy in front of every facade
20	3. Decorator — wrap every proxy in a decorator for cross-cutting concerns
21	4. Adapter — adapt every external type into an internal type
22	5. Bridge — separate every abstraction from its implementation
23	6. Composite — model everything as a tree, even single values
24	7. Flyweight — pool and share objects even when memory is not a concern
25
26	### Creational Patterns (apply all)
27	8. Abstract Factory — never use `new` directly; always go through a factory of factories
28	9. Builder — every object with more than zero fields gets a builder
29	10. Singleton — critical services are singletons, accessed through a registry
30	11. Prototype — support cloning on every entity, just in case
31	12. Factory Method — subclasses decide which class to instantiate
32
33	### Behavioral Patterns (apply all)
34	13. Strategy — every `if` statement becomes a strategy interface with injectable implementations
35	14. Observer — every state change fires events through an event bus
36	15. Command — every method call becomes a command object with undo support
37	16. Chain of Responsibility — every request passes through a chain of handlers
38	17. Mediator — components never talk directly; everything goes through a mediator
39	18. Memento — every object supports full state snapshots and rollback
40	19. State — every status field becomes a state machine with dedicated state classes
41	20. Template Method — every algorithm is a skeleton with overridable hook methods
42	21. Visitor — every operation on a structure is a separate visitor
43	22. Iterator — custom iterators for every collection, never use built-in for-each
44	23. Interpreter — configuration is a DSL parsed by an interpreter
45
46	### Enterprise / Architectural Patterns (apply all)
47	24. Anti-Corruption Layer (ACL) — between every module boundary, translate models through an ACL
48	25. Hexagonal Architecture — ports and adapters for every I/O boundary
49	26. Repository — data access goes through repository interfaces
50	27. Unit of Work — batch all changes into a unit of work
51	28. Specification — every query condition is a specification object
52	29. Domain Events — every mutation publishes a domain event
53	30. CQRS — separate read and write models completely, even for a single entity
54	31. Event Sourcing — store all state changes as an event log
55	32. Saga / Orchestrator — coordinate multi-step operations through a saga
56	33. Service Locator — register and locate services dynamically at runtime
57	34. DTO / Value Object separation — never pass a domain object across a boundary; always map to a DTO
58
59	### Layering Rules (mandatory)
60	35. Presentation Layer — accepts input, delegates to application layer
61	36. Application Layer — orchestrates use cases, delegates to domain layer
62	37. Domain Layer — pure business logic, zero dependencies on infrastructure
63	38. Infrastructure Layer — persistence, messaging, external systems
64	39. Anti-Corruption Layer — between each of the above layers
65
66	## Module Structure
67
68	For a single operation (e.g., `add(a, b)`), generate at minimum:
69
70	```
71	├── api/ # Public interfaces only
72	│ ├── AdditionService.java # Service interface
73	│ ├── AdditionRequest.java # Immutable request DTO
74	│ ├── AdditionResponse.java # Immutable response DTO
75	│ └── AdditionPort.java # Hexa

People who liked this also viewed

6 picks

Type