@cubis/foundry 0.3.70 → 0.3.72

package/workflows/powers/react-expert/POWER.md

@@ -1,59 +1,69 @@
 ````markdown
 ---
 inclusion: manual
-name: "react-expert"
-description: "Use for framework-agnostic React architecture with React 19 patterns, state design, and performance tuning."
+name: react-expert
+description: "Use for framework-agnostic React architecture with React 19 patterns, state design, component boundaries, and rendering-performance decisions."
 license: MIT
 metadata:
-  version: "2.0.0"
-  domain: "frontend"
-  role: "specialist"
-  stack: "react"
-  baseline: "React 19"
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # React Expert
 
-## Scope
+## Purpose
 
-- Use this for React component and state architecture.
-- Use `nextjs-developer` for Next.js routing/App Router specifics.
+Use for framework-agnostic React architecture with React 19 patterns, state design, component boundaries, and rendering-performance decisions.
 
-## When to use
+## When to Use
 
-- Building reusable component systems.
-- Designing local/shared/remote state boundaries.
-- Refactoring for rendering performance.
-- Implementing robust form and async UI flows.
+- Designing reusable component and state boundaries.
+- Refactoring React code for predictable rendering and side-effect control.
+- Choosing local, shared, server, or async UI state placement.
+- Reviewing hooks, forms, transitions, and accessibility-sensitive UI flows.
 
-## Core workflow
+## Instructions
 
-1. Model component responsibilities and ownership boundaries.
-2. Decide state location and mutation strategy.
-3. Implement with accessible markup and predictable effects.
-4. Measure rerender behavior before applying memoization.
-5. Validate with component and interaction tests.
+1. Define component ownership and server/client boundaries first.
+2. Place state at the lowest level that preserves correctness.
+3. Keep effects explicit, idempotent, and cleanup-safe.
+4. Profile rerender behavior before reaching for memoization.
+5. Validate accessible interaction states and error/loading behavior.
 
-## Baseline standards
+### Baseline standards
 
-- Prefer pure render logic and explicit side-effect boundaries.
-- Use transitions/suspense intentionally for UX.
-- Keep effects idempotent and cleanup-safe.
+- Prefer pure render logic and explicit mutation boundaries.
 - Derive state instead of duplicating it.
-- Keep mutation logic centralized when state grows.
+- Use transitions and suspense intentionally for UX, not fashion.
+- Keep form and async flows predictable.
+- Pair implementation with focused component or interaction tests.
 
-## Avoid
+### Constraints
 
-- Blanket memoization without profiling evidence.
-- Effect-driven derived state loops.
-- Hidden shared mutable module state.
+- Avoid blanket memoization with no evidence.
+- Avoid effect-driven derived-state loops.
+- Avoid hidden shared mutable module state.
+- Avoid client-only patterns when server rendering would simplify the surface.
 
-## Reference files
+## Output Format
 
-- `references/react-19-features.md`
-- `references/hooks-patterns.md`
-- `references/state-management.md`
-- `references/performance.md`
-- `references/testing-react.md`
-- `references/server-components.md`
+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/rendering-state-checklist.md` | The task needs a deeper playbook for state placement, effect discipline, rendering cost, and interaction-level verification. |
+
+## 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 react expert best practices in this project"
+- "Review my react expert implementation for issues"
 ````

package/workflows/powers/react-expert/SKILL.md

@@ -1,56 +1,66 @@
 ---
-name: "react-expert"
-description: "Use for framework-agnostic React architecture with React 19 patterns, state design, and performance tuning."
+name: react-expert
+description: "Use for framework-agnostic React architecture with React 19 patterns, state design, component boundaries, and rendering-performance decisions."
 license: MIT
 metadata:
-  version: "2.0.0"
-  domain: "frontend"
-  role: "specialist"
-  stack: "react"
-  baseline: "React 19"
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # React Expert
 
-## Scope
+## Purpose
 
-- Use this for React component and state architecture.
-- Use `nextjs-developer` for Next.js routing/App Router specifics.
+Use for framework-agnostic React architecture with React 19 patterns, state design, component boundaries, and rendering-performance decisions.
 
-## When to use
+## When to Use
 
-- Building reusable component systems.
-- Designing local/shared/remote state boundaries.
-- Refactoring for rendering performance.
-- Implementing robust form and async UI flows.
+- Designing reusable component and state boundaries.
+- Refactoring React code for predictable rendering and side-effect control.
+- Choosing local, shared, server, or async UI state placement.
+- Reviewing hooks, forms, transitions, and accessibility-sensitive UI flows.
 
-## Core workflow
+## Instructions
 
-1. Model component responsibilities and ownership boundaries.
-2. Decide state location and mutation strategy.
-3. Implement with accessible markup and predictable effects.
-4. Measure rerender behavior before applying memoization.
-5. Validate with component and interaction tests.
+1. Define component ownership and server/client boundaries first.
+2. Place state at the lowest level that preserves correctness.
+3. Keep effects explicit, idempotent, and cleanup-safe.
+4. Profile rerender behavior before reaching for memoization.
+5. Validate accessible interaction states and error/loading behavior.
 
-## Baseline standards
+### Baseline standards
 
-- Prefer pure render logic and explicit side-effect boundaries.
-- Use transitions/suspense intentionally for UX.
-- Keep effects idempotent and cleanup-safe.
+- Prefer pure render logic and explicit mutation boundaries.
 - Derive state instead of duplicating it.
-- Keep mutation logic centralized when state grows.
+- Use transitions and suspense intentionally for UX, not fashion.
+- Keep form and async flows predictable.
+- Pair implementation with focused component or interaction tests.
 
-## Avoid
+### Constraints
 
-- Blanket memoization without profiling evidence.
-- Effect-driven derived state loops.
-- Hidden shared mutable module state.
+- Avoid blanket memoization with no evidence.
+- Avoid effect-driven derived-state loops.
+- Avoid hidden shared mutable module state.
+- Avoid client-only patterns when server rendering would simplify the surface.
 
-## Reference files
+## Output Format
 
-- `references/react-19-features.md`
-- `references/hooks-patterns.md`
-- `references/state-management.md`
-- `references/performance.md`
-- `references/testing-react.md`
-- `references/server-components.md`
+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/rendering-state-checklist.md` | The task needs a deeper playbook for state placement, effect discipline, rendering cost, and interaction-level verification. |
+
+## 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 react expert best practices in this project"
+- "Review my react expert implementation for issues"

package/workflows/powers/redis/POWER.md

@@ -0,0 +1,67 @@
+````markdown
+---
+inclusion: manual
+name: redis
+description: "Use when the task is specifically Redis: cache design, key strategy, TTLs, queues, rate limiting, pub/sub, memory tradeoffs, and safe persistence or eviction decisions."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Redis
+
+## Purpose
+
+Use when the task is specifically Redis: cache design, key strategy, TTLs, queues, rate limiting, pub/sub, memory tradeoffs, and safe persistence or eviction decisions.
+
+## When to Use
+
+- The task is specifically about Redis for cache, coordination, queue, rate-limit, or ephemeral data behavior.
+- You need Redis-aware key design, TTL, eviction, persistence, or memory guidance.
+- The workload depends on Redis data structures or latency-sensitive read paths.
+
+## Instructions
+
+1. Confirm whether Redis is cache, queue, coordination layer, or primary transient store.
+2. Define key shape, TTL, invalidation, and cardinality expectations explicitly.
+3. Choose the smallest data structure and persistence posture that fits the workload.
+4. Check memory pressure, eviction, hot-key risk, and failure behavior.
+5. Validate correctness under cache misses, stale data, and failover.
+
+### Baseline standards
+
+- Treat invalidation and staleness as design work, not cleanup.
+- Prefer simple keys and clear TTL policy.
+- Make persistence and recovery expectations explicit.
+- Use Redis to reduce latency or coordination cost, not to hide data-model ambiguity.
+
+### Constraints
+
+- Avoid permanent business truth in cache without justification.
+- Avoid unbounded key growth or missing TTL strategy.
+- Avoid complex Lua or multi-step logic where simpler patterns would suffice.
+- Avoid ignoring eviction behavior in production planning.
+
+## 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/redis-checklist.md` | You need a deeper Redis playbook for keys, TTL, invalidation, eviction, queues, and persistence tradeoffs. |
+
+## 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 redis best practices in this project"
+- "Review my redis implementation for issues"
+````

package/workflows/powers/redis/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: redis
+description: "Use when the task is specifically Redis: cache design, key strategy, TTLs, queues, rate limiting, pub/sub, memory tradeoffs, and safe persistence or eviction decisions."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Redis
+
+## Purpose
+
+Use when the task is specifically Redis: cache design, key strategy, TTLs, queues, rate limiting, pub/sub, memory tradeoffs, and safe persistence or eviction decisions.
+
+## When to Use
+
+- The task is specifically about Redis for cache, coordination, queue, rate-limit, or ephemeral data behavior.
+- You need Redis-aware key design, TTL, eviction, persistence, or memory guidance.
+- The workload depends on Redis data structures or latency-sensitive read paths.
+
+## Instructions
+
+1. Confirm whether Redis is cache, queue, coordination layer, or primary transient store.
+2. Define key shape, TTL, invalidation, and cardinality expectations explicitly.
+3. Choose the smallest data structure and persistence posture that fits the workload.
+4. Check memory pressure, eviction, hot-key risk, and failure behavior.
+5. Validate correctness under cache misses, stale data, and failover.
+
+### Baseline standards
+
+- Treat invalidation and staleness as design work, not cleanup.
+- Prefer simple keys and clear TTL policy.
+- Make persistence and recovery expectations explicit.
+- Use Redis to reduce latency or coordination cost, not to hide data-model ambiguity.
+
+### Constraints
+
+- Avoid permanent business truth in cache without justification.
+- Avoid unbounded key growth or missing TTL strategy.
+- Avoid complex Lua or multi-step logic where simpler patterns would suffice.
+- Avoid ignoring eviction behavior in production planning.
+
+## 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/redis-checklist.md` | You need a deeper Redis playbook for keys, TTL, invalidation, eviction, queues, and persistence tradeoffs. |
+
+## 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 redis best practices in this project"
+- "Review my redis implementation for issues"

package/workflows/powers/redis/references/redis-checklist.md

@@ -0,0 +1,19 @@
+# Redis Checklist
+
+Load this when Redis-specific tradeoffs matter.
+
+## Data purpose
+
+- Confirm whether Redis is cache, queue, coordination layer, or transient store.
+- Keep the system of record explicit.
+
+## Keys and TTL
+
+- Design keys, namespaces, and cardinality deliberately.
+- Make TTL and invalidation policy explicit.
+- Check hot keys and unbounded growth risk.
+
+## Operations
+
+- Choose persistence and eviction posture intentionally.
+- Re-check failure behavior, stale data handling, and cache miss correctness.

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

@@ -0,0 +1,118 @@
+````markdown
+---
+inclusion: manual
+name: ruby-pro
+description: "Use for modern Ruby 3.4-era backend, scripting, and application engineering with clear object boundaries, concurrency awareness, and test discipline."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "2.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Ruby Pro
+
+## Purpose
+
+Use for modern Ruby 3.4-era backend, scripting, and application engineering with clear object boundaries, concurrency awareness, and test discipline.
+
+## When to Use
+
+- Building or refactoring Ruby services, scripts, or app-layer code.
+- Clarifying object boundaries, service layers, and package structure.
+- Improving background jobs, test coverage, and runtime safety.
+
+## Instructions
+
+1. Confirm runtime and app structure before editing.
+2. Keep object responsibilities small and explicit.
+3. Prefer clear data flow over callback-heavy indirection.
+4. Make concurrency, I/O, and retries explicit when present.
+5. Validate with focused tests and dependency-aware Bundler hygiene.
+
+### Baseline standards
+
+- Use Ruby 3.4+ features: pattern matching (`in`/`=>` patterns), Data classes, and frozen string literals.
+- Add `# frozen_string_literal: true` to every file. Mutable strings must be explicit (`String.new` or `.dup`).
+- Run RuboCop in CI with project-specific `.rubocop.yml`. Treat offenses as build failures.
+- Use Sorbet or RBS type signatures at module boundaries for large codebases.
+- Pin gems to exact versions in `Gemfile.lock`. Run `bundle audit` in CI for vulnerability checks.
+
+### Object design
+
+- Keep classes focused on a single responsibility. Extract service objects, value objects, and query objects.
+- Prefer composition over inheritance. Use modules for shared behavior, not deep class hierarchies.
+- Use `Data.define` (Ruby 3.2+) for immutable value objects instead of `Struct` or `OpenStruct`.
+- Use pattern matching with `case`/`in` for structured data decomposition.
+- Make method visibility explicit (`public`, `private`, `protected`). Default to private.
+
+### Concurrency
+
+- Use Ractors for CPU-bound parallelism that needs true thread safety.
+- Use Fibers and `Async` gem for I/O-bound concurrency within a single thread.
+- Use thread-safe data structures (`Queue`, `Mutex`, `Monitor`) when sharing state across threads.
+- Background jobs (Sidekiq, GoodJob) are the preferred pattern for async work in web apps.
+- Never share mutable state between Ractors — pass messages or use shareable frozen objects.
+
+### Error handling
+
+- Rescue specific exceptions, not bare `rescue` or `rescue Exception`.
+- Use custom exception classes per failure domain. Include context in the error message.
+- Prefer returning result objects (Success/Failure) for expected failures over exception-based control flow.
+- Always re-raise or log rescued exceptions — never swallow errors silently.
+
+### Testing
+
+- Use RSpec or Minitest. Keep test files mirroring the source structure.
+- Use `let`, `subject`, and `context` blocks for readable test organization in RSpec.
+- Mock external dependencies (HTTP, databases, file I/O) — test business logic in isolation.
+- Use FactoryBot or fixtures for test data. Never depend on production database state.
+- Run tests with SimpleCov for coverage reporting. Focus on meaningful coverage over percentage targets.
+
+### Performance
+
+- Profile with `ruby-prof`, `stackprof`, or `memory_profiler` before optimizing.
+- Use `Enumerable` methods (`map`, `select`, `reduce`) over manual loops. They express intent clearly.
+- Prefer `freeze` on constants and frequently reused strings to reduce object allocations.
+- Use connection pooling for database connections. Never create connections per-request.
+- Cache expensive computations with `Rails.cache`, `Dalli`, or application-level memoization.
+
+### Bundler hygiene
+
+- Group gems by purpose in `Gemfile`: `:development`, `:test`, `:production`.
+- Run `bundle outdated` regularly. Update gems in small batches with test verification.
+- Audit gems with `bundle audit` before deploy. Block deploys on critical vulnerabilities.
+- Prefer gems with active maintainers and recent releases. Avoid abandoned gems.
+
+### Constraints
+
+- Avoid `method_missing` without `respond_to_missing?` — makes debugging impossible.
+- Avoid `eval` and `instance_eval` with user input — injection risk.
+- Avoid `OpenStruct` in production code — slow, no type safety, memory-heavy.
+- Avoid monkey-patching core classes — use Refinements instead when behavior extension is needed.
+- Avoid bare `rescue` without exception class — catches everything including `SystemExit`.
+- Avoid deep callback chains (Rails `before_action`, `after_commit`) — make control flow invisible.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                         | Load when                                                                                                        |
+| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| `references/ruby-concurrency-and-testing.md` | Concurrency patterns (Ractors, Fibers, Async), testing strategy, or gem dependency audit is needed.              |
+| `references/modern-ruby-features.md`         | You need pattern matching, Data.define, numbered block parameters, endless ranges, or deconstruct patterns.      |
+| `references/object-design-patterns.md`       | You need service objects, value objects, query objects, result monads, or composition-over-inheritance patterns. |
+| `references/testing-and-rspec.md`            | You need RSpec patterns, shared examples, request specs, FactoryBot strategies, or SimpleCov CI setup.           |
+| `references/performance-and-profiling.md`    | You need profiling with stackprof/ruby-prof, memory analysis, GC tuning, Yjit, or caching strategies.            |
+
+## 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 ruby pro best practices in this project"
+- "Review my ruby pro implementation for issues"
+````

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

@@ -0,0 +1,115 @@
+---
+name: ruby-pro
+description: "Use for modern Ruby 3.4-era backend, scripting, and application engineering with clear object boundaries, concurrency awareness, and test discipline."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "2.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Ruby Pro
+
+## Purpose
+
+Use for modern Ruby 3.4-era backend, scripting, and application engineering with clear object boundaries, concurrency awareness, and test discipline.
+
+## When to Use
+
+- Building or refactoring Ruby services, scripts, or app-layer code.
+- Clarifying object boundaries, service layers, and package structure.
+- Improving background jobs, test coverage, and runtime safety.
+
+## Instructions
+
+1. Confirm runtime and app structure before editing.
+2. Keep object responsibilities small and explicit.
+3. Prefer clear data flow over callback-heavy indirection.
+4. Make concurrency, I/O, and retries explicit when present.
+5. Validate with focused tests and dependency-aware Bundler hygiene.
+
+### Baseline standards
+
+- Use Ruby 3.4+ features: pattern matching (`in`/`=>` patterns), Data classes, and frozen string literals.
+- Add `# frozen_string_literal: true` to every file. Mutable strings must be explicit (`String.new` or `.dup`).
+- Run RuboCop in CI with project-specific `.rubocop.yml`. Treat offenses as build failures.
+- Use Sorbet or RBS type signatures at module boundaries for large codebases.
+- Pin gems to exact versions in `Gemfile.lock`. Run `bundle audit` in CI for vulnerability checks.
+
+### Object design
+
+- Keep classes focused on a single responsibility. Extract service objects, value objects, and query objects.
+- Prefer composition over inheritance. Use modules for shared behavior, not deep class hierarchies.
+- Use `Data.define` (Ruby 3.2+) for immutable value objects instead of `Struct` or `OpenStruct`.
+- Use pattern matching with `case`/`in` for structured data decomposition.
+- Make method visibility explicit (`public`, `private`, `protected`). Default to private.
+
+### Concurrency
+
+- Use Ractors for CPU-bound parallelism that needs true thread safety.
+- Use Fibers and `Async` gem for I/O-bound concurrency within a single thread.
+- Use thread-safe data structures (`Queue`, `Mutex`, `Monitor`) when sharing state across threads.
+- Background jobs (Sidekiq, GoodJob) are the preferred pattern for async work in web apps.
+- Never share mutable state between Ractors — pass messages or use shareable frozen objects.
+
+### Error handling
+
+- Rescue specific exceptions, not bare `rescue` or `rescue Exception`.
+- Use custom exception classes per failure domain. Include context in the error message.
+- Prefer returning result objects (Success/Failure) for expected failures over exception-based control flow.
+- Always re-raise or log rescued exceptions — never swallow errors silently.
+
+### Testing
+
+- Use RSpec or Minitest. Keep test files mirroring the source structure.
+- Use `let`, `subject`, and `context` blocks for readable test organization in RSpec.
+- Mock external dependencies (HTTP, databases, file I/O) — test business logic in isolation.
+- Use FactoryBot or fixtures for test data. Never depend on production database state.
+- Run tests with SimpleCov for coverage reporting. Focus on meaningful coverage over percentage targets.
+
+### Performance
+
+- Profile with `ruby-prof`, `stackprof`, or `memory_profiler` before optimizing.
+- Use `Enumerable` methods (`map`, `select`, `reduce`) over manual loops. They express intent clearly.
+- Prefer `freeze` on constants and frequently reused strings to reduce object allocations.
+- Use connection pooling for database connections. Never create connections per-request.
+- Cache expensive computations with `Rails.cache`, `Dalli`, or application-level memoization.
+
+### Bundler hygiene
+
+- Group gems by purpose in `Gemfile`: `:development`, `:test`, `:production`.
+- Run `bundle outdated` regularly. Update gems in small batches with test verification.
+- Audit gems with `bundle audit` before deploy. Block deploys on critical vulnerabilities.
+- Prefer gems with active maintainers and recent releases. Avoid abandoned gems.
+
+### Constraints
+
+- Avoid `method_missing` without `respond_to_missing?` — makes debugging impossible.
+- Avoid `eval` and `instance_eval` with user input — injection risk.
+- Avoid `OpenStruct` in production code — slow, no type safety, memory-heavy.
+- Avoid monkey-patching core classes — use Refinements instead when behavior extension is needed.
+- Avoid bare `rescue` without exception class — catches everything including `SystemExit`.
+- Avoid deep callback chains (Rails `before_action`, `after_commit`) — make control flow invisible.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                         | Load when                                                                                                        |
+| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| `references/ruby-concurrency-and-testing.md` | Concurrency patterns (Ractors, Fibers, Async), testing strategy, or gem dependency audit is needed.              |
+| `references/modern-ruby-features.md`         | You need pattern matching, Data.define, numbered block parameters, endless ranges, or deconstruct patterns.      |
+| `references/object-design-patterns.md`       | You need service objects, value objects, query objects, result monads, or composition-over-inheritance patterns. |
+| `references/testing-and-rspec.md`            | You need RSpec patterns, shared examples, request specs, FactoryBot strategies, or SimpleCov CI setup.           |
+| `references/performance-and-profiling.md`    | You need profiling with stackprof/ruby-prof, memory analysis, GC tuning, Yjit, or caching strategies.            |
+
+## 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 ruby pro best practices in this project"
+- "Review my ruby pro implementation for issues"