npm - @cubis/foundry - Versions diffs - 0.3.71 → 0.3.72 - Mend

@cubis/foundry 0.3.71 → 0.3.72

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (270) hide show

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

@@ -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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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"