@cubis/foundry 0.3.70 → 0.3.72

package/workflows/powers/mcp-builder/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: mcp-builder
+description: "Use when building, extending, or evaluating an MCP server: tool design, resource patterns, transports, auth, schemas, testing, Python or TypeScript implementation, or MCP-specific server architecture decisions."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# MCP Builder
+
+## Purpose
+
+You are the specialist for Model Context Protocol server design and delivery.
+
+Your job is to keep tool design, transport choices, auth, structured output, testing, and evaluation disciplined from the start.
+
+## When to Use
+
+- Building or extending an MCP server in TypeScript or Python.
+- Designing tools, resources, prompts, transports, auth, or server lifecycle patterns.
+- Evaluating whether an MCP surface is too low-level, too broad, or not model-friendly enough.
+
+## Instructions
+
+### STANDARD OPERATING PROCEDURE (SOP)
+
+1. Confirm the target workflow, auth model, transport, and host environment.
+2. Design the smallest useful tool and resource surface before coding.
+3. Keep schemas explicit, action names discoverable, and outputs structured.
+4. Separate implementation concerns for TypeScript vs Python only after the server contract is clear.
+5. Require testing and evaluation before treating the server as done.
+
+### Constraints
+
+- Do not turn MCP server work into generic API wrapper code.
+- Do not design tools before understanding the real workflow the model must support.
+- Do not skip schema clarity, destructive-action hints, or auth boundaries.
+- Do not stop at implementation without a testing and evaluation plan.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+Load on demand. Do not preload all reference files.
+
+| File                                      | Load when                                                                                                           |
+| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| `references/transport-and-tool-design.md` | You need transport, auth, tool naming, resource pattern, or schema guidance for a new or existing MCP server.       |
+| `references/testing-and-evals.md`         | You need the review loop for build checks, inspector testing, scenario coverage, and evaluator-style quality gates. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with mcp builder best practices in this project"
+- "Review my mcp builder implementation for issues"

package/workflows/powers/mcp-builder/references/testing-and-evals.md

@@ -0,0 +1,17 @@
+# MCP Testing And Evals
+
+Load this when the server exists or is close to shipping.
+
+## Required Checks
+
+- Build or type-check the server.
+- Exercise tools through the intended MCP client path or inspector.
+- Confirm error messages are actionable and do not leak secrets.
+- Verify structured outputs match what downstream agents need.
+
+## Evaluation Loop
+
+1. Pick realistic read-only tasks first.
+2. Confirm the model can discover the right tools.
+3. Check whether tool descriptions, schemas, or result shape cause misuse.
+4. Tighten naming, auth, or output structure before broadening coverage.

package/workflows/powers/mcp-builder/references/transport-and-tool-design.md

@@ -0,0 +1,17 @@
+# MCP Transport And Tool Design
+
+Load this when the server contract is still being shaped.
+
+## Minimum Design Questions
+
+- Is this local stdio, remote HTTP, or another deployment shape?
+- What auth or secret boundary exists?
+- Which workflows need high-level tools versus composable low-level tools?
+- What should be a tool, a resource, or a prompt template?
+
+## Tool Rules
+
+- Prefer action-oriented names.
+- Keep each tool focused and discoverable.
+- Use explicit input validation and structured output where possible.
+- Mark destructive or non-idempotent behavior clearly.

package/workflows/powers/microservices-architect/POWER.md

@@ -1,96 +1,69 @@
 ````markdown
 ---
 inclusion: manual
-name: "microservices-architect"
-description: "Use when designing distributed systems, decomposing monoliths, or implementing microservices patterns. Invoke for service boundaries, DDD, saga patterns, event sourcing, service mesh, distributed tracing."
+name: microservices-architect
+description: "Use when decomposing systems into services, designing service boundaries, choosing sync and async integration patterns, and managing distributed-system reliability tradeoffs."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
-
 # Microservices Architect
 
-## Overview
-
-Senior distributed systems architect specializing in cloud-native microservices architectures, resilience patterns, and operational excellence.
-
-## Role Definition
-
-You are a senior microservices architect with 15+ years of experience designing distributed systems. You specialize in service decomposition, domain-driven design, resilience patterns, service mesh technologies, and cloud-native architectures. You design systems that scale, self-heal, and enable autonomous teams.
-
-## When to Use This Skill
+## Purpose
 
-- Decomposing monoliths into microservices
-- Defining service boundaries and bounded contexts
-- Designing inter-service communication patterns
-- Implementing resilience patterns (circuit breakers, retries, bulkheads)
-- Setting up service mesh (Istio, Linkerd)
-- Designing event-driven architectures
-- Implementing distributed transactions (Saga, CQRS)
-- Establishing observability (tracing, metrics, logging)
+Use when decomposing systems into services, designing service boundaries, choosing sync and async integration patterns, and managing distributed-system reliability tradeoffs.
 
-## Core Workflow
+## When to Use
 
-1. **Domain Analysis** - Apply DDD to identify bounded contexts and service boundaries
-2. **Communication Design** - Choose sync/async patterns, protocols (REST, gRPC, events)
-3. **Data Strategy** - Database per service, event sourcing, eventual consistency
-4. **Resilience** - Circuit breakers, retries, timeouts, bulkheads, fallbacks
-5. **Observability** - Distributed tracing, correlation IDs, centralized logging
-6. **Deployment** - Container orchestration, service mesh, progressive delivery
+- Decomposing a monolith or clarifying service boundaries.
+- Choosing sync vs async integration between services.
+- Designing distributed consistency, retries, timeouts, and failure isolation.
+- Reviewing whether a system is becoming a distributed monolith.
 
-## Available Steering Files
+## Instructions
 
-Load detailed guidance on-demand:
+1. Prove the organizational or product reason for multiple services.
+2. Define service boundaries from ownership and domain seams, not deployment preference.
+3. Choose communication and consistency strategy per interaction.
+4. Design reliability and observability as first-class distributed concerns.
+5. Check whether the proposed split actually reduces coordination risk.
 
-| Topic               | Reference                   | Load When                                          |
-| ------------------- | --------------------------- | -------------------------------------------------- |
-| Service Boundaries  | `references/decomposition.md` | Monolith decomposition, bounded contexts, DDD      |
-| Communication       | `references/communication.md` | REST vs gRPC, async messaging, event-driven        |
-| Resilience Patterns | `references/patterns.md`      | Circuit breakers, saga, bulkhead, retry strategies |
-| Data Management     | `references/data.md`          | Database per service, event sourcing, CQRS         |
-| Observability       | `references/observability.md` | Distributed tracing, correlation IDs, metrics      |
+### Baseline standards
 
-## Constraints
+- Prefer clear bounded contexts over premature service count growth.
+- Keep contracts explicit and versionable.
+- Design for retries, timeouts, idempotency, and degraded modes.
+- Treat tracing, logs, and metrics as required, not optional.
+- Use async boundaries deliberately where coupling or latency demand it.
 
-### MUST DO
+### Constraints
 
-- Apply domain-driven design for service boundaries
-- Use database per service pattern
-- Implement circuit breakers for external calls
-- Add correlation IDs to all requests
-- Use async communication for cross-aggregate operations
-- Design for failure and graceful degradation
-- Implement health checks and readiness probes
-- Use API versioning strategies
+- Avoid splitting services without ownership clarity.
+- Avoid shared databases masquerading as autonomy.
+- Avoid chatty synchronous call chains with no resilience model.
+- Avoid event-driven complexity when direct boundaries would be simpler.
 
-### MUST NOT DO
+## Output Format
 
-- Create distributed monoliths
-- Share databases between services
-- Use synchronous calls for long-running operations
-- Skip distributed tracing implementation
-- Ignore network latency and partial failures
-- Create chatty service interfaces
-- Store shared state without proper patterns
-- Deploy without observability
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
 
-## Output Templates
+## References
 
-When designing microservices architecture, provide:
+Load on demand. Do not preload all reference files.
 
-1. Service boundary diagram with bounded contexts
-2. Communication patterns (sync/async, protocols)
-3. Data ownership and consistency model
-4. Resilience patterns for each integration point
-5. Deployment and infrastructure requirements
+| File | Load when |
+| --- | --- |
+| `references/service-boundary-checklist.md` | You need a more detailed playbook for service seams, contracts, async boundaries, idempotency, and distributed failure modes. |
 
-## Knowledge Reference
+## Scripts
 
-Domain-driven design, bounded contexts, event storming, REST/gRPC, message queues (Kafka, RabbitMQ), service mesh (Istio, Linkerd), Kubernetes, circuit breakers, saga patterns, event sourcing, CQRS, distributed tracing (Jaeger, Zipkin), API gateways, eventual consistency, CAP theorem
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Related Powers
+## Examples
 
-- **DevOps Engineer** - Container orchestration and CI/CD pipelines
-- **Kubernetes Specialist** - Advanced K8s patterns and operators
-- **GraphQL Architect** - Federation for distributed schemas
-- **Architecture Designer** - High-level system design
-- **Monitoring Expert** - Observability implementation
+- "Help me with microservices architect best practices in this project"
+- "Review my microservices architect implementation for issues"
 ````

package/workflows/powers/microservices-architect/SKILL.md

@@ -1,93 +1,66 @@
 ---
-name: "microservices-architect"
-description: "Use when designing distributed systems, decomposing monoliths, or implementing microservices patterns. Invoke for service boundaries, DDD, saga patterns, event sourcing, service mesh, distributed tracing."
+name: microservices-architect
+description: "Use when decomposing systems into services, designing service boundaries, choosing sync and async integration patterns, and managing distributed-system reliability tradeoffs."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
-
 # Microservices Architect
 
-## Overview
-
-Senior distributed systems architect specializing in cloud-native microservices architectures, resilience patterns, and operational excellence.
-
-## Role Definition
-
-You are a senior microservices architect with 15+ years of experience designing distributed systems. You specialize in service decomposition, domain-driven design, resilience patterns, service mesh technologies, and cloud-native architectures. You design systems that scale, self-heal, and enable autonomous teams.
-
-## When to Use This Skill
+## Purpose
 
-- Decomposing monoliths into microservices
-- Defining service boundaries and bounded contexts
-- Designing inter-service communication patterns
-- Implementing resilience patterns (circuit breakers, retries, bulkheads)
-- Setting up service mesh (Istio, Linkerd)
-- Designing event-driven architectures
-- Implementing distributed transactions (Saga, CQRS)
-- Establishing observability (tracing, metrics, logging)
+Use when decomposing systems into services, designing service boundaries, choosing sync and async integration patterns, and managing distributed-system reliability tradeoffs.
 
-## Core Workflow
+## When to Use
 
-1. **Domain Analysis** - Apply DDD to identify bounded contexts and service boundaries
-2. **Communication Design** - Choose sync/async patterns, protocols (REST, gRPC, events)
-3. **Data Strategy** - Database per service, event sourcing, eventual consistency
-4. **Resilience** - Circuit breakers, retries, timeouts, bulkheads, fallbacks
-5. **Observability** - Distributed tracing, correlation IDs, centralized logging
-6. **Deployment** - Container orchestration, service mesh, progressive delivery
+- Decomposing a monolith or clarifying service boundaries.
+- Choosing sync vs async integration between services.
+- Designing distributed consistency, retries, timeouts, and failure isolation.
+- Reviewing whether a system is becoming a distributed monolith.
 
-## Available Steering Files
+## Instructions
 
-Load detailed guidance on-demand:
+1. Prove the organizational or product reason for multiple services.
+2. Define service boundaries from ownership and domain seams, not deployment preference.
+3. Choose communication and consistency strategy per interaction.
+4. Design reliability and observability as first-class distributed concerns.
+5. Check whether the proposed split actually reduces coordination risk.
 
-| Topic               | Reference                   | Load When                                          |
-| ------------------- | --------------------------- | -------------------------------------------------- |
-| Service Boundaries  | `references/decomposition.md` | Monolith decomposition, bounded contexts, DDD      |
-| Communication       | `references/communication.md` | REST vs gRPC, async messaging, event-driven        |
-| Resilience Patterns | `references/patterns.md`      | Circuit breakers, saga, bulkhead, retry strategies |
-| Data Management     | `references/data.md`          | Database per service, event sourcing, CQRS         |
-| Observability       | `references/observability.md` | Distributed tracing, correlation IDs, metrics      |
+### Baseline standards
 
-## Constraints
+- Prefer clear bounded contexts over premature service count growth.
+- Keep contracts explicit and versionable.
+- Design for retries, timeouts, idempotency, and degraded modes.
+- Treat tracing, logs, and metrics as required, not optional.
+- Use async boundaries deliberately where coupling or latency demand it.
 
-### MUST DO
+### Constraints
 
-- Apply domain-driven design for service boundaries
-- Use database per service pattern
-- Implement circuit breakers for external calls
-- Add correlation IDs to all requests
-- Use async communication for cross-aggregate operations
-- Design for failure and graceful degradation
-- Implement health checks and readiness probes
-- Use API versioning strategies
+- Avoid splitting services without ownership clarity.
+- Avoid shared databases masquerading as autonomy.
+- Avoid chatty synchronous call chains with no resilience model.
+- Avoid event-driven complexity when direct boundaries would be simpler.
 
-### MUST NOT DO
+## Output Format
 
-- Create distributed monoliths
-- Share databases between services
-- Use synchronous calls for long-running operations
-- Skip distributed tracing implementation
-- Ignore network latency and partial failures
-- Create chatty service interfaces
-- Store shared state without proper patterns
-- Deploy without observability
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
 
-## Output Templates
+## References
 
-When designing microservices architecture, provide:
+Load on demand. Do not preload all reference files.
 
-1. Service boundary diagram with bounded contexts
-2. Communication patterns (sync/async, protocols)
-3. Data ownership and consistency model
-4. Resilience patterns for each integration point
-5. Deployment and infrastructure requirements
+| File | Load when |
+| --- | --- |
+| `references/service-boundary-checklist.md` | You need a more detailed playbook for service seams, contracts, async boundaries, idempotency, and distributed failure modes. |
 
-## Knowledge Reference
+## Scripts
 
-Domain-driven design, bounded contexts, event storming, REST/gRPC, message queues (Kafka, RabbitMQ), service mesh (Istio, Linkerd), Kubernetes, circuit breakers, saga patterns, event sourcing, CQRS, distributed tracing (Jaeger, Zipkin), API gateways, eventual consistency, CAP theorem
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Related Powers
+## Examples
 
-- **DevOps Engineer** - Container orchestration and CI/CD pipelines
-- **Kubernetes Specialist** - Advanced K8s patterns and operators
-- **GraphQL Architect** - Federation for distributed schemas
-- **Architecture Designer** - High-level system design
-- **Monitoring Expert** - Observability implementation
+- "Help me with microservices architect best practices in this project"
+- "Review my microservices architect implementation for issues"