@cubis/foundry 0.3.31 → 0.3.33

package/workflows/skills/sub-agents/references/cli-formats.md

@@ -0,0 +1,25 @@
+# CLI Formats for Sub-Agents
+
+This reference defines the expected invocation style per CLI target.
+
+## codex
+- Mode: non-interactive command execution.
+- Preferred output: structured markdown or JSON when requested.
+- Use explicit cwd and deterministic prompts.
+
+## claude
+- Mode: prompt-first invocation.
+- Keep task boundary narrow and include acceptance checks.
+
+## gemini
+- Mode: concise instruction with explicit constraints.
+- Include required output sections to reduce drift.
+
+## cursor-agent
+- Mode: task delegation with repository-aware context.
+- Provide concrete files, checks, and done criteria.
+
+## Common requirements
+- Always include: goal, scope, constraints, expected output.
+- Avoid hidden assumptions; pass critical context explicitly.
+- Request machine-readable output when parsing is required.

package/workflows/skills/tdd-workflow/SKILL.md

@@ -1,149 +1,21 @@
 ---
 name: tdd-workflow
-description: Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+description: "Compatibility alias skill. Deprecated: use test-master."
+metadata:
+  deprecated: true
+  replaced_by: test-master
+  removal_target: v0.6.0
 ---
 
-# TDD Workflow
+# Tdd Workflow
 
-> Write tests first, code second.
+## Compatibility Alias
 
----
-
-## 1. The TDD Cycle
-
-```
-🔴 RED → Write failing test
-    ↓
-🟢 GREEN → Write minimal code to pass
-    ↓
-🔵 REFACTOR → Improve code quality
-    ↓
-   Repeat...
-```
-
----
-
-## 2. The Three Laws of TDD
-
-1. Write production code only to make a failing test pass
-2. Write only enough test to demonstrate failure
-3. Write only enough code to make the test pass
-
----
-
-## 3. RED Phase Principles
-
-### What to Write
-
-| Focus | Example |
-|-------|---------|
-| Behavior | "should add two numbers" |
-| Edge cases | "should handle empty input" |
-| Error states | "should throw for invalid data" |
-
-### RED Phase Rules
-
-- Test must fail first
-- Test name describes expected behavior
-- One assertion per test (ideally)
-
----
-
-## 4. GREEN Phase Principles
-
-### Minimum Code
-
-| Principle | Meaning |
-|-----------|---------|
-| **YAGNI** | You Aren't Gonna Need It |
-| **Simplest thing** | Write the minimum to pass |
-| **No optimization** | Just make it work |
-
-### GREEN Phase Rules
-
-- Don't write unneeded code
-- Don't optimize yet
-- Pass the test, nothing more
-
----
-
-## 5. REFACTOR Phase Principles
-
-### What to Improve
+This skill is deprecated and kept for backward compatibility.
 
-| Area | Action |
-|------|--------|
-| Duplication | Extract common code |
-| Naming | Make intent clear |
-| Structure | Improve organization |
-| Complexity | Simplify logic |
+Use `test-master` as the canonical skill.
 
-### REFACTOR Rules
-
-- All tests must stay green
-- Small incremental changes
-- Commit after each refactor
-
----
-
-## 6. AAA Pattern
-
-Every test follows:
-
-| Step | Purpose |
-|------|---------|
-| **Arrange** | Set up test data |
-| **Act** | Execute code under test |
-| **Assert** | Verify expected outcome |
-
----
-
-## 7. When to Use TDD
-
-| Scenario | TDD Value |
-|----------|-----------|
-| New feature | High |
-| Bug fix | High (write test first) |
-| Complex logic | High |
-| Exploratory | Low (spike, then TDD) |
-| UI layout | Low |
-
----
-
-## 8. Test Prioritization
-
-| Priority | Test Type |
-|----------|-----------|
-| 1 | Happy path |
-| 2 | Error cases |
-| 3 | Edge cases |
-| 4 | Performance |
-
----
-
-## 9. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Skip the RED phase | Watch test fail first |
-| Write tests after | Write tests before |
-| Over-engineer initial | Keep it simple |
-| Multiple asserts | One behavior per test |
-| Test implementation | Test behavior |
-
----
-
-## 10. AI-Augmented TDD
-
-### Multi-Agent Pattern
-
-| Agent | Role |
-|-------|------|
-| Agent A | Write failing tests (RED) |
-| Agent B | Implement to pass (GREEN) |
-| Agent C | Optimize (REFACTOR) |
-
----
+## Migration
 
-> **Remember:** The test is the specification. If you can't write a test, you don't understand the requirement.
+1. Replace direct references to `tdd-workflow` with `test-master`.
+2. Apply the full workflow from `test-master` for new work.

package/workflows/skills/testing-patterns/SKILL.md

@@ -1,178 +1,21 @@
 ---
 name: testing-patterns
-description: Testing patterns and principles. Unit, integration, mocking strategies.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+description: "Compatibility alias skill. Deprecated: use test-master."
+metadata:
+  deprecated: true
+  replaced_by: test-master
+  removal_target: v0.6.0
 ---
 
 # Testing Patterns
 
-> Principles for reliable test suites.
+## Compatibility Alias
 
----
-
-## 1. Testing Pyramid
-
-```
-        /\          E2E (Few)
-       /  \         Critical flows
-      /----\
-     /      \       Integration (Some)
-    /--------\      API, DB queries
-   /          \
-  /------------\    Unit (Many)
-                    Functions, classes
-```
-
----
-
-## 2. AAA Pattern
-
-| Step | Purpose |
-|------|---------|
-| **Arrange** | Set up test data |
-| **Act** | Execute code under test |
-| **Assert** | Verify outcome |
-
----
-
-## 3. Test Type Selection
-
-### When to Use Each
-
-| Type | Best For | Speed |
-|------|----------|-------|
-| **Unit** | Pure functions, logic | Fast (<50ms) |
-| **Integration** | API, DB, services | Medium |
-| **E2E** | Critical user flows | Slow |
-
----
-
-## 4. Unit Test Principles
-
-### Good Unit Tests
-
-| Principle | Meaning |
-|-----------|---------|
-| Fast | < 100ms each |
-| Isolated | No external deps |
-| Repeatable | Same result always |
-| Self-checking | No manual verification |
-| Timely | Written with code |
-
-### What to Unit Test
-
-| Test | Don't Test |
-|------|------------|
-| Business logic | Framework code |
-| Edge cases | Third-party libs |
-| Error handling | Simple getters |
-
----
-
-## 5. Integration Test Principles
-
-### What to Test
-
-| Area | Focus |
-|------|-------|
-| API endpoints | Request/response |
-| Database | Queries, transactions |
-| External services | Contracts |
-
-### Setup/Teardown
-
-| Phase | Action |
-|-------|--------|
-| Before All | Connect resources |
-| Before Each | Reset state |
-| After Each | Clean up |
-| After All | Disconnect |
-
----
+This skill is deprecated and kept for backward compatibility.
 
-## 6. Mocking Principles
+Use `test-master` as the canonical skill.
 
-### When to Mock
-
-| Mock | Don't Mock |
-|------|------------|
-| External APIs | The code under test |
-| Database (unit) | Simple dependencies |
-| Time/random | Pure functions |
-| Network | In-memory stores |
-
-### Mock Types
-
-| Type | Use |
-|------|-----|
-| Stub | Return fixed values |
-| Spy | Track calls |
-| Mock | Set expectations |
-| Fake | Simplified implementation |
-
----
-
-## 7. Test Organization
-
-### Naming
-
-| Pattern | Example |
-|---------|---------|
-| Should behavior | "should return error when..." |
-| When condition | "when user not found..." |
-| Given-when-then | "given X, when Y, then Z" |
-
-### Grouping
-
-| Level | Use |
-|-------|-----|
-| describe | Group related tests |
-| it/test | Individual case |
-| beforeEach | Common setup |
-
----
-
-## 8. Test Data
-
-### Strategies
-
-| Approach | Use |
-|----------|-----|
-| Factories | Generate test data |
-| Fixtures | Predefined datasets |
-| Builders | Fluent object creation |
-
-### Principles
-
-- Use realistic data
-- Randomize non-essential values (faker)
-- Share common fixtures
-- Keep data minimal
-
----
-
-## 9. Best Practices
-
-| Practice | Why |
-|----------|-----|
-| One assert per test | Clear failure reason |
-| Independent tests | No order dependency |
-| Fast tests | Run frequently |
-| Descriptive names | Self-documenting |
-| Clean up | Avoid side effects |
-
----
-
-## 10. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Test implementation | Test behavior |
-| Duplicate test code | Use factories |
-| Complex test setup | Simplify or split |
-| Ignore flaky tests | Fix root cause |
-| Skip cleanup | Reset state |
-
----
+## Migration
 
-> **Remember:** Tests are documentation. If someone can't understand what the code does from the tests, rewrite them.
+1. Replace direct references to `testing-patterns` with `test-master`.
+2. Apply the full workflow from `test-master` for new work.

package/workflows/skills/typescript-pro/SKILL.md

@@ -1,87 +1,60 @@
 ---
 name: "typescript-pro"
-description: "Use when building TypeScript applications requiring advanced type systems, generics, or full-stack type safety. Invoke for type guards, utility types, tRPC integration, monorepo setup."
+description: "Use for TypeScript architecture and implementation with TS 5.9+ production baselines and TS 6/7 transition readiness."
+license: MIT
+metadata:
+  version: "2.0.0"
+  domain: "language"
+  role: "specialist"
+  stack: "typescript"
+  baseline: "TypeScript 5.9 stable"
+  transition: "TypeScript 6 compatibility prep"
 ---
 
-
 # TypeScript Pro
 
-## Overview
-
-Senior TypeScript specialist with deep expertise in advanced type systems, full-stack type safety, and production-grade TypeScript development.
-
-## Role Definition
-
-You are a senior TypeScript developer with 10+ years of experience. You specialize in TypeScript 5.0+ advanced type system features, full-stack type safety, and build optimization. You create type-safe APIs with zero runtime type errors.
-
-## When to Use This Skill
-
-- Building type-safe full-stack applications
-- Implementing advanced generics and conditional types
-- Setting up tsconfig and build tooling
-- Creating discriminated unions and type guards
-- Implementing end-to-end type safety with tRPC
-- Optimizing TypeScript compilation and bundle size
-
-## Core Workflow
-
-1. **Analyze type architecture** - Review tsconfig, type coverage, build performance
-2. **Design type-first APIs** - Create branded types, generics, utility types
-3. **Implement with type safety** - Write type guards, discriminated unions, conditional types
-4. **Optimize build** - Configure project references, incremental compilation, tree shaking
-5. **Test types** - Verify type coverage, test type logic, ensure zero runtime errors
-
-## Available Steering Files
-
-Load detailed guidance on-demand:
-
-| Topic          | Reference                    | Load When                                                    |
-| -------------- | ---------------------------- | ------------------------------------------------------------ |
-| Advanced Types | `references/advanced-types.md` | Generics, conditional types, mapped types, template literals |
-| Type Guards    | `references/type-guards.md`    | Type narrowing, discriminated unions, assertion functions    |
-| Utility Types  | `references/utility-types.md`  | Partial, Pick, Omit, Record, custom utilities                |
-| Configuration  | `references/configuration.md`  | tsconfig options, strict mode, project references            |
-| Patterns       | `references/patterns.md`       | Builder pattern, factory pattern, type-safe APIs             |
-
-## Constraints
+## When to use
 
-### MUST DO
+- Designing type-safe APIs and shared contracts.
+- Refactoring codebases to strict TypeScript.
+- Reducing type regressions in monorepos.
+- Preparing for upcoming TS 6/7 behavior shifts.
 
-- Enable strict mode with all compiler flags
-- Use type-first API design
-- Implement branded types for domain modeling
-- Use `satisfies` operator for type validation
-- Create discriminated unions for state machines
-- Use `Annotated` pattern with type predicates
-- Generate declaration files for libraries
-- Optimize for type inference
+## Core workflow
 
-### MUST NOT DO
+1. Confirm runtime and module target (Node, browser, edge).
+2. Lock strict compiler baseline before feature work.
+3. Model domain types first, then implement behavior.
+4. Keep runtime validation where untrusted input enters.
+5. Run type checks and targeted tests before finishing.
 
-- Use explicit `any` without justification
-- Skip type coverage for public APIs
-- Mix type-only and value imports
-- Disable strict null checks
-- Use `as` assertions without necessity
-- Ignore compiler performance warnings
-- Skip declaration file generation
-- Use enums (prefer const objects with `as const`)
+## Baseline standards
 
-## Output Templates
+- Use `strict: true` and avoid opt-outs unless documented.
+- Prefer `unknown` over `any` at boundaries.
+- Use `satisfies` and `as const` for safer inference.
+- Keep public API types stable and explicit.
+- Use project references for large repos.
 
-When implementing TypeScript features, provide:
+## Implementation guidance
 
-1. Type definitions (interfaces, types, generics)
-2. Implementation with type guards
-3. tsconfig configuration if needed
-4. Brief explanation of type design decisions
+- Encode state with discriminated unions.
+- Narrow with type guards instead of assertions.
+- Keep utility types readable; avoid type-level obfuscation.
+- Use schema validation (zod/valibot/etc.) for external input.
+- Treat type errors as design feedback, not noise.
 
-## Knowledge Reference
+## Avoid
 
-TypeScript 5.0+, generics, conditional types, mapped types, template literal types, discriminated unions, type guards, branded types, tRPC, project references, incremental compilation, declaration files, const assertions, satisfies operator
+- Library-facing `any`.
+- Broad `as` casts to silence errors.
+- Hidden implicit `any` from weak tsconfig defaults.
+- Mixing runtime and type-only imports carelessly.
 
-## Related Powers
+## Reference files
 
-- **React Developer** - Component type safety
-- **Fullstack Guardian** - End-to-end type safety
-- **API Designer** - Type-safe API contracts
+- `references/configuration.md`
+- `references/advanced-types.md`
+- `references/type-guards.md`
+- `references/utility-types.md`
+- `references/patterns.md`

package/workflows/skills/vercel-ai/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: vercel-ai
+description: "Canonical Vercel AI skill covering AI Gateway and AI SDK integration, routing, resilience, and observability."
+metadata:
+  deprecated: false
+  replaced_by: null
+  removal_target: null
+---
+
+# Vercel AI
+
+## Purpose
+
+Implement Vercel AI workloads with a single operating model across AI Gateway and AI SDK: provider routing, fallback resilience, secure key handling, streaming UX, and usage observability.
+
+## Use This For
+
+- AI Gateway provider routing and fallback chains
+- BYOK/auth strategy and OpenAI-compatible endpoints
+- AI SDK integration for chat/completions/streaming
+- AI request telemetry and cost/usage controls
+
+## Decision Flow
+
+1. Select provider topology and fallback policy.
+2. Define auth and secret boundaries.
+3. Implement SDK streaming/UI contract.
+4. Validate latency/cost/error behavior with telemetry.
+
+## Verification
+
+- Gateway routes and fallback logic are deterministic.
+- SDK streaming path is stable under provider failure.
+- Token usage and error rates are observable per route/model.
+
+## Related Skills
+
+- `vercel-platform`
+- `prompt-engineer`
+- `vercel-observability`

package/workflows/skills/vercel-ai-gateway/SKILL.md

@@ -1,79 +1,21 @@
 ---
 name: vercel-ai-gateway
-description: "Complete Vercel AI Gateway integration: LLM traffic routing, authentication/BYOK, fallback chains, model-provider routing policies, usage observability, and OpenAI-compatible endpoints."
-license: MIT
+description: "Compatibility alias skill. Deprecated: use vercel-ai."
 metadata:
-  author: cubis-foundry
-  version: "1.0.0"
-  domain: vercel
-  triggers: vercel, ai, gateway, llm, byok, fallback, model routing, openai compatible, token usage, ai observability
-  role: specialist
-  scope: implementation
-  output-format: checklist
-  related-skills: prompt-engineer, monitoring-expert, secure-code-guardian, vercel-observability
-  consolidates: vercel-ai-gateway-core, vercel-ai-gateway-auth-byok, vercel-ai-gateway-fallbacks, vercel-ai-gateway-model-routing, vercel-ai-gateway-observability, vercel-ai-gateway-openai-compatible
+  deprecated: true
+  replaced_by: vercel-ai
+  removal_target: v0.6.0
 ---
 
-# Vercel AI Gateway
+# Vercel Ai Gateway
 
-## Purpose
+## Compatibility Alias
 
-Route LLM traffic through Vercel AI Gateway with unified controls covering authentication, model-provider routing, resilient fallback chains, usage observability, and OpenAI-compatible endpoint compatibility.
+This skill is deprecated and kept for backward compatibility.
 
-## When To Use
+Use `vercel-ai` as the canonical skill.
 
-- Routing AI/LLM requests through Vercel's managed gateway.
-- Configuring bring-your-own-key (BYOK) authentication for AI providers.
-- Implementing retries and fallback chains for resilient AI responses.
-- Designing model and provider routing policies for latency, quality, and cost.
-- Monitoring AI Gateway usage, latency, and spend.
-- Using OpenAI-compatible endpoints without provider lock-in.
+## Migration
 
-## Domain Areas
-
-### Core Routing
-
-- Define unified gateway endpoint and routing config.
-- Set per-model quality, latency, and cost objectives.
-
-### Authentication & BYOK
-
-- Configure provider API key management and BYOK controls.
-- Scope key access per project/environment.
-
-### Fallbacks & Resilience
-
-- Implement retry policies and fallback provider chains.
-- Define circuit-breaker thresholds.
-
-### Model Routing Policies
-
-- Route by latency, cost, capability, or custom weights.
-- Support multi-provider and multi-region strategies.
-
-### Observability
-
-- Instrument token usage, latency, and error rates per model.
-- Set spend thresholds and alerting.
-
-### OpenAI Compatibility
-
-- Use OpenAI-compatible request/response format.
-- Migrate between providers without application changes.
-
-## Operating Checklist
-
-1. Define model quality, latency, and cost objectives for each endpoint.
-2. Configure authentication and BYOK key scoping per environment.
-3. Implement routing, fallback, and retry policies explicitly.
-4. Instrument token usage, latency, and error classes for all calls.
-5. Validate OpenAI-compatible endpoint compatibility if needed.
-6. Run safety and regression checks before broad rollout.
-
-## Output Contract
-
-- Proposed routing and authentication architecture with tradeoffs
-- Required config, code, and environment changes
-- Fallback chain definition and circuit-breaker settings
-- Validation evidence (spend limits, latency targets, error budgets)
-- Residual risks and follow-up actions
+1. Replace direct references to `vercel-ai-gateway` with `vercel-ai`.
+2. Apply the full workflow from `vercel-ai` for new work.