@cubis/foundry 0.3.67 → 0.3.68

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/testing-patterns/SKILL.md

@@ -1,20 +1,165 @@
 ---
 name: testing-patterns
-description: "Compatibility alias skill. Deprecated: use test-master."
+description: Design test strategies with unit, integration, and e2e testing. Apply TDD, mocking, fixtures, coverage analysis, and test architecture best practices.
+license: Apache-2.0
 metadata:
-  deprecated: true
-  replaced_by: test-master
-  removal_target: v0.6.0
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
 ---
 # Testing Patterns
 
-## Compatibility Alias
+## Purpose
 
-This skill is deprecated and kept for backward compatibility.
+Guide test strategy, structure, and implementation across all testing levels. Covers unit, integration, and e2e testing patterns, TDD methodology, mocking strategies, and test architecture.
 
-Use `test-master` as the canonical skill.
+## When to Use
 
-## Migration
+- Writing tests for new features or bug fixes
+- Designing a test strategy for a new project or module
+- Debugging flaky or slow tests
+- Reviewing test quality and coverage gaps
+- Setting up test infrastructure (runners, fixtures, mocks)
+- Deciding what level of testing is appropriate
 
-1. Replace direct references to `testing-patterns` with `test-master`.
-2. Apply the full workflow from `test-master` for new work.
+## Instructions
+
+### Step 1 — Choose the Right Test Level
+
+| Level       | Tests                        | Speed    | Confidence                   | When to Use                                        |
+| ----------- | ---------------------------- | -------- | ---------------------------- | -------------------------------------------------- |
+| Unit        | Individual functions/classes | ms       | Logic correctness            | Pure logic, calculations, transformers             |
+| Integration | Module boundaries            | 100ms–1s | Components work together     | API routes, database queries, service interactions |
+| E2E         | Full user flows              | 5–30s    | System works as user expects | Critical paths (signup, checkout, deploy)          |
+
+**Testing Trophy** (preferred distribution):
+
+- Many integration tests (highest ROI)
+- Some unit tests (fast logic verification)
+- Few e2e tests (critical paths only)
+- Static analysis as the foundation (TypeScript, linting)
+
+### Step 2 — Write Effective Tests
+
+**Structure every test as Arrange → Act → Assert**:
+
+```typescript
+test("calculates total with tax", () => {
+  // Arrange
+  const items = [{ price: 100 }, { price: 200 }];
+  const taxRate = 0.1;
+
+  // Act
+  const total = calculateTotal(items, taxRate);
+
+  // Assert
+  expect(total).toBe(330);
+});
+```
+
+**Naming**: Use natural language that describes the behavior:
+
+- DO: `"returns empty array when no items match filter"`
+- DON'T: `"test filter"` or `"test1"`
+
+**One assertion per behavior** (not per test):
+
+- One test can have multiple `expect()` calls if they verify the same behavior
+- Split separate behaviors into separate tests
+
+### Step 3 — Mock Strategically
+
+**Mock at boundaries, not everywhere**:
+
+- Mock: external APIs, databases, file system, time, randomness
+- Don't mock: your own code, simple utilities, data transformations
+
+**Mock patterns**:
+
+```typescript
+// Dependency injection (preferred)
+function createUserService(db: Database) {
+  return { getUser: (id) => db.query("SELECT...", [id]) };
+}
+
+// Module mocking (when DI not available)
+vi.mock("./database", () => ({
+  query: vi.fn().mockResolvedValue([{ id: 1, name: "Alice" }]),
+}));
+```
+
+**Avoid**:
+
+- Mocking implementation details (private methods, internal state)
+- Over-mocking (if you mock everything, you're testing nothing)
+- Snapshot tests for behavior (only for serialized output like HTML)
+
+### Step 4 — Handle Test Data
+
+**Factories over fixtures**:
+
+```typescript
+function createUser(overrides = {}) {
+  return {
+    id: crypto.randomUUID(),
+    name: "Test User",
+    email: "test@example.com",
+    role: "user",
+    ...overrides,
+  };
+}
+
+// Usage
+const admin = createUser({ role: "admin" });
+```
+
+**Test isolation**:
+
+- Each test creates its own data (no shared mutable state)
+- Clean up after integration tests (database, files)
+- Use transactions for database tests (rollback after each test)
+
+### Step 5 — Fix Common Test Problems
+
+**Flaky tests**:
+
+- Remove timing dependencies (`setTimeout`, `sleep`)
+- Use deterministic data (no `Math.random()` without seeding)
+- Await all async operations properly
+- Isolate external dependencies (mock network, use test databases)
+
+**Slow tests**:
+
+- Run in parallel when tests are isolated
+- Use in-memory databases for integration tests
+- Minimize e2e tests — push logic down to unit/integration
+- Profile and fix the slowest 10% first
+
+**Brittle tests**:
+
+- Test behavior, not implementation
+- Use accessible queries in UI tests (role, label — not CSS selectors)
+- Avoid testing framework internals
+
+## Output Format
+
+```
+## Test Strategy
+[approach and reasoning for test level choices]
+
+## Tests
+[test code organized by describe blocks]
+
+## Coverage Notes
+[what's tested, what's intentionally not tested, and why]
+```
+
+## Examples
+
+**User**: "Write tests for this user registration function"
+
+**Response approach**: Unit tests for validation logic (email format, password strength). Integration test for the full registration flow (validate → hash password → insert DB → send email). Mock the email service and database. Test edge cases (duplicate email, weak password, missing fields).
+
+**User**: "Our test suite takes 20 minutes, help us speed it up"
+
+**Response approach**: Profile the slowest tests. Look for unnecessary e2e tests that could be integration. Check for missing parallelization. Identify shared state causing serial execution. Suggest in-memory database for integration tests.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/testing-patterns/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "evals": [
+    {
+      "prompt": "Write tests for a user registration function that validates email, hashes password, inserts to DB, and sends welcome email",
+      "assertions": [
+        "includes unit tests for email validation logic",
+        "includes integration test for the full registration flow",
+        "mocks external dependencies (email service, database)",
+        "tests edge cases (duplicate email, weak password)",
+        "uses Arrange-Act-Assert pattern"
+      ]
+    },
+    {
+      "prompt": "Our test suite takes 20 minutes and has 15 flaky tests",
+      "assertions": [
+        "suggests profiling to find the slowest tests",
+        "identifies common causes of flaky tests (timing, shared state, network)",
+        "recommends parallelization for isolated tests",
+        "suggests replacing slow e2e tests with integration tests where possible"
+      ]
+    }
+  ]
+}

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/typescript-pro/SKILL.md

@@ -1,79 +1,68 @@
 ---
-name: "typescript-pro"
-description: "Use for TypeScript architecture and implementation with TS 5.9+ production baselines and TS 6/7 transition readiness."
+name: typescript-pro
+description: "Use for TypeScript architecture and implementation with TS 5.9+ production baselines and TS 6/7 transition readiness. Use when designing type-safe APIs, refactoring to strict TypeScript, reducing type regressions in monorepos, or preparing for TS 6/7 behavior shifts."
 license: MIT
 metadata:
-  version: "2.0.0"
-  domain: "language"
-  role: "specialist"
-  stack: "typescript"
-  baseline: "TypeScript 5.9 stable"
-  transition: "TypeScript 6 compatibility prep"
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 # TypeScript Pro
 
-## When to use
+## Purpose
+
+Language-layer specialist for TypeScript architecture, type design, and production implementation. Provides the type-system foundation before loading framework skills like `nextjs-developer` or `nestjs-expert`. Covers strict compiler configuration, domain modeling with discriminated unions, generic patterns, module structure, and tooling selection for TS 5.9+ codebases with awareness of TS 6/7 transitions.
+
+## When to Use
 
 - 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.
+- Acting as the language-layer foundation before loading framework skills.
+
+## Instructions
+
+1. Confirm runtime and module target (Node, browser, edge) because compiler settings and polyfill requirements differ.
+2. Lock strict compiler baseline (`strict: true`) before feature work because weak defaults hide implicit `any`.
+3. Model domain types first with discriminated unions and `satisfies`/`as const`, then implement behavior — type design is the primary design feedback loop.
+4. Use `unknown` over `any` at boundaries because `any` silently defeats type checking.
+5. Narrow with type guards (`x is T`) instead of `as` assertions because guards provide runtime safety while assertions only silence the compiler.
+6. Encode state machines with discriminated unions and exhaustive `switch`/`assertNever` checks because unhandled variants become compile errors.
+7. Use schema validation (Zod/Valibot) for external input because runtime validation must match declared types at system boundaries.
+8. Keep public API types stable and explicit — do not rely on inferred return types for exported functions.
+9. Use project references (`composite: true` + `references`) for large repos because they enable incremental builds and cross-package type awareness.
+10. Keep barrel exports (`index.ts`) thin — re-export only the public API because deep barrels cause circular dependency pain and slow IDE resolution.
+11. Use `import type` for type-only imports because it prevents runtime import of type-only modules and improves tree-shaking.
+12. Use constrained generics to express input/output relationships — do not exceed 3 type parameters without splitting the abstraction.
+13. Prefer mapped types and template literal types for systematic type transformations — extract complex conditional types into named types for readability.
+14. Run `tsc --noEmit` in CI separately from bundling because type errors should fail CI even when the bundler succeeds.
+15. Use Biome or ESLint + `typescript-eslint` for linting; `tsup` for library builds; Vitest for tests with native TS support.
+16. Do not use library-facing `any` — it poisons downstream callers.
+17. Do not use broad `as` casts to silence errors — treat type errors as design feedback, not noise.
+18. Do not mix runtime and type-only imports carelessly — use `import type` consistently.
+
+## Output Format
+
+Provide type definitions, implementation code, and compiler configuration as fenced TypeScript code blocks. Include `tsconfig.json` excerpts when configuration changes are part of the solution. Explain type-level design decisions inline with brief comments.
+
+## References
+
+| File                           | Load when                                                                    |
+| ------------------------------ | ---------------------------------------------------------------------------- |
+| `references/configuration.md`  | `tsconfig`, strictness, module targets, or project references need detail.   |
+| `references/advanced-types.md` | Generics, conditional types, mapped types, or template literals are central. |
+| `references/type-guards.md`    | Narrowing and runtime-safe type refinement need detail.                      |
+| `references/utility-types.md`  | Utility-type composition or shared helper types are in scope.                |
+| `references/patterns.md`       | Type-safe architecture patterns or public API design needs detail.           |
 
-## When not to use
-
-- Plain JavaScript-only work where runtime constraints matter more than type architecture.
-- Database-only tuning with no TypeScript code change.
-- Simple shell or config edits that do not benefit from TS guidance.
-
-## Core workflow
-
-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.
-
-## Baseline standards
-
-- 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.
-
-## Implementation guidance
-
-- 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.
-
-## Debugging and observability
-
-- Reproduce type regressions with focused compiler output before widening changes.
-- Keep runtime validation and structured logging at untrusted boundaries.
-- Prefer targeted failing examples over broad `as`-based workarounds.
-
-## Performance and reliability
-
-- Keep module boundaries explicit so public types stay stable.
-- Use incremental builds/project references deliberately in large repos.
-- Measure hot runtime paths separately from type-system complexity.
-
-## Avoid
+## Scripts
 
-- Library-facing `any`.
-- Broad `as` casts to silence errors.
-- Hidden implicit `any` from weak tsconfig defaults.
-- Mixing runtime and type-only imports carelessly.
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Reference files
+## Examples
 
-| File | Load when |
-| --- | --- |
-| `references/configuration.md` | `tsconfig`, strictness, module targets, or project references need detail. |
-| `references/advanced-types.md` | Generics, conditional types, mapped types, or template literals are central. |
-| `references/type-guards.md` | Narrowing and runtime-safe type refinement need detail. |
-| `references/utility-types.md` | Utility-type composition or shared helper types are in scope. |
-| `references/patterns.md` | Type-safe architecture patterns or public API design needs detail. |
+- "Refactor this module to use strict TypeScript with discriminated unions for state"
+- "Design a type-safe event system with template literal types"
+- "Set up tsconfig project references for our monorepo"
+- "Replace these `any` casts with proper type narrowing"

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

@@ -0,0 +1,63 @@
+---
+name: vitess
+description: "Use when the task is specifically Vitess or Vitess-backed MySQL platforms: shard-key design, vindexes, resharding, query-routing constraints, Online DDL, and operational tradeoffs for horizontally scaled MySQL."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+# Vitess
+
+## Purpose
+
+Use when the task is specifically Vitess or Vitess-backed MySQL platforms: shard-key design, vindexes, resharding, query-routing constraints, Online DDL, and operational tradeoffs for horizontally scaled MySQL.
+
+## When to Use
+
+- The engine is Vitess or a Vitess-backed managed MySQL platform.
+- The problem depends on shard keys, vindexes, resharding, query routing, or Online DDL behavior.
+- You need guidance for scaling MySQL horizontally rather than treating it like a single-node database.
+
+## Instructions
+
+1. Confirm whether the task is schema design, query shape, shard-key choice, or operational scaling.
+2. Make entity ownership and routing key choice explicit before optimizing anything else.
+3. Check whether queries respect shard boundaries and Vitess execution constraints.
+4. Plan Online DDL, resharding, and rollback with operational evidence.
+5. Report the coupling, fan-out, and migration risks that remain after the change.
+
+### Baseline standards
+
+- Choose shard keys from access patterns and ownership, not convenience.
+- Minimize cross-shard fan-out and hidden coordination costs.
+- Treat Online DDL and resharding as operational programs, not single commands.
+- Keep query routing constraints visible to application teams.
+
+### Constraints
+
+- Avoid designing as if the database were a single-node MySQL instance.
+- Avoid late shard-key decisions after application coupling hardens.
+- Avoid cross-shard joins or transactions without explicit justification.
+- Avoid treating Vitess complexity as free scale.
+
+## 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/vitess-checklist.md` | You need deeper Vitess guidance for shard keys, vindexes, query routing, resharding, and Online DDL 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 vitess best practices in this project"
+- "Review my vitess implementation for issues"

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/vitess/references/vitess-checklist.md

@@ -0,0 +1,19 @@
+# Vitess Checklist
+
+Load this when sharded MySQL behavior is the real problem.
+
+## Routing and ownership
+
+- Choose shard keys from access patterns and ownership boundaries.
+- Keep cross-shard fan-out visible and minimized.
+- Treat vindexes as application-shaping decisions, not low-level detail.
+
+## Query behavior
+
+- Check whether queries respect shard routing constraints.
+- Avoid assuming single-node MySQL semantics when the topology is distributed.
+
+## Operations
+
+- Make Online DDL, resharding, and rollback operationally explicit.
+- Keep coupling and migration risk visible to application teams.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/vulnerability-scanner/SKILL.md

@@ -1,20 +1,156 @@
 ---
 name: vulnerability-scanner
-description: "Compatibility alias skill. Deprecated: use security-reviewer."
+description: Scan dependencies for CVEs, perform SAST/DAST analysis, manage security advisories, and implement automated vulnerability management workflows.
+license: Apache-2.0
 metadata:
-  deprecated: true
-  replaced_by: security-reviewer
-  removal_target: v0.6.0
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
 ---
 # Vulnerability Scanner
 
-## Compatibility Alias
+## Purpose
 
-This skill is deprecated and kept for backward compatibility.
+Guide dependency scanning, static/dynamic application security testing, CVE management, and automated vulnerability remediation workflows.
 
-Use `security-reviewer` as the canonical skill.
+## When to Use
 
-## Migration
+- Auditing project dependencies for known vulnerabilities
+- Setting up automated security scanning in CI/CD
+- Triaging and remediating CVEs in dependencies
+- Implementing SAST (static) or DAST (dynamic) security testing
+- Managing security advisories and disclosure
+- Building a software bill of materials (SBOM)
 
-1. Replace direct references to `vulnerability-scanner` with `security-reviewer`.
-2. Apply the full workflow from `security-reviewer` for new work.
+## Instructions
+
+### Step 1 — Scan Dependencies
+
+**Tools by ecosystem**:
+| Ecosystem | Tool | Command |
+|-----------|------|---------|
+| npm | `npm audit` | `npm audit --production` |
+| Node.js | Socket.dev | GitHub App |
+| Python | pip-audit, Safety | `pip-audit` |
+| Go | govulncheck | `govulncheck ./...` |
+| Rust | cargo-audit | `cargo audit` |
+| Multi-lang | Snyk, Dependabot, Trivy | `snyk test`, `trivy fs .` |
+
+**Scan levels**:
+
+- **Direct dependencies**: what you explicitly installed
+- **Transitive dependencies**: dependencies of your dependencies (most vulnerabilities hide here)
+- **Dev dependencies**: lower risk but still scan (supply chain attacks)
+
+### Step 2 — Triage Vulnerabilities
+
+**Severity assessment** (CVSS + context):
+
+| CVSS     | Severity | Response Time                  |
+| -------- | -------- | ------------------------------ |
+| 9.0-10.0 | Critical | Fix within 24 hours            |
+| 7.0-8.9  | High     | Fix within 1 week              |
+| 4.0-6.9  | Medium   | Fix within 1 month             |
+| 0.1-3.9  | Low      | Fix at next maintenance window |
+
+**Context reduces severity**:
+
+- Dev-only dependency? Lower priority (unless it affects build output)
+- Vulnerability requires network access but the dep runs client-side only? Lower priority
+- Vulnerable function isn't used in your code? Document and monitor
+
+**Decision matrix**:
+| Can Update? | Is Exploitable? | Action |
+|-------------|-----------------|--------|
+| Yes | Yes | Update immediately |
+| Yes | No | Update at next opportunity |
+| No (breaking) | Yes | Fork/patch, or find alternative |
+| No | No | Document, monitor, revisit |
+
+### Step 3 — Remediate
+
+**Update strategies**:
+
+1. **Direct update**: bump the vulnerable package (preferred)
+2. **Override/resolution**: force transitive dependency version (npm overrides, yarn resolutions)
+3. **Fork and patch**: fork the dep, apply security fix, use your fork
+4. **Replace**: switch to an alternative package
+5. **Mitigate**: add application-level controls (input validation, WAF rules) while working on a fix
+
+**Testing after remediation**:
+
+- Run full test suite
+- Check for breaking changes in the updated dependency
+- Verify the vulnerability is actually fixed (`npm audit` should show resolved)
+- Deploy to staging before production
+
+### Step 4 — Automate in CI/CD
+
+**Pipeline integration**:
+
+```yaml
+# GitHub Actions example
+security-scan:
+  runs-on: ubuntu-latest
+  steps:
+    - uses: actions/checkout@v4
+    - run: npm ci
+    - run: npm audit --production --audit-level=high
+    - name: Run Trivy
+      uses: aquasecurity/trivy-action@master
+      with:
+        scan-type: "fs"
+        severity: "HIGH,CRITICAL"
+```
+
+**Policy**:
+
+- Block PRs with critical/high vulnerabilities
+- Auto-create tickets for medium vulnerabilities
+- Dashboard for low-severity tracking
+- Weekly automated dependency update PRs (Dependabot, Renovate)
+
+### Step 5 — Generate SBOM
+
+**Software Bill of Materials** — inventory of all components:
+
+- Use CycloneDX or SPDX format
+- Generate on every release
+- Include in release artifacts
+- Required for many compliance frameworks
+
+**Command examples**:
+
+```bash
+# Node.js
+npx @cyclonedx/cyclonedx-npm --output-file sbom.json
+
+# Container
+trivy image --format cyclonedx myapp:latest > sbom.json
+```
+
+## Output Format
+
+```
+## Scan Results
+[vulnerability count by severity]
+
+## Critical/High Findings
+[CVE ID, package, severity, fix version, exploitability]
+
+## Remediation Plan
+[priority-ordered fixes with commands]
+
+## CI Configuration
+[automated scanning pipeline config]
+```
+
+## Examples
+
+**User**: "Audit our project dependencies for security vulnerabilities"
+
+**Response approach**: Run `npm audit` (or equivalent). List all vulnerabilities by severity. For each critical/high: explain the CVE, check if the vulnerable function is used, provide update command. Suggest adding to CI pipeline.
+
+**User**: "We have a critical CVE in a transitive dependency we can't update"
+
+**Response approach**: Check if the vulnerability is exploitable in context. Use npm overrides to force the patched version of the transitive dep. If not possible, check for alternative packages. Document the mitigation. Set up monitoring for a proper fix.