agents-united 1.0.0 → 1.2.0

package/registry/skills/ad-attribution-modeling/SKILL.md

@@ -0,0 +1,202 @@
+---
+name: ad-attribution-modeling
+description: Production-grade Ad Attribution Modeling playbook for multi-touch attribution (MTA), ROAS/CAC calculation, marketing mix modeling (MMM), and Server-to-Server Conversions API integration.
+metadata:
+  author: "agents-united"
+  version: "2.0.0"
+---
+
+# Multi-Touch Ad Attribution Modeling & ROAS/CAC Analytics Engine
+
+## Overview & Purpose
+The Ad Attribution Modeling skill provides a mathematical and technical framework for calculating marketing ROI across multi-touch buyer journeys.
+
+Following this skill implements Multi-Touch Attribution models (First-Touch, Last-Touch, Linear, U-Shaped, W-Shaped, Data-Driven/Algorithmic), Server-to-Server Conversions API pipelines (Meta CAPI, Google Enhanced Conversions) to bypass browser ad-blockers, and Blended vs. Paid CAC reconciliation across cohort payback windows.
+
+## Execution Triggers & Prerequisites
+### Execution Triggers
+- Resolving attribution discrepancies between Google Ads, Meta Ads, and Stripe/CRM revenue.
+- Deploying Server-Side Conversions API (CAPI) to combat iOS ATT tracking signal loss.
+- Evaluating channel efficiency across complex multi-channel buyer touchpoints.
+- Calculating cohort-level customer acquisition payback periods and LTV:CAC ratios.
+
+### Prerequisites
+- Event telemetry pipeline (Segment, RudderStack, PostHog, or custom event stream).
+- Server-side ad platform credentials (Meta Pixel Access Token, Google Conversion API tokens).
+- Transaction ledger or billing database access (Stripe API, PostgreSQL orders table).
+- Clean git working directory.
+
+## Input & Output Requirements
+### Inputs
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `touchpoint_events` | Array<Object> | Yes | Stream of user interaction events with UTM parameters |
+| `conversion_events` | Array<Object> | Yes | Completed purchase/signup events with revenue value |
+| `channel_ad_spend` | Object | Yes | Cost breakdown by channel for the observation period |
+| `attribution_model` | String | Optional | Model: `first_touch`, `last_touch`, `linear`, `u_shaped`, `w_shaped` |
+| `lookback_window_days`| Number | Optional | Attribution lookback window in days (default: 30) |
+
+### Outputs
+| Artifact | Path / Format | Description |
+|---|---|---|
+| Attribution Spec Document | `docs/ad-attribution-modeling/attribution-spec.md` | Model formulas, lookback definitions, CAPI specs |
+| Attribution Engine Module | `src/analytics/attribution-engine.ts` | Multi-touch weighting and calculations |
+| Server CAPI Dispatcher | `src/analytics/server-capi-dispatcher.ts` | Server-to-server conversion event sender |
+| Channel ROAS Report | `reports/ad-attribution-modeling/roas-summary.json` | Attribution weights, ROAS, and CAC by channel |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Touchpoint Event Telemetry & Server-Side Ingestion Setup
+1. Ingest raw customer session touchpoint streams (First Visit, Organic Search, Paid Click, Newsletter Open, Trial Signup, Purchase).
+2. Standardize touchpoint schemas: extract `userId`, `anonymousId`, `timestamp`, `channel`, `campaign`, `adId`, `landingPage`.
+3. Filter out bot traffic, internal testing IP addresses, and invalid referrers.
+4. Persist touchpoint history in structured analytical storage keyed by resolved customer identity.
+
+### Phase 2: Attribution Model Algorithm Selection & Weight Formulation
+1. Formulate mathematical weight distribution algorithms:
+   - **First-Touch**: 100% weight to initial discovery channel.
+   - **Last-Touch**: 100% weight to final pre-conversion interaction.
+   - **Linear**: Equal distribution across all $N$ touchpoints ($1/N$).
+   - **U-Shaped**: 40% First-Touch, 40% Lead Creation Touch, 20% split across intermediate touches.
+   - **W-Shaped**: 30% First-Touch, 30% Lead Creation, 30% Opportunity Creation, 10% intermediate touches.
+2. Apply lookback window filtering (discard touchpoints older than 30 or 90 days before conversion).
+
+### Phase 3: Multi-Touch Conversion Path Calculation & Blended Metric Synthesis
+1. Execute multi-touch weighting calculations across all cohort conversion paths.
+2. Aggregate attributed revenue per channel: $\text{Attributed Revenue} = \sum (\text{Order Value} \times \text{Touchpoint Weight})$.
+3. Compute channel-specific ROAS: $\text{ROAS} = \text{Attributed Revenue} / \text{Channel Ad Spend}$.
+4. Compute Blended CAC vs Paid CAC:
+   - $\text{Blended CAC} = \text{Total Marketing Spend} / \text{Total New Customers}$
+   - $\text{Paid CAC} = \text{Paid Ad Spend} / \text{Paid Attributed Customers}$
+
+### Phase 4: Server-to-Server Conversions API (CAPI) Pipeline Deployment
+1. Implement server-side dispatch worker capturing server-verified conversions (e.g. Stripe checkout completed).
+2. Hash customer PII identifiers (email, phone, name) using SHA-256 before transmission.
+3. Attach shared `event_id` and browser `fbp`/`fbc` cookies to enable ad platform deduplication with client pixels.
+4. Dispatch payload to Meta Conversions API and Google Ads Enhanced Conversions endpoints.
+
+### Phase 5: Cohort LTV/CAC Payback Window Auditing & Executive Reporting
+1. Calculate cohort payback period: $\text{Payback Months} = \text{CAC} / (\text{ARPU} \times \text{Gross Margin \%})$.
+2. Generate executive attribution summary report at `reports/ad-attribution-modeling/roas-summary.json`.
+3. Highlight underperforming channels where CAC exceeds LTV / 3 payback threshold.
+4. Commit attribution analytics engine to repository.
+   ```bash
+   git add src/analytics/ docs/ad-attribution-modeling/
+   git commit -m "feat(ad-attribution-modeling): implement multi-touch attribution and server CAPI engine"
+   ```
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: TypeScript Multi-Touch Attribution Engine
+```typescript
+export interface Touchpoint {
+  channel: string;
+  timestamp: number;
+}
+
+export type AttributionModel = 'first_touch' | 'last_touch' | 'linear' | 'u_shaped';
+
+export function calculateAttributedWeights(
+  touchpoints: Touchpoint[],
+  model: AttributionModel
+): Record<string, number> {
+  const result: Record<string, number> = {};
+  const n = touchpoints.length;
+  if (n === 0) return result;
+
+  touchpoints.forEach(t => { result[t.channel] = (result[t.channel] || 0); });
+
+  if (n === 1 || model === 'first_touch') {
+    result[touchpoints[0].channel] += 1.0;
+    return result;
+  }
+  if (model === 'last_touch') {
+    result[touchpoints[n - 1].channel] += 1.0;
+    return result;
+  }
+  if (model === 'linear') {
+    const weight = 1.0 / n;
+    touchpoints.forEach(t => { result[t.channel] += weight; });
+    return result;
+  }
+  if (model === 'u_shaped') {
+    if (n === 2) {
+      result[touchpoints[0].channel] += 0.5;
+      result[touchpoints[1].channel] += 0.5;
+    } else {
+      result[touchpoints[0].channel] += 0.4;
+      result[touchpoints[n - 1].channel] += 0.4;
+      const middleWeight = 0.2 / (n - 2);
+      for (let i = 1; i < n - 1; i++) {
+        result[touchpoints[i].channel] += middleWeight;
+      }
+    }
+    return result;
+  }
+  return result;
+}
+```
+
+### Exemplar 2: Server-Side Meta CAPI Conversion Dispatcher
+```typescript
+import crypto from 'node:crypto';
+
+export interface CapiConversionPayload {
+  eventName: string;
+  eventId: string;
+  eventTime: number;
+  userEmail: string;
+  value: number;
+  currency: string;
+}
+
+export function hashSha256(value: string): string {
+  return crypto.createHash('sha256').update(value.trim().toLowerCase()).digest('hex');
+}
+
+export function formatMetaCapiPayload(payload: CapiConversionPayload, pixelId: string) {
+  return {
+    data: [
+      {
+        event_name: payload.eventName,
+        event_time: payload.eventTime,
+        event_id: payload.eventId,
+        user_data: {
+          em: [hashSha256(payload.userEmail)],
+        },
+        custom_data: {
+          currency: payload.currency,
+          value: payload.value,
+        },
+        action_source: 'website',
+      },
+    ],
+  };
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Duplicate Conversion Reporting between Browser Pixel and Server CAPI
+1. **Diagnosis**: Ad platform counts purchase event twice, inflating reported ROAS by 100%.
+2. **Recovery Protocol**:
+   - Step 1: Verify `event_id` string parity between client-side pixel event and server-side CAPI payload.
+   - Step 2: Ensure timestamps on both dispatches are within platform deduplication window (under 48 hours).
+   - Step 3: Inspect Meta Events Manager deduplication diagnostics to confirm 100% deduplication rate.
+
+### Scenario B: Orphaned Touchpoint Sessions Due to Cross-Domain Redirects
+1. **Diagnosis**: UTM parameters lost when user redirects from marketing landing page to auth/checkout subdomain.
+2. **Recovery Protocol**:
+   - Step 1: Implement first-party cookie persistence storing original UTM touchpoint for 30 days.
+   - Step 2: Append persistent anonymous session ID across cross-domain link anchors.
+   - Step 3: Re-stitch orphaned checkout sessions using server-side anonymous ID lookup.
+
+## Verification & Validation Checklist
+- [ ] Frontmatter conforms strictly to `author: "agents-united"` and `version: "2.0.0"`.
+- [ ] All 7 mandatory sections present with explicit headers.
+- [ ] Step-by-Step Execution Runbook body contains >= 50 lines.
+- [ ] Multi-touch models (Linear, U-Shaped, W-Shaped) formulated with exact math.
+- [ ] Server-Side CAPI integration with SHA-256 PII hashing detailed.
+- [ ] Code exemplars provided with valid syntax fencing.
+- [ ] Zero dummy placeholder strings or unpopulated template markers present.
+- [ ] Project build, test suite, and doctor check pass 100% cleanly.

package/registry/skills/ad-creative-design/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: ad-creative-design
+description: High-converting advertising visual layouts, social banner design systems, aspect ratio formatting, and visual hook variations.
+metadata:
+  author: "Agents United Creative Team"
+  version: "1.0.0"
+  license: "MIT"
+---
+
+# Ad Creative Design Playbook
+
+## Overview & Purpose
+`ad-creative-design` provides standardized design frameworks and visual hierarchies for digital advertising campaigns across Meta, Google Display, LinkedIn, and X.
+
+## Core Directives & Standards
+1. **Visual Hierarchy** — Lead with a high-contrast visual hook (top 40% of viewport), followed by a 1-sentence value proposition, social proof badge, and an actionable CTA.
+2. **Aspect Ratio Compliance** — Export designs in 1:1 (Feed/Square), 9:16 (Stories/Reels/Shorts), and 1.91:1 (Landscape/Feed).
+3. **Contrast & Readability** — Maintain WCAG AA compliant text contrast against background gradients or imagery.
+4. **Multi-Hook Variation** — Provide at least 3 distinct visual angle variations per campaign concept (Product Demo screenshot, Stat/Metric Callout, Minimalist Typography).
+
+## Verification Checklist
+- [ ] Visual elements scale cleanly across mobile screen viewports.
+- [ ] Text covers less than 20% of ad image area to maximize ad delivery score.
+- [ ] CTA button stands out with clear accent color contrast.

package/registry/skills/ai-prototype-refactoring/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: ai-prototype-refactoring
+description: Refactoring rapid AI-generated prototypes from Lovable, v0, and Bolt into production-ready modular React components, typed design tokens, and clean architectures.
+metadata:
+  author: "Agents United Frontend Group"
+  version: "1.0.0"
+  license: "MIT"
+---
+
+# AI Prototype Refactoring Playbook (Lovable / v0 / Bolt)
+
+## Overview & Purpose
+`ai-prototype-refactoring` standardizes the ingestion and transformation of single-file AI prototype exports (from Lovable.dev, v0.dev, Bolt.new) into enterprise-grade modular React/TypeScript codebases.
+
+## Core Directives & Standards
+1. **Deconstruct Monolithic Files** — Break large 1000+ line single-file components into atomic design hierarchy (`atoms`, `molecules`, `organisms`, `layouts`).
+2. **Strict TypeScript Typing** — Replace all inferred `any` and inline untyped JSON objects with formal TypeScript interfaces and Zod validation schemas.
+3. **Design System Token Mapping** — Extract hardcoded arbitrary Tailwind classes (e.g. `bg-[#1a2b3c]`, `p-[17px]`) into semantic Tailwind configuration tokens (e.g. `bg-primary`, `p-4`).
+4. **Interactive State & Hook Extraction** — Move inline messy `useState` spaghetti into custom hooks (`useCartState`, `useFilterParams`, `useAuthModal`).
+5. **Accessibility (a11y) & Semantic HTML** — Replace unsemantic `div` click handlers with semantic `<button>`, `<nav>`, `<main>`, `<dialog>`, and accessible ARIA attributes.
+
+## Verification Checklist
+- [ ] Refactored components pass strict TypeScript compilation (`tsc --noEmit`).
+- [ ] Unit and visual regression tests author for critical interaction flows.
+- [ ] No hardcoded placeholder mock data remaining in production component code.

package/registry/skills/architecture-design/SKILL.md

@@ -1,13 +1,139 @@
 ---
 name: architecture-design
-description: Official Architecture Design skill for Agents United ecosystem providing runbooks and guidelines.
+description: Production-grade Architecture Design playbook for microservices, event-driven backends, and C4 domain modeling.
+metadata:
+  author: "agents-united"
+  version: "2.0.0"
 ---
 
-# Architecture Design
+# System Architecture Design & ADR Management
 
-This skill provides comprehensive instructions, runbooks, and guidelines for Architecture Design.
+## Overview & Purpose
+The System Architecture Design & ADR Management skill provides a deterministic, battle-tested framework for executing architecture-design processes across the Agents United multi-agent ecosystem.
 
-## Procedure & Guidelines
-1. Review domain requirements and constraints.
-2. Execute step-by-step procedures test-first.
-3. Validate results against acceptance criteria.
+Following this skill ensures high quality, zero-regression execution, rigorous testing gates, and seamless cross-functional team alignment.
+
+## Execution Triggers & Prerequisites
+### Execution Triggers
+- Direct request or workflow step invoking architecture-design.
+- Auditing, implementing, or standardizing architecture-design procedures.
+- Addressing technical debt, architectural reviews, or production readiness gates.
+- Preparing pull requests or automated release validations.
+
+### Prerequisites
+- Active project repository workspace with version control configured.
+- Operational testing, typechecking, and build toolchains.
+- Domain requirements, architectural constraints, or user stories defined.
+- Clean git working tree before beginning execution.
+
+## Input & Output Requirements
+### Inputs
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `target_scope` | String | Yes | Target module, service, component, or file path |
+| `config` | Object | Optional | Specific domain configurations, thresholds, and options |
+| `output_dir` | Directory Path | Optional | Destination directory for generated artifacts and reports |
+| `strict_mode` | Boolean | Optional | Enforce strict zero-warning validation and high test coverage |
+
+### Outputs
+| Artifact | Path / Format | Description |
+|---|---|---|
+| Specification Document | `docs/architecture-design/spec.md` | Full technical specification and architectural plan |
+| Implementation Files | `src/architecture-design/*` | Production-ready source code, tests, and configurations |
+| Execution Report | `reports/architecture-design/summary.json` | Verification metrics, test results, and audit summary |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Domain Decomposition & C4 Model Framing
+1. Deconstruct system requirements into Context, Container, Component, and Code layers.
+2. Define bounded contexts and domain aggregates to prevent leaky domain boundaries.
+3. Chart synchronous vs asynchronous communication channels and latency budgets.
+4. Identify stateful storage requirements and data partitioning strategies.
+5. Draft high-level architecture diagram and component topology.
+
+### Phase 2: Tradeoff Analysis & Non-Functional Requirements (NFRs)
+1. Quantify SLA/SLO requirements: p99 latency (<150ms), availability (99.99%), throughput (10k rps).
+2. Evaluate CAP theorem tradeoffs: Consistency vs Availability during network partitions.
+3. Assess infrastructure cost implications across compute, bandwidth, and managed services.
+4. Perform threat modeling (STRIDE) against network boundaries and data stores.
+5. Document architectural alternatives considered and reasons for rejection.
+
+### Phase 3: ADR Authoring & Interface Contract Definition
+1. Author formal ADR in docs/adr/ADR-XXXX.md following MADR template standards.
+2. Specify OpenAPI / gRPC Protobuf interface contracts for inter-service boundaries.
+3. Define idempotency keys and retry policies for distributed operations.
+4. Define failure domains, circuit breaker thresholds, and fallback degradations.
+5. Submit ADR for peer review by security and system architecture teams.
+
+### Phase 4: Architecture Validation & Prototyping Spike
+1. Build minimal executable spike to validate performance and latency assumptions.
+2. Verify distributed tracing propagation across boundary headers (TraceContext).
+3. Run automated load testing against prototype endpoints using k6 or autocannon.
+4. Validate disaster recovery and failover behavior under simulated node outages.
+5. Review spike results against target SLO metrics.
+
+### Phase 5: Governance & Downstream Implementation Handoff
+1. Publish accepted ADR to repository architecture registry.
+2. Generate service scaffold templates with pre-configured telemetry and lint rules.
+3. Brief backend and infrastructure subagents on architectural constraints.
+4. Create milestone tracking tickets linked directly to ADR acceptance criteria.
+5. Establish quarterly architectural drift review cadence.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: System Architecture Design & ADR Management Configuration & Specification
+```yaml
+title: "ADR-004: Event-Driven Order Processing Architecture"
+status: "accepted"
+date: "2026-08-14"
+deciders: ["System Architect", "Backend Lead"]
+context: |
+  Synchronous REST calls between Checkout and Inventory services caused cascading latency spikes during peak loads.
+decision: |
+  We will adopt an event-driven architecture using Apache Kafka with transactional outbox patterns.
+consequences:
+  positive:
+    - Decouples checkout service latency from inventory processing.
+    - Guarantees at-least-once message delivery via transactional outbox.
+  negative:
+    - Eventual consistency requires asynchronous UI status polling.
+```
+
+### Exemplar 2: System Architecture Design & ADR Management TypeScript Type Contract
+```typescript
+export interface ArchitectureDecisionRecord {
+  id: string;
+  title: string;
+  status: 'draft' | 'proposed' | 'accepted' | 'rejected' | 'deprecated';
+  context: string;
+  decision: string;
+  consequences: {
+    positive: string[];
+    negative: string[];
+  };
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in System Architecture Design & ADR Management
+1. **Diagnosis**: Static analysis, typechecking, or unit tests fail validation rules during execution.
+2. **Recovery Protocol**:
+   - Step 1: Inspect detailed error log output in test/build terminal.
+   - Step 2: Formulate targeted hypothesis and isolate failing line or assertion.
+   - Step 3: Implement surgical code fix and re-run verification suite.
+
+### Scenario B: Missing or Incompatible Dependency
+1. **Diagnosis**: Required toolchain binary or library dependency is missing from the environment.
+2. **Recovery Protocol**:
+   - Step 1: Verify `package.json` engine requirements and local environment versions.
+   - Step 2: Install required peer dependencies cleanly with lockfile sync.
+   - Step 3: Resume runbook from Phase 1.
+
+## Verification & Validation Checklist
+- [ ] Frontmatter conforms strictly to `author: "agents-united"` and `version: "2.0.0"`.
+- [ ] All 7 mandatory sections present with explicit headers.
+- [ ] Step-by-Step Execution Runbook body contains >= 50 lines.
+- [ ] Code exemplars provided with valid syntax fencing.
+- [ ] Zero dummy placeholder strings or unpopulated template markers present.
+- [ ] Project build, test suite, and doctor check pass 100% cleanly.

package/registry/skills/azure-infrastructure-bicep/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: azure-infrastructure-bicep
+description: Enterprise cloud infrastructure automation on Microsoft Azure using Bicep IaC, Azure Container Apps, AKS, Azure OpenAI services, and Managed Identities.
+metadata:
+  author: "Agents United DevOps Group"
+  version: "1.0.0"
+  license: "MIT"
+---
+
+# Azure Infrastructure with Bicep Playbook
+
+## Overview & Purpose
+`azure-infrastructure-bicep` defines cloud architecture standards and Infrastructure-as-Code (IaC) templates for deploying scalable applications on Microsoft Azure.
+
+## Core Directives & Standards
+1. **Modular Bicep Templates** — Organize IaC into reusable Bicep modules (`modules/containerApp.bicep`, `modules/keyVault.bicep`, `modules/openAI.bicep`) with strict parameter typing.
+2. **Passwordless Managed Identities** — Use Azure System-Assigned or User-Assigned Managed Identities and Azure RBAC instead of hardcoded connection strings or access keys.
+3. **Azure Container Apps (ACA) Microservices** — Deploy containerized workloads with KEDA auto-scaling (HTTP traffic and queue depth scaling) and Dapr sidecars.
+4. **Azure OpenAI Service Deployment** — Provision dedicated Azure OpenAI Cognitive Service accounts with private endpoints, virtual network integration, and rate-limit monitoring.
+5. **Azure Key Vault Integration** — Store all application secrets in Key Vault and inject them into container environments via Key Vault secret references.
+
+## Verification Checklist
+- [ ] Bicep templates pass `az bicep build` and `az deployment group what-if` dry-run validations.
+- [ ] Public network access disabled on storage accounts and databases (private endpoints enforced).

package/registry/skills/backend-api-design/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: backend-api-design
+description: Production-grade Backend API Design playbook for RESTful, gRPC, and GraphQL enterprise architectures.
+metadata:
+  author: "agents-united"
+  version: "2.0.0"
+---
+
+# Backend API Design & Contract Specification
+
+## Overview & Purpose
+The Backend API Design & Contract Specification skill provides a deterministic, battle-tested framework for executing backend-api-design processes across the Agents United multi-agent ecosystem.
+
+Following this skill ensures high quality, zero-regression execution, rigorous testing gates, and seamless cross-functional team alignment.
+
+## Execution Triggers & Prerequisites
+### Execution Triggers
+- Direct request or workflow step invoking backend-api-design.
+- Auditing, implementing, or standardizing backend-api-design procedures.
+- Addressing technical debt, architectural reviews, or production readiness gates.
+- Preparing pull requests or automated release validations.
+
+### Prerequisites
+- Active project repository workspace with version control configured.
+- Operational testing, typechecking, and build toolchains.
+- Domain requirements, architectural constraints, or user stories defined.
+- Clean git working tree before beginning execution.
+
+## Input & Output Requirements
+### Inputs
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `target_scope` | String | Yes | Target module, service, component, or file path |
+| `config` | Object | Optional | Specific domain configurations, thresholds, and options |
+| `output_dir` | Directory Path | Optional | Destination directory for generated artifacts and reports |
+| `strict_mode` | Boolean | Optional | Enforce strict zero-warning validation and high test coverage |
+
+### Outputs
+| Artifact | Path / Format | Description |
+|---|---|---|
+| Specification Document | `docs/backend-api-design/spec.md` | Full technical specification and architectural plan |
+| Implementation Files | `src/backend-api-design/*` | Production-ready source code, tests, and configurations |
+| Execution Report | `reports/backend-api-design/summary.json` | Verification metrics, test results, and audit summary |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: API Resource & Contract Modeling
+1. Model domain resources with standard pluralized URI paths (/api/v2/resources).
+2. Select communication protocol: RESTful JSON, gRPC Protobuf, or GraphQL based on payload needs.
+3. Define HTTP verb semantics strictly: GET (idempotent/safe), POST (create), PUT (replace), PATCH (partial), DELETE.
+4. Establish unified error response schema matching RFC 7807 Problem Details.
+5. Design pagination schemas supporting cursor-based and offset-based navigation.
+
+### Phase 2: Schema Validation & Security Hardening
+1. Write strict JSON Schema / Zod runtime validation definitions for all input payloads.
+2. Enforce Idempotency-Key headers for all non-idempotent financial/state transitions.
+3. Configure rate-limiting policies (token bucket algorithm) by authenticated tenant.
+4. Implement OAuth2 / JWT bearer token authentication and RBAC scope authorization checks.
+5. Sanitize all headers and query parameters against injection attacks.
+
+### Phase 3: Implementation & Middleware Pipeline Assembly
+1. Assemble Express / Fastify / Koa middleware pipeline: CORS -> Tracing -> Auth -> BodyParser -> RateLimit.
+2. Implement controller handlers with explicit separation between transport and service domains.
+3. Implement database transactions with optimistic locking for concurrent updates.
+4. Wire up structured JSON logging with CorrelationId injected on every log line.
+5. Enforce strict error boundary middleware to prevent uncaught promise rejections.
+
+### Phase 4: Automated Contract Testing & Mock Server Verification
+1. Run contract tests validating OpenAPI specification against live responses (Prism/Dredd).
+2. Execute end-to-end integration tests using Supertest or Vitest.
+3. Verify error code compliance for 400, 401, 403, 404, 409, 422, 429, and 500 scenarios.
+4. Benchmark p95 response time under concurrent simulated load.
+5. Validate backward-compatibility against previous API versions.
+
+### Phase 5: SDK Generation & Documentation Publication
+1. Generate TypeScript / Python client SDKs from OpenAPI definitions via @openapitools/openapi-generator-cli.
+2. Publish interactive Swagger / Redoc documentation endpoint.
+3. Generate changelog highlighting added fields, deprecated routes, and breaking changes.
+4. Commit updated API schemas to version control.
+5. Tag production release candidate.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: Backend API Design & Contract Specification Configuration & Specification
+```yaml
+openapi: 3.1.0
+info:
+  title: Enterprise Order Management API
+  version: 2.0.0
+paths:
+  /api/v2/orders:
+    post:
+      summary: Create idempotent purchase order
+      parameters:
+        - in: header
+          name: Idempotency-Key
+          required: true
+          schema:
+            type: string
+            format: uuid
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/CreateOrderRequest'
+```
+
+### Exemplar 2: Backend API Design & Contract Specification TypeScript Type Contract
+```typescript
+export interface ApiResponse<T> {
+  success: boolean;
+  data?: T;
+  error?: {
+    code: string;
+    message: string;
+    details?: Record<string, unknown>;
+  };
+  metadata: {
+    requestId: string;
+    timestamp: string;
+  };
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in Backend API Design & Contract Specification
+1. **Diagnosis**: Static analysis, typechecking, or unit tests fail validation rules during execution.
+2. **Recovery Protocol**:
+   - Step 1: Inspect detailed error log output in test/build terminal.
+   - Step 2: Formulate targeted hypothesis and isolate failing line or assertion.
+   - Step 3: Implement surgical code fix and re-run verification suite.
+
+### Scenario B: Missing or Incompatible Dependency
+1. **Diagnosis**: Required toolchain binary or library dependency is missing from the environment.
+2. **Recovery Protocol**:
+   - Step 1: Verify `package.json` engine requirements and local environment versions.
+   - Step 2: Install required peer dependencies cleanly with lockfile sync.
+   - Step 3: Resume runbook from Phase 1.
+
+## Verification & Validation Checklist
+- [ ] Frontmatter conforms strictly to `author: "agents-united"` and `version: "2.0.0"`.
+- [ ] All 7 mandatory sections present with explicit headers.
+- [ ] Step-by-Step Execution Runbook body contains >= 50 lines.
+- [ ] Code exemplars provided with valid syntax fencing.
+- [ ] Zero dummy placeholder strings or unpopulated template markers present.
+- [ ] Project build, test suite, and doctor check pass 100% cleanly.

package/registry/skills/chaos-engineering/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: chaos-engineering
+description: Chaos engineering methodology, fault injection, network latency simulation, service degradation tests, and disaster recovery validation.
+metadata:
+  author: "Agents United Core Team"
+  version: "1.0.0"
+  source: "https://github.com/NeoAnthropocene/agents-united"
+---
+
+# Chaos Engineering & Fault Injection Playbook
+
+## Overview & Purpose
+`chaos-engineering` provides a structured methodology for injecting controlled failures into distributed services and frontend applications to prove resilience before production incidents occur.
+
+## Rules & Constraints
+1. **Define Steady State** — Measure baseline normal behavior (error rate < 0.05%, p99 latency < 200ms) before injecting chaos.
+2. **Formulate Falsifiable Hypothesis** — Hypothesize that the system will continue functioning despite specific service or network outages.
+3. **Minimize Blast Radius** — Run chaos experiments in staging or with scoped tenant canary headers before cluster-wide testing.
+4. **Automated Abort Conditions** — Configure automated triggers that immediately halt the experiment if key business SLOs degrade beyond safety margins.
+
+## Step-by-Step Execution Runbook
+
+### Phase 1 — Experiment Design & Hypothesis
+- Select chaos vector: Network latency (Toxiproxy), Database connection drop, Redis cache outage, or Pod termination.
+- Establish baseline monitoring dashboards.
+
+### Phase 2 — Fault Injection Execution
+- Trigger the fault in a controlled staging environment.
+- Observe circuit breaker tripping, fallback cache utilization, and error message rendering.
+
+### Phase 3 — Analysis & Remediation
+- Document whether the system gracefully degraded or suffered cascading failures.
+- Implement necessary resilience patches (timeouts, retries with jitter, fallback defaults).
+
+## Verification Checklist
+- [ ] System gracefully handles injected faults without crashing.
+- [ ] Fallback user experience displays helpful degraded state UI.
+- [ ] Post-experiment system recovers to steady state automatically.