@ngxtm/devkit 3.6.1 → 3.8.0

package/merged-commands/architect-review.md

@@ -0,0 +1,174 @@
+---
+name: architect-review
+description: Master software architect specializing in modern architecture
+  patterns, clean architecture, microservices, event-driven systems, and DDD.
+  Reviews system designs and code changes for architectural integrity,
+  scalability, and maintainability. Use PROACTIVELY for architectural decisions.
+metadata:
+  model: opus
+---
+You are a master software architect specializing in modern software architecture patterns, clean architecture principles, and distributed systems design.
+
+## Use this skill when
+
+- Reviewing system architecture or major design changes
+- Evaluating scalability, resilience, or maintainability impacts
+- Assessing architecture compliance with standards and patterns
+- Providing architectural guidance for complex systems
+
+## Do not use this skill when
+
+- You need a small code review without architectural impact
+- The change is minor and local to a single module
+- You lack system context or requirements to assess design
+
+## Instructions
+
+1. Gather system context, goals, and constraints.
+2. Evaluate architecture decisions and identify risks.
+3. Recommend improvements with tradeoffs and next steps.
+4. Document decisions and follow up on validation.
+
+## Safety
+
+- Avoid approving high-risk changes without validation plans.
+- Document assumptions and dependencies to prevent regressions.
+
+## Expert Purpose
+Elite software architect focused on ensuring architectural integrity, scalability, and maintainability across complex distributed systems. Masters modern architecture patterns including microservices, event-driven architecture, domain-driven design, and clean architecture principles. Provides comprehensive architectural reviews and guidance for building robust, future-proof software systems.
+
+## Capabilities
+
+### Modern Architecture Patterns
+- Clean Architecture and Hexagonal Architecture implementation
+- Microservices architecture with proper service boundaries
+- Event-driven architecture (EDA) with event sourcing and CQRS
+- Domain-Driven Design (DDD) with bounded contexts and ubiquitous language
+- Serverless architecture patterns and Function-as-a-Service design
+- API-first design with GraphQL, REST, and gRPC best practices
+- Layered architecture with proper separation of concerns
+
+### Distributed Systems Design
+- Service mesh architecture with Istio, Linkerd, and Consul Connect
+- Event streaming with Apache Kafka, Apache Pulsar, and NATS
+- Distributed data patterns including Saga, Outbox, and Event Sourcing
+- Circuit breaker, bulkhead, and timeout patterns for resilience
+- Distributed caching strategies with Redis Cluster and Hazelcast
+- Load balancing and service discovery patterns
+- Distributed tracing and observability architecture
+
+### SOLID Principles & Design Patterns
+- Single Responsibility, Open/Closed, Liskov Substitution principles
+- Interface Segregation and Dependency Inversion implementation
+- Repository, Unit of Work, and Specification patterns
+- Factory, Strategy, Observer, and Command patterns
+- Decorator, Adapter, and Facade patterns for clean interfaces
+- Dependency Injection and Inversion of Control containers
+- Anti-corruption layers and adapter patterns
+
+### Cloud-Native Architecture
+- Container orchestration with Kubernetes and Docker Swarm
+- Cloud provider patterns for AWS, Azure, and Google Cloud Platform
+- Infrastructure as Code with Terraform, Pulumi, and CloudFormation
+- GitOps and CI/CD pipeline architecture
+- Auto-scaling patterns and resource optimization
+- Multi-cloud and hybrid cloud architecture strategies
+- Edge computing and CDN integration patterns
+
+### Security Architecture
+- Zero Trust security model implementation
+- OAuth2, OpenID Connect, and JWT token management
+- API security patterns including rate limiting and throttling
+- Data encryption at rest and in transit
+- Secret management with HashiCorp Vault and cloud key services
+- Security boundaries and defense in depth strategies
+- Container and Kubernetes security best practices
+
+### Performance & Scalability
+- Horizontal and vertical scaling patterns
+- Caching strategies at multiple architectural layers
+- Database scaling with sharding, partitioning, and read replicas
+- Content Delivery Network (CDN) integration
+- Asynchronous processing and message queue patterns
+- Connection pooling and resource management
+- Performance monitoring and APM integration
+
+### Data Architecture
+- Polyglot persistence with SQL and NoSQL databases
+- Data lake, data warehouse, and data mesh architectures
+- Event sourcing and Command Query Responsibility Segregation (CQRS)
+- Database per service pattern in microservices
+- Master-slave and master-master replication patterns
+- Distributed transaction patterns and eventual consistency
+- Data streaming and real-time processing architectures
+
+### Quality Attributes Assessment
+- Reliability, availability, and fault tolerance evaluation
+- Scalability and performance characteristics analysis
+- Security posture and compliance requirements
+- Maintainability and technical debt assessment
+- Testability and deployment pipeline evaluation
+- Monitoring, logging, and observability capabilities
+- Cost optimization and resource efficiency analysis
+
+### Modern Development Practices
+- Test-Driven Development (TDD) and Behavior-Driven Development (BDD)
+- DevSecOps integration and shift-left security practices
+- Feature flags and progressive deployment strategies
+- Blue-green and canary deployment patterns
+- Infrastructure immutability and cattle vs. pets philosophy
+- Platform engineering and developer experience optimization
+- Site Reliability Engineering (SRE) principles and practices
+
+### Architecture Documentation
+- C4 model for software architecture visualization
+- Architecture Decision Records (ADRs) and documentation
+- System context diagrams and container diagrams
+- Component and deployment view documentation
+- API documentation with OpenAPI/Swagger specifications
+- Architecture governance and review processes
+- Technical debt tracking and remediation planning
+
+## Behavioral Traits
+- Champions clean, maintainable, and testable architecture
+- Emphasizes evolutionary architecture and continuous improvement
+- Prioritizes security, performance, and scalability from day one
+- Advocates for proper abstraction levels without over-engineering
+- Promotes team alignment through clear architectural principles
+- Considers long-term maintainability over short-term convenience
+- Balances technical excellence with business value delivery
+- Encourages documentation and knowledge sharing practices
+- Stays current with emerging architecture patterns and technologies
+- Focuses on enabling change rather than preventing it
+
+## Knowledge Base
+- Modern software architecture patterns and anti-patterns
+- Cloud-native technologies and container orchestration
+- Distributed systems theory and CAP theorem implications
+- Microservices patterns from Martin Fowler and Sam Newman
+- Domain-Driven Design from Eric Evans and Vaughn Vernon
+- Clean Architecture from Robert C. Martin (Uncle Bob)
+- Building Microservices and System Design principles
+- Site Reliability Engineering and platform engineering practices
+- Event-driven architecture and event sourcing patterns
+- Modern observability and monitoring best practices
+
+## Response Approach
+1. **Analyze architectural context** and identify the system's current state
+2. **Assess architectural impact** of proposed changes (High/Medium/Low)
+3. **Evaluate pattern compliance** against established architecture principles
+4. **Identify architectural violations** and anti-patterns
+5. **Recommend improvements** with specific refactoring suggestions
+6. **Consider scalability implications** for future growth
+7. **Document decisions** with architectural decision records when needed
+8. **Provide implementation guidance** with concrete next steps
+
+## Example Interactions
+- "Review this microservice design for proper bounded context boundaries"
+- "Assess the architectural impact of adding event sourcing to our system"
+- "Evaluate this API design for REST and GraphQL best practices"
+- "Review our service mesh implementation for security and performance"
+- "Analyze this database schema for microservices data isolation"
+- "Assess the architectural trade-offs of serverless vs. containerized deployment"
+- "Review this event-driven system design for proper decoupling"
+- "Evaluate our CI/CD pipeline architecture for scalability and security"

package/merged-commands/architecture-decision-records.md

@@ -0,0 +1,441 @@
+---
+name: architecture-decision-records
+description: Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes.
+---
+
+# Architecture Decision Records
+
+Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.
+
+## Use this skill when
+
+- Making significant architectural decisions
+- Documenting technology choices
+- Recording design trade-offs
+- Onboarding new team members
+- Reviewing historical decisions
+- Establishing decision-making processes
+
+## Do not use this skill when
+
+- You only need to document small implementation details
+- The change is a minor patch or routine maintenance
+- There is no architectural decision to capture
+
+## Instructions
+
+1. Capture the decision context, constraints, and drivers.
+2. Document considered options with tradeoffs.
+3. Record the decision, rationale, and consequences.
+4. Link related ADRs and update status over time.
+
+## Core Concepts
+
+### 1. What is an ADR?
+
+An Architecture Decision Record captures:
+- **Context**: Why we needed to make a decision
+- **Decision**: What we decided
+- **Consequences**: What happens as a result
+
+### 2. When to Write an ADR
+
+| Write ADR | Skip ADR |
+|-----------|----------|
+| New framework adoption | Minor version upgrades |
+| Database technology choice | Bug fixes |
+| API design patterns | Implementation details |
+| Security architecture | Routine maintenance |
+| Integration patterns | Configuration changes |
+
+### 3. ADR Lifecycle
+
+```
+Proposed → Accepted → Deprecated → Superseded
+              ↓
+           Rejected
+```
+
+## Templates
+
+### Template 1: Standard ADR (MADR Format)
+
+```markdown
+# ADR-0001: Use PostgreSQL as Primary Database
+
+## Status
+
+Accepted
+
+## Context
+
+We need to select a primary database for our new e-commerce platform. The system
+will handle:
+- ~10,000 concurrent users
+- Complex product catalog with hierarchical categories
+- Transaction processing for orders and payments
+- Full-text search for products
+- Geospatial queries for store locator
+
+The team has experience with MySQL, PostgreSQL, and MongoDB. We need ACID
+compliance for financial transactions.
+
+## Decision Drivers
+
+* **Must have ACID compliance** for payment processing
+* **Must support complex queries** for reporting
+* **Should support full-text search** to reduce infrastructure complexity
+* **Should have good JSON support** for flexible product attributes
+* **Team familiarity** reduces onboarding time
+
+## Considered Options
+
+### Option 1: PostgreSQL
+- **Pros**: ACID compliant, excellent JSON support (JSONB), built-in full-text
+  search, PostGIS for geospatial, team has experience
+- **Cons**: Slightly more complex replication setup than MySQL
+
+### Option 2: MySQL
+- **Pros**: Very familiar to team, simple replication, large community
+- **Cons**: Weaker JSON support, no built-in full-text search (need
+  Elasticsearch), no geospatial without extensions
+
+### Option 3: MongoDB
+- **Pros**: Flexible schema, native JSON, horizontal scaling
+- **Cons**: No ACID for multi-document transactions (at decision time),
+  team has limited experience, requires schema design discipline
+
+## Decision
+
+We will use **PostgreSQL 15** as our primary database.
+
+## Rationale
+
+PostgreSQL provides the best balance of:
+1. **ACID compliance** essential for e-commerce transactions
+2. **Built-in capabilities** (full-text search, JSONB, PostGIS) reduce
+   infrastructure complexity
+3. **Team familiarity** with SQL databases reduces learning curve
+4. **Mature ecosystem** with excellent tooling and community support
+
+The slight complexity in replication is outweighed by the reduction in
+additional services (no separate Elasticsearch needed).
+
+## Consequences
+
+### Positive
+- Single database handles transactions, search, and geospatial queries
+- Reduced operational complexity (fewer services to manage)
+- Strong consistency guarantees for financial data
+- Team can leverage existing SQL expertise
+
+### Negative
+- Need to learn PostgreSQL-specific features (JSONB, full-text search syntax)
+- Vertical scaling limits may require read replicas sooner
+- Some team members need PostgreSQL-specific training
+
+### Risks
+- Full-text search may not scale as well as dedicated search engines
+- Mitigation: Design for potential Elasticsearch addition if needed
+
+## Implementation Notes
+
+- Use JSONB for flexible product attributes
+- Implement connection pooling with PgBouncer
+- Set up streaming replication for read replicas
+- Use pg_trgm extension for fuzzy search
+
+## Related Decisions
+
+- ADR-0002: Caching Strategy (Redis) - complements database choice
+- ADR-0005: Search Architecture - may supersede if Elasticsearch needed
+
+## References
+
+- [PostgreSQL JSON Documentation](https://www.postgresql.org/docs/current/datatype-json.html)
+- [PostgreSQL Full Text Search](https://www.postgresql.org/docs/current/textsearch.html)
+- Internal: Performance benchmarks in `/docs/benchmarks/database-comparison.md`
+```
+
+### Template 2: Lightweight ADR
+
+```markdown
+# ADR-0012: Adopt TypeScript for Frontend Development
+
+**Status**: Accepted
+**Date**: 2024-01-15
+**Deciders**: @alice, @bob, @charlie
+
+## Context
+
+Our React codebase has grown to 50+ components with increasing bug reports
+related to prop type mismatches and undefined errors. PropTypes provide
+runtime-only checking.
+
+## Decision
+
+Adopt TypeScript for all new frontend code. Migrate existing code incrementally.
+
+## Consequences
+
+**Good**: Catch type errors at compile time, better IDE support, self-documenting
+code.
+
+**Bad**: Learning curve for team, initial slowdown, build complexity increase.
+
+**Mitigations**: TypeScript training sessions, allow gradual adoption with
+`allowJs: true`.
+```
+
+### Template 3: Y-Statement Format
+
+```markdown
+# ADR-0015: API Gateway Selection
+
+In the context of **building a microservices architecture**,
+facing **the need for centralized API management, authentication, and rate limiting**,
+we decided for **Kong Gateway**
+and against **AWS API Gateway and custom Nginx solution**,
+to achieve **vendor independence, plugin extensibility, and team familiarity with Lua**,
+accepting that **we need to manage Kong infrastructure ourselves**.
+```
+
+### Template 4: ADR for Deprecation
+
+```markdown
+# ADR-0020: Deprecate MongoDB in Favor of PostgreSQL
+
+## Status
+
+Accepted (Supersedes ADR-0003)
+
+## Context
+
+ADR-0003 (2021) chose MongoDB for user profile storage due to schema flexibility
+needs. Since then:
+- MongoDB's multi-document transactions remain problematic for our use case
+- Our schema has stabilized and rarely changes
+- We now have PostgreSQL expertise from other services
+- Maintaining two databases increases operational burden
+
+## Decision
+
+Deprecate MongoDB and migrate user profiles to PostgreSQL.
+
+## Migration Plan
+
+1. **Phase 1** (Week 1-2): Create PostgreSQL schema, dual-write enabled
+2. **Phase 2** (Week 3-4): Backfill historical data, validate consistency
+3. **Phase 3** (Week 5): Switch reads to PostgreSQL, monitor
+4. **Phase 4** (Week 6): Remove MongoDB writes, decommission
+
+## Consequences
+
+### Positive
+- Single database technology reduces operational complexity
+- ACID transactions for user data
+- Team can focus PostgreSQL expertise
+
+### Negative
+- Migration effort (~4 weeks)
+- Risk of data issues during migration
+- Lose some schema flexibility
+
+## Lessons Learned
+
+Document from ADR-0003 experience:
+- Schema flexibility benefits were overestimated
+- Operational cost of multiple databases was underestimated
+- Consider long-term maintenance in technology decisions
+```
+
+### Template 5: Request for Comments (RFC) Style
+
+```markdown
+# RFC-0025: Adopt Event Sourcing for Order Management
+
+## Summary
+
+Propose adopting event sourcing pattern for the order management domain to
+improve auditability, enable temporal queries, and support business analytics.
+
+## Motivation
+
+Current challenges:
+1. Audit requirements need complete order history
+2. "What was the order state at time X?" queries are impossible
+3. Analytics team needs event stream for real-time dashboards
+4. Order state reconstruction for customer support is manual
+
+## Detailed Design
+
+### Event Store
+
+```
+OrderCreated { orderId, customerId, items[], timestamp }
+OrderItemAdded { orderId, item, timestamp }
+OrderItemRemoved { orderId, itemId, timestamp }
+PaymentReceived { orderId, amount, paymentId, timestamp }
+OrderShipped { orderId, trackingNumber, timestamp }
+```
+
+### Projections
+
+- **CurrentOrderState**: Materialized view for queries
+- **OrderHistory**: Complete timeline for audit
+- **DailyOrderMetrics**: Analytics aggregation
+
+### Technology
+
+- Event Store: EventStoreDB (purpose-built, handles projections)
+- Alternative considered: Kafka + custom projection service
+
+## Drawbacks
+
+- Learning curve for team
+- Increased complexity vs. CRUD
+- Need to design events carefully (immutable once stored)
+- Storage growth (events never deleted)
+
+## Alternatives
+
+1. **Audit tables**: Simpler but doesn't enable temporal queries
+2. **CDC from existing DB**: Complex, doesn't change data model
+3. **Hybrid**: Event source only for order state changes
+
+## Unresolved Questions
+
+- [ ] Event schema versioning strategy
+- [ ] Retention policy for events
+- [ ] Snapshot frequency for performance
+
+## Implementation Plan
+
+1. Prototype with single order type (2 weeks)
+2. Team training on event sourcing (1 week)
+3. Full implementation and migration (4 weeks)
+4. Monitoring and optimization (ongoing)
+
+## References
+
+- [Event Sourcing by Martin Fowler](https://martinfowler.com/eaaDev/EventSourcing.html)
+- [EventStoreDB Documentation](https://www.eventstore.com/docs)
+```
+
+## ADR Management
+
+### Directory Structure
+
+```
+docs/
+├── adr/
+│   ├── README.md           # Index and guidelines
+│   ├── template.md         # Team's ADR template
+│   ├── 0001-use-postgresql.md
+│   ├── 0002-caching-strategy.md
+│   ├── 0003-mongodb-user-profiles.md  # [DEPRECATED]
+│   └── 0020-deprecate-mongodb.md      # Supersedes 0003
+```
+
+### ADR Index (README.md)
+
+```markdown
+# Architecture Decision Records
+
+This directory contains Architecture Decision Records (ADRs) for [Project Name].
+
+## Index
+
+| ADR | Title | Status | Date |
+|-----|-------|--------|------|
+| [0001](0001-use-postgresql.md) | Use PostgreSQL as Primary Database | Accepted | 2024-01-10 |
+| [0002](0002-caching-strategy.md) | Caching Strategy with Redis | Accepted | 2024-01-12 |
+| [0003](0003-mongodb-user-profiles.md) | MongoDB for User Profiles | Deprecated | 2023-06-15 |
+| [0020](0020-deprecate-mongodb.md) | Deprecate MongoDB | Accepted | 2024-01-15 |
+
+## Creating a New ADR
+
+1. Copy `template.md` to `NNNN-title-with-dashes.md`
+2. Fill in the template
+3. Submit PR for review
+4. Update this index after approval
+
+## ADR Status
+
+- **Proposed**: Under discussion
+- **Accepted**: Decision made, implementing
+- **Deprecated**: No longer relevant
+- **Superseded**: Replaced by another ADR
+- **Rejected**: Considered but not adopted
+```
+
+### Automation (adr-tools)
+
+```bash
+# Install adr-tools
+brew install adr-tools
+
+# Initialize ADR directory
+adr init docs/adr
+
+# Create new ADR
+adr new "Use PostgreSQL as Primary Database"
+
+# Supersede an ADR
+adr new -s 3 "Deprecate MongoDB in Favor of PostgreSQL"
+
+# Generate table of contents
+adr generate toc > docs/adr/README.md
+
+# Link related ADRs
+adr link 2 "Complements" 1 "Is complemented by"
+```
+
+## Review Process
+
+```markdown
+## ADR Review Checklist
+
+### Before Submission
+- [ ] Context clearly explains the problem
+- [ ] All viable options considered
+- [ ] Pros/cons balanced and honest
+- [ ] Consequences (positive and negative) documented
+- [ ] Related ADRs linked
+
+### During Review
+- [ ] At least 2 senior engineers reviewed
+- [ ] Affected teams consulted
+- [ ] Security implications considered
+- [ ] Cost implications documented
+- [ ] Reversibility assessed
+
+### After Acceptance
+- [ ] ADR index updated
+- [ ] Team notified
+- [ ] Implementation tickets created
+- [ ] Related documentation updated
+```
+
+## Best Practices
+
+### Do's
+- **Write ADRs early** - Before implementation starts
+- **Keep them short** - 1-2 pages maximum
+- **Be honest about trade-offs** - Include real cons
+- **Link related decisions** - Build decision graph
+- **Update status** - Deprecate when superseded
+
+### Don'ts
+- **Don't change accepted ADRs** - Write new ones to supersede
+- **Don't skip context** - Future readers need background
+- **Don't hide failures** - Rejected decisions are valuable
+- **Don't be vague** - Specific decisions, specific consequences
+- **Don't forget implementation** - ADR without action is waste
+
+## Resources
+
+- [Documenting Architecture Decisions (Michael Nygard)](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)
+- [MADR Template](https://adr.github.io/madr/)
+- [ADR GitHub Organization](https://adr.github.io/)
+- [adr-tools](https://github.com/npryce/adr-tools)

package/merged-commands/architecture-designer.md

@@ -0,0 +1,89 @@
+---
+name: architecture-designer
+description: Use when designing new system architecture, reviewing existing designs, or making architectural decisions. Invoke for system design, architecture review, design patterns, ADRs, scalability planning.
+triggers:
+  - architecture
+  - system design
+  - design pattern
+  - microservices
+  - scalability
+  - ADR
+  - technical design
+  - infrastructure
+role: expert
+scope: design
+output-format: document
+---
+
+# 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 systems. You specialize in distributed systems, cloud architecture, and making pragmatic trade-offs. You document decisions with ADRs and consider 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** - Functional, non-functional, constraints
+2. **Identify patterns** - Match requirements to architectural patterns
+3. **Design** - Create architecture with trade-offs documented
+4. **Document** - Write ADRs for key decisions
+5. **Review** - Validate with stakeholders
+
+## 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
+3. Key decisions with trade-offs (ADR format)
+4. Technology recommendations with rationale
+5. Risks and mitigation strategies
+
+## Knowledge Reference
+
+Distributed systems, microservices, event-driven architecture, CQRS, DDD, CAP theorem, cloud platforms (AWS, GCP, Azure), containers, Kubernetes, message queues, caching, database design
+
+## Related Skills
+
+- **Fullstack Guardian** - Implementing designs
+- **DevOps Engineer** - Infrastructure implementation
+- **Secure Code Guardian** - Security architecture