@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/swift-best-practices/evals/evals.json

@@ -1,64 +0,0 @@
-[
-  {
-    "id": "swift-actor-based-service",
-    "prompt": "Design an actor-based network service in Swift 6 that fetches user profiles from a REST API. The service should support concurrent requests, cancellation, and expose a clean protocol-based interface. Include proper error handling with typed throws and Sendable enforcement.",
-    "assertions": [
-      {
-        "id": "uses-actor-for-shared-state",
-        "description": "The service implementation uses an actor (not a class with locks) for managing mutable shared state such as caches or in-flight request tracking.",
-        "weight": 1.0
-      },
-      {
-        "id": "protocol-based-interface",
-        "description": "A protocol defines the service contract with async throwing methods, and the actor conforms to this protocol, enabling dependency injection and test doubles.",
-        "weight": 1.0
-      },
-      {
-        "id": "cancellation-propagation",
-        "description": "CancellationToken or Task.isCancelled is checked in long operations, and the service supports structured concurrency with TaskGroup or withThrowingTaskGroup for parallel requests.",
-        "weight": 1.0
-      },
-      {
-        "id": "typed-throws-and-sendable",
-        "description": "Error handling uses typed throws (throws(NetworkError) or similar) with a specific error enum. All types crossing actor boundaries conform to Sendable.",
-        "weight": 1.0
-      },
-      {
-        "id": "async-stream-or-sequence",
-        "description": "The design uses AsyncSequence, AsyncStream, or async/await patterns correctly — no completion handlers or DispatchQueue usage in new code.",
-        "weight": 1.0
-      }
-    ]
-  },
-  {
-    "id": "swift-swiftui-state-management",
-    "prompt": "Refactor a SwiftUI shopping cart view that currently uses ObservableObject with @Published properties. Migrate it to use the @Observable macro. The cart should support adding/removing items, computing totals, and persisting state. Show the view, model, and how state flows between parent and child views.",
-    "assertions": [
-      {
-        "id": "observable-macro-adoption",
-        "description": "The cart model uses the @Observable macro instead of ObservableObject/@Published, and properties are plain stored properties tracked automatically by the observation framework.",
-        "weight": 1.0
-      },
-      {
-        "id": "state-and-environment-usage",
-        "description": "View-local state uses @State for the observable object or primitives, and shared state is passed via @Environment or explicit parameters — not via @StateObject or @ObservedObject.",
-        "weight": 1.0
-      },
-      {
-        "id": "pure-view-bodies",
-        "description": "View body properties are side-effect-free. Async work like persistence is triggered via .task modifiers or explicit method calls from button actions, not from computed body properties.",
-        "weight": 1.0
-      },
-      {
-        "id": "parent-child-data-flow",
-        "description": "Parent views own state and pass data down to child views through initializer parameters or environment. Child views that need to mutate parent state use @Bindable or callback closures.",
-        "weight": 1.0
-      },
-      {
-        "id": "value-types-and-immutability",
-        "description": "Cart items are modeled as structs (value types) with let properties where possible. The cart model class uses @Observable but item data structures prefer value semantics for Sendable safety.",
-        "weight": 1.0
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/system-design/evals/assertions.md

@@ -1,52 +0,0 @@
-# System Design Eval Assertions
-
-## Eval 1: Distributed Cache Design
-
-This eval tests the ability to design a caching architecture with proper pattern selection, invalidation, consistency trade-offs, and failure handling for a high-traffic read path.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `cache-aside` — Caching pattern identification | The design must name and justify the caching pattern. Cache-aside is the most appropriate for read-heavy catalogs because the application controls when to populate and invalidate. |
-| 2 | contains | `TTL` — Time-to-live expiration | TTL provides a safety net for cache invalidation. Without it, stale data can persist indefinitely if active invalidation fails. The duration must be justified by the staleness tolerance. |
-| 3 | contains | `invalidat` — Active invalidation strategy | With 500 updates/minute, relying solely on TTL expiry means customers see stale prices and stock levels. Active invalidation (event-driven or direct) is necessary for acceptable freshness. |
-| 4 | contains | `failover` — Cache failure handling | A cache outage must not become a database outage. The design must specify fallback behavior: direct DB reads with circuit breaker, local in-process cache, or graceful degradation. |
-| 5 | contains | `consistent hashing` — Key distribution strategy | Adding or removing cache nodes without consistent hashing causes a thundering herd of cache misses. Consistent hashing minimizes redistribution when the cluster topology changes. |
-
-### What a passing response looks like
-
-- Cache-aside pattern with Redis Cluster as the primary cache layer.
-- TTL of 5-15 minutes with justification based on acceptable staleness for catalog data.
-- Event-driven invalidation via Kafka/SNS triggered by merchant product updates.
-- Consistent hashing for distributing keys across Redis nodes with virtual nodes for balance.
-- Failover strategy: circuit breaker on cache reads, fall back to database with rate limiting.
-- Capacity estimate: 2M products x average 2KB per cached entry = ~4GB base, with headroom for hot keys and replication.
-- Thundering herd prevention: request coalescing or probabilistic early expiration.
-
----
-
-## Eval 2: Event-Driven Architecture
-
-This eval tests the ability to design an event-driven system with proper delivery semantics, schema management, consumer design, and failure handling for a critical business workflow.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `idempoten` — Idempotent consumer design | At-least-once delivery means consumers will receive duplicates. Without idempotency (deduplication keys, upserts), duplicate processing creates financial and data integrity issues. |
-| 2 | contains | `dead letter` — Failed event handling | Events that cannot be processed after retries must be moved to a dead letter queue for manual inspection. Without this, poison messages block the entire consumer group. |
-| 3 | contains | `partition` — Event partitioning strategy | Partitioning by order ID ensures all events for a single order are processed in sequence while enabling parallel processing across different orders. Wrong partitioning breaks ordering guarantees. |
-| 4 | contains | `schema` — Event schema with versioning | Events are contracts between services. Without versioned schemas, a producer change can silently break all consumers. Schema registry enforces compatibility at publish time. |
-| 5 | contains | `at-least-once` — Explicit delivery guarantee | The design must state the delivery guarantee and explain why exactly-once is not achievable in practice across distributed systems, requiring idempotent consumers as the mitigation. |
-
-### What a passing response looks like
-
-- Kafka or equivalent event streaming platform with topics per business domain (orders, payments, inventory, shipping).
-- Partitioning by order ID for ordering guarantees within a single order flow.
-- At-least-once delivery with idempotent consumers using a processed-event deduplication table.
-- Event schemas defined in Avro or Protobuf with a schema registry enforcing backward compatibility.
-- Dead letter topic per consumer group with alerting on DLQ depth.
-- Consumer group configuration with appropriate parallelism (partitions >= consumers).
-- Retention policy enabling replay for debugging (7-30 days).
-- Back-of-envelope: 10K orders/min x 5 events/order = 50K events/min, sizing for 3x headroom.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/system-design/evals/evals.json

@@ -1,68 +0,0 @@
-{
-  "evals": [
-    {
-      "name": "distributed-cache-design",
-      "description": "Validate that the skill produces a distributed caching architecture with proper invalidation strategy, consistency model, failure handling, and capacity planning for a high-traffic read-heavy application.",
-      "input": "Design a distributed caching layer for an e-commerce product catalog that serves 50,000 read QPS with a 99th percentile latency target of 10ms. The catalog has 2 million products updated by merchants approximately 500 times per minute. Design the caching architecture including cache topology, invalidation strategy, consistency model, failure handling, and capacity estimates.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "cache-aside",
-          "description": "The design must identify and justify the caching pattern (cache-aside, write-through, or write-behind) based on the read-heavy access pattern and consistency requirements."
-        },
-        {
-          "type": "contains",
-          "value": "TTL",
-          "description": "The design must specify a TTL-based expiration policy with concrete duration values tied to the acceptable staleness window for product catalog data."
-        },
-        {
-          "type": "contains",
-          "value": "invalidat",
-          "description": "The design must include an active cache invalidation strategy (event-driven, pub/sub, or direct invalidation) to handle the 500 updates per minute without relying solely on TTL expiry."
-        },
-        {
-          "type": "contains",
-          "value": "failover",
-          "description": "The design must address cache failure scenarios with a fallback strategy (database direct read, local cache, or degraded response) to maintain availability when the cache layer is unavailable."
-        },
-        {
-          "type": "contains",
-          "value": "consistent hashing",
-          "description": "The design must use consistent hashing or a similar partitioning strategy for distributing cache keys across nodes so that node additions or removals minimize cache misses."
-        }
-      ]
-    },
-    {
-      "name": "event-driven-architecture",
-      "description": "Validate that the skill produces an event-driven architecture with proper event schema design, delivery guarantees, ordering, consumer group management, and dead letter handling for an order processing system.",
-      "input": "Design an event-driven architecture for an order processing system that handles order placement, payment processing, inventory reservation, shipping coordination, and notification delivery. The system must guarantee that no order is lost, handle out-of-order events, support replay for debugging, and scale to 10,000 orders per minute at peak. Include event schema design, topic structure, consumer group configuration, and dead letter queue handling.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "idempoten",
-          "description": "The design must address idempotency in event consumers so that duplicate message delivery (inherent in at-least-once systems) does not cause duplicate side effects."
-        },
-        {
-          "type": "contains",
-          "value": "dead letter",
-          "description": "The design must include a dead letter queue or topic for events that fail processing after retries so that poison messages do not block the consumer pipeline."
-        },
-        {
-          "type": "contains",
-          "value": "partition",
-          "description": "The design must specify a partitioning strategy (e.g., by order ID) to maintain event ordering within a single order while enabling parallel processing across orders."
-        },
-        {
-          "type": "contains",
-          "value": "schema",
-          "description": "The design must define event schemas with versioning (Avro, JSON Schema, or Protobuf) so that producers and consumers can evolve independently without breaking contracts."
-        },
-        {
-          "type": "contains",
-          "value": "at-least-once",
-          "description": "The design must explicitly state the delivery guarantee (at-least-once with idempotent consumers) and explain why exactly-once is impractical in a distributed system."
-        }
-      ]
-    }
-  ]
-}

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/systematic-debugging/evals/assertions.md

@@ -1,44 +0,0 @@
-# Systematic Debugging -- Eval Assertions
-
-## Eval 001: Root Cause Analysis for Intermittent Null Pointer
-
-| # | Assertion Type | Value | Rationale |
-|---|---------------|-------|-----------|
-| 1 | contains | `reproduce` | The response must start by establishing reliable reproduction steps under load, since intermittent bugs cannot be verified as fixed without consistent reproduction. |
-| 2 | contains | `hypothesis` | The response must form a specific, falsifiable hypothesis (e.g., race condition in cache initialization) rather than making random changes. |
-| 3 | contains | `why` | The response must apply the Five Whys or equivalent root cause analysis to go beyond the symptom (null return) to the systemic cause. |
-| 4 | contains | `thread` | The response must investigate thread safety and concurrent access as a primary suspect, given the "only under load" trigger condition. |
-| 5 | contains | `regression test` | The response must recommend a regression test that verifies the fix under concurrent conditions to prevent recurrence. |
-
-### What a Passing Response Looks Like
-
-A passing response conducts a structured investigation that:
-- Establishes reproduction by generating 100+ concurrent requests to the endpoint.
-- Forms a hypothesis about why `ConcurrentHashMap.get()` returns null under load (e.g., cache is being cleared and repopulated, or a race condition during initialization).
-- Applies the Five Whys: null return -> cache miss -> cache was cleared -> background refresh job -> no synchronization on refresh.
-- Recommends adding strategic logging at cache read/write points.
-- Proposes a fix (e.g., copy-on-write pattern, read-write lock) with a concurrent regression test.
-- Suggests checking for similar unsynchronized shared state elsewhere in the codebase.
-
----
-
-## Eval 002: Systematic Bisection for Deployment Regression
-
-| # | Assertion Type | Value | Rationale |
-|---|---------------|-------|-----------|
-| 1 | contains | `bisect` | The response must recommend git bisect or equivalent binary search to efficiently narrow 47 commits to the responsible one. |
-| 2 | contains | `good` | The response must define clear good/bad criteria based on measurable response time (e.g., good = <200ms, bad = >500ms). |
-| 3 | contains | `skip` | The response must address how to handle untestable commits (e.g., migration-only commits) using git bisect skip or manual workarounds. |
-| 4 | contains | `log` | The response must reference logarithmic efficiency (log2(47) ~ 6 steps) or suggest using logging/measurement to evaluate each step. |
-| 5 | contains | `automat` | The response must recommend automating the bisection with a test script for consistent, reproducible evaluation at each step. |
-
-### What a Passing Response Looks Like
-
-A passing response designs a bisection strategy that:
-- Uses `git bisect start` with the bad commit (v2.4.0) and good commit (v2.3.0 or last known good).
-- Defines good/bad criteria: response time under 200ms = good, over 500ms = bad.
-- Creates an automated test script that measures p95 latency and exits with 0 (good) or 1 (bad).
-- Handles untestable commits (e.g., partial migrations) with `git bisect skip`.
-- Estimates ~6 steps to find the culprit (log2(47)).
-- Recommends running the benchmark multiple times at each step to avoid noise.
-- After finding the commit, performs root cause analysis on the specific change.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/systematic-debugging/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "systematic-debugging-eval-001",
-    "name": "Root cause analysis for intermittent null pointer",
-    "description": "Evaluate the skill's ability to conduct a structured root cause analysis for an intermittent NullPointerException in a multi-threaded service, applying the Five Whys and evidence-based investigation.",
-    "prompt": "Our user-service throws a NullPointerException about 5% of the time when handling GET /api/users/:id requests. It only happens under load (>100 concurrent requests). The stack trace points to UserCache.get() returning null. The cache is a ConcurrentHashMap populated on startup. Walk me through a systematic debugging process to find the root cause.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "reproduce",
-        "description": "Should start by establishing reliable reproduction steps under load conditions"
-      },
-      {
-        "type": "contains",
-        "value": "hypothesis",
-        "description": "Should form a specific, falsifiable hypothesis about the cause (e.g., race condition, cache eviction)"
-      },
-      {
-        "type": "contains",
-        "value": "why",
-        "description": "Should apply the Five Whys or equivalent root cause analysis technique"
-      },
-      {
-        "type": "contains",
-        "value": "thread",
-        "description": "Should investigate thread safety and concurrent access patterns as a likely root cause"
-      },
-      {
-        "type": "contains",
-        "value": "regression test",
-        "description": "Should recommend a regression test that verifies the fix under concurrent conditions"
-      }
-    ]
-  },
-  {
-    "id": "systematic-debugging-eval-002",
-    "name": "Systematic bisection for deployment regression",
-    "description": "Evaluate the skill's ability to apply systematic bisection (git bisect or equivalent) to identify the exact commit that introduced a performance regression after a release.",
-    "prompt": "After deploying version 2.4.0 (containing 47 commits), our API response time jumped from 150ms to 800ms. We need to find the responsible commit. Design a systematic bisection strategy. The commits span database changes, new middleware, dependency updates, and feature code. Show the bisection process, how to define good/bad criteria, and how to handle commits that can't be tested in isolation.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "bisect",
-        "description": "Should recommend git bisect or equivalent binary search strategy to narrow from 47 commits"
-      },
-      {
-        "type": "contains",
-        "value": "good",
-        "description": "Should define clear good/bad criteria based on measurable response time threshold"
-      },
-      {
-        "type": "contains",
-        "value": "skip",
-        "description": "Should address how to handle untestable commits (git bisect skip or manual workaround)"
-      },
-      {
-        "type": "contains",
-        "value": "log",
-        "description": "Should suggest using logarithmic narrowing (O(log n) steps) for efficiency"
-      },
-      {
-        "type": "contains",
-        "value": "automat",
-        "description": "Should recommend automating the bisection with a test script for consistent evaluation"
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/t3-stack/SKILL.md

@@ -1,82 +0,0 @@
----
-name: t3-stack
-description: "Use when building or maintaining T3 Stack apps with Next.js App Router, tRPC, Prisma, NextAuth.js, Tailwind CSS, and end-to-end type safety."
-allowed-tools: Read Grep Glob Bash Edit Write
-user-invocable: true
-argument-hint: "T3 Stack component, tRPC router, or configuration"
----
-
-# T3 Stack
-
-## Purpose
-
-Guide the design and implementation of production-grade full-stack TypeScript applications using the T3 Stack (Next.js + tRPC + Prisma + NextAuth.js + Tailwind CSS). Every instruction prioritizes end-to-end type safety, minimal client-side JavaScript, and secure-by-default session management.
-
-## When to Use
-
-- Scaffolding a new T3 Stack project or adding features to an existing one.
-- Designing tRPC routers, procedures, and middleware chains.
-- Writing Prisma schemas, queries, or migrations for a T3 application.
-- Configuring NextAuth.js providers, callbacks, and session strategies.
-- Connecting server components to tRPC queries with type-safe data fetching.
-- Reviewing T3 Stack code for type holes, security gaps, or performance regressions.
-
-## Instructions
-
-1. **Confirm the runtime stack before writing code** because T3 projects vary across Next.js versions (Pages Router vs. App Router), tRPC versions (v10 vs. v11), and Prisma versions (v5 vs. v6). Mismatched assumptions cause subtle type errors.
-
-2. **Initialize tRPC with a root router and typed caller** so that every procedure inherits shared context (session, database client) and the front end gets full autocompletion without manual type imports.
-
-3. **Define Prisma models before writing tRPC procedures** because the schema is the single source of truth for database shape, and tRPC input/output types should derive from or validate against it.
-
-4. **Use Zod schemas for every tRPC input and output** because runtime validation at the API boundary catches malformed data that TypeScript alone cannot enforce at runtime.
-
-5. **Create reusable tRPC middleware for authentication and authorization** so that protected procedures declare their requirements declaratively rather than scattering session checks across every handler.
-
-6. **Wire NextAuth.js session into the tRPC context** so that every procedure has access to the authenticated user without redundant session lookups or prop drilling.
-
-7. **Prefer server-side tRPC callers in React Server Components** because calling tRPC on the server avoids a network round-trip, keeps secrets off the client, and feeds data directly into the RSC render tree.
-
-8. **Use `@tanstack/react-query` integration for client components only** because client-side cache, optimistic updates, and mutations require a query client that does not exist in server components.
-
-9. **Keep Prisma client as a singleton** by instantiating it once in a `db.ts` module with a global cache guard, because Next.js hot-reload in development creates many Prisma Client instances that exhaust database connections.
-
-10. **Apply Tailwind CSS with utility-first composition and `cn()` helper** because consistent styling requires a merge strategy that handles conditional classes and avoids specificity conflicts.
-
-11. **Write integration tests that exercise the full tRPC-to-Prisma path** because unit-testing procedures in isolation misses query bugs, middleware ordering issues, and session edge cases.
-
-12. **Configure environment variables with `@t3-oss/env-nextjs`** so that missing or mistyped environment variables fail at build time rather than silently producing undefined values at runtime.
-
-13. **Separate public and protected routers explicitly** because a single misconfigured middleware chain can expose private data, and explicit separation makes the boundary auditable.
-
-14. **Handle tRPC errors with structured error codes and messages** so that the client can display meaningful feedback and retry logic can distinguish transient failures from permanent ones.
-
-15. **Use Prisma transactions for multi-step mutations** because partial writes without a transaction leave the database in an inconsistent state when any step fails.
-
-16. **Deploy with connection pooling (PgBouncer or Prisma Accelerate)** because serverless environments create a new database connection per invocation, quickly exhausting the connection limit.
-
-## Output Format
-
-Provide implementation code, schema definitions, configuration snippets, and architectural guidance as appropriate. Include file paths relative to the project root. When generating tRPC routers, always show the Zod input schema alongside the procedure.
-
-## References
-
-| File                              | Load when                                                                                     |
-| --------------------------------- | --------------------------------------------------------------------------------------------- |
-| `references/trpc-patterns.md`    | Designing tRPC routers, procedures, middleware, error handling, or server-side callers.       |
-| `references/prisma-t3-patterns.md` | Writing Prisma schemas, queries, relations, or configuring the singleton client in T3.     |
-| `references/auth-strategies.md`  | Configuring NextAuth.js providers, callbacks, session strategies, or wiring auth into tRPC.  |
-
-## Examples
-
-- "Set up a new T3 Stack project with Google OAuth and a Prisma PostgreSQL schema."
-- "Add a tRPC router for CRUD operations on a blog post model with auth middleware."
-- "Review my T3 Stack app for type safety gaps between tRPC and Prisma."
-
-## Claude Platform Notes
-
-- Use `$ARGUMENTS` to access user-provided arguments passed when the skill is invoked.
-- Reference skill-local files with `${CLAUDE_SKILL_DIR}/references/<file>` for portable paths.
-- When `context: fork` is set, the skill runs in an isolated subagent context; the `agent` field names the fork target.
-- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available for dynamic skill discovery and loading.
-- Use `allowed-tools` in frontmatter to restrict tool access for security-sensitive skills.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/t3-stack/evals/assertions.md

@@ -1,48 +0,0 @@
-# T3 Stack Eval Assertions
-
-## Eval 1: tRPC Router with Prisma Queries
-
-This eval tests the core T3 Stack workflow: building a tRPC router backed by Prisma with proper authentication middleware.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `z.object` — Zod schema usage                  | Runtime validation at the tRPC boundary is non-negotiable. TypeScript types vanish at runtime.       |
-| 2 | contains | `protectedProcedure` — Auth middleware          | Mutations that modify data must require authentication. Using publicProcedure here is a security bug.|
-| 3 | contains | `prisma` — Prisma client usage                  | The T3 Stack convention is Prisma for all database access. Raw SQL or other ORMs break type safety.  |
-| 4 | contains | `TRPCError` — Structured error handling         | Generic throws produce unhelpful client errors. TRPCError codes enable proper client-side handling.  |
-| 5 | contains | `ctx.session` — Session context access           | The session must flow through tRPC context, not be fetched inside each procedure independently.      |
-
-### What a passing response looks like
-
-- A `projectRouter` with five procedures (list, getById, create, update, delete).
-- Zod schemas for inputs with proper field types (string, number, optional).
-- `publicProcedure` for read operations, `protectedProcedure` for writes.
-- Prisma queries using `findMany` with pagination, `findUnique`, `create`, `update`, `delete`.
-- `TRPCError` thrown for not-found and unauthorized cases with descriptive messages.
-- `ctx.session.user.id` used to scope queries to the authenticated user.
-
----
-
-## Eval 2: NextAuth Session with tRPC Context
-
-This eval tests the authentication integration layer: NextAuth.js configuration wired into the tRPC context.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `PrismaAdapter` — Database-backed auth          | Persisting auth state in the database (not just JWTs) enables account linking and session management.|
-| 2 | contains | `GoogleProvider` — OAuth provider setup          | The eval specifically requests Google OAuth. Must configure with env vars, not hardcoded secrets.    |
-| 3 | contains | `getServerSession` — Server-side session fetch   | tRPC context must fetch the session server-side for security and performance.                        |
-| 4 | contains | `callbacks` — Session/JWT callbacks              | Without callbacks, the session object lacks the user ID needed by tRPC procedures.                   |
-| 5 | contains | `NEXTAUTH_SECRET` — Secure secret reference      | Hardcoded secrets are a critical vulnerability. Must reference environment variables.                 |
-
-### What a passing response looks like
-
-- An `authOptions` object with `PrismaAdapter`, Google and GitHub providers, and session/JWT callbacks.
-- A `createTRPCContext` function that calls `getServerSession(authOptions)` and passes the session to context.
-- A `protectedProcedure` middleware that checks `ctx.session` and throws `UNAUTHORIZED` if missing.
-- A sample procedure that accesses `ctx.session.user.id` to return the user profile from Prisma.
-- Environment variable references for `GOOGLE_CLIENT_ID`, `GOOGLE_CLIENT_SECRET`, `NEXTAUTH_SECRET`.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/t3-stack/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "trpc-router-with-prisma-queries",
-    "description": "Validate that the skill produces a tRPC router with Prisma queries that follows T3 Stack conventions: Zod input validation, singleton Prisma client, proper error handling, and end-to-end type safety.",
-    "input": "Create a tRPC router for a 'projects' resource in a T3 Stack app. The Prisma model has id, name, description, ownerId, createdAt, and updatedAt fields. Include list (paginated), getById, create, update, and delete procedures. The create, update, and delete procedures should require authentication.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "z.object",
-        "description": "Every procedure input must use Zod schema validation to enforce runtime type safety at the API boundary."
-      },
-      {
-        "type": "contains",
-        "value": "protectedProcedure",
-        "description": "Mutation procedures (create, update, delete) must use protectedProcedure middleware to enforce authentication."
-      },
-      {
-        "type": "contains",
-        "value": "prisma",
-        "description": "Procedures must use the Prisma client for database operations rather than raw SQL or other ORMs."
-      },
-      {
-        "type": "contains",
-        "value": "TRPCError",
-        "description": "Error handling must use structured TRPCError with appropriate error codes (NOT_FOUND, UNAUTHORIZED, etc.)."
-      },
-      {
-        "type": "contains",
-        "value": "ctx.session",
-        "description": "Protected procedures must access the authenticated user through ctx.session, which is wired from NextAuth.js into the tRPC context."
-      }
-    ]
-  },
-  {
-    "name": "nextauth-session-with-trpc-context",
-    "description": "Validate that the skill correctly configures NextAuth.js session handling and wires it into the tRPC context for a T3 Stack application.",
-    "input": "Configure NextAuth.js with GitHub and Google OAuth providers for a T3 Stack app. Wire the session into the tRPC context so that protected procedures can access the user. Include the Prisma adapter for persisting accounts and sessions. Show the auth configuration, tRPC context creation, and a protected procedure that returns the current user's profile.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "PrismaAdapter",
-        "description": "NextAuth.js must use the Prisma adapter to persist user accounts, sessions, and verification tokens in the database."
-      },
-      {
-        "type": "contains",
-        "value": "GoogleProvider",
-        "description": "The auth configuration must include Google OAuth provider setup with client ID and secret from environment variables."
-      },
-      {
-        "type": "contains",
-        "value": "getServerSession",
-        "description": "The tRPC context must retrieve the session using getServerSession (or getServerAuthSession) so that procedures have access to the authenticated user."
-      },
-      {
-        "type": "contains",
-        "value": "callbacks",
-        "description": "NextAuth.js must configure session and JWT callbacks to include user ID in the session object for downstream use in tRPC procedures."
-      },
-      {
-        "type": "contains",
-        "value": "NEXTAUTH_SECRET",
-        "description": "The configuration must reference NEXTAUTH_SECRET environment variable for secure token signing, never a hardcoded value."
-      }
-    ]
-  }
-]