@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/llm-eval/references/scoring-methods.md

@@ -1,188 +0,0 @@
-# Scoring Methods
-
-## Overview
-
-Scoring translates raw LLM outputs into quantitative signals that drive pass/fail decisions, regression detection, and variant comparison. This reference covers deterministic scoring, LLM-as-judge scoring, composite metrics, and calibration techniques.
-
-## Deterministic Scoring
-
-Deterministic scores are binary (0 or 1) or computed from exact rules. They are reproducible, cheap, and should form the foundation of every eval suite.
-
-### Binary Pass/Fail
-
-The simplest scoring: the assertion either passes (1.0) or fails (0.0).
-
-```python
-def score_contains(output: str, expected: str) -> float:
-    return 1.0 if expected.lower() in output.lower() else 0.0
-```
-
-### Partial Credit
-
-Some assertions benefit from partial credit. For example, if the expected output has 5 required fields and the model produces 3:
-
-```python
-def score_fields(output: dict, required_fields: list[str]) -> float:
-    present = sum(1 for f in required_fields if f in output)
-    return present / len(required_fields)
-```
-
-### ROUGE and BLEU
-
-For summarization or translation tasks, n-gram overlap metrics provide a deterministic quality signal.
-
-```python
-from rouge_score import rouge_scorer
-
-scorer = rouge_scorer.RougeScorer(['rouge1', 'rouge2', 'rougeL'], use_stemmer=True)
-
-def score_summary(output: str, reference: str) -> dict:
-    scores = scorer.score(reference, output)
-    return {
-        "rouge1": scores["rouge1"].fmeasure,
-        "rouge2": scores["rouge2"].fmeasure,
-        "rougeL": scores["rougeL"].fmeasure
-    }
-```
-
-**Limitation:** ROUGE and BLEU measure lexical overlap, not semantic equivalence. Two semantically identical summaries with different wording will score low. Use them as a floor check, not a ceiling.
-
-## LLM-as-Judge Scoring
-
-LLM-as-judge uses a second model to evaluate the output of the first. This enables scoring of subjective dimensions like helpfulness, accuracy, and tone.
-
-### Single-Point Rubric
-
-The judge scores the output on a numeric scale with anchored definitions.
-
-```python
-JUDGE_PROMPT = """You are evaluating an LLM's response to a customer support query.
-
-INPUT: {input}
-OUTPUT: {output}
-
-Rate the response on a 1-5 scale for HELPFULNESS:
-1 - Does not address the user's question at all.
-2 - Partially addresses the question but missing key information.
-3 - Addresses the question but the answer is generic or imprecise.
-4 - Addresses the question with specific, actionable information.
-5 - Exceeds expectations: specific, actionable, empathetic, and proactive.
-
-Return ONLY a JSON object: {{"score": <int>, "reasoning": "<explanation>"}}
-"""
-
-async def judge_helpfulness(input_text: str, output_text: str) -> dict:
-    prompt = JUDGE_PROMPT.format(input=input_text, output=output_text)
-    response = await call_judge_model(prompt)
-    return json.loads(response)
-```
-
-### Pairwise Comparison
-
-Instead of absolute scores, the judge chooses which of two outputs is better.
-
-```python
-PAIRWISE_PROMPT = """Compare these two responses to the same query.
-
-QUERY: {input}
-RESPONSE A: {output_a}
-RESPONSE B: {output_b}
-
-Which response is more helpful? Consider accuracy, completeness, and tone.
-Return ONLY: {{"winner": "A" or "B" or "TIE", "reasoning": "<explanation>"}}
-"""
-```
-
-**Advantage:** Pairwise comparison is easier for the judge model than absolute scoring. It is the preferred method for A/B testing prompt variants.
-
-### Multi-Dimension Scoring
-
-Score multiple dimensions in a single judge call to reduce API costs.
-
-```python
-MULTI_DIM_PROMPT = """Evaluate this response on three dimensions.
-
-INPUT: {input}
-OUTPUT: {output}
-
-Score each dimension 1-5:
-- ACCURACY: Is the information factually correct?
-- COMPLETENESS: Does it address all parts of the question?
-- TONE: Is it professional, empathetic, and appropriate?
-
-Return ONLY: {{"accuracy": <int>, "completeness": <int>, "tone": <int>, "reasoning": "<explanation>"}}
-"""
-```
-
-**Pitfall:** Multi-dimension scoring can create halo effects where a strong first impression inflates all dimensions. If dimensions are critical, score them in separate judge calls.
-
-## Variance Reduction for Judge Scoring
-
-LLM-as-judge scores vary across runs due to model sampling. Use these techniques to reduce variance:
-
-### Median of Odd Runs
-
-Run the judge 3 or 5 times and take the median. This eliminates single-run outliers.
-
-```python
-async def stable_judge_score(input_text: str, output_text: str, runs: int = 3) -> float:
-    scores = []
-    for _ in range(runs):
-        result = await judge_helpfulness(input_text, output_text)
-        scores.append(result["score"])
-    return statistics.median(scores)
-```
-
-### Temperature Control
-
-Set the judge model's temperature to 0.0 for maximum determinism. This does not eliminate variance (top-p sampling still introduces noise) but reduces it substantially.
-
-### Prompt Anchoring
-
-Include concrete examples of each score level in the judge prompt. Anchored prompts produce tighter score distributions.
-
-## Composite Metrics
-
-Combine multiple scores into a single decision metric.
-
-### Weighted Average
-
-```python
-def composite_score(scores: dict, weights: dict) -> float:
-    total = sum(scores[dim] * weights[dim] for dim in scores)
-    return total / sum(weights.values())
-
-# Example: accuracy matters more than tone
-composite = composite_score(
-    scores={"accuracy": 4.5, "completeness": 4.0, "tone": 3.5},
-    weights={"accuracy": 0.5, "completeness": 0.3, "tone": 0.2}
-)
-# Result: 4.1
-```
-
-### Gate + Score
-
-Deterministic assertions act as a gate; judgmental scores only matter if the gate passes.
-
-```python
-def gated_score(deterministic_pass: bool, judge_score: float) -> float:
-    if not deterministic_pass:
-        return 0.0  # Hard fail regardless of judge score
-    return judge_score
-```
-
-This prevents a scenario where a response gets a high judge score but violates a hard requirement (e.g., leaks a secret but is very helpful).
-
-## Calibration
-
-### Score Distribution Analysis
-
-After the first eval run, plot the distribution of judge scores. A healthy distribution spans the full scale. If 90% of scores cluster at 4-5, the rubric is too lenient or the cases are too easy.
-
-### Reference Outputs
-
-Include 2-3 test cases with known-good outputs and expected scores. If the judge consistently scores these differently than expected, the rubric or judge model needs adjustment.
-
-### Cross-Judge Validation
-
-Run the same eval cases through two different judge models. High disagreement signals that the scoring dimension is ambiguous and needs a clearer rubric definition.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/mcp-server-builder/evals/assertions.md

@@ -1,47 +0,0 @@
-# MCP Server Builder Eval Assertions
-
-## Eval 1: Tool Registration with Validation
-
-This eval tests MCP tool registration: JSON Schema input validation, action-oriented naming, destructive tool labeling, and capability negotiation.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `inputSchema` — JSON Schema validation           | Tools without input schemas accept any input, causing runtime errors deep in handler logic. Schema validation rejects malformed inputs at the protocol layer with clear error messages. |
-| 2 | contains | `list-issues` — Action-oriented naming           | AI agents match user intent to tool names. Action-oriented names like `list-issues` are immediately understandable, while abstract names like `issue-manager` require the agent to read the full description. |
-| 3 | contains | `capabilities` — Capability negotiation          | The initialize response must declare capabilities so clients know which features are available. Omitting capabilities causes clients to skip tool discovery entirely. |
-| 4 | contains | `destructive` — Write operation labeling         | Agents must distinguish read-only from state-modifying operations. Without clear labeling, an agent exploring options may accidentally create or modify issues. |
-| 5 | contains | `required` — Required field declaration          | JSON Schema `required` arrays ensure agents provide mandatory parameters. Without them, agents may omit the issue title or number, causing cryptic handler failures. |
-
-### What a passing response looks like
-
-- Server with `initialize` handler returning capabilities object with `tools: {}`.
-- Four tools registered: `list-issues`, `get-issue`, `create-issue`, `update-issue`.
-- Each tool with `inputSchema` containing `type: "object"`, `properties`, and `required` arrays.
-- `create-issue` and `update-issue` descriptions containing "destructive" or "modifies state" language.
-- Filter parameters on `list-issues` (state, labels, assignee) as optional properties with enum constraints.
-
----
-
-## Eval 2: Resource Provider Implementation
-
-This eval tests MCP resource providers: resource listing, URI templates for parameterized content, MIME type declarations, and protocol-compliant response format.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `resources/list` — Resource discovery            | Without resources/list, clients cannot discover what resources the server offers. They would need prior knowledge of every URI, defeating the purpose of dynamic context. |
-| 2 | contains | `uri` — Resource URI declaration                 | URIs are the primary identifier for resources in the MCP protocol. Omitting them makes resources unaddressable by clients. |
-| 3 | contains | `mimeType` — Content type declaration            | MIME types tell clients how to render content. A markdown resource displayed as plain text loses formatting; a JSON resource without the type cannot be parsed. |
-| 4 | contains | `resourceTemplates` — Parameterized resources    | URI templates enable a single resource definition to serve many instances (any table schema, any API endpoint) without enumerating every possible URI at registration time. |
-| 5 | contains | `contents` — Response format compliance          | The MCP protocol requires resource read responses to include a `contents` array with URI, MIME type, and content. Non-compliant responses are silently dropped by clients. |
-
-### What a passing response looks like
-
-- `resources/list` handler returning static resources (README, changelog) and resource templates (API docs, schema).
-- Static resources with fixed URIs like `docs://project/readme` and `docs://project/changelog`.
-- Resource templates with URI patterns like `docs://api/{endpoint}` and `schema://database/{table}`.
-- Each resource declaring `mimeType: "text/markdown"` or appropriate content type.
-- `resources/read` handler returning `{ contents: [{ uri, mimeType, text }] }` format.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/mcp-server-builder/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "tool-registration-with-validation",
-    "description": "Validate that the skill produces correct MCP tool registration with JSON Schema input validation, structured output, descriptive naming, and capability negotiation.",
-    "input": "Build an MCP server that exposes tools for managing a project's GitHub issues. Register tools for: list-issues (with filters for state, labels, assignee), get-issue (by number), create-issue (title, body, labels, assignee), and update-issue (number, with optional title, body, state, labels). Each tool must have JSON Schema input validation. Use descriptive tool descriptions that help AI agents understand when to use each tool. Mark create and update tools as destructive. Implement capability negotiation in the initialize response.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "inputSchema",
-        "description": "Every tool registration must include an inputSchema with JSON Schema that validates required and optional parameters before handler execution."
-      },
-      {
-        "type": "contains",
-        "value": "list-issues",
-        "description": "Must use action-oriented tool names (list-issues, get-issue, create-issue) that describe what the tool does for agent discoverability."
-      },
-      {
-        "type": "contains",
-        "value": "capabilities",
-        "description": "Must include a capabilities object in the initialize response declaring supported features (tools, resources, prompts) for client discovery."
-      },
-      {
-        "type": "contains",
-        "value": "destructive",
-        "description": "Must mark create and update tools as destructive or state-modifying in their descriptions so agents can distinguish read-only from write operations."
-      },
-      {
-        "type": "contains",
-        "value": "required",
-        "description": "JSON Schema input definitions must specify required fields to ensure agents provide mandatory parameters and receive clear validation errors for missing inputs."
-      }
-    ]
-  },
-  {
-    "name": "resource-provider-implementation",
-    "description": "Validate that the skill produces a correct MCP resource provider implementation with URI templates, content types, dynamic context generation, and proper protocol compliance.",
-    "input": "Add resource providers to an MCP server for a documentation platform. Implement resources for: project README (static URI), API endpoint documentation (URI template with endpoint path parameter), database schema (URI template with table name parameter), and changelog (static URI with pagination support). Each resource must declare its MIME type. Support resource listing so clients can discover available resources. Include caching headers for frequently accessed resources.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "resources/list",
-        "description": "Must implement the resources/list method so clients can discover available resources and their URI patterns without prior knowledge."
-      },
-      {
-        "type": "contains",
-        "value": "uri",
-        "description": "Every resource must declare a URI (static or template) that clients use to request specific content from the resource provider."
-      },
-      {
-        "type": "contains",
-        "value": "mimeType",
-        "description": "Resources must declare their MIME type (text/markdown, application/json, etc.) so clients can render content appropriately."
-      },
-      {
-        "type": "contains",
-        "value": "resourceTemplates",
-        "description": "Must use resourceTemplates for parameterized resources (API docs by endpoint, schema by table) to enable dynamic content serving."
-      },
-      {
-        "type": "contains",
-        "value": "contents",
-        "description": "Resource read responses must include a contents array with URI, MIME type, and text/blob content following the MCP resource response format."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/microservices-design/SKILL.md

@@ -1,88 +0,0 @@
----
-name: microservices-design
-description: Microservices architecture patterns covering service decomposition, API gateways, service mesh, saga pattern, event sourcing, and deployment strategies for distributed applications.
-allowed-tools: Read Grep Glob
-user-invocable: true
-argument-hint: "Service boundary, communication pattern, or architecture concern"
----
-
-# Microservices Design
-
-## Purpose
-
-Provide systematic guidance for designing, building, and operating microservices architectures. Covers service boundary identification, inter-service communication patterns, distributed transaction management, observability instrumentation, and deployment strategies. Ensures that microservices deliver on their promise of independent deployability and team autonomy without introducing unmanageable operational complexity.
-
-## When to Use
-
-- Decomposing a monolith into independently deployable services
-- Defining service boundaries using domain-driven design techniques
-- Choosing between synchronous and asynchronous communication patterns
-- Implementing distributed transactions with saga orchestration or choreography
-- Designing API gateways, service meshes, or sidecar proxy configurations
-- Planning observability across a multi-service architecture
-- Establishing deployment pipelines for independent service releases
-- Evaluating whether microservices are the right architecture for a given system
-
-## Instructions
-
-1. **Validate the need for microservices before decomposing** — Verify that the system has independent scaling requirements, separate team ownership boundaries, or distinct deployment cadences that justify the operational overhead of distribution so that complexity is added only where it pays for itself.
-
-2. **Identify service boundaries using bounded contexts** — Apply domain-driven design to discover bounded contexts where each context owns a cohesive set of domain concepts, data, and business rules so that services are aligned with business capabilities rather than technical layers. See `references/decomposition.md`.
-
-3. **Design each service around a single business capability** — A service should own one capability end-to-end (data store, business logic, API) so that changes to one capability do not require coordinated deployments across multiple services.
-
-4. **Choose communication patterns by coupling tolerance** — Use synchronous HTTP/gRPC for queries requiring immediate responses and asynchronous messaging for commands that tolerate eventual consistency so that coupling between services is explicit and intentional. See `references/communication-patterns.md`.
-
-5. **Implement an API gateway as the single entry point** — Route external traffic through a gateway that handles authentication, rate limiting, request routing, and protocol translation so that cross-cutting concerns are centralized rather than duplicated in every service.
-
-6. **Use the saga pattern for distributed transactions** — Replace two-phase commits with sagas (orchestration for complex workflows, choreography for simple ones) with compensating actions for rollback so that transactions span service boundaries without distributed locks. See `references/saga-pattern.md`.
-
-7. **Design events as first-class contracts** — Define event schemas with versioning, publish events to a durable log, and let consumers process them independently so that services can react to domain changes without direct coupling to the producer.
-
-8. **Deploy a service mesh for operational concerns** — Offload mTLS, retries, circuit breaking, and traffic shaping to the mesh infrastructure (Istio, Linkerd) so that service code focuses on business logic rather than network resilience.
-
-9. **Instrument every service with distributed tracing** — Propagate correlation IDs across all service calls, emit spans with timing data, and aggregate traces centrally so that end-to-end request flows are visible and latency bottlenecks can be isolated. See `references/observability.md`.
-
-10. **Enforce independent deployability as an architectural constraint** — Every service must be deployable without coordinating with other services. If a change requires simultaneous deployment of two services, the boundary is wrong and must be refactored.
-
-11. **Implement health checks and readiness probes** — Expose `/health` (liveness) and `/ready` (readiness) endpoints that check dependencies so that orchestrators can route traffic only to healthy instances and restart stuck ones.
-
-12. **Use contract testing to prevent integration breakage** — Write consumer-driven contract tests (Pact, Spring Cloud Contract) instead of relying solely on end-to-end tests so that API compatibility is verified early and cheaply without requiring all services to be running.
-
-13. **Design for graceful degradation** — When a downstream service is unavailable, return cached data, default values, or a reduced feature set rather than propagating the failure so that user-facing functionality degrades proportionally rather than catastrophically.
-
-14. **Version APIs explicitly from day one** — Use URL path versioning (v1, v2) or header-based versioning and maintain backward compatibility for at least one previous version so that consumers can migrate at their own pace. See `references/deployment.md`.
-
-15. **Automate canary deployments and rollback** — Deploy new versions to a small traffic percentage first, monitor error rates and latency, and auto-rollback if SLOs are breached so that bad deployments are caught before they affect all users.
-
-16. **Centralize configuration management** — Use a configuration server or environment-specific secret stores (Vault, AWS Secrets Manager) rather than config files baked into images so that configuration changes do not require redeployment.
-
-## Output Format
-
-Deliver:
-
-1. **Service boundary map** — List of services with owned capabilities, data stores, and team ownership
-2. **Communication topology** — Sync vs. async patterns between each service pair with protocol choices
-3. **Saga design** — Transaction flow with compensating actions for each failure point
-4. **Observability plan** — Metrics, traces, and logs for each service with alerting thresholds
-5. **Deployment strategy** — Pipeline stages, canary configuration, and rollback triggers
-
-## References
-
-Load only what the current task requires.
-
-| File | Load when |
-| --- | --- |
-| `references/decomposition.md` | Task involves identifying service boundaries, bounded contexts, or domain modeling. |
-| `references/communication-patterns.md` | Task involves sync vs. async patterns, API gateways, or protocol selection. |
-| `references/saga-pattern.md` | Task involves distributed transactions, compensation logic, or orchestration vs. choreography. |
-| `references/observability.md` | Task involves distributed tracing, metrics collection, log aggregation, or alerting. |
-| `references/deployment.md` | Task involves CI/CD pipelines, canary releases, blue-green deployments, or rollback strategies. |
-
-## Claude Platform Notes
-
-- Use `$ARGUMENTS` to access user-provided arguments passed when the skill is invoked.
-- Reference skill-local files with `${CLAUDE_SKILL_DIR}/references/<file>` for portable paths.
-- When `context: fork` is set, the skill runs in an isolated subagent context; the `agent` field names the fork target.
-- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available for dynamic skill discovery and loading.
-- Use `allowed-tools` in frontmatter to restrict tool access for security-sensitive skills.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/microservices-design/evals/assertions.md

@@ -1,52 +0,0 @@
-# Microservices Design Eval Assertions
-
-## Eval 1: Service Decomposition Strategy
-
-This eval tests the ability to identify service boundaries using domain-driven design, define data ownership, and plan an incremental migration from a monolith.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `bounded context` — DDD-driven boundaries | Service boundaries must align with business domains, not technical layers. Bounded contexts ensure each service owns a cohesive domain model with clear interfaces to other contexts. |
-| 2 | contains | `data ownership` — Per-service data stores | A shared database is the number one cause of microservices failure. Each service must own its data and expose it only through APIs or events. Without this, services cannot deploy independently. |
-| 3 | contains | `strangler` — Incremental migration pattern | Big-bang rewrites have a high failure rate. The strangler fig pattern extracts services one at a time behind a routing layer, allowing the monolith to shrink incrementally with rollback capability. |
-| 4 | contains | `event` — Asynchronous communication | Synchronous-only communication between services creates tight coupling and cascading failures. Event-driven patterns decouple producers from consumers and enable eventual consistency. |
-| 5 | contains | `API gateway` — External traffic routing | An API gateway provides a stable external interface while internal service boundaries evolve. It also centralizes authentication, rate limiting, and request routing. |
-
-### What a passing response looks like
-
-- 5-7 bounded contexts identified: User/Identity, Catalog, Order, Payment, Inventory, Shipping, Notification.
-- Each service owns its data store (User service owns user table, Order service owns orders table).
-- Cross-service data access via API calls or events, no shared database.
-- Strangler fig migration: start with the least-coupled context (e.g., Notification), route via gateway, extract one service per sprint/quarter.
-- Event-driven communication for order-placed, payment-completed, shipment-created events.
-- API gateway routes external traffic, authenticates requests, and fans out to internal services.
-- Team ownership model: one team per 1-2 services with full autonomy over their deployment pipeline.
-
----
-
-## Eval 2: Saga Orchestration Pattern
-
-This eval tests the ability to design a saga with proper step sequencing, compensating actions, timeout handling, and failure recovery for a multi-service distributed transaction.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `compensat` — Compensating action design | Every forward step in a saga must have a reverse (compensating) action. Without compensation, a failed saga leaves the system in an inconsistent state with charged payments and no order. |
-| 2 | contains | `orchestrat` — Central orchestrator pattern | Complex multi-step workflows need a central orchestrator to manage the saga state machine. Pure choreography becomes unmanageable beyond 3-4 steps and makes debugging nearly impossible. |
-| 3 | contains | `timeout` — Step-level timeout handling | A downstream service that hangs indefinitely blocks the entire saga. Each step must have a timeout after which the orchestrator triggers compensation for already-completed steps. |
-| 4 | contains | `idempoten` — Idempotent actions and compensations | Network retries mean both forward and compensating actions may execute multiple times. Without idempotency, retries create duplicate charges, double inventory releases, or ghost shipments. |
-| 5 | contains | `state` — Persistent saga state tracking | If the orchestrator crashes mid-saga, it must recover by reading persisted state. Without durable state, in-flight sagas are lost and the system ends up in an unrecoverable inconsistent state. |
-
-### What a passing response looks like
-
-- Saga orchestrator as a dedicated service with a state machine (states: STARTED, PAYMENT_CHARGED, INVENTORY_RESERVED, SHIPMENT_SCHEDULED, COMPLETED, COMPENSATING, FAILED).
-- Forward steps: CreateOrder -> ChargePayment -> ReserveInventory -> ScheduleShipment -> SendNotification.
-- Compensating actions: CancelOrder, RefundPayment, ReleaseInventory, CancelShipment (notification has no compensation — it is the last step).
-- Failure scenario 1: InventoryService fails -> refund payment -> cancel order.
-- Failure scenario 2: ShippingService times out after 30s -> release inventory -> refund payment -> cancel order.
-- Saga state persisted in a database table with step status, timestamps, and idempotency keys.
-- Idempotency: each step checks if already completed before executing, compensations check if already reversed.
-- Observability: saga ID in all log entries, trace spans per step, dashboard for saga completion rates and failure reasons.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/microservices-design/evals/evals.json

@@ -1,68 +0,0 @@
-{
-  "evals": [
-    {
-      "name": "service-decomposition-strategy",
-      "description": "Validate that the skill produces a service decomposition plan using domain-driven design with proper bounded context identification, data ownership, communication patterns, and team alignment for a monolith-to-microservices migration.",
-      "input": "A monolithic e-commerce platform handles user management, product catalog, order processing, payment, inventory, shipping, and notifications. The team wants to decompose it into microservices. The monolith currently serves 5,000 concurrent users with a shared PostgreSQL database. Identify bounded contexts, define service boundaries, specify which data each service owns, determine communication patterns between services, and propose a phased migration strategy that avoids a big-bang rewrite.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "bounded context",
-          "description": "The decomposition must use bounded contexts from domain-driven design to identify service boundaries aligned with business capabilities rather than technical layers."
-        },
-        {
-          "type": "contains",
-          "value": "data ownership",
-          "description": "The design must specify which service owns which data entities and how cross-service data access is handled (API calls, events, or data replication) to eliminate shared database coupling."
-        },
-        {
-          "type": "contains",
-          "value": "strangler",
-          "description": "The migration strategy must use the strangler fig pattern or an equivalent incremental approach to extract services from the monolith one at a time without requiring a complete rewrite."
-        },
-        {
-          "type": "contains",
-          "value": "event",
-          "description": "The design must include event-driven communication for at least some service interactions (e.g., order placed, payment completed) to reduce synchronous coupling between services."
-        },
-        {
-          "type": "contains",
-          "value": "API gateway",
-          "description": "The design must include an API gateway to route external traffic, handle authentication, and provide a stable public API while internal service boundaries evolve."
-        }
-      ]
-    },
-    {
-      "name": "saga-orchestration-pattern",
-      "description": "Validate that the skill produces a saga orchestration design with proper step sequencing, compensating actions, failure handling, timeout management, and observability for a multi-service transaction.",
-      "input": "Design a saga for an order fulfillment workflow that spans five services: OrderService creates the order, PaymentService charges the customer, InventoryService reserves stock, ShippingService schedules delivery, and NotificationService sends confirmation. Each step can fail independently. Design the saga orchestrator with step sequencing, compensating actions for each step, timeout handling, partial failure recovery, and observability. Show the happy path and at least two failure scenarios with their compensation flows.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "compensat",
-          "description": "The saga must define a compensating action for each step (refund payment, release inventory, cancel shipment) that reverses the effect of a completed step when a subsequent step fails."
-        },
-        {
-          "type": "contains",
-          "value": "orchestrat",
-          "description": "The design must use a central saga orchestrator that coordinates the sequence of steps and manages the saga state machine rather than relying solely on event choreography for this complex workflow."
-        },
-        {
-          "type": "contains",
-          "value": "timeout",
-          "description": "The design must include timeout handling for each saga step so that a hung downstream service does not block the entire saga indefinitely."
-        },
-        {
-          "type": "contains",
-          "value": "idempoten",
-          "description": "Both forward actions and compensating actions must be idempotent so that retries during failure recovery do not create duplicate side effects."
-        },
-        {
-          "type": "contains",
-          "value": "state",
-          "description": "The saga must maintain persistent state (e.g., in a database) tracking which steps have completed, which have failed, and which compensations have run so that recovery is possible after an orchestrator crash."
-        }
-      ]
-    }
-  ]
-}

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/microservices-design/examples/01-monolith-decomposition.md

@@ -1,120 +0,0 @@
-# Example: Monolith-to-Microservices Decomposition
-
-## Prompt
-
-> We have a monolithic e-commerce platform (Node.js, PostgreSQL) handling users, products, orders, payments, inventory, and shipping. We want to break it into microservices without a big-bang rewrite. How do we identify boundaries, handle shared data, and migrate incrementally?
-
-## Response
-
-### Bounded Context Identification
-
-Using domain-driven design event storming, we identify 7 bounded contexts aligned with business capabilities:
-
-| Bounded Context | Core Entities | Key Events | Team |
-|----------------|---------------|------------|------|
-| **Identity** | User, Role, Session | user.registered, user.authenticated | Platform team |
-| **Catalog** | Product, Category, Brand | product.created, product.updated | Catalog team |
-| **Order** | Order, OrderLine, OrderStatus | order.placed, order.confirmed, order.cancelled | Commerce team |
-| **Payment** | Payment, Refund, PaymentMethod | payment.charged, payment.refunded | Payments team |
-| **Inventory** | StockLevel, Reservation, Warehouse | stock.reserved, stock.released, stock.depleted | Supply chain team |
-| **Shipping** | Shipment, TrackingEvent, Carrier | shipment.created, shipment.delivered | Logistics team |
-| **Notification** | Template, Channel, DeliveryLog | notification.sent, notification.failed | Platform team |
-
-### Data Ownership Rules
-
-Each service owns its data exclusively. Cross-context data access is handled through:
-
-1. **API calls** for synchronous queries (e.g., Order service calls Catalog service to get product details for order confirmation).
-2. **Events** for asynchronous state propagation (e.g., Catalog publishes `product.updated`, Order service caches relevant product data locally).
-3. **Data replication** for read-heavy cross-context needs (e.g., Order service maintains a read-only projection of product names and prices to avoid synchronous calls during checkout).
-
-**Anti-pattern avoided:** No shared database. The monolith's single PostgreSQL database will be split so each service has its own schema or database instance.
-
-### Communication Patterns
-
-```
-  External clients
-        │
-        ▼
-  ┌──────────┐
-  │   API    │  Authentication, rate limiting,
-  │ Gateway  │  request routing, TLS termination
-  └────┬─────┘
-       │
-  ┌────┼────────────────────────────────────┐
-  │    │         Service Mesh (Istio)       │
-  │    │    mTLS, retries, circuit breaking │
-  │    │                                    │
-  │  ┌─▼──┐  sync   ┌──────┐              │
-  │  │Order│────────►│Catalog│              │
-  │  │     │         └──────┘              │
-  │  └──┬──┘                               │
-  │     │ event: order.placed              │
-  │     ▼                                  │
-  │  ┌──────┐  event: payment.charged      │
-  │  │Payment│──────────────────┐          │
-  │  └──────┘                   ▼          │
-  │                         ┌────────┐     │
-  │                         │Inventory│     │
-  │                         └───┬────┘     │
-  │                             │ event     │
-  │                             ▼          │
-  │                         ┌────────┐     │
-  │                         │Shipping│     │
-  │                         └───┬────┘     │
-  │                             │ event     │
-  │                             ▼          │
-  │                         ┌──────────┐   │
-  │                         │Notification│  │
-  │                         └──────────┘   │
-  └────────────────────────────────────────┘
-```
-
-- **Synchronous (gRPC):** Order -> Catalog (product lookup during checkout). Low latency, circuit breaker protected.
-- **Asynchronous (Kafka events):** Order -> Payment -> Inventory -> Shipping -> Notification. Decoupled, at-least-once delivery.
-
-### API Gateway Configuration
-
-The API gateway provides a stable external API while internal boundaries evolve:
-
-- `/api/v1/products/*` -> Catalog Service
-- `/api/v1/orders/*` -> Order Service
-- `/api/v1/users/*` -> Identity Service
-- Authentication: JWT validation at the gateway, user context forwarded as headers.
-- Rate limiting: per-API-key and per-endpoint limits.
-
-### Migration Strategy: Strangler Fig
-
-**Phase 1 (Month 1-2): Extract Notification service**
-- Lowest coupling to other domains (no synchronous callers depend on it).
-- Create Notification service, deploy alongside monolith.
-- Monolith publishes events to Kafka instead of sending notifications directly.
-- Notification service consumes events and sends emails/push/SMS.
-- Rollback: re-enable notification sending in monolith, stop consumer.
-
-**Phase 2 (Month 3-4): Extract Catalog service**
-- High read traffic but low write coupling.
-- Stand up Catalog service with its own PostgreSQL.
-- Migrate product data using dual-write (monolith writes to both old and new DB).
-- Gateway routes `/products/*` to new service.
-- Verify data consistency, cut over reads, then stop dual-write.
-
-**Phase 3 (Month 5-7): Extract Payment service**
-- Compliance and PCI scope benefit from isolation.
-- Payment service owns payment tables, exposes charge/refund API.
-- Order flow in monolith calls Payment service instead of internal payment module.
-
-**Phase 4 (Month 8-10): Extract Inventory and Shipping**
-- These are tightly coupled; extract together or in quick succession.
-- Event-driven: Order -> Payment -> Inventory -> Shipping.
-
-**Phase 5 (Month 11-12): Extract Order and Identity**
-- These are the core of the monolith and the last to leave.
-- At this point, the monolith is thin enough to replace entirely.
-
-### Risk Mitigations
-
-- **Feature flags** on every extraction to enable instant rollback to monolith behavior.
-- **Shadow mode** for new services: run both paths, compare outputs, alert on divergence.
-- **Contract tests** between each service pair before cutting over.
-- **Shared nothing** from day one: no service reads another service's database tables.