agcel 1.0.1

package/skills/architecture/examples.md

@@ -0,0 +1,94 @@
+# Architecture Examples
+
+> Real-world architecture decisions by project type.
+
+---
+
+## Example 1: MVP E-commerce (Solo Developer)
+
+```yaml
+Requirements:
+  - <1000 users initially
+  - Solo developer
+  - Fast to market (8 weeks)
+  - Budget-conscious
+
+Architecture Decisions:
+  App Structure: Monolith (simpler for solo)
+  Framework: Next.js (full-stack, fast)
+  Data Layer: Prisma direct (no over-abstraction)
+  Authentication: JWT (simpler than OAuth)
+  Payment: Stripe (hosted solution)
+  Database: PostgreSQL (ACID for orders)
+
+Trade-offs Accepted:
+  - Monolith → Can't scale independently (team doesn't justify it)
+  - No Repository → Less testable (simple CRUD doesn't need it)
+  - JWT → No social login initially (can add later)
+
+Future Migration Path:
+  - Users > 10K → Extract payment service
+  - Team > 3 → Add Repository pattern
+  - Social login requested → Add OAuth
+```
+
+---
+
+## Example 2: SaaS Product (5-10 Developers)
+
+```yaml
+Requirements:
+  - 1K-100K users
+  - 5-10 developers
+  - Long-term (12+ months)
+  - Multiple domains (billing, users, core)
+
+Architecture Decisions:
+  App Structure: Modular Monolith (team size optimal)
+  Framework: NestJS (modular by design)
+  Data Layer: Repository pattern (testing, flexibility)
+  Domain Model: Partial DDD (rich entities)
+  Authentication: OAuth + JWT
+  Caching: Redis
+  Database: PostgreSQL
+
+Trade-offs Accepted:
+  - Modular Monolith → Some module coupling (microservices not justified)
+  - Partial DDD → No full aggregates (no domain experts)
+  - RabbitMQ later → Initial synchronous (add when proven needed)
+
+Migration Path:
+  - Team > 10 → Consider microservices
+  - Domains conflict → Extract bounded contexts
+  - Read performance issues → Add CQRS
+```
+
+---
+
+## Example 3: Enterprise (100K+ Users)
+
+```yaml
+Requirements:
+  - 100K+ users
+  - 10+ developers
+  - Multiple business domains
+  - Different scaling needs
+  - 24/7 availability
+
+Architecture Decisions:
+  App Structure: Microservices (independent scale)
+  API Gateway: Kong/AWS API GW
+  Domain Model: Full DDD
+  Consistency: Event-driven (eventual OK)
+  Message Bus: Kafka
+  Authentication: OAuth + SAML (enterprise SSO)
+  Database: Polyglot (right tool per job)
+  CQRS: Selected services
+
+Operational Requirements:
+  - Service mesh (Istio/Linkerd)
+  - Distributed tracing (Jaeger/Tempo)
+  - Centralized logging (ELK/Loki)
+  - Circuit breakers (Resilience4j)
+  - Kubernetes/Helm
+```

package/skills/architecture/pattern-selection.md

@@ -0,0 +1,68 @@
+# Pattern Selection Guidelines
+
+> Decision trees for choosing architectural patterns.
+
+## Main Decision Tree
+
+```
+START: What's your MAIN concern?
+
+┌─ Data Access Complexity?
+│  ├─ HIGH (complex queries, testing needed)
+│  │  → Repository Pattern + Unit of Work
+│  │  VALIDATE: Will data source change frequently?
+│  │     ├─ YES → Repository worth the indirection
+│  │     └─ NO  → Consider simpler ORM direct access
+│  └─ LOW (simple CRUD, single database)
+│     → ORM directly (Prisma, Drizzle)
+│     Simpler = Better, Faster
+│
+├─ Business Rules Complexity?
+│  ├─ HIGH (domain logic, rules vary by context)
+│  │  → Domain-Driven Design
+│  │  VALIDATE: Do you have domain experts on team?
+│  │     ├─ YES → Full DDD (Aggregates, Value Objects)
+│  │     └─ NO  → Partial DDD (rich entities, clear boundaries)
+│  └─ LOW (mostly CRUD, simple validation)
+│     → Transaction Script pattern
+│     Simpler = Better, Faster
+│
+├─ Independent Scaling Needed?
+│  ├─ YES (different components scale differently)
+│  │  → Microservices WORTH the complexity
+│  │  REQUIREMENTS (ALL must be true):
+│  │    - Clear domain boundaries
+│  │    - Team > 10 developers
+│  │    - Different scaling needs per service
+│  │  IF NOT ALL MET → Modular Monolith instead
+│  └─ NO (everything scales together)
+│     → Modular Monolith
+│     Can extract services later when proven needed
+│
+└─ Real-time Requirements?
+   ├─ HIGH (immediate updates, multi-user sync)
+   │  → Event-Driven Architecture
+   │  → Message Queue (RabbitMQ, Redis, Kafka)
+   │  VALIDATE: Can you handle eventual consistency?
+   │     ├─ YES → Event-driven valid
+   │     └─ NO  → Synchronous with polling
+   └─ LOW (eventual consistency acceptable)
+      → Synchronous (REST/GraphQL)
+      Simpler = Better, Faster
+```
+
+## The 3 Questions (Before ANY Pattern)
+
+1. **Problem Solved**: What SPECIFIC problem does this pattern solve?
+2. **Simpler Alternative**: Is there a simpler solution?
+3. **Deferred Complexity**: Can we add this LATER when needed?
+
+## Red Flags (Anti-patterns)
+
+| Pattern | Anti-pattern | Simpler Alternative |
+|---------|-------------|-------------------|
+| Microservices | Premature splitting | Start monolith, extract later |
+| Clean/Hexagonal | Over-abstraction | Concrete first, interfaces later |
+| Event Sourcing | Over-engineering | Append-only audit log |
+| CQRS | Unnecessary complexity | Single model |
+| Repository | YAGNI for simple CRUD | ORM direct access |

package/skills/architecture/patterns-reference.md

@@ -0,0 +1,50 @@
+# Architecture Patterns Reference
+
+> Quick reference for common patterns with usage guidance.
+
+## Data Access Patterns
+
+| Pattern | When to Use | When NOT to Use | Complexity |
+|---------|-------------|-----------------|------------|
+| **Active Record** | Simple CRUD, rapid prototyping | Complex queries, multiple sources | Low |
+| **Repository** | Testing needed, multiple sources | Simple CRUD, single database | Medium |
+| **Unit of Work** | Complex transactions | Simple operations | High |
+| **Data Mapper** | Complex domain, performance | Simple CRUD, rapid dev | High |
+
+## Domain Logic Patterns
+
+| Pattern | When to Use | When NOT to Use | Complexity |
+|---------|-------------|-----------------|------------|
+| **Transaction Script** | Simple CRUD, procedural | Complex business rules | Low |
+| **Table Module** | Record-based logic | Rich behavior needed | Low |
+| **Domain Model** | Complex business logic | Simple CRUD | Medium |
+| **DDD (Full)** | Complex domain, domain experts | Simple domain, no experts | High |
+
+## Distributed System Patterns
+
+| Pattern | When to Use | When NOT to Use | Complexity |
+|---------|-------------|-----------------|------------|
+| **Modular Monolith** | Small teams, unclear boundaries | Clear contexts, different scales | Medium |
+| **Microservices** | Different scales, large teams | Small teams, simple domain | Very High |
+| **Event-Driven** | Real-time, loose coupling | Simple workflows, strong consistency | High |
+| **CQRS** | Read/write performance diverges | Simple CRUD, same model | High |
+| **Saga** | Distributed transactions | Single database, simple ACID | High |
+
+## API Patterns
+
+| Pattern | When to Use | When NOT to Use | Complexity |
+|---------|-------------|-----------------|------------|
+| **REST** | Standard CRUD, resources | Real-time, complex queries | Low |
+| **GraphQL** | Flexible queries, multiple clients | Simple CRUD, caching needs | Medium |
+| **gRPC** | Internal services, performance | Public APIs, browser clients | Medium |
+| **WebSocket** | Real-time updates | Simple request/response | Medium |
+
+---
+
+## Simplicity Principle
+
+**"Start simple, add complexity only when proven necessary."**
+
+- You can always add patterns later
+- Removing complexity is MUCH harder than adding it
+- When in doubt, choose simpler option

package/skills/architecture/trade-off-analysis.md

@@ -0,0 +1,77 @@
+# Trade-off Analysis & ADR
+
+> Document every architectural decision with trade-offs.
+
+## Decision Framework
+
+For EACH architectural component, document:
+
+```markdown
+## Architecture Decision Record
+
+### Context
+- **Problem**: [What problem are we solving?]
+- **Constraints**: [Team size, scale, timeline, budget]
+
+### Options Considered
+
+| Option | Pros | Cons | Complexity | When Valid |
+|--------|------|------|------------|-----------|
+| Option A | Benefit 1 | Cost 1 | Low | [Conditions] |
+| Option B | Benefit 2 | Cost 2 | High | [Conditions] |
+
+### Decision
+**Chosen**: [Option B]
+
+### Rationale
+1. [Reason 1 - tied to constraints]
+2. [Reason 2 - tied to requirements]
+
+### Trade-offs Accepted
+- [What we're giving up]
+- [Why this is acceptable]
+
+### Consequences
+- **Positive**: [Benefits we gain]
+- **Negative**: [Costs/risks we accept]
+- **Mitigation**: [How we'll address negatives]
+
+### Revisit Trigger
+- [When to reconsider this decision]
+```
+
+## ADR Template
+
+```markdown
+# ADR-[XXX]: [Decision Title]
+
+## Status
+Proposed | Accepted | Deprecated | Superseded by [ADR-YYY]
+
+## Context
+[What problem? What constraints?]
+
+## Decision
+[What we chose - be specific]
+
+## Rationale
+[Why - tie to requirements and constraints]
+
+## Trade-offs
+[What we're giving up - be honest]
+
+## Consequences
+- **Positive**: [Benefits]
+- **Negative**: [Costs]
+- **Mitigation**: [How to address]
+```
+
+## ADR Storage
+
+```
+docs/
+└── architecture/
+    ├── adr-001-use-nextjs.md
+    ├── adr-002-postgresql-over-mongodb.md
+    └── adr-003-adopt-repository-pattern.md
+```

package/skills/aws-serverless/SKILL.md

@@ -0,0 +1,327 @@
+---
+name: aws-serverless
+description: "Specialized skill for building production-ready serverless applications on AWS. Covers Lambda functions, API Gateway, DynamoDB, SQS/SNS event-driven patterns, SAM/CDK deployment, and cold start optimization."
+source: vibeship-spawner-skills (Apache 2.0)
+---
+
+# AWS Serverless
+
+## Patterns
+
+### Lambda Handler Pattern
+
+Proper Lambda function structure with error handling
+
+**When to use**: ['Any Lambda function implementation', 'API handlers, event processors, scheduled tasks']
+
+```python
+```javascript
+// Node.js Lambda Handler
+// handler.js
+
+// Initialize outside handler (reused across invocations)
+const { DynamoDBClient } = require('@aws-sdk/client-dynamodb');
+const { DynamoDBDocumentClient, GetCommand } = require('@aws-sdk/lib-dynamodb');
+
+const client = new DynamoDBClient({});
+const docClient = DynamoDBDocumentClient.from(client);
+
+// Handler function
+exports.handler = async (event, context) => {
+  // Optional: Don't wait for event loop to clear (Node.js)
+  context.callbackWaitsForEmptyEventLoop = false;
+
+  try {
+    // Parse input based on event source
+    const body = typeof event.body === 'string'
+      ? JSON.parse(event.body)
+      : event.body;
+
+    // Business logic
+    const result = await processRequest(body);
+
+    // Return API Gateway compatible response
+    return {
+      statusCode: 200,
+      headers: {
+        'Content-Type': 'application/json',
+        'Access-Control-Allow-Origin': '*'
+      },
+      body: JSON.stringify(result)
+    };
+  } catch (error) {
+    console.error('Error:', JSON.stringify({
+      error: error.message,
+      stack: error.stack,
+      requestId: context.awsRequestId
+    }));
+
+    return {
+      statusCode: error.statusCode || 500,
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify({
+        error: error.message || 'Internal server error'
+      })
+    };
+  }
+};
+
+async function processRequest(data) {
+  // Your business logic here
+  const result = await docClient.send(new GetCommand({
+    TableName: process.env.TABLE_NAME,
+    Key: { id: data.id }
+  }));
+  return result.Item;
+}
+```
+
+```python
+# Python Lambda Handler
+# handler.py
+
+import json
+import os
+import logging
+import boto3
+from botocore.exceptions import ClientError
+
+# Initialize outside handler (reused across invocations)
+logger = logging.getLogger()
+logger.setLevel(logging.INFO)
+
+dynamodb = boto3.resource('dynamodb')
+table = dynamodb.Table(os.environ['TABLE_NAME'])
+
+def handler(event, context):
+    try:
+        # Parse i
+```
+
+### API Gateway Integration Pattern
+
+REST API and HTTP API integration with Lambda
+
+**When to use**: ['Building REST APIs backed by Lambda', 'Need HTTP endpoints for functions']
+
+```javascript
+```yaml
+# template.yaml (SAM)
+AWSTemplateFormatVersion: '2010-09-09'
+Transform: AWS::Serverless-2016-10-31
+
+Globals:
+  Function:
+    Runtime: nodejs20.x
+    Timeout: 30
+    MemorySize: 256
+    Environment:
+      Variables:
+        TABLE_NAME: !Ref ItemsTable
+
+Resources:
+  # HTTP API (recommended for simple use cases)
+  HttpApi:
+    Type: AWS::Serverless::HttpApi
+    Properties:
+      StageName: prod
+      CorsConfiguration:
+        AllowOrigins:
+          - "*"
+        AllowMethods:
+          - GET
+          - POST
+          - DELETE
+        AllowHeaders:
+          - "*"
+
+  # Lambda Functions
+  GetItemFunction:
+    Type: AWS::Serverless::Function
+    Properties:
+      Handler: src/handlers/get.handler
+      Events:
+        GetItem:
+          Type: HttpApi
+          Properties:
+            ApiId: !Ref HttpApi
+            Path: /items/{id}
+            Method: GET
+      Policies:
+        - DynamoDBReadPolicy:
+            TableName: !Ref ItemsTable
+
+  CreateItemFunction:
+    Type: AWS::Serverless::Function
+    Properties:
+      Handler: src/handlers/create.handler
+      Events:
+        CreateItem:
+          Type: HttpApi
+          Properties:
+            ApiId: !Ref HttpApi
+            Path: /items
+            Method: POST
+      Policies:
+        - DynamoDBCrudPolicy:
+            TableName: !Ref ItemsTable
+
+  # DynamoDB Table
+  ItemsTable:
+    Type: AWS::DynamoDB::Table
+    Properties:
+      AttributeDefinitions:
+        - AttributeName: id
+          AttributeType: S
+      KeySchema:
+        - AttributeName: id
+          KeyType: HASH
+      BillingMode: PAY_PER_REQUEST
+
+Outputs:
+  ApiUrl:
+    Value: !Sub "https://${HttpApi}.execute-api.${AWS::Region}.amazonaws.com/prod"
+```
+
+```javascript
+// src/handlers/get.js
+const { getItem } = require('../lib/dynamodb');
+
+exports.handler = async (event) => {
+  const id = event.pathParameters?.id;
+
+  if (!id) {
+    return {
+      statusCode: 400,
+      body: JSON.stringify({ error: 'Missing id parameter' })
+    };
+  }
+
+  const item =
+```
+
+### Event-Driven SQS Pattern
+
+Lambda triggered by SQS for reliable async processing
+
+**When to use**: ['Decoupled, asynchronous processing', 'Need retry logic and DLQ', 'Processing messages in batches']
+
+```python
+```yaml
+# template.yaml
+Resources:
+  ProcessorFunction:
+    Type: AWS::Serverless::Function
+    Properties:
+      Handler: src/handlers/processor.handler
+      Events:
+        SQSEvent:
+          Type: SQS
+          Properties:
+            Queue: !GetAtt ProcessingQueue.Arn
+            BatchSize: 10
+            FunctionResponseTypes:
+              - ReportBatchItemFailures  # Partial batch failure handling
+
+  ProcessingQueue:
+    Type: AWS::SQS::Queue
+    Properties:
+      VisibilityTimeout: 180  # 6x Lambda timeout
+      RedrivePolicy:
+        deadLetterTargetArn: !GetAtt DeadLetterQueue.Arn
+        maxReceiveCount: 3
+
+  DeadLetterQueue:
+    Type: AWS::SQS::Queue
+    Properties:
+      MessageRetentionPeriod: 1209600  # 14 days
+```
+
+```javascript
+// src/handlers/processor.js
+exports.handler = async (event) => {
+  const batchItemFailures = [];
+
+  for (const record of event.Records) {
+    try {
+      const body = JSON.parse(record.body);
+      await processMessage(body);
+    } catch (error) {
+      console.error(`Failed to process message ${record.messageId}:`, error);
+      // Report this item as failed (will be retried)
+      batchItemFailures.push({
+        itemIdentifier: record.messageId
+      });
+    }
+  }
+
+  // Return failed items for retry
+  return { batchItemFailures };
+};
+
+async function processMessage(message) {
+  // Your processing logic
+  console.log('Processing:', message);
+
+  // Simulate work
+  await saveToDatabase(message);
+}
+```
+
+```python
+# Python version
+import json
+import logging
+
+logger = logging.getLogger()
+
+def handler(event, context):
+    batch_item_failures = []
+
+    for record in event['Records']:
+        try:
+            body = json.loads(record['body'])
+            process_message(body)
+        except Exception as e:
+            logger.error(f"Failed to process {record['messageId']}: {e}")
+            batch_item_failures.append({
+                'itemIdentifier': record['messageId']
+            })
+
+    return {'batchItemFailures': batch_ite
+```
+
+## Anti-Patterns
+
+### ❌ Monolithic Lambda
+
+**Why bad**: Large deployment packages cause slow cold starts.
+Hard to scale individual operations.
+Updates affect entire system.
+
+### ❌ Large Dependencies
+
+**Why bad**: Increases deployment package size.
+Slows down cold starts significantly.
+Most of SDK/library may be unused.
+
+### ❌ Synchronous Calls in VPC
+
+**Why bad**: VPC-attached Lambdas have ENI setup overhead.
+Blocking DNS lookups or connections worsen cold starts.
+
+## ⚠️ Sharp Edges
+
+| Issue | Severity | Solution |
+|-------|----------|----------|
+| Issue | high | ## Measure your INIT phase |
+| Issue | high | ## Set appropriate timeout |
+| Issue | high | ## Increase memory allocation |
+| Issue | medium | ## Verify VPC configuration |
+| Issue | medium | ## Tell Lambda not to wait for event loop |
+| Issue | medium | ## For large file uploads |
+| Issue | high | ## Use different buckets/prefixes |
+
+
+## Gap Analysis Rule
+Always identify gaps and suggest next steps to users. In case there is no gaps anymore, then AI should clearly state that there is no gap left.