@cubis/foundry 0.3.67 → 0.3.69

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/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/workflows/agent-environment-setup/platforms/copilot/skills/neki/SKILL.md

@@ -0,0 +1,63 @@
+---
+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/workflows/agent-environment-setup/platforms/copilot/skills/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/workflows/agent-environment-setup/platforms/copilot/skills/nestjs-expert/SKILL.md

@@ -1,105 +1,67 @@
 ---
-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
+## Purpose
 
-Senior NestJS specialist with deep expertise in enterprise-grade, scalable TypeScript backend applications. Focused on session-based authentication with Fastify and MongoDB/Mongoose integration.
+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.
 
-## Role Definition
+## When to Use
 
-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.
+- 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.
 
-## When to Use This Skill
+## Instructions
 
-- 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
+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.
 
-## Core Workflow
+### Baseline standards
 
-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
+- 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.
 
-## Available Steering Files
+### Constraints
 
-Load detailed guidance on-demand:
+- 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.
 
-| 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         |
+## Output Format
 
-## Authentication Approach
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
 
-**OneUp uses session-based authentication, NOT JWT.**
+## References
 
-```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);
+Load on demand. Do not preload all reference files.
 
-  // Store user info in session
-  request.session.set('userId', user.userId);
-  request.session.set('organizationId', user.organizationId);
-  request.session.set('role', user.role);
+| 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. |
 
-  return { message: 'Login successful' };
-}
+## Scripts
 
-@Post('logout')
-async logout(@Req() request: FastifyRequest) {
-  request.session.delete();
-  return { message: 'Logout successful' };
-}
-```
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-See `references/authentication.md` for complete session auth implementation.
+## Examples
 
-## Constraints
-
-### MUST DO
-
-- 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
-
-### MUST NOT DO
-
-- 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
-
-## Output Templates
-
-When implementing NestJS features, provide:
-
-1. Module definition
-2. Controller with Swagger decorators
-3. Service with error handling
-4. DTOs with validation
-5. Tests for service methods
-
-## Knowledge Reference
-
-NestJS, TypeScript, Mongoose, Fastify, @fastify/secure-session, class-validator, class-transformer, Swagger/OpenAPI, Jest, Supertest, Guards, Interceptors, Pipes, Filters
+- "Help me with nestjs expert best practices in this project"
+- "Review my nestjs expert implementation for issues"

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/nestjs-expert/references/module-dto-guard-playbook.md

@@ -0,0 +1,34 @@
+# Module, DTO, And Guard Playbook
+
+Load this when NestJS design needs more detail than the root skill.
+
+## Modules and providers
+
+- Use modules to express bounded context and ownership.
+- Keep provider graphs acyclic and easy to trace.
+- Avoid hiding core business rules in framework decorators.
+
+## DTO and validation boundaries
+
+- Treat DTOs as transport contracts, not domain models.
+- Keep validation explicit at the boundary.
+- Avoid reusing DTOs across unrelated routes when that leaks coupling.
+
+## Guards, interceptors, filters, pipes
+
+- Apply each abstraction only where its responsibility is clear.
+- Prefer explicit local behavior over global framework magic when blast radius is high.
+- Keep auth, logging, and error shaping testable and visible.
+
+## Auth and transports
+
+- Keep auth strategy, guard composition, and policy checks explicit at the module boundary.
+- Do not hide business authorization rules inside decorators without service-level ownership.
+- Keep HTTP, GraphQL, queue, and event transport concerns from bleeding into each other.
+- Treat monorepo shared modules as contracts, not a dumping ground for cross-cutting shortcuts.
+
+## Maintainability
+
+- Keep controllers thin.
+- Push domain logic into services or domain modules.
+- Re-check config, bootstrap, and infrastructure coupling before shipping.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/nextjs-developer/SKILL.md

@@ -1,57 +1,65 @@
 ---
-name: "nextjs-developer"
-description: "Use for implementing/refactoring Next.js App Router features, React Server Components/Actions, SEO, and production architecture."
+name: nextjs-developer
+description: "Use for implementing and reviewing Next.js App Router features, React Server Components and Actions, caching strategy, SEO, and production runtime behavior."
 license: MIT
 metadata:
-  version: "2.0.0"
-  domain: "frontend"
-  role: "specialist"
-  stack: "nextjs"
-  baseline: "Next.js 16 + React 19"
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 # Next.js Developer
 
-## Scope
+## Purpose
 
-- Primary skill for App Router implementation and refactors.
-- Not for version migration playbooks (`next-upgrade`) or cache-components-only tuning (`next-cache-components`).
+Use for implementing and reviewing Next.js App Router features, React Server Components and Actions, caching strategy, SEO, and production runtime behavior.
 
-## When to use
+## When to Use
 
-- Building routes/layouts/loading/error boundaries.
-- Implementing server components and server actions.
-- Designing data fetching/revalidation strategy.
-- Improving SEO and web vitals.
+- Building or refactoring App Router routes, layouts, loading states, and errors.
+- Choosing static, dynamic, or streaming rendering behavior per route.
+- Implementing React Server Components, Server Actions, and cache invalidation.
+- Improving metadata, structured data, and Core Web Vitals in a Next app.
 
-## Core workflow
+## Instructions
 
-1. Define rendering mode per route (static/dynamic/streaming).
-2. Keep server/client component boundaries explicit.
-3. Implement data access with caching semantics by intent.
-4. Add forms/actions with validation and auth checks.
-5. Verify perf, accessibility, and error handling.
+1. Decide rendering mode and data boundary per route.
+2. Keep server and client components separated by necessity, not habit.
+3. Use caching and invalidation intentionally rather than globally.
+4. Add route-level loading, error, and auth-sensitive behavior explicitly.
+5. Verify SEO, accessibility, and runtime performance before shipping.
 
-## Baseline standards
+### Baseline standards
 
-- Default to Server Components; opt into client components only when needed.
+- Default to Server Components and opt into client components deliberately.
 - Keep server-only code out of client bundles.
-- Use route-level loading/error states.
-- Use metadata API and structured data for SEO.
-- Measure Core Web Vitals and act on regressions.
-
-## Avoid
-
-- Unnecessary client hydration.
-- Mixing auth-sensitive logic into client-only paths.
-- Overusing global revalidation when targeted invalidation is possible.
-
-## Reference files
-
-- `references/app-router.md`
-- `references/server-components.md`
-- `references/server-actions.md`
-- `references/data-fetching.md`
-- `references/performance.md`
-- `references/seo.md`
-- `references/deployment.md`
-- `references/testing.md`
+- Use route-level loading and error states.
+- Prefer targeted revalidation over broad cache busting.
+- Measure Web Vitals after changes that affect rendering or data flow.
+
+### Constraints
+
+- Avoid unnecessary client hydration.
+- Avoid mixing secret or auth-sensitive logic into client paths.
+- Avoid global revalidation when route- or tag-scoped invalidation is enough.
+- Avoid framework-heavy decisions without checking the underlying React boundary first.
+
+## 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/app-router-cache-playbook.md` | The task needs route-level guidance for App Router rendering, caching, revalidation, metadata, and server/client boundaries. |
+
+## 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 nextjs developer best practices in this project"
+- "Review my nextjs developer implementation for issues"

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/nextjs-developer/references/app-router-cache-playbook.md

@@ -0,0 +1,26 @@
+# App Router And Cache Playbook
+
+Load this when route-level Next.js behavior is the real problem.
+
+## Rendering mode
+
+- Decide per route whether the target is static, dynamic, or streaming.
+- Default to Server Components and add client components only where interactivity requires them.
+- Keep secret, auth-sensitive, and server-only logic out of client bundles.
+
+## Data and cache
+
+- Choose the narrowest caching strategy that matches the data lifecycle.
+- Prefer targeted revalidation over global cache busting.
+- Make route, tag, or mutation-driven invalidation explicit.
+
+## UX and SEO
+
+- Add route-level loading and error states intentionally.
+- Keep metadata and structured data close to the route they describe.
+- Verify hydration cost when adding new client boundaries.
+
+## Operational checks
+
+- Re-check auth, cache invalidation, and user-specific data paths together.
+- Measure Web Vitals after changing route rendering or data flow.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/nodejs-best-practices/SKILL.md

@@ -1,48 +1,67 @@
 ---
-name: "nodejs-best-practices"
-description: "Decision framework for modern Node.js backend architecture, operations, and security using current LTS-era practices."
+name: nodejs-best-practices
+description: "Use for modern Node.js backend architecture, runtime choices, worker or queue boundaries, edge-vs-server tradeoffs, reliability controls, and production-safe service implementation in the current LTS era."
 license: MIT
 metadata:
-  version: "2.0.0"
-  domain: "backend"
-  role: "decision-guide"
-  stack: "nodejs"
-  baseline: "Node 22/24 LTS era"
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 # Node.js Best Practices
 
 ## Purpose
 
-Use this skill to choose the right Node backend patterns for the actual constraints of the task, not by habit.
+Use for modern Node.js backend architecture, runtime choices, worker or queue boundaries, edge-vs-server tradeoffs, reliability controls, and production-safe service implementation in the current LTS era.
 
-## Decision flow
+## When to Use
 
-1. Clarify deployment target (container, serverless, edge).
-2. Select framework/runtime shape based on latency and team constraints.
-3. Define API, validation, auth, and observability boundaries.
-4. Implement smallest safe slice, then harden.
+- Choosing Node backend structure for APIs, workers, or service code.
+- Making runtime, framework, validation, queue, and observability decisions.
+- Hardening Node services for concurrency, deployment, and failure handling.
+- Reviewing service code for event-loop safety, background work boundaries, and production behavior.
 
-## Core guidance
+## Instructions
 
-- Prefer typed boundaries (TypeScript + schema validation).
-- Keep transport concerns out of business logic.
-- Standardize error envelopes and correlation IDs.
-- Enforce timeout, retry, and circuit-breaker strategy for downstream calls.
-- Use graceful shutdown and health/readiness probes.
+1. Confirm runtime context: container, serverless, edge, worker, queue consumer, or long-lived process.
+2. Pick the smallest framework/runtime shape that fits latency, I/O profile, and deployment constraints.
+3. Keep transport, business logic, persistence, and background execution boundaries explicit.
+4. Add validation, timeout, retry, backpressure, and observability controls before shipping.
+5. Verify graceful shutdown, health checks, worker behavior, and dependency failure handling.
 
-## Security and reliability
+### Baseline standards
 
-- Validate all request input before business logic.
-- Use least-privilege credentials and secret rotation.
+- Prefer typed boundaries and explicit schema validation.
 - Avoid blocking the event loop in request paths.
-- Add rate limits and abuse controls on external endpoints.
+- Use workers or queues when CPU-heavy or long-lived background work would distort request latency.
+- Add correlation IDs and consistent error envelopes.
+- Use graceful shutdown and readiness probes.
+- Measure CPU, heap, and I/O hot paths before optimizing.
 
-## Performance
+### Constraints
 
-- Measure before optimizing.
-- Profile CPU and heap in realistic workloads.
-- Use streaming/backpressure for large I/O paths.
+- Avoid framework-by-habit decisions.
+- Avoid hidden background work with no timeout or cancellation path.
+- Avoid running CPU-bound work on the main event loop when workers or out-of-process jobs are needed.
+- Avoid unbounded retries and silent downstream failures.
+- Avoid secret handling or auth logic without explicit least-privilege boundaries.
 
-## Output expectation
+## Output Format
 
-Return concrete architecture choices with tradeoffs, then implementation steps and verification criteria.
+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/runtime-reliability-checklist.md` | You need a deeper checklist for runtime choice, shutdown, workers or queues, edge-vs-server tradeoffs, validation, retries, observability, and production failure handling. |
+
+## 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 nodejs best practices best practices in this project"
+- "Review my nodejs best practices implementation for issues"

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/nodejs-best-practices/references/runtime-reliability-checklist.md

@@ -0,0 +1,34 @@
+# Runtime And Reliability Checklist
+
+Load this when Node service work needs deeper operational discipline.
+
+## Runtime shape
+
+- Confirm whether the process is serverless, edge, worker, or long-lived server.
+- Match the framework and concurrency model to latency, I/O, and deployment constraints.
+- Keep transport, domain logic, and persistence boundaries explicit.
+
+## Workers, queues, and edge boundaries
+
+- Use worker threads only when CPU-bound work must stay in-process.
+- Use queues or separate workers for durable, slow, or retry-heavy jobs.
+- Keep edge runtimes free of Node-only assumptions such as unrestricted filesystem or native modules.
+- Make cancellation, timeout, and retry behavior explicit for background work.
+
+## Safety controls
+
+- Validate input at the boundary with explicit schemas.
+- Add deadlines, retries, and cancellation rules for networked dependencies.
+- Keep secrets, auth decisions, and privilege boundaries explicit.
+
+## Production posture
+
+- Add health checks, graceful shutdown, and readiness semantics.
+- Use correlation IDs and structured logging.
+- Make failure behavior obvious for queues, jobs, and background work.
+
+## Performance
+
+- Avoid blocking CPU work in request paths.
+- Measure heap, event-loop delay, and I/O hotspots before optimizing.
+- Prefer one high-signal optimization at a time.