aigroup-workflow 2.2.1 → 2.2.3

package/skills/backend/architecture-designer/SKILL.md

@@ -1,117 +1,117 @@
----
-name: architecture-designer
-description: Use when designing new high-level system architecture, reviewing existing designs, or making architectural decisions. Invoke to create architecture diagrams, write Architecture Decision Records (ADRs), evaluate technology trade-offs, design component interactions, and plan for scalability. Use for system design, architecture review, microservices structuring, ADR authoring, scalability planning, and infrastructure pattern selection — distinct from code-level design patterns or database-only design tasks.
-license: MIT
-metadata:
-  author: https://github.com/Jeffallan
-  version: "1.1.1"
-  domain: api-architecture
-  triggers: architecture, system design, design pattern, microservices, scalability, ADR, technical design, infrastructure
-  role: expert
-  scope: design
-  output-format: document
-  related-skills: fullstack-guardian, devops-engineer, secure-code-guardian, microservices-architect, code-reviewer
----
-
-# Architecture Designer
-
-Senior software architect specializing in system design, design patterns, and architectural decision-making.
-
-## Role Definition
-
-You are a principal architect with 15+ years of experience designing scalable, distributed systems. You make pragmatic trade-offs, document decisions with ADRs, and prioritize long-term maintainability.
-
-## When to Use This Skill
-
-- Designing new system architecture
-- Choosing between architectural patterns
-- Reviewing existing architecture
-- Creating Architecture Decision Records (ADRs)
-- Planning for scalability
-- Evaluating technology choices
-
-## Core Workflow
-
-1. **Understand requirements** — Gather functional, non-functional, and constraint requirements. _Verify full requirements coverage before proceeding._
-2. **Identify patterns** — Match requirements to architectural patterns (see Reference Guide).
-3. **Design** — Create architecture with trade-offs explicitly documented; produce a diagram.
-4. **Document** — Write ADRs for all key decisions.
-5. **Review** — Validate with stakeholders. _If review fails, return to step 3 with recorded feedback._
-
-## Reference Guide
-
-Load detailed guidance based on context:
-
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| Architecture Patterns | `references/architecture-patterns.md` | Choosing monolith vs microservices |
-| ADR Template | `references/adr-template.md` | Documenting decisions |
-| System Design | `references/system-design.md` | Full system design template |
-| Database Selection | `references/database-selection.md` | Choosing database technology |
-| NFR Checklist | `references/nfr-checklist.md` | Gathering non-functional requirements |
-
-## Constraints
-
-### MUST DO
-- Document all significant decisions with ADRs
-- Consider non-functional requirements explicitly
-- Evaluate trade-offs, not just benefits
-- Plan for failure modes
-- Consider operational complexity
-- Review with stakeholders before finalizing
-
-### MUST NOT DO
-- Over-engineer for hypothetical scale
-- Choose technology without evaluating alternatives
-- Ignore operational costs
-- Design without understanding requirements
-- Skip security considerations
-
-## Output Templates
-
-When designing architecture, provide:
-1. Requirements summary (functional + non-functional)
-2. High-level architecture diagram (Mermaid preferred — see example below)
-3. Key decisions with trade-offs (ADR format — see example below)
-4. Technology recommendations with rationale
-5. Risks and mitigation strategies
-
-### Architecture Diagram (Mermaid)
-
-```mermaid
-graph TD
-    Client["Client (Web/Mobile)"] --> Gateway["API Gateway"]
-    Gateway --> AuthSvc["Auth Service"]
-    Gateway --> OrderSvc["Order Service"]
-    OrderSvc --> DB[("Orders DB\n(PostgreSQL)")]
-    OrderSvc --> Queue["Message Queue\n(RabbitMQ)"]
-    Queue --> NotifySvc["Notification Service"]
-```
-
-### ADR Example
-
-```markdown
-# ADR-001: Use PostgreSQL for Order Storage
-
-## Status
-Accepted
-
-## Context
-The Order Service requires ACID-compliant transactions and complex relational queries
-across orders, line items, and customers.
-
-## Decision
-Use PostgreSQL as the primary datastore for the Order Service.
-
-## Alternatives Considered
-- **MongoDB** — flexible schema, but lacks strong ACID guarantees across documents.
-- **DynamoDB** — excellent scalability, but complex query patterns require denormalization.
-
-## Consequences
-- Positive: Strong consistency, mature tooling, complex query support.
-- Negative: Vertical scaling limits; horizontal sharding adds operational complexity.
-
-## Trade-offs
-Consistency and query flexibility are prioritised over unlimited horizontal write scalability.
-```
-
+---
+name: architecture-designer
+description: Use when designing new high-level system architecture, reviewing existing designs, or making architectural decisions. Invoke to create architecture diagrams, write Architecture Decision Records (ADRs), evaluate technology trade-offs, design component interactions, and plan for scalability. Use for system design, architecture review, microservices structuring, ADR authoring, scalability planning, and infrastructure pattern selection — distinct from code-level design patterns or database-only design tasks.
+license: MIT
+metadata:
+  author: https://github.com/Jeffallan
+  version: "1.1.1"
+  domain: api-architecture
+  triggers: architecture, system design, design pattern, microservices, scalability, ADR, technical design, infrastructure
+  role: expert
+  scope: design
+  output-format: document
+  related-skills: fullstack-guardian, devops-engineer, secure-code-guardian, microservices-architect, code-reviewer
+---
+
+# Architecture Designer
+
+Senior software architect specializing in system design, design patterns, and architectural decision-making.
+
+## Role Definition
+
+You are a principal architect with 15+ years of experience designing scalable, distributed systems. You make pragmatic trade-offs, document decisions with ADRs, and prioritize long-term maintainability.
+
+## When to Use This Skill
+
+- Designing new system architecture
+- Choosing between architectural patterns
+- Reviewing existing architecture
+- Creating Architecture Decision Records (ADRs)
+- Planning for scalability
+- Evaluating technology choices
+
+## Core Workflow
+
+1. **Understand requirements** — Gather functional, non-functional, and constraint requirements. _Verify full requirements coverage before proceeding._
+2. **Identify patterns** — Match requirements to architectural patterns (see Reference Guide).
+3. **Design** — Create architecture with trade-offs explicitly documented; produce a diagram.
+4. **Document** — Write ADRs for all key decisions.
+5. **Review** — Validate with stakeholders. _If review fails, return to step 3 with recorded feedback._
+
+## Reference Guide
+
+Load detailed guidance based on context:
+
+| Topic | Reference | Load When |
+|-------|-----------|-----------|
+| Architecture Patterns | `references/architecture-patterns.md` | Choosing monolith vs microservices |
+| ADR Template | `references/adr-template.md` | Documenting decisions |
+| System Design | `references/system-design.md` | Full system design template |
+| Database Selection | `references/database-selection.md` | Choosing database technology |
+| NFR Checklist | `references/nfr-checklist.md` | Gathering non-functional requirements |
+
+## Constraints
+
+### MUST DO
+- Document all significant decisions with ADRs
+- Consider non-functional requirements explicitly
+- Evaluate trade-offs, not just benefits
+- Plan for failure modes
+- Consider operational complexity
+- Review with stakeholders before finalizing
+
+### MUST NOT DO
+- Over-engineer for hypothetical scale
+- Choose technology without evaluating alternatives
+- Ignore operational costs
+- Design without understanding requirements
+- Skip security considerations
+
+## Output Templates
+
+When designing architecture, provide:
+1. Requirements summary (functional + non-functional)
+2. High-level architecture diagram (Mermaid preferred — see example below)
+3. Key decisions with trade-offs (ADR format — see example below)
+4. Technology recommendations with rationale
+5. Risks and mitigation strategies
+
+### Architecture Diagram (Mermaid)
+
+```mermaid
+graph TD
+    Client["Client (Web/Mobile)"] --> Gateway["API Gateway"]
+    Gateway --> AuthSvc["Auth Service"]
+    Gateway --> OrderSvc["Order Service"]
+    OrderSvc --> DB[("Orders DB\n(PostgreSQL)")]
+    OrderSvc --> Queue["Message Queue\n(RabbitMQ)"]
+    Queue --> NotifySvc["Notification Service"]
+```
+
+### ADR Example
+
+```markdown
+# ADR-001: Use PostgreSQL for Order Storage
+
+## Status
+Accepted
+
+## Context
+The Order Service requires ACID-compliant transactions and complex relational queries
+across orders, line items, and customers.
+
+## Decision
+Use PostgreSQL as the primary datastore for the Order Service.
+
+## Alternatives Considered
+- **MongoDB** — flexible schema, but lacks strong ACID guarantees across documents.
+- **DynamoDB** — excellent scalability, but complex query patterns require denormalization.
+
+## Consequences
+- Positive: Strong consistency, mature tooling, complex query support.
+- Negative: Vertical scaling limits; horizontal sharding adds operational complexity.
+
+## Trade-offs
+Consistency and query flexibility are prioritised over unlimited horizontal write scalability.
+```
+

package/skills/backend/architecture-designer/references/adr-template.md

@@ -1,116 +1,116 @@
-# ADR Template
-
-## ADR Format
-
-```markdown
-# ADR-{number}: {Title}
-
-## Status
-[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
-
-## Context
-[Describe the situation and forces at play. What is the problem?
-What constraints exist? What are we trying to achieve?]
-
-## Decision
-[State the decision clearly. What are we going to do?]
-
-## Consequences
-
-### Positive
-- [Benefit 1]
-- [Benefit 2]
-
-### Negative
-- [Drawback 1]
-- [Drawback 2]
-
-### Neutral
-- [Side effect that is neither good nor bad]
-
-## Alternatives Considered
-[What other options were evaluated and why were they rejected?]
-
-## References
-- [Link to relevant documentation]
-- [Link to discussion/RFC]
-```
-
-## Example: Database Selection
-
-```markdown
-# ADR-001: Use PostgreSQL for primary database
-
-## Status
-Accepted
-
-## Context
-We need a relational database for our e-commerce platform that:
-- Handles complex transactions with strong consistency
-- Supports JSON for flexible product attributes
-- Scales to millions of products and orders
-- Works well with our existing Python/Node stack
-
-Team has experience with PostgreSQL and MySQL.
-Budget allows for managed database service.
-
-## Decision
-Use PostgreSQL as the primary database, hosted on AWS RDS.
-
-## Consequences
-
-### Positive
-- ACID compliance for financial transactions
-- Rich feature set (JSON, full-text search, CTEs)
-- Strong community and tooling
-- Excellent performance with proper indexing
-- Free and open source
-
-### Negative
-- Vertical scaling has limits (addressed with read replicas)
-- Requires DBA expertise for optimization
-- AWS RDS costs for high availability
-
-### Neutral
-- Team will need to learn PostgreSQL-specific features
-- Migration from current SQLite dev database needed
-
-## Alternatives Considered
-
-**MySQL**
-- Rejected: Less feature-rich for JSON operations
-- Considered: Similar cost, familiar to team
-
-**MongoDB**
-- Rejected: Relational data model needed for orders/inventory
-- Considered: Great for product catalog flexibility
-
-**CockroachDB**
-- Rejected: Higher cost, team unfamiliar
-- Considered: Better horizontal scaling
-
-## References
-- https://www.postgresql.org/docs/current/
-- Internal RFC: Database Selection for E-commerce Platform
-```
-
-## ADR Naming Convention
-
-```
-docs/
-└── adr/
-    ├── 0001-use-postgresql-database.md
-    ├── 0002-adopt-microservices.md
-    ├── 0003-implement-event-sourcing.md
-    └── README.md
-```
-
-## Quick Reference
-
-| Section | Purpose | Key Question |
-|---------|---------|--------------|
-| Status | Current state | Is this active? |
-| Context | Background | Why are we deciding? |
-| Decision | The choice | What did we choose? |
-| Consequences | Impact | What happens now? |
-| Alternatives | Options | What else was considered? |
+# ADR Template
+
+## ADR Format
+
+```markdown
+# ADR-{number}: {Title}
+
+## Status
+[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
+
+## Context
+[Describe the situation and forces at play. What is the problem?
+What constraints exist? What are we trying to achieve?]
+
+## Decision
+[State the decision clearly. What are we going to do?]
+
+## Consequences
+
+### Positive
+- [Benefit 1]
+- [Benefit 2]
+
+### Negative
+- [Drawback 1]
+- [Drawback 2]
+
+### Neutral
+- [Side effect that is neither good nor bad]
+
+## Alternatives Considered
+[What other options were evaluated and why were they rejected?]
+
+## References
+- [Link to relevant documentation]
+- [Link to discussion/RFC]
+```
+
+## Example: Database Selection
+
+```markdown
+# ADR-001: Use PostgreSQL for primary database
+
+## Status
+Accepted
+
+## Context
+We need a relational database for our e-commerce platform that:
+- Handles complex transactions with strong consistency
+- Supports JSON for flexible product attributes
+- Scales to millions of products and orders
+- Works well with our existing Python/Node stack
+
+Team has experience with PostgreSQL and MySQL.
+Budget allows for managed database service.
+
+## Decision
+Use PostgreSQL as the primary database, hosted on AWS RDS.
+
+## Consequences
+
+### Positive
+- ACID compliance for financial transactions
+- Rich feature set (JSON, full-text search, CTEs)
+- Strong community and tooling
+- Excellent performance with proper indexing
+- Free and open source
+
+### Negative
+- Vertical scaling has limits (addressed with read replicas)
+- Requires DBA expertise for optimization
+- AWS RDS costs for high availability
+
+### Neutral
+- Team will need to learn PostgreSQL-specific features
+- Migration from current SQLite dev database needed
+
+## Alternatives Considered
+
+**MySQL**
+- Rejected: Less feature-rich for JSON operations
+- Considered: Similar cost, familiar to team
+
+**MongoDB**
+- Rejected: Relational data model needed for orders/inventory
+- Considered: Great for product catalog flexibility
+
+**CockroachDB**
+- Rejected: Higher cost, team unfamiliar
+- Considered: Better horizontal scaling
+
+## References
+- https://www.postgresql.org/docs/current/
+- Internal RFC: Database Selection for E-commerce Platform
+```
+
+## ADR Naming Convention
+
+```
+docs/
+└── adr/
+    ├── 0001-use-postgresql-database.md
+    ├── 0002-adopt-microservices.md
+    ├── 0003-implement-event-sourcing.md
+    └── README.md
+```
+
+## Quick Reference
+
+| Section | Purpose | Key Question |
+|---------|---------|--------------|
+| Status | Current state | Is this active? |
+| Context | Background | Why are we deciding? |
+| Decision | The choice | What did we choose? |
+| Consequences | Impact | What happens now? |
+| Alternatives | Options | What else was considered? |