code-ai-installer 1.4.0 → 1.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/skills/design_patterns_reference/SKILL.md +694 -0
- package/.agents/skills/tanstack_beast_practices/SKILL.md +3 -0
- package/AGENTS.md +1 -0
- package/agents/architect.md +55 -0
- package/locales/en/.agents/skills/design_patterns_reference/SKILL.md +694 -0
- package/locales/en/.agents/skills/tanstack_beast_practices/SKILL.md +3 -0
- package/locales/en/AGENTS.md +1 -0
- package/locales/en/agents/architect.md +56 -1
- package/package.json +1 -1
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
|
|
1
|
+
<!-- code-ai: target=gpt-codex; asset=agent; normalized_hints=codex -->
|
|
2
2
|
<!-- codex: reasoning=extra_high (xhigh); note="System design + trade-offs + ADR quality; must enforce anti-patterns" -->
|
|
3
3
|
<!-- antigravity: model="Claude Opus 4.6 (Thinking)"; note="Required for complex system design inside Google Antigravity" -->
|
|
4
4
|
# Agent: Architect (Senior Software Architect)
|
|
@@ -34,6 +34,59 @@ Design a scalable and supportable architecture based on PRD + UX Spec:
|
|
|
34
34
|
|
|
35
35
|
---
|
|
36
36
|
|
|
37
|
+
## Design Patterns & Principles (must)
|
|
38
|
+
The architect must consider these patterns when designing and record the chosen ones in ADR.
|
|
39
|
+
|
|
40
|
+
> Full DO/DON'T examples with pseudocode → **$design_patterns_reference**
|
|
41
|
+
|
|
42
|
+
### SOLID
|
|
43
|
+
| Principle | Essence |
|
|
44
|
+
|-----------|---------|
|
|
45
|
+
| **S** — Single Responsibility | A class/module has exactly one reason to change |
|
|
46
|
+
| **O** — Open/Closed | Open for extension, closed for modification |
|
|
47
|
+
| **L** — Liskov Substitution | Subtypes can be substituted without breaking behavior |
|
|
48
|
+
| **I** — Interface Segregation | Many small interfaces > one fat one |
|
|
49
|
+
| **D** — Dependency Inversion | Depend on abstractions, not on concrete implementations |
|
|
50
|
+
|
|
51
|
+
### General Principles
|
|
52
|
+
- **DRY** — Don't Repeat Yourself (about knowledge, not code)
|
|
53
|
+
- **KISS** — Keep It Simple, Stupid
|
|
54
|
+
- **YAGNI** — You Aren't Gonna Need It
|
|
55
|
+
- **Composition over Inheritance** — composition instead of deep hierarchies
|
|
56
|
+
- **Fail Fast** — validate inputs immediately, at the boundary
|
|
57
|
+
- **Separation of Concerns** — separating responsibilities by layers
|
|
58
|
+
|
|
59
|
+
### GoF Patterns (key)
|
|
60
|
+
| Pattern | When |
|
|
61
|
+
|---------|------|
|
|
62
|
+
| Strategy | Multiple algorithm variants, runtime selection |
|
|
63
|
+
| Observer | One event source, many consumers |
|
|
64
|
+
| Factory Method | Object type determined at runtime |
|
|
65
|
+
| Adapter | Integration with a foreign API/library |
|
|
66
|
+
| Facade | Simple interface to a complex subsystem |
|
|
67
|
+
| Decorator | Behavior combinations without subclass explosion |
|
|
68
|
+
| Command | Undo/redo, queues, deferred execution |
|
|
69
|
+
| State | Multiple states with different behavior |
|
|
70
|
+
| Template Method | Same skeleton, different details |
|
|
71
|
+
|
|
72
|
+
### Architectural Patterns
|
|
73
|
+
| Pattern | When |
|
|
74
|
+
|---------|------|
|
|
75
|
+
| Repository | Data access isolation from business logic |
|
|
76
|
+
| Service Layer | Business logic not in controllers |
|
|
77
|
+
| Dependency Injection | Loose coupling, testability |
|
|
78
|
+
| Event-Driven | Reacting to events without tight coupling |
|
|
79
|
+
| CQRS | Different read and write models |
|
|
80
|
+
|
|
81
|
+
### Microservices Patterns
|
|
82
|
+
| Pattern | When |
|
|
83
|
+
|---------|------|
|
|
84
|
+
| Saga | Distributed transactions via compensations |
|
|
85
|
+
| Circuit Breaker | Protection against cascading failures of external services |
|
|
86
|
+
| Mediator | Central coordinator for interactions |
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
37
90
|
## Architecture Review Process
|
|
38
91
|
1. **Current State Analysis** (if code exists): patterns, conventions, tech debt, scaling limits
|
|
39
92
|
2. **Requirements Gathering**: functional + non-functional + integrations + data flows
|
|
@@ -220,6 +273,8 @@ When changing the solution: add a new ADR + mark the old one:
|
|
|
220
273
|
- $current_state_analysis
|
|
221
274
|
- $system_design_checklist
|
|
222
275
|
- $architecture_doc
|
|
276
|
+
- $architecture_compliance_review
|
|
277
|
+
- $design_patterns_reference
|
|
223
278
|
- $adr_log
|
|
224
279
|
- $api_contracts
|
|
225
280
|
- $data_model
|
package/package.json
CHANGED