@wipal/agent-team 1.0.0

package/.claude/skills/domain/architecture/adr-writing/references/adr-examples.md

@@ -0,0 +1,246 @@
+# ADR Examples
+
+Real-world examples of Architecture Decision Records.
+
+---
+
+## Example 1: Database Selection
+
+# ADR-001: Use PostgreSQL for Primary Database
+
+## Status
+Accepted
+
+## Context
+Our e-commerce application requires a relational database for:
+- User accounts and authentication
+- Product catalog with complex relationships
+- Order management with ACID transactions
+- Inventory tracking with strong consistency
+
+Current situation:
+- MySQL 5.7 running on single EC2 instance
+- Approaching capacity limits (500GB)
+- No high availability
+- Manual backups
+
+Requirements:
+- ACID compliance
+- JSON support for flexible product attributes
+- Full-text search capability
+- High availability
+- Managed service preferred
+
+## Decision
+We will use Amazon RDS for PostgreSQL as our primary database.
+
+Configuration:
+- Instance: db.r6g.xlarge (4 vCPU, 32GB RAM)
+- Multi-AZ deployment for HA
+- 1TB gp3 storage with auto-scaling
+- PostgreSQL 15.x
+
+## Consequences
+
+### Positive
+- Strong ACID compliance for financial transactions
+- Native JSON support eliminates need for separate document store
+- Built-in full-text search reduces infrastructure
+- Managed service reduces operational burden
+- Point-in-time recovery for backups
+- Better query optimizer than MySQL for complex joins
+
+### Negative
+- Team needs to learn PostgreSQL (MySQL experience currently)
+- Migration effort estimated at 3 weeks
+- Higher cost than self-managed ($800/month vs $400/month)
+- Some MySQL-specific queries need rewriting
+
+### Risks
+| Risk | Likelihood | Impact | Mitigation |
+|------|------------|--------|------------|
+| Migration data loss | Low | High | Test migration 3x, use CDC |
+| Performance regression | Medium | Medium | Load test with production data |
+| Team learning curve | High | Low | Training budget allocated |
+
+## Alternatives Considered
+
+### Option 1: Continue with MySQL (upgraded)
+- **Pros**: No migration, team expertise
+- **Cons**: Limited JSON support, no native full-text, more ops
+- **Why not**: Doesn't meet requirements for JSON and search
+
+### Option 2: Amazon Aurora MySQL
+- **Pros**: MySQL compatible, managed, better performance
+- **Cons**: More expensive, still MySQL limitations
+- **Why not**: JSON and full-text still limited
+
+### Option 3: MongoDB + PostgreSQL
+- **Pros**: Best of both worlds
+- **Cons**: Operational complexity, data sync issues
+- **Why not**: Over-engineering for current needs
+
+## Related Decisions
+- ADR-002: Database Migration Strategy
+- ADR-005: Backup and Disaster Recovery
+
+## References
+- [PostgreSQL vs MySQL comparison](link)
+- [Migration plan document](link)
+- [Cost analysis spreadsheet](link)
+
+---
+
+## Example 2: API Style
+
+# ADR-005: Use GraphQL for Public API
+
+## Status
+Accepted
+
+## Context
+Our mobile application makes 15+ API calls to render the home screen.
+This results in:
+- Slow load times (3+ seconds)
+- High bandwidth usage
+- Poor user experience
+- N+1 query problems
+
+Current REST API:
+- `/api/users/{id}`
+- `/api/users/{id}/orders`
+- `/api/orders/{id}/items`
+- `/api/products/{id}`
+- etc.
+
+Mobile team reports frustration with over/under-fetching.
+
+## Decision
+We will implement GraphQL for our public-facing APIs.
+
+Implementation:
+- Apollo Server on Node.js
+- Schema-first design
+- DataLoader for N+1 prevention
+- Persisted queries for production
+- Keep REST for internal services
+
+## Consequences
+
+### Positive
+- Single request for complex data
+- Clients fetch exactly what they need
+- Self-documenting API
+- Strong typing with schema
+- Better mobile performance
+
+### Negative
+- Learning curve for team
+- New caching strategy needed
+- Query complexity analysis required
+- Different error handling
+- File uploads more complex
+
+## Alternatives Considered
+
+### Option 1: REST with include parameters
+```
+GET /api/users/1?include=orders.items.product
+```
+- **Why not**: Non-standard, limited flexibility
+
+### Option 2: Custom endpoints per screen
+- **Why not**: Maintenance burden, tight coupling
+
+### Option 3: gRPC
+- **Why not**: Not browser-friendly, overkill for JSON
+
+## Related Decisions
+- ADR-006: GraphQL Security Guidelines
+- ADR-007: API Rate Limiting Strategy
+
+---
+
+## Example 3: Microservices Decision
+
+# ADR-010: Split Order Service from Monolith
+
+## Status
+Accepted
+
+## Context
+The Order module in our monolith has:
+- Different scaling requirements (high traffic during sales)
+- Different reliability requirements (critical path)
+- Dedicated team of 6 developers
+- Clear bounded context (DDD)
+
+Current pain points:
+- Full application deployment for order changes
+- Order bugs affect entire system
+- Team blocked by other teams' changes
+
+## Decision
+Extract Order Service as a separate microservice.
+
+Boundaries:
+- Order creation and management
+- Payment processing
+- Order status tracking
+
+NOT included:
+- Inventory (stays in monolith for now)
+- User management (stays in monolith)
+- Product catalog (stays in monolith)
+
+## Consequences
+
+### Positive
+- Independent deployment and scaling
+- Team autonomy
+- Technology choice freedom
+- Fault isolation
+- Clearer ownership
+
+### Negative
+- Distributed system complexity
+- Need for API versioning
+- Monitoring complexity increases
+- Data consistency across boundaries
+
+## Implementation Timeline
+1. Week 1-2: Define API contract
+2. Week 3-4: Implement service
+3. Week 5-6: Strangler migration
+4. Week 7: Cut over and monitor
+
+## Related Decisions
+- ADR-011: Service Communication Pattern
+- ADR-012: Order Service Database Design
+
+---
+
+## Example 4: Deprecating a Decision
+
+# ADR-003: Use Redis for Session Storage
+
+## Status
+**Deprecated** - See ADR-015
+
+## Context
+[Historical context preserved]
+
+## Decision
+We used Redis for session storage.
+
+## Consequences
+[Historical consequences preserved]
+
+## Deprecation Note
+**Date**: 2024-06-15
+**Reason**: Moving to JWT-based stateless authentication
+**Migration**: See ADR-015 for migration plan
+**Timeline**: Full migration by 2024-08-01
+
+## Related Decisions
+- **Superseded by**: ADR-015: JWT Authentication

package/.claude/skills/domain/architecture/adr-writing/references/adr-template.md

@@ -0,0 +1,160 @@
+# ADR Template
+
+This is the standard template for Architecture Decision Records.
+
+---
+
+# ADR-XXX: [Title]
+
+## Meta
+- **Status**: [Proposed | Accepted | Deprecated | Superseded]
+- **Date**: YYYY-MM-DD
+- **Decision Makers**: @username1, @username2
+- **Consulted**: @username3, @username4
+- **Informed**: @team-name
+
+## Status
+[Proposed | Accepted | Deprecated | Superseded by ADR-YYY]
+
+If Superseded, link to the new ADR.
+
+## Context
+
+### Problem Statement
+[What is the issue that we're seeing? What problem needs to be solved?]
+
+### Business Context
+[Why is this important? What business need drives this?]
+
+### Technical Context
+[What is the current technical situation?]
+[What constraints exist?]
+
+### Requirements
+- Requirement 1
+- Requirement 2
+- Requirement 3
+
+### Constraints
+- Constraint 1 (e.g., budget, timeline, team expertise)
+- Constraint 2
+- Constraint 3
+
+## Decision
+
+### Summary
+[One sentence summary of the decision]
+
+### Details
+[Detailed description of the decision. Be specific and concrete.]
+
+### Implementation
+[How will this be implemented? What are the steps?]
+
+### Timeline
+[When will this be implemented?]
+
+## Consequences
+
+### Positive
+1. [Benefit 1]
+2. [Benefit 2]
+3. [Benefit 3]
+
+### Negative
+1. [Drawback 1]
+2. [Drawback 2]
+3. [Drawback 3]
+
+### Neutral
+1. [Side effect 1 - neither good nor bad]
+2. [Side effect 2]
+
+### Risks and Mitigations
+| Risk | Likelihood | Impact | Mitigation |
+|------|------------|--------|------------|
+| Risk 1 | High/Medium/Low | High/Medium/Low | How to mitigate |
+| Risk 2 | ... | ... | ... |
+
+## Alternatives Considered
+
+### Option 1: [Name]
+**Description**: [Brief description]
+
+**Pros**:
+- Pro 1
+- Pro 2
+
+**Cons**:
+- Con 1
+- Con 2
+
+**Why not chosen**: [Reason]
+
+### Option 2: [Name]
+**Description**: [Brief description]
+
+**Pros**:
+- Pro 1
+- Pro 2
+
+**Cons**:
+- Con 1
+- Con 2
+
+**Why not chosen**: [Reason]
+
+### Option 3: [Name]
+[Same structure]
+
+## Decision Criteria
+| Criteria | Weight | Option 1 | Option 2 | Option 3 |
+|----------|--------|----------|----------|----------|
+| [Criterion 1] | 25% | 5/5 | 3/5 | 4/5 |
+| [Criterion 2] | 25% | 4/5 | 5/5 | 3/5 |
+| [Criterion 3] | 25% | 3/5 | 4/5 | 5/5 |
+| [Criterion 4] | 25% | 4/5 | 3/5 | 4/5 |
+| **Total** | 100% | **4.0** | **3.75** | **4.0** |
+
+## Related Decisions
+- ADR-XXX: [Title] - [Relationship description]
+- ADR-YYY: [Title] - [Relationship description]
+
+## References
+- [Link to relevant documentation]
+- [Link to RFC or proposal]
+- [Link to meeting notes]
+- [Link to external articles]
+
+## Notes
+[Any additional notes or context]
+
+## Review History
+| Date | Reviewer | Action | Notes |
+|------|----------|--------|-------|
+| YYYY-MM-DD | @username | Reviewed | [Feedback] |
+| YYYY-MM-DD | @username | Approved | [Comments] |
+
+---
+
+## Quick Template (Minimal)
+
+```markdown
+# ADR-XXX: [Title]
+
+## Status
+[Proposed | Accepted | Deprecated | Superseded by ADR-YYY]
+
+## Context
+[Why are we making this decision?]
+
+## Decision
+[What is the change?]
+
+## Consequences
+- [What becomes easier/harder?]
+
+## Alternatives Considered
+- Option A: [Why not chosen]
+- Option B: [Why not chosen]
+```

package/.claude/skills/domain/architecture/architecture-patterns/SKILL.md

@@ -0,0 +1,316 @@
+---
+name: architecture-patterns
+description: |
+  Use when choosing or implementing architecture patterns like microservices,
+  monolith, event-driven, or serverless. Covers patterns, trade-offs,
+  and when to use each approach.
+version: 1.0.0
+category: architecture
+tags:
+  - microservices
+  - monolith
+  - event-driven
+  - serverless
+  - patterns
+dependencies:
+  - system-design
+references:
+  - references/microservices.md
+  - references/monolith.md
+  - references/event-driven.md
+  - references/serverless.md
+---
+
+# Architecture Patterns
+
+## Core Principle
+**Choose the architecture that fits your problem, team, and scale - not what's trendy.**
+
+## When to Use This Skill
+
+### Trigger Conditions
+- Starting a new project
+- Evaluating current architecture
+- Planning a migration
+- Scaling challenges
+- Team structure changes
+
+### Keywords
+- "microservices"
+- "monolith"
+- "serverless"
+- "event-driven"
+- "architecture pattern"
+- "service decomposition"
+
+## Pattern Comparison
+
+| Pattern | Complexity | Scale | Team Size | Best For |
+|---------|------------|-------|-----------|----------|
+| **Monolith** | Low | Medium | Small-Medium | Early stage, simple domains |
+| **Microservices** | High | High | Large | Complex domains, independent scaling |
+| **Event-Driven** | Medium-High | High | Medium-Large | Async workflows, real-time |
+| **Serverless** | Medium | Auto | Any | Variable load, quick prototypes |
+| **Modular Monolith** | Medium | Medium | Medium | Growing products, bounded contexts |
+
+## Architecture Styles Overview
+
+### 1. Monolithic Architecture
+```
+┌─────────────────────────────────────────┐
+│            Monolith Application         │
+├─────────────────────────────────────────┤
+│  ┌─────────┐ ┌─────────┐ ┌─────────┐  │
+│  │  Users  │ │ Orders  │ │Products │  │
+│  │ Module  │ │ Module  │ │ Module  │  │
+│  └─────────┘ └─────────┘ └─────────┘  │
+│  ┌─────────────────────────────────┐   │
+│  │         Shared Database         │   │
+│  └─────────────────────────────────┘   │
+└─────────────────────────────────────────┘
+
+Pros:
+- Simple to develop and deploy
+- Easy to debug and test
+- Low operational overhead
+- Strong consistency
+
+Cons:
+- Can become complex over time
+- Scaling requires full deployment
+- Technology lock-in
+- Single point of failure
+```
+
+### 2. Microservices Architecture
+```
+┌───────────┐ ┌───────────┐ ┌───────────┐
+│  User     │ │  Order    │ │ Product   │
+│ Service   │ │ Service   │ │ Service   │
+└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
+      │             │             │
+      ▼             ▼             ▼
+ ┌─────────┐  ┌─────────┐  ┌─────────┐
+ │ User DB │  │Order DB │  │ Prod DB │
+ └─────────┘  └─────────┘  └─────────┘
+
+Pros:
+- Independent deployment and scaling
+- Technology flexibility
+- Team autonomy
+- Fault isolation
+
+Cons:
+- Distributed system complexity
+- Operational overhead
+- Data consistency challenges
+- Network latency
+```
+
+### 3. Event-Driven Architecture
+```
+                    ┌─────────────┐
+                    │   Event     │
+                    │   Broker    │
+                    └──────┬──────┘
+                           │
+        ┌──────────────────┼──────────────────┐
+        │                  │                  │
+        ▼                  ▼                  ▼
+ ┌───────────┐      ┌───────────┐      ┌───────────┐
+ │  Service  │      │  Service  │      │  Service  │
+ │    A      │      │    B      │      │    C      │
+ └─────┬─────┘      └─────┬─────┘      └─────┬─────┘
+       │                  │                  │
+       └──────────────────┴──────────────────┘
+                     produces events
+
+Pros:
+- Loose coupling
+- Async processing
+- Easy to add consumers
+- Scalable
+
+Cons:
+- Eventual consistency
+- Debugging complexity
+- Event schema evolution
+- Message ordering
+```
+
+### 4. Serverless Architecture
+```
+┌─────────┐     ┌─────────────┐     ┌─────────────┐
+│ API     │────▶│  Lambda/    │────▶│   Managed   │
+│ Gateway │     │  Function   │     │   Services  │
+└─────────┘     └─────────────┘     └─────────────┘
+                      │
+                      ▼
+               ┌─────────────┐
+               │  DynamoDB/  │
+               │  S3/SQS     │
+               └─────────────┘
+
+Pros:
+- No server management
+- Auto-scaling
+- Pay per use
+- Fast time to market
+
+Cons:
+- Vendor lock-in
+- Cold starts
+- Debugging challenges
+- Limited execution time
+```
+
+## Decision Framework
+
+### When to Choose Monolith
+```
+✅ Early-stage startup
+✅ Small team (< 10 developers)
+✅ Simple domain
+✅ Quick time to market needed
+✅ Limited operational expertise
+✅ Tight budget
+```
+
+### When to Choose Microservices
+```
+✅ Large team (> 20 developers)
+✅ Complex domain with bounded contexts
+✅ Need independent scaling
+✅ Different technology requirements
+✅ Need fault isolation
+✅ Multiple deployment cadences needed
+```
+
+### When to Choose Event-Driven
+```
+✅ Async workflows
+✅ Real-time processing needs
+✅ High throughput
+✅ Loose coupling required
+✅ Event sourcing requirements
+✅ CQRS pattern needed
+```
+
+### When to Choose Serverless
+```
+✅ Unpredictable/variable traffic
+✅ Event-based triggers
+✅ Quick prototyping
+✅ Small, stateless functions
+✅ Limited ops team
+✅ Cost optimization for low traffic
+```
+
+## Migration Paths
+
+### Monolith to Microservices
+```
+Phase 1: Modularize
+- Identify bounded contexts
+- Create clear module boundaries
+- Establish interfaces between modules
+
+Phase 2: Extract
+- Start with least coupled service
+- Strangler fig pattern
+- One service at a time
+
+Phase 3: Independent
+- Separate databases
+- Independent deployment
+- Own infrastructure
+```
+
+### Strangler Fig Pattern
+```
+Original:                    After:
+┌─────────────────┐         ┌─────────────────┐
+│    Monolith     │         │    Monolith     │
+│                 │         │   (remaining)   │
+└────────┬────────┘         └────────┬────────┘
+         │                           │
+         │                           │
+         │              ┌────────────┼────────────┐
+         │              │            │            │
+         ▼              ▼            ▼            ▼
+    ┌─────────┐    ┌─────────┐  ┌─────────┐  ┌─────────┐
+    │ Service │    │ Service │  │ Service │  │ Service │
+    │    A    │    │    B    │  │    C    │  │    D    │
+    └─────────┘    └─────────┘  └─────────┘  └─────────┘
+
+Route new features to new services.
+Gradually migrate existing functionality.
+```
+
+## Common Patterns by Domain
+
+### E-commerce
+```
+Services:
+- Product Catalog
+- Shopping Cart
+- Order Management
+- Payment Processing
+- Inventory
+- User Management
+- Search
+- Recommendations
+
+Events:
+- ProductViewed
+- CartUpdated
+- OrderPlaced
+- PaymentProcessed
+- InventoryUpdated
+```
+
+### Social Media
+```
+Services:
+- User Service
+- Post Service
+- Feed Service
+- Notification Service
+- Media Service
+- Search Service
+
+Events:
+- UserFollowed
+- PostCreated
+- PostLiked
+- CommentAdded
+```
+
+## Rules
+
+### DO
+- ✅ Start with monolith unless you have clear reasons
+- ✅ Design for decomposition from the start
+- ✅ Use bounded contexts to define service boundaries
+- ✅ Keep services loosely coupled
+- ✅ Have strong monitoring and observability
+
+### DON'T
+- ❌ Start with microservices for a new product
+- ❌ Create distributed monolith (services tightly coupled)
+- ❌ Share databases between services
+- ❌ Make synchronous calls everywhere
+- ❌ Ignore operational complexity
+
+## Output
+
+When using this skill, produce:
+1. **Architecture Decision Record** - Why this pattern was chosen
+2. **Service Map** - If microservices, define boundaries
+3. **Communication Patterns** - How services interact
+4. **Migration Plan** - If changing architecture
+
+## Related Skills
+- `system-design` - Core distributed systems concepts
+- `adr-writing` - Document architecture decisions
+- `api-design` - Service interfaces