@cubis/foundry 0.3.70 → 0.3.72

package/workflows/powers/mysql/POWER.md

@@ -0,0 +1,67 @@
+````markdown
+---
+inclusion: manual
+name: mysql
+description: "Use when the task is specifically MySQL or InnoDB: schema/index design, transaction behavior, replication-aware migrations, query tuning, and managed MySQL operational tradeoffs."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# MySQL
+
+## Purpose
+
+Use when the task is specifically MySQL or InnoDB: schema/index design, transaction behavior, replication-aware migrations, query tuning, and managed MySQL operational tradeoffs.
+
+## When to Use
+
+- The engine is MySQL, MariaDB-compatible MySQL, or a managed MySQL platform.
+- The task depends on InnoDB behavior, replication, Online DDL, or MySQL-specific indexing/query behavior.
+- You need MySQL-aware migration, lock, or read/write topology guidance.
+
+## Instructions
+
+1. Confirm MySQL variant, version, topology, and operational constraints.
+2. Identify the dominant query and write patterns before changing schema or indexes.
+3. Design for InnoDB realities: clustering, covering indexes, transaction scope, and lock impact.
+4. Plan migrations around Online DDL behavior, replicas, and rollback constraints.
+5. Re-check with query-plan evidence and operational safety notes.
+
+### Baseline standards
+
+- Optimize for actual read/write mix, not synthetic benchmarks.
+- Keep transaction boundaries tight and predictable.
+- Treat index shape and row access order as first-class design concerns.
+- Make replication lag, schema rollout, and failover constraints explicit.
+
+### Constraints
+
+- Avoid wide indexes with no evidence.
+- Avoid large DDL changes without topology-aware rollout.
+- Avoid assuming MySQL and Postgres tuning rules are interchangeable.
+- Avoid hiding consistency tradeoffs behind ORM defaults.
+
+## 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/mysql-checklist.md` | You need a deeper MySQL playbook for InnoDB behavior, Online DDL, replication-aware rollout, and index 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 mysql best practices in this project"
+- "Review my mysql implementation for issues"
+````

package/workflows/powers/mysql/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: mysql
+description: "Use when the task is specifically MySQL or InnoDB: schema/index design, transaction behavior, replication-aware migrations, query tuning, and managed MySQL operational tradeoffs."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# MySQL
+
+## Purpose
+
+Use when the task is specifically MySQL or InnoDB: schema/index design, transaction behavior, replication-aware migrations, query tuning, and managed MySQL operational tradeoffs.
+
+## When to Use
+
+- The engine is MySQL, MariaDB-compatible MySQL, or a managed MySQL platform.
+- The task depends on InnoDB behavior, replication, Online DDL, or MySQL-specific indexing/query behavior.
+- You need MySQL-aware migration, lock, or read/write topology guidance.
+
+## Instructions
+
+1. Confirm MySQL variant, version, topology, and operational constraints.
+2. Identify the dominant query and write patterns before changing schema or indexes.
+3. Design for InnoDB realities: clustering, covering indexes, transaction scope, and lock impact.
+4. Plan migrations around Online DDL behavior, replicas, and rollback constraints.
+5. Re-check with query-plan evidence and operational safety notes.
+
+### Baseline standards
+
+- Optimize for actual read/write mix, not synthetic benchmarks.
+- Keep transaction boundaries tight and predictable.
+- Treat index shape and row access order as first-class design concerns.
+- Make replication lag, schema rollout, and failover constraints explicit.
+
+### Constraints
+
+- Avoid wide indexes with no evidence.
+- Avoid large DDL changes without topology-aware rollout.
+- Avoid assuming MySQL and Postgres tuning rules are interchangeable.
+- Avoid hiding consistency tradeoffs behind ORM defaults.
+
+## 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/mysql-checklist.md` | You need a deeper MySQL playbook for InnoDB behavior, Online DDL, replication-aware rollout, and index 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 mysql best practices in this project"
+- "Review my mysql implementation for issues"

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

@@ -0,0 +1,20 @@
+# MySQL Checklist
+
+Load this when MySQL behavior materially affects the answer.
+
+## InnoDB and indexes
+
+- Model for clustered primary-key access and covering-index opportunities.
+- Keep transaction scope tight and predictable.
+- Validate index tradeoffs against actual read/write mix.
+
+## Rollout
+
+- Check Online DDL behavior, replicas, and rollback constraints.
+- Make replication lag and topology effects explicit.
+- Stage heavy schema changes when operational risk is non-trivial.
+
+## Evidence
+
+- Use query-plan evidence before recommending index or query changes.
+- Do not borrow Postgres assumptions blindly.

package/workflows/powers/neki/POWER.md

@@ -0,0 +1,67 @@
+````markdown
+---
+inclusion: manual
+name: neki
+description: "Use when the task is specifically Neki, PlanetScale’s sharded Postgres architecture: shard-key design, distributed Postgres tradeoffs, routing constraints, and operational decisions for large-scale Postgres workloads."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Neki
+
+## Purpose
+
+Use when the task is specifically Neki, PlanetScale’s sharded Postgres architecture: shard-key design, distributed Postgres tradeoffs, routing constraints, and operational decisions for large-scale Postgres workloads.
+
+## When to Use
+
+- The task is specifically about Neki or PlanetScale’s sharded Postgres posture.
+- The problem depends on shard keys, distributed Postgres behavior, routing constraints, or operational scaling tradeoffs.
+- You need guidance that differs from plain single-cluster Postgres assumptions.
+
+## Instructions
+
+1. Confirm what is known about the Neki deployment and which product constraints are actually available today.
+2. Separate normal Postgres reasoning from sharding-specific concerns such as routing, fan-out, and ownership.
+3. Make shard-key and entity-boundary choices explicit before proposing query or schema changes.
+4. Prefer conservative operational guidance when platform details are still evolving.
+5. Report assumptions, unknowns, and fallback plans clearly.
+
+### Baseline standards
+
+- Treat Neki as sharded Postgres, not just “Postgres but bigger.”
+- Keep assumptions explicit because the platform is still evolving.
+- Design around ownership, routing, and predictable access paths.
+- Fall back to standard Postgres guidance whenever a Neki-specific claim is not well supported.
+
+### Constraints
+
+- Avoid assuming all Postgres features behave identically in a sharded environment.
+- Avoid recommending cross-shard patterns without evidence.
+- Avoid hiding uncertainty when product details are incomplete.
+- Avoid using Neki-specific advice when plain Postgres guidance would be safer.
+
+## 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/neki-checklist.md` | You need a sharper Neki-specific checklist for sharded Postgres assumptions, routing, uncertainty handling, and fallback to plain Postgres guidance. |
+
+## 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 neki best practices in this project"
+- "Review my neki implementation for issues"
+````

package/workflows/powers/neki/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: neki
+description: "Use when the task is specifically Neki, PlanetScale’s sharded Postgres architecture: shard-key design, distributed Postgres tradeoffs, routing constraints, and operational decisions for large-scale Postgres workloads."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Neki
+
+## Purpose
+
+Use when the task is specifically Neki, PlanetScale’s sharded Postgres architecture: shard-key design, distributed Postgres tradeoffs, routing constraints, and operational decisions for large-scale Postgres workloads.
+
+## When to Use
+
+- The task is specifically about Neki or PlanetScale’s sharded Postgres posture.
+- The problem depends on shard keys, distributed Postgres behavior, routing constraints, or operational scaling tradeoffs.
+- You need guidance that differs from plain single-cluster Postgres assumptions.
+
+## Instructions
+
+1. Confirm what is known about the Neki deployment and which product constraints are actually available today.
+2. Separate normal Postgres reasoning from sharding-specific concerns such as routing, fan-out, and ownership.
+3. Make shard-key and entity-boundary choices explicit before proposing query or schema changes.
+4. Prefer conservative operational guidance when platform details are still evolving.
+5. Report assumptions, unknowns, and fallback plans clearly.
+
+### Baseline standards
+
+- Treat Neki as sharded Postgres, not just “Postgres but bigger.”
+- Keep assumptions explicit because the platform is still evolving.
+- Design around ownership, routing, and predictable access paths.
+- Fall back to standard Postgres guidance whenever a Neki-specific claim is not well supported.
+
+### Constraints
+
+- Avoid assuming all Postgres features behave identically in a sharded environment.
+- Avoid recommending cross-shard patterns without evidence.
+- Avoid hiding uncertainty when product details are incomplete.
+- Avoid using Neki-specific advice when plain Postgres guidance would be safer.
+
+## 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/neki-checklist.md` | You need a sharper Neki-specific checklist for sharded Postgres assumptions, routing, uncertainty handling, and fallback to plain Postgres guidance. |
+
+## 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 neki best practices in this project"
+- "Review my neki implementation for issues"

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

@@ -0,0 +1,18 @@
+# Neki Checklist
+
+Load this when Neki-specific sharded Postgres assumptions are in play.
+
+## Assumption control
+
+- Confirm which Neki behavior is actually known versus inferred.
+- Fall back to plain Postgres guidance when a Neki-specific claim is weak.
+
+## Architecture
+
+- Treat shard keys, routing, and ownership as first-class concerns.
+- Avoid cross-shard assumptions unless supported by the platform behavior in scope.
+
+## Communication
+
+- Report uncertainty explicitly.
+- Keep fallback plans and safer plain-Postgres alternatives visible.

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

@@ -1,117 +1,71 @@
 ````markdown
 ---
 inclusion: manual
-name: "nestjs-expert"
-description: "Use when building NestJS applications requiring modular architecture, dependency injection, or TypeScript backend development. Invoke for modules, controllers, services, DTOs, guards, interceptors, Mongoose."
+name: nestjs-expert
+description: "Use when building NestJS services that need strong module boundaries, dependency injection, DTO validation, guards or interceptors, auth boundaries, transport-aware module design, and production-safe TypeScript backend structure."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
-
 # NestJS Expert
 
-## Overview
-
-Senior NestJS specialist with deep expertise in enterprise-grade, scalable TypeScript backend applications. Focused on session-based authentication with Fastify and MongoDB/Mongoose integration.
-
-## Role Definition
-
-You are a senior Node.js engineer with 10+ years of backend experience. You specialize in NestJS architecture, dependency injection, and enterprise patterns. You build modular, testable applications with proper separation of concerns.
-
-## When to Use This Power
-
-- Building NestJS REST APIs with Fastify
-- Implementing modules, controllers, and services
-- Creating DTOs with validation
-- Setting up session-based authentication (NOT JWT)
-- Implementing guards, interceptors, and pipes
-- Database integration with Mongoose
-
-## Core Workflow
-
-1. **Analyze requirements** - Identify modules, endpoints, entities
-2. **Design structure** - Plan module organization and dependencies
-3. **Implement** - Create modules, services, controllers with DI
-4. **Secure** - Add guards, validation, authentication
-5. **Test** - Write unit tests and E2E tests
-
-## Available Steering Files
-
-Load detailed guidance on-demand:
-
-| Topic             | Reference                            | Load When                                   |
-| ----------------- | ------------------------------------ | ------------------------------------------- |
-| Controllers       | `references/controllers-routing.md`    | Creating controllers, routing, Swagger docs |
-| Services          | `references/services-di.md`            | Services, dependency injection, providers   |
-| DTOs              | `references/dtos-validation.md`        | Validation, class-validator, DTOs           |
-| Authentication    | `references/authentication.md`         | Session auth, guards, roles, multi-tenant   |
-| Testing           | `references/testing-patterns.md`       | Unit tests, E2E tests, mocking              |
-| Express Migration | `references/migration-from-express.md` | Migrating from Express.js to NestJS         |
-
-## Authentication Approach
+## Purpose
 
-**OneUp uses session-based authentication, NOT JWT.**
+Use when building NestJS services that need strong module boundaries, dependency injection, DTO validation, guards or interceptors, auth boundaries, transport-aware module design, and production-safe TypeScript backend structure.
 
-```typescript
-// Session-based auth with Fastify
-@Post('login')
-async login(@Body() dto: LoginDto, @Req() request: FastifyRequest) {
-  const user = await this.authService.validateUser(dto.username, dto.password);
+## When to Use
 
-  // Store user info in session
-  request.session.set('userId', user.userId);
-  request.session.set('organizationId', user.organizationId);
-  request.session.set('role', user.role);
+- Building or refactoring NestJS APIs and service modules.
+- Designing providers, controllers, DTOs, guards, interceptors, pipes, and auth boundaries.
+- Enforcing modular TypeScript backend boundaries in a Nest app or monorepo.
+- Reviewing Nest code for dependency direction, transport separation, validation, and operational safety.
 
-  return { message: 'Login successful' };
-}
+## Instructions
 
-@Post('logout')
-async logout(@Req() request: FastifyRequest) {
-  request.session.delete();
-  return { message: 'Logout successful' };
-}
-```
+1. Define module boundaries, provider ownership, and transport boundaries before adding endpoints.
+2. Keep controllers thin and push logic into services or domain layers.
+3. Validate input with DTOs and explicit boundary rules.
+4. Apply guards, interceptors, filters, and auth wiring intentionally rather than globally by habit.
+5. Verify testability, error behavior, dependency direction, and bootstrap posture before shipping.
 
-See `references/authentication.md` for complete session auth implementation.
+### Baseline standards
 
-## Constraints
+- Use modules to express bounded context, not folder cosmetics.
+- Keep DI graphs simple and acyclic.
+- Treat DTOs as boundary contracts, not domain models.
+- Keep transport concerns, auth policy, and domain logic separate.
+- Use guards/interceptors/pipes only where their responsibility is clear.
+- Keep config and infrastructure concerns explicit and testable.
 
-### MUST DO
+### Constraints
 
-- Use dependency injection for all services
-- Validate all inputs with class-validator
-- Use DTOs for request/response bodies
-- Implement proper error handling with HTTP exceptions
-- Document APIs with Swagger decorators
-- Write unit tests for services
-- Use environment variables for configuration
+- Avoid fat controllers and hidden business logic in decorators.
+- Avoid circular module/provider dependencies.
+- Avoid dTO reuse that leaks transport concerns across layers.
+- Avoid request-scoped providers by default when singleton or explicit factory wiring is enough.
+- Avoid global framework magic when local explicit behavior is safer.
 
-### MUST NOT DO
+## Output Format
 
-- Expose passwords or secrets in responses
-- Trust user input without validation
-- Use `any` type unless absolutely necessary
-- Create circular dependencies between modules
-- Hardcode configuration values
-- Skip error handling
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
 
-## Output Templates
+## References
 
-When implementing NestJS features, provide:
+Load on demand. Do not preload all reference files.
 
-1. Module definition
-2. Controller with Swagger decorators
-3. Service with error handling
-4. DTOs with validation
-5. Tests for service methods
+| File | Load when |
+| --- | --- |
+| `references/module-dto-guard-playbook.md` | You need a more explicit Nest playbook for modules, DTOs, guards, auth, transports, config, and testable dependency graphs. |
 
-## Knowledge Reference
+## Scripts
 
-NestJS, TypeScript, Mongoose, Fastify, @fastify/secure-session, class-validator, class-transformer, Swagger/OpenAPI, Jest, Supertest, Guards, Interceptors, Pipes, Filters
+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
 
-- **Fastify Patterns** - Fastify adapter and session configuration
-- **Mongoose NestJS** - MongoDB integration patterns
-- **Test Master** - Comprehensive testing strategies
-- **Security Reviewer** - Security auditing
+- "Help me with nestjs expert best practices in this project"
+- "Review my nestjs expert implementation for issues"
 ````

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

@@ -1,114 +1,68 @@
 ---
-name: "nestjs-expert"
-description: "Use when building NestJS applications requiring modular architecture, dependency injection, or TypeScript backend development. Invoke for modules, controllers, services, DTOs, guards, interceptors, Mongoose."
+name: nestjs-expert
+description: "Use when building NestJS services that need strong module boundaries, dependency injection, DTO validation, guards or interceptors, auth boundaries, transport-aware module design, and production-safe TypeScript backend structure."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
-
 # NestJS Expert
 
-## Overview
-
-Senior NestJS specialist with deep expertise in enterprise-grade, scalable TypeScript backend applications. Focused on session-based authentication with Fastify and MongoDB/Mongoose integration.
-
-## Role Definition
-
-You are a senior Node.js engineer with 10+ years of backend experience. You specialize in NestJS architecture, dependency injection, and enterprise patterns. You build modular, testable applications with proper separation of concerns.
-
-## When to Use This Power
-
-- Building NestJS REST APIs with Fastify
-- Implementing modules, controllers, and services
-- Creating DTOs with validation
-- Setting up session-based authentication (NOT JWT)
-- Implementing guards, interceptors, and pipes
-- Database integration with Mongoose
-
-## Core Workflow
-
-1. **Analyze requirements** - Identify modules, endpoints, entities
-2. **Design structure** - Plan module organization and dependencies
-3. **Implement** - Create modules, services, controllers with DI
-4. **Secure** - Add guards, validation, authentication
-5. **Test** - Write unit tests and E2E tests
-
-## Available Steering Files
-
-Load detailed guidance on-demand:
-
-| Topic             | Reference                            | Load When                                   |
-| ----------------- | ------------------------------------ | ------------------------------------------- |
-| Controllers       | `references/controllers-routing.md`    | Creating controllers, routing, Swagger docs |
-| Services          | `references/services-di.md`            | Services, dependency injection, providers   |
-| DTOs              | `references/dtos-validation.md`        | Validation, class-validator, DTOs           |
-| Authentication    | `references/authentication.md`         | Session auth, guards, roles, multi-tenant   |
-| Testing           | `references/testing-patterns.md`       | Unit tests, E2E tests, mocking              |
-| Express Migration | `references/migration-from-express.md` | Migrating from Express.js to NestJS         |
-
-## Authentication Approach
+## Purpose
 
-**OneUp uses session-based authentication, NOT JWT.**
+Use when building NestJS services that need strong module boundaries, dependency injection, DTO validation, guards or interceptors, auth boundaries, transport-aware module design, and production-safe TypeScript backend structure.
 
-```typescript
-// Session-based auth with Fastify
-@Post('login')
-async login(@Body() dto: LoginDto, @Req() request: FastifyRequest) {
-  const user = await this.authService.validateUser(dto.username, dto.password);
+## When to Use
 
-  // Store user info in session
-  request.session.set('userId', user.userId);
-  request.session.set('organizationId', user.organizationId);
-  request.session.set('role', user.role);
+- Building or refactoring NestJS APIs and service modules.
+- Designing providers, controllers, DTOs, guards, interceptors, pipes, and auth boundaries.
+- Enforcing modular TypeScript backend boundaries in a Nest app or monorepo.
+- Reviewing Nest code for dependency direction, transport separation, validation, and operational safety.
 
-  return { message: 'Login successful' };
-}
+## Instructions
 
-@Post('logout')
-async logout(@Req() request: FastifyRequest) {
-  request.session.delete();
-  return { message: 'Logout successful' };
-}
-```
+1. Define module boundaries, provider ownership, and transport boundaries before adding endpoints.
+2. Keep controllers thin and push logic into services or domain layers.
+3. Validate input with DTOs and explicit boundary rules.
+4. Apply guards, interceptors, filters, and auth wiring intentionally rather than globally by habit.
+5. Verify testability, error behavior, dependency direction, and bootstrap posture before shipping.
 
-See `references/authentication.md` for complete session auth implementation.
+### Baseline standards
 
-## Constraints
+- Use modules to express bounded context, not folder cosmetics.
+- Keep DI graphs simple and acyclic.
+- Treat DTOs as boundary contracts, not domain models.
+- Keep transport concerns, auth policy, and domain logic separate.
+- Use guards/interceptors/pipes only where their responsibility is clear.
+- Keep config and infrastructure concerns explicit and testable.
 
-### MUST DO
+### Constraints
 
-- Use dependency injection for all services
-- Validate all inputs with class-validator
-- Use DTOs for request/response bodies
-- Implement proper error handling with HTTP exceptions
-- Document APIs with Swagger decorators
-- Write unit tests for services
-- Use environment variables for configuration
+- Avoid fat controllers and hidden business logic in decorators.
+- Avoid circular module/provider dependencies.
+- Avoid dTO reuse that leaks transport concerns across layers.
+- Avoid request-scoped providers by default when singleton or explicit factory wiring is enough.
+- Avoid global framework magic when local explicit behavior is safer.
 
-### MUST NOT DO
+## Output Format
 
-- Expose passwords or secrets in responses
-- Trust user input without validation
-- Use `any` type unless absolutely necessary
-- Create circular dependencies between modules
-- Hardcode configuration values
-- Skip error handling
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
 
-## Output Templates
+## References
 
-When implementing NestJS features, provide:
+Load on demand. Do not preload all reference files.
 
-1. Module definition
-2. Controller with Swagger decorators
-3. Service with error handling
-4. DTOs with validation
-5. Tests for service methods
+| File | Load when |
+| --- | --- |
+| `references/module-dto-guard-playbook.md` | You need a more explicit Nest playbook for modules, DTOs, guards, auth, transports, config, and testable dependency graphs. |
 
-## Knowledge Reference
+## Scripts
 
-NestJS, TypeScript, Mongoose, Fastify, @fastify/secure-session, class-validator, class-transformer, Swagger/OpenAPI, Jest, Supertest, Guards, Interceptors, Pipes, Filters
+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
 
-- **Fastify Patterns** - Fastify adapter and session configuration
-- **Mongoose NestJS** - MongoDB integration patterns
-- **Test Master** - Comprehensive testing strategies
-- **Security Reviewer** - Security auditing
+- "Help me with nestjs expert best practices in this project"
+- "Review my nestjs expert implementation for issues"