@cubis/foundry 0.3.71 → 0.3.72

package/workflows/powers/javascript-pro/SKILL.md

@@ -1,55 +1,68 @@
 ---
 name: "javascript-pro"
-description: "Use for modern JavaScript architecture and implementation across browser, Node, and edge runtimes with ES2025+ practices."
+description: "Use for modern JavaScript architecture and implementation across browser, Node, and edge runtimes with runtime-aware production practices."
 license: MIT
 metadata:
-  version: "2.0.0"
-  domain: "language"
-  role: "specialist"
-  stack: "javascript"
-  baseline: "ES2025+"
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # JavaScript Pro
 
-## When to use
+## Purpose
+
+Expert-level guidance for modern JavaScript development across browser, Node.js, and edge runtimes. Covers module design, async orchestration, runtime-specific patterns, and production-grade error handling with a focus on runtime-aware code that respects platform boundaries.
+
+## When to Use
 
 - Implementing feature work in plain JavaScript.
 - Refactoring legacy JS toward modern modules and async flows.
-- Improving performance and reliability in browser/Node runtimes.
+- Improving performance and reliability in browser, Node, or edge runtimes.
+- Serving as the language baseline before framework-specific skills are loaded.
+
+## Instructions
+
+1. **Confirm runtime constraints** — identify browser targets, Node version, or edge runtime before choosing APIs or module formats. Runtime determines available features and performance characteristics.
+
+2. **Choose module boundaries and format** — prefer ESM (`import`/`export`) for new code. Configure `"type": "module"` in `package.json`. Keep modules focused to one responsibility. Use barrel exports (`index.js`) only for the public API to preserve tree-shaking.
+
+3. **Design async strategy** — use `AbortSignal` and `AbortController` for cancellable operations. Use `Promise.allSettled()` when all results matter regardless of individual failures. Limit concurrent operations with semaphore patterns to prevent resource exhaustion.
+
+4. **Implement with explicit error and cancellation handling** — always attach `.catch()` or use `try/catch` in async flows. Do not leave promise rejections unhandled because they terminate Node.js processes and cause silent failures in browsers.
+
+5. **Keep side effects at module edges** — pure logic belongs in reusable modules. Side-effectful initialization at module top-level prevents tree-shaking and complicates testing.
+
+6. **Validate untrusted input at boundaries** — sanitize at system entry points such as API handlers and form inputs. Keep dependency surface intentionally small.
+
+7. **Use runtime-appropriate tooling** — Vitest or `node --test` for testing, Biome or ESLint for linting, Vite or esbuild for bundling. Use lockfile-based installs (`npm ci`, `pnpm install --frozen-lockfile`) in CI. Enable `corepack` for consistent package manager versions.
+
+8. **Debug in the target environment** — reproduce runtime-specific failures in the exact target (browser, Node, or edge). Use structured logging with consistent error shapes. Profile with Chrome DevTools or `node --prof` before redesigning hot paths.
 
-## Core workflow
+9. **Optimize deliberately** — use streams for large payloads to avoid memory spikes. Use `Promise.all` for independent parallel operations. Use dynamic `import()` for code-splitting heavy modules. Do not use UA sniffing in browser code because feature detection is more reliable and maintainable.
 
-1. Confirm runtime constraints (browser targets, Node/edge version).
-2. Choose module boundaries and async strategy.
-3. Implement with explicit error and cancellation handling.
-4. Verify behavior with tests and runtime checks.
+10. **Do not use heavy framework coupling in low-level modules** because it prevents reuse. Do not allow copy-paste utility proliferation without consolidation because it causes drift and duplication.
 
-## Baseline standards
+## Output Format
 
-- Prefer ESM for new code unless compatibility blocks it.
-- Use `AbortSignal` for cancellable async operations.
-- Keep side effects at edges; pure logic in reusable modules.
-- Validate untrusted input at boundaries.
-- Keep dependency surface intentionally small.
+Produces JavaScript code following ESM module conventions with explicit async error handling, runtime-appropriate API usage, and clear module boundaries. Includes structured error objects and cancellation support where applicable.
 
-## Implementation guidance
+## References
 
-- Use `Promise.all` for independent parallel operations.
-- Use structured logging and consistent error shapes.
-- Use streams for large payloads to avoid memory spikes.
-- Use feature detection, not UA sniffing, in browser code.
+| File                            | Load when                                                                   |
+| ------------------------------- | --------------------------------------------------------------------------- |
+| `references/modern-syntax.md`   | Choosing modern syntax/features for current runtime targets.                |
+| `references/async-patterns.md`  | Cancellation, retries, concurrency, or promise orchestration needs detail.  |
+| `references/modules.md`         | ESM/CJS/module-boundary tradeoffs are in scope.                             |
+| `references/browser-apis.md`    | Browser-specific APIs, capability checks, or UX/runtime constraints matter. |
+| `references/node-essentials.md` | Node runtime behavior, streams, files, or process concerns matter.          |
 
-## Avoid
+## Scripts
 
-- Silent promise rejections.
-- Heavy framework coupling in low-level modules.
-- Copy-paste utility proliferation without consolidation.
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Reference files
+## Examples
 
-- `references/modern-syntax.md`
-- `references/async-patterns.md`
-- `references/modules.md`
-- `references/browser-apis.md`
-- `references/node-essentials.md`
+- "Refactor this callback-heavy Express handler to use async/await with proper error handling and AbortController for timeout."
+- "Design the module structure for a shared utility library that needs to support both ESM and CJS consumers."
+- "Optimize this Node.js data pipeline to use streams instead of loading the full dataset into memory."

package/workflows/powers/kotlin-pro/POWER.md

@@ -5,39 +5,62 @@ name: "kotlin-pro"
 description: "Use for modern Kotlin backend/mobile/shared code with Kotlin 2.3-era language tooling and production patterns."
 license: MIT
 metadata:
-  version: "1.0.0"
-  domain: "language"
-  role: "specialist"
-  stack: "kotlin"
-  baseline: "Kotlin 2.3 line (2.2.20+ compatible)"
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Kotlin Pro
 
-## When to use
+## Purpose
+
+Expert-level guidance for modern Kotlin development across JVM, Android, and multiplatform targets. Covers null safety, coroutine-based concurrency, Flow patterns, sealed type hierarchies, and Kotlin Multiplatform architecture with production testing discipline.
+
+## When to Use
 
 - Building Kotlin services or Android/shared modules.
-- Designing coroutine-based async flows.
-- Improving null-safety and domain model clarity.
+- Designing coroutine-based async flows and reactive patterns.
+- Improving null-safety, domain model clarity, and testability.
+
+## Instructions
+
+1. **Establish target platform** — confirm JVM, Android, or Kotlin Multiplatform before choosing runtime-specific APIs. Put shared logic in `commonMain`; platform-specific implementations in `androidMain`/`iosMain`/`jvmMain`.
+
+2. **Design types with null safety** — keep nullability explicit. Prefer non-null types by default; use `?` only when null is valid domain state. Use `sealed class`/`sealed interface` for closed type hierarchies with exhaustive `when`. Use `data class` for value objects. Use `value class` for type-safe wrappers with zero runtime overhead. Do not use `!!` (forced non-null) in production code because it crashes at runtime — use `requireNotNull` with a message or safe alternatives (`?.`, `?:`, `let`).
+
+3. **Model concurrency with structured coroutines** — always launch coroutines in a scope with clear ownership (`viewModelScope`, `lifecycleScope`, custom `CoroutineScope`). Use `supervisorScope` when child failures should not cancel siblings. Use `withContext(Dispatchers.IO)` for blocking I/O. Use `withTimeout` for time-bounded operations. Respect cancellation by checking `isActive` in loops and letting `CancellationException` propagate. Do not use `GlobalScope` because it breaks structured concurrency and hides lifecycle bugs. Do not use `runBlocking` on the main thread because it deadlocks on Android and blocks server threads.
+
+4. **Use Flow for reactive streams** — use `StateFlow` for observable state; `SharedFlow` for events. Use `stateIn`/`shareIn` to share upstream flows. Prefer `flow {}` for cold streams; `channelFlow` when coroutine interleaving is needed. Use `flowOn(Dispatchers.IO)` for upstream context shifting. Handle backpressure with `conflate()`, `buffer()`, or `collectLatest`.
+
+5. **Keep serialization and transport separate from domain** — use `kotlinx.serialization` for cross-platform serialization (not Gson or Moshi in multiplatform code). Keep platform boundary interfaces thin; heavy logic belongs in common code. Use `expect`/`actual` declarations for platform abstractions.
+
+6. **Use extensions and DSLs judiciously** — prefer member functions for core type behavior; extensions for cross-cutting concerns. Scope extensions to the narrowest visibility. Use receiver-based DSLs for configuration blocks. Do not overuse extension properties because functions are more discoverable in IDE completion.
+
+7. **Validate with tests, detekt, and ktlint** — keep coroutine context, dispatcher use, and cancellation visible in logs and traces. Use `-Dkotlinx.coroutines.debug` for coroutine creation stack traces in development. Use `CoroutineExceptionHandler` at scope boundaries. Bound coroutine fan-out with `limitedParallelism` or `Semaphore`. Do not launch coroutines without lifecycle ownership because it causes leaks on Android and servers.
+
+8. **Optimize with measurement** — use `Sequence` for lazy evaluation of large collections; `List` for small, eager operations. Prefer `buildList`, `buildMap`, `buildSet` for efficient construction. Use `value class` for primitive wrappers in hot paths. Do not allow platform-specific leakage into shared/core modules because it breaks multiplatform portability. Measure with profiling tools before micro-optimizing.
+
+## Output Format
+
+Produces Kotlin code using data classes, sealed hierarchies, structured coroutines, and Flow patterns with explicit null safety and platform-appropriate architecture. Includes multiplatform separation where applicable.
 
-## Core workflow
+## References
 
-1. Establish target platform (JVM/Android/multiplatform).
-2. Define domain types and boundary contracts first.
-3. Implement with coroutine/flow patterns where appropriate.
-4. Validate with tests and static analysis.
+| File                                      | Load when                                                                                               |
+| ----------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| `references/operational-baseline.md`      | You need Kotlin coroutine, modularity, testing, and production guardrails.                              |
+| `references/coroutine-patterns.md`        | You need structured concurrency, scope management, dispatcher selection, or cancellation design.        |
+| `references/flow-and-channels.md`         | You need StateFlow/SharedFlow patterns, reactive streams, backpressure, or channel-based communication. |
+| `references/sealed-types-and-dsl.md`      | You need sealed class hierarchies, value classes, pattern matching, or DSL builder patterns.            |
+| `references/multiplatform-and-testing.md` | You need KMP architecture, expect/actual patterns, or coroutine test strategies.                        |
 
-## Baseline standards
+## Scripts
 
-- Keep nullability explicit; avoid forced non-null assertions.
-- Prefer immutable data models and pure transforms.
-- Use structured concurrency and clear scope ownership.
-- Keep serialization and transport models separate from domain.
-- Use dependency boundaries that support modular testing.
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Avoid
+## Examples
 
-- Coroutine launches without lifecycle ownership.
-- Platform-specific leakage into shared/core modules.
-- Overusing extension magic that hurts readability.
+- "Design a coroutine-based repository layer with StateFlow for UI state and proper cancellation handling."
+- "Refactor this Java-style service to use sealed classes, when expressions, and value classes for type safety."
+- "Set up the Kotlin Multiplatform module structure with shared business logic and platform-specific implementations."
 ````

package/workflows/powers/kotlin-pro/SKILL.md

@@ -3,38 +3,61 @@ name: "kotlin-pro"
 description: "Use for modern Kotlin backend/mobile/shared code with Kotlin 2.3-era language tooling and production patterns."
 license: MIT
 metadata:
-  version: "1.0.0"
-  domain: "language"
-  role: "specialist"
-  stack: "kotlin"
-  baseline: "Kotlin 2.3 line (2.2.20+ compatible)"
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Kotlin Pro
 
-## When to use
+## Purpose
+
+Expert-level guidance for modern Kotlin development across JVM, Android, and multiplatform targets. Covers null safety, coroutine-based concurrency, Flow patterns, sealed type hierarchies, and Kotlin Multiplatform architecture with production testing discipline.
+
+## When to Use
 
 - Building Kotlin services or Android/shared modules.
-- Designing coroutine-based async flows.
-- Improving null-safety and domain model clarity.
+- Designing coroutine-based async flows and reactive patterns.
+- Improving null-safety, domain model clarity, and testability.
+
+## Instructions
+
+1. **Establish target platform** — confirm JVM, Android, or Kotlin Multiplatform before choosing runtime-specific APIs. Put shared logic in `commonMain`; platform-specific implementations in `androidMain`/`iosMain`/`jvmMain`.
+
+2. **Design types with null safety** — keep nullability explicit. Prefer non-null types by default; use `?` only when null is valid domain state. Use `sealed class`/`sealed interface` for closed type hierarchies with exhaustive `when`. Use `data class` for value objects. Use `value class` for type-safe wrappers with zero runtime overhead. Do not use `!!` (forced non-null) in production code because it crashes at runtime — use `requireNotNull` with a message or safe alternatives (`?.`, `?:`, `let`).
+
+3. **Model concurrency with structured coroutines** — always launch coroutines in a scope with clear ownership (`viewModelScope`, `lifecycleScope`, custom `CoroutineScope`). Use `supervisorScope` when child failures should not cancel siblings. Use `withContext(Dispatchers.IO)` for blocking I/O. Use `withTimeout` for time-bounded operations. Respect cancellation by checking `isActive` in loops and letting `CancellationException` propagate. Do not use `GlobalScope` because it breaks structured concurrency and hides lifecycle bugs. Do not use `runBlocking` on the main thread because it deadlocks on Android and blocks server threads.
+
+4. **Use Flow for reactive streams** — use `StateFlow` for observable state; `SharedFlow` for events. Use `stateIn`/`shareIn` to share upstream flows. Prefer `flow {}` for cold streams; `channelFlow` when coroutine interleaving is needed. Use `flowOn(Dispatchers.IO)` for upstream context shifting. Handle backpressure with `conflate()`, `buffer()`, or `collectLatest`.
+
+5. **Keep serialization and transport separate from domain** — use `kotlinx.serialization` for cross-platform serialization (not Gson or Moshi in multiplatform code). Keep platform boundary interfaces thin; heavy logic belongs in common code. Use `expect`/`actual` declarations for platform abstractions.
+
+6. **Use extensions and DSLs judiciously** — prefer member functions for core type behavior; extensions for cross-cutting concerns. Scope extensions to the narrowest visibility. Use receiver-based DSLs for configuration blocks. Do not overuse extension properties because functions are more discoverable in IDE completion.
+
+7. **Validate with tests, detekt, and ktlint** — keep coroutine context, dispatcher use, and cancellation visible in logs and traces. Use `-Dkotlinx.coroutines.debug` for coroutine creation stack traces in development. Use `CoroutineExceptionHandler` at scope boundaries. Bound coroutine fan-out with `limitedParallelism` or `Semaphore`. Do not launch coroutines without lifecycle ownership because it causes leaks on Android and servers.
+
+8. **Optimize with measurement** — use `Sequence` for lazy evaluation of large collections; `List` for small, eager operations. Prefer `buildList`, `buildMap`, `buildSet` for efficient construction. Use `value class` for primitive wrappers in hot paths. Do not allow platform-specific leakage into shared/core modules because it breaks multiplatform portability. Measure with profiling tools before micro-optimizing.
+
+## Output Format
+
+Produces Kotlin code using data classes, sealed hierarchies, structured coroutines, and Flow patterns with explicit null safety and platform-appropriate architecture. Includes multiplatform separation where applicable.
 
-## Core workflow
+## References
 
-1. Establish target platform (JVM/Android/multiplatform).
-2. Define domain types and boundary contracts first.
-3. Implement with coroutine/flow patterns where appropriate.
-4. Validate with tests and static analysis.
+| File                                      | Load when                                                                                               |
+| ----------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| `references/operational-baseline.md`      | You need Kotlin coroutine, modularity, testing, and production guardrails.                              |
+| `references/coroutine-patterns.md`        | You need structured concurrency, scope management, dispatcher selection, or cancellation design.        |
+| `references/flow-and-channels.md`         | You need StateFlow/SharedFlow patterns, reactive streams, backpressure, or channel-based communication. |
+| `references/sealed-types-and-dsl.md`      | You need sealed class hierarchies, value classes, pattern matching, or DSL builder patterns.            |
+| `references/multiplatform-and-testing.md` | You need KMP architecture, expect/actual patterns, or coroutine test strategies.                        |
 
-## Baseline standards
+## Scripts
 
-- Keep nullability explicit; avoid forced non-null assertions.
-- Prefer immutable data models and pure transforms.
-- Use structured concurrency and clear scope ownership.
-- Keep serialization and transport models separate from domain.
-- Use dependency boundaries that support modular testing.
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Avoid
+## Examples
 
-- Coroutine launches without lifecycle ownership.
-- Platform-specific leakage into shared/core modules.
-- Overusing extension magic that hurts readability.
+- "Design a coroutine-based repository layer with StateFlow for UI state and proper cancellation handling."
+- "Refactor this Java-style service to use sealed classes, when expressions, and value classes for type safety."
+- "Set up the Kotlin Multiplatform module structure with shared business logic and platform-specific implementations."

package/workflows/powers/legacy-modernizer/POWER.md

@@ -2,86 +2,69 @@
 ---
 inclusion: manual
 name: legacy-modernizer
-description: Use when modernizing legacy systems, implementing incremental migration strategies, or reducing technical debt. Invoke for strangler fig pattern, monolith decomposition, framework upgrades.
+description: "Use when planning and executing incremental migration of legacy systems using strangler fig, branch by abstraction, and feature-flag-controlled rollouts."
 license: MIT
 metadata:
-  author: https://github.com/Jeffallan
-  version: "1.0.0"
-  domain: specialized
-  triggers: legacy modernization, strangler fig, incremental migration, technical debt, legacy refactoring, system migration, legacy system, modernize codebase
-  role: specialist
-  scope: architecture
-  output-format: code+analysis
-  related-skills: test-master, devops-engineer
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Legacy Modernizer
 
-Senior legacy modernization specialist with expertise in transforming aging systems into modern architectures without disrupting business operations.
+## Purpose
 
-## Role Definition
+Use when planning and executing incremental migration of legacy systems using strangler fig, branch by abstraction, and feature-flag-controlled rollouts.
 
-You are a senior legacy modernization expert with 15+ years of experience in incremental migration strategies. You specialize in strangler fig pattern, branch by abstraction, and risk-free modernization approaches. You transform legacy systems while maintaining zero downtime and ensuring business continuity.
+## When to Use
 
-## When to Use This Skill
+- Migrating legacy systems to modern architectures without big-bang rewrites.
+- Designing strangler fig patterns for gradual service extraction.
+- Planning incremental migrations with feature flags and canary rollouts.
+- Building safety nets (characterization tests) before changing legacy behavior.
+- Modernizing databases, APIs, or UI layers incrementally.
 
-- Modernizing legacy codebases and outdated technology stacks
-- Implementing strangler fig or branch by abstraction patterns
-- Migrating from monoliths to microservices incrementally
-- Refactoring legacy code with comprehensive safety nets
-- Upgrading frameworks, languages, or infrastructure safely
-- Reducing technical debt while maintaining business continuity
+## Instructions
 
-## Core Workflow
+1. Assess the system — map dependencies, identify high-risk areas, and document current behavior.
+2. Plan the migration — choose strategy (strangler fig, branch by abstraction, parallel run) and define phases.
+3. Build a safety net — write characterization tests that capture current behavior before any changes.
+4. Migrate incrementally — extract one bounded context at a time behind feature flags.
+5. Validate and iterate — verify behavior parity, monitor for regressions, roll back if needed.
+6. Decommission legacy — remove old code paths only after migration is verified and stable.
 
-1. **Assess system** - Analyze codebase, dependencies, risks, and business constraints
-2. **Plan migration** - Design incremental roadmap with rollback strategies
-3. **Build safety net** - Create characterization tests and monitoring
-4. **Migrate incrementally** - Apply strangler fig pattern with feature flags
-5. **Validate & iterate** - Test thoroughly, monitor metrics, adjust approach
+### Baseline standards
 
-## Reference Guide
+- Zero production disruption is the primary constraint.
+- Maintain 80%+ test coverage on migrated paths.
+- Use feature flags for all migration switches.
+- Include monitoring and rollback capability for every migration step.
+- Document every decision and its rationale.
+- Preserve existing business logic exactly unless explicitly changing it.
 
-Load detailed guidance based on context:
+### Constraints
 
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| Strangler Fig | `references/strangler-fig-pattern.md` | Incremental replacement, facade layer, routing |
-| Refactoring | `references/refactoring-patterns.md` | Extract service, branch by abstraction, adapters |
-| Migration | `references/migration-strategies.md` | Database, UI, API, framework migrations |
-| Testing | `references/legacy-testing.md` | Characterization tests, golden master, approval |
-| Assessment | `references/system-assessment.md` | Code analysis, dependency mapping, risk evaluation |
+- Never attempt big-bang rewrites — always migrate incrementally.
+- Never skip characterization testing before modifying legacy behavior.
+- Never deploy migration steps without rollback capability.
+- Never remove legacy code until the replacement is verified in production.
+- Always maintain the ability to revert to the previous system state.
 
-## Constraints
+## Output Format
 
-### MUST DO
-- Maintain zero production disruption during all migrations
-- Create comprehensive test coverage before refactoring (target 80%+)
-- Use feature flags for all incremental rollouts
-- Implement monitoring and rollback procedures
-- Document all migration decisions and rationale
-- Preserve existing business logic and behavior
-- Communicate progress and risks transparently
+Provide a migration plan with phases, risk assessment, rollback strategy, and verification checkpoints.
 
-### MUST NOT DO
-- Big bang rewrites or replacements
-- Skip testing legacy behavior before changes
-- Deploy without rollback capability
-- Break existing integrations or APIs
-- Ignore technical debt in new code
-- Rush migrations without proper validation
-- Remove legacy code before new code is proven
+## References
 
-## Output Templates
+No additional reference files.
 
-When implementing modernization, provide:
-1. Assessment summary (risks, dependencies, approach)
-2. Migration plan (phases, rollback strategy, metrics)
-3. Implementation code (facades, adapters, new services)
-4. Test coverage (characterization, integration, e2e)
-5. Monitoring setup (metrics, alerts, dashboards)
+## Scripts
 
-## Knowledge Reference
+No helper scripts are required for this skill right now.
 
-Strangler fig pattern, branch by abstraction, characterization testing, incremental migration, feature flags, canary deployments, API versioning, database refactoring, microservices extraction, technical debt reduction, zero-downtime deployment
+## Examples
+
+- "Plan a strangler fig migration for this monolithic API"
+- "Design characterization tests for this legacy payment module"
+- "Create a phased migration plan with feature flags and rollback"
 ````

package/workflows/powers/legacy-modernizer/SKILL.md

@@ -1,84 +1,67 @@
 ---
 name: legacy-modernizer
-description: Use when modernizing legacy systems, implementing incremental migration strategies, or reducing technical debt. Invoke for strangler fig pattern, monolith decomposition, framework upgrades.
+description: "Use when planning and executing incremental migration of legacy systems using strangler fig, branch by abstraction, and feature-flag-controlled rollouts."
 license: MIT
 metadata:
-  author: https://github.com/Jeffallan
-  version: "1.0.0"
-  domain: specialized
-  triggers: legacy modernization, strangler fig, incremental migration, technical debt, legacy refactoring, system migration, legacy system, modernize codebase
-  role: specialist
-  scope: architecture
-  output-format: code+analysis
-  related-skills: test-master, devops-engineer
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # Legacy Modernizer
 
-Senior legacy modernization specialist with expertise in transforming aging systems into modern architectures without disrupting business operations.
+## Purpose
 
-## Role Definition
+Use when planning and executing incremental migration of legacy systems using strangler fig, branch by abstraction, and feature-flag-controlled rollouts.
 
-You are a senior legacy modernization expert with 15+ years of experience in incremental migration strategies. You specialize in strangler fig pattern, branch by abstraction, and risk-free modernization approaches. You transform legacy systems while maintaining zero downtime and ensuring business continuity.
+## When to Use
 
-## When to Use This Skill
+- Migrating legacy systems to modern architectures without big-bang rewrites.
+- Designing strangler fig patterns for gradual service extraction.
+- Planning incremental migrations with feature flags and canary rollouts.
+- Building safety nets (characterization tests) before changing legacy behavior.
+- Modernizing databases, APIs, or UI layers incrementally.
 
-- Modernizing legacy codebases and outdated technology stacks
-- Implementing strangler fig or branch by abstraction patterns
-- Migrating from monoliths to microservices incrementally
-- Refactoring legacy code with comprehensive safety nets
-- Upgrading frameworks, languages, or infrastructure safely
-- Reducing technical debt while maintaining business continuity
+## Instructions
 
-## Core Workflow
+1. Assess the system — map dependencies, identify high-risk areas, and document current behavior.
+2. Plan the migration — choose strategy (strangler fig, branch by abstraction, parallel run) and define phases.
+3. Build a safety net — write characterization tests that capture current behavior before any changes.
+4. Migrate incrementally — extract one bounded context at a time behind feature flags.
+5. Validate and iterate — verify behavior parity, monitor for regressions, roll back if needed.
+6. Decommission legacy — remove old code paths only after migration is verified and stable.
 
-1. **Assess system** - Analyze codebase, dependencies, risks, and business constraints
-2. **Plan migration** - Design incremental roadmap with rollback strategies
-3. **Build safety net** - Create characterization tests and monitoring
-4. **Migrate incrementally** - Apply strangler fig pattern with feature flags
-5. **Validate & iterate** - Test thoroughly, monitor metrics, adjust approach
+### Baseline standards
 
-## Reference Guide
+- Zero production disruption is the primary constraint.
+- Maintain 80%+ test coverage on migrated paths.
+- Use feature flags for all migration switches.
+- Include monitoring and rollback capability for every migration step.
+- Document every decision and its rationale.
+- Preserve existing business logic exactly unless explicitly changing it.
 
-Load detailed guidance based on context:
+### Constraints
 
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| Strangler Fig | `references/strangler-fig-pattern.md` | Incremental replacement, facade layer, routing |
-| Refactoring | `references/refactoring-patterns.md` | Extract service, branch by abstraction, adapters |
-| Migration | `references/migration-strategies.md` | Database, UI, API, framework migrations |
-| Testing | `references/legacy-testing.md` | Characterization tests, golden master, approval |
-| Assessment | `references/system-assessment.md` | Code analysis, dependency mapping, risk evaluation |
+- Never attempt big-bang rewrites — always migrate incrementally.
+- Never skip characterization testing before modifying legacy behavior.
+- Never deploy migration steps without rollback capability.
+- Never remove legacy code until the replacement is verified in production.
+- Always maintain the ability to revert to the previous system state.
 
-## Constraints
+## Output Format
 
-### MUST DO
-- Maintain zero production disruption during all migrations
-- Create comprehensive test coverage before refactoring (target 80%+)
-- Use feature flags for all incremental rollouts
-- Implement monitoring and rollback procedures
-- Document all migration decisions and rationale
-- Preserve existing business logic and behavior
-- Communicate progress and risks transparently
+Provide a migration plan with phases, risk assessment, rollback strategy, and verification checkpoints.
 
-### MUST NOT DO
-- Big bang rewrites or replacements
-- Skip testing legacy behavior before changes
-- Deploy without rollback capability
-- Break existing integrations or APIs
-- Ignore technical debt in new code
-- Rush migrations without proper validation
-- Remove legacy code before new code is proven
+## References
 
-## Output Templates
+No additional reference files.
 
-When implementing modernization, provide:
-1. Assessment summary (risks, dependencies, approach)
-2. Migration plan (phases, rollback strategy, metrics)
-3. Implementation code (facades, adapters, new services)
-4. Test coverage (characterization, integration, e2e)
-5. Monitoring setup (metrics, alerts, dashboards)
+## Scripts
 
-## Knowledge Reference
+No helper scripts are required for this skill right now.
 
-Strangler fig pattern, branch by abstraction, characterization testing, incremental migration, feature flags, canary deployments, API versioning, database refactoring, microservices extraction, technical debt reduction, zero-downtime deployment
+## Examples
+
+- "Plan a strangler fig migration for this monolithic API"
+- "Design characterization tests for this legacy payment module"
+- "Create a phased migration plan with feature flags and rollback"

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

@@ -0,0 +1,65 @@
+````markdown
+---
+inclusion: manual
+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"
+````