@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/database-design/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "normalized-schema-design",
-    "description": "Validate that the skill produces a properly normalized relational schema with appropriate constraints, key selection, and relationship modeling for a multi-entity domain.",
-    "input": "Design a database schema for an e-commerce platform. The domain includes: users (with profiles and addresses), products (with categories and inventory), orders (with line items and payment status), and reviews (tied to both users and products). Users can have multiple shipping addresses. Products belong to multiple categories. Orders contain multiple line items referencing products. Design the schema in PostgreSQL DDL with proper normalization, constraints, and relationships.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "REFERENCES",
-        "description": "Foreign key constraints must be declared explicitly to enforce referential integrity between entities (users-orders, orders-line_items, products-reviews)."
-      },
-      {
-        "type": "contains",
-        "value": "NOT NULL",
-        "description": "Required columns must have NOT NULL constraints to prevent incomplete records from being inserted at the database level."
-      },
-      {
-        "type": "contains",
-        "value": "UNIQUE",
-        "description": "Natural uniqueness constraints (such as email on users or composite keys on junction tables) must be enforced to prevent duplicate data."
-      },
-      {
-        "type": "contains",
-        "value": "CREATE TABLE",
-        "description": "The schema must be expressed as executable PostgreSQL DDL statements, not just prose descriptions of tables."
-      },
-      {
-        "type": "contains",
-        "value": "PRIMARY KEY",
-        "description": "Every table must have an explicit primary key declaration to ensure row uniqueness and enable efficient joins."
-      }
-    ]
-  },
-  {
-    "name": "index-optimization-strategy",
-    "description": "Validate that the skill produces an indexing strategy grounded in specific query patterns with composite index column ordering, covering indexes, and partial indexes where appropriate.",
-    "input": "Given a PostgreSQL orders table with columns (id, user_id, status, created_at, total_amount, shipping_address_id) and these query patterns: (1) fetch all orders for a user sorted by creation date descending, (2) count orders by status for a dashboard, (3) find orders above $100 created in the last 30 days, (4) look up orders by user and status together. Design an indexing strategy with CREATE INDEX statements and explain why each index serves its target query.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "CREATE INDEX",
-        "description": "Index definitions must be expressed as executable CREATE INDEX statements, not just recommendations in prose."
-      },
-      {
-        "type": "contains",
-        "value": "user_id",
-        "description": "An index on user_id must be present because multiple query patterns filter or join on user_id, making it the highest-value single-column index."
-      },
-      {
-        "type": "contains",
-        "value": "status",
-        "description": "The status column must appear in at least one index because the dashboard query groups by status and the lookup query filters by user and status together."
-      },
-      {
-        "type": "contains",
-        "value": "created_at",
-        "description": "The created_at column must be indexed (alone or in a composite) because queries sort by creation date and filter by date range."
-      },
-      {
-        "type": "contains",
-        "value": "WHERE",
-        "description": "At least one partial index or query explanation must reference WHERE clauses to demonstrate that indexes are designed for specific predicate patterns, not added blindly."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/deep-research/evals/assertions.md

@@ -1,17 +0,0 @@
-# Deep Research Eval Assertions
-
-## Eval 1: Latest Capability Verification
-
-1. **repo-first** — Starts by checking repo or local evidence before jumping to web claims.
-2. **official-first** — Uses official docs or upstream sources as the primary evidence for the capability.
-3. **secondary-labeled** — If community sources are mentioned, labels them as secondary evidence instead of presenting them as authoritative.
-4. **gaps-called-out** — Identifies unresolved uncertainty or missing confirmation.
-5. **next-route** — Ends with a concrete recommended workflow, agent, or skill to use next.
-
-## Eval 2: Tool Comparison
-
-1. **comparison-frame** — Defines the comparison axes instead of producing vague preferences.
-2. **repo-impact** — Connects the comparison back to the current repo or implementation constraints.
-3. **fact-vs-inference** — Separates verified facts from inference or interpretation.
-4. **decision-oriented** — Produces a recommendation or explicit defer condition.
-5. **no-research-sprawl** — Keeps the output concise and structured rather than dumping raw links.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/deep-research/evals/evals.json

@@ -1,56 +0,0 @@
-[
-  {
-    "name": "latest-capability-verification",
-    "description": "Validate that the skill performs repo-first research, prioritizes official documentation, labels secondary evidence, and recommends a next route.",
-    "prompt": "Research whether the latest official Claude Code hook surface supports reinforcing route honoring before implementation. Start with the current repo state, then use official docs if needed. If community sources add useful practical context, include them but label them appropriately. End with the next workflow, agent, or skill we should use.",
-    "assertions": [
-      {
-        "id": "repo-first",
-        "description": "Starts with repo or local evidence before using external sources."
-      },
-      {
-        "id": "official-first",
-        "description": "Treats official docs or upstream sources as the primary evidence."
-      },
-      {
-        "id": "secondary-labeled",
-        "description": "Labels any Reddit or community evidence as secondary rather than authoritative."
-      },
-      {
-        "id": "gaps-called-out",
-        "description": "States any unresolved gaps, conflicts, or unknowns."
-      },
-      {
-        "id": "next-route",
-        "description": "Ends with a concrete recommended next route."
-      }
-    ]
-  },
-  {
-    "name": "tool-comparison",
-    "description": "Validate that the skill compares options with a clear frame, ties findings back to repo impact, and produces a decision-ready output.",
-    "prompt": "Compare whether our CLI should keep enforcement in Gemini command wrappers only or also add Claude hook templates. Use the repo state first, then official docs for current platform capabilities, and include community evidence only if it adds implementation nuance. Finish with a recommendation and the next route to take.",
-    "assertions": [
-      {
-        "id": "comparison-frame",
-        "description": "Defines concrete comparison axes such as repo impact, enforcement surface, and maintenance cost."
-      },
-      {
-        "id": "repo-impact",
-        "description": "Connects each option back to the current repo or bundle behavior."
-      },
-      {
-        "id": "fact-vs-inference",
-        "description": "Separates verified facts from inference or interpretation."
-      },
-      {
-        "id": "decision-oriented",
-        "description": "Produces a recommendation or explicit defer condition."
-      },
-      {
-        "id": "no-research-sprawl",
-        "description": "Keeps the answer structured instead of turning into an unfiltered dump of sources."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/django-drf/evals/assertions.md

@@ -1,21 +0,0 @@
-# Django DRF Skill Assertions
-
-## Eval 1: ViewSet with Nested Serializers
-
-| # | Assertion | Type | Expected Value | Rationale |
-|---|-----------|------|----------------|-----------|
-| 1 | Uses ModelSerializer | contains | `ModelSerializer` | ModelSerializer auto-generates fields and validators from the Django model, reducing boilerplate and drift. |
-| 2 | Uses select_related | contains | `select_related` | ForeignKey traversals without select_related cause one query per row, degrading response time linearly. |
-| 3 | Uses prefetch_related | contains | `prefetch_related` | Reverse and many-to-many relationships require prefetch_related to batch into a single query. |
-| 4 | Uses ModelViewSet | contains | `ModelViewSet` | ModelViewSet provides the full CRUD action set with consistent method routing and permission integration. |
-| 5 | Registers with router | contains | `router.register` | Router registration generates URL patterns automatically, ensuring consistency and reducing routing errors. |
-
-## Eval 2: Custom Permission Class
-
-| # | Assertion | Type | Expected Value | Rationale |
-|---|-----------|------|----------------|-----------|
-| 1 | Extends BasePermission | contains | `BasePermission` | All custom DRF permissions must extend BasePermission to integrate with the framework's permission pipeline. |
-| 2 | Implements has_object_permission | contains | `has_object_permission` | Object-level authorization requires this method; has_permission alone only checks view-level access. |
-| 3 | Overrides get_queryset | contains | `get_queryset` | Queryset scoping is the first line of defense; it prevents unauthorized objects from being visible at all. |
-| 4 | Uses APITestCase | contains | `APITestCase` | APITestCase provides DRF-specific assertions and an APIClient that handles content negotiation correctly. |
-| 5 | Sets permission_classes | contains | `permission_classes` | The ViewSet must declare permission_classes to wire in the custom permission; DRF does not auto-discover permissions. |

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/django-drf/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "viewset-with-nested-serializers",
-    "description": "Validate that the skill produces a correct DRF ViewSet with nested serializers, eager loading, and proper router registration.",
-    "prompt": "Create a Django REST Framework API for a BlogPost model that belongs to an Author and has many Comments. Each Comment belongs to a User. Use nested serializers to return the author name, post content, and comments with commenter username and text. Include the ViewSet, serializers, router registration, and queryset optimization.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "ModelSerializer",
-        "description": "Must use ModelSerializer for automatic field generation and validation."
-      },
-      {
-        "type": "contains",
-        "value": "select_related",
-        "description": "Must use select_related for ForeignKey relationships to prevent N+1 queries."
-      },
-      {
-        "type": "contains",
-        "value": "prefetch_related",
-        "description": "Must use prefetch_related for reverse/many relationships to prevent N+1 queries."
-      },
-      {
-        "type": "contains",
-        "value": "ModelViewSet",
-        "description": "Must use ModelViewSet or appropriate ViewSet mixin for CRUD operations."
-      },
-      {
-        "type": "contains",
-        "value": "router.register",
-        "description": "Must register the ViewSet with a DefaultRouter for consistent URL generation."
-      }
-    ]
-  },
-  {
-    "name": "custom-permission-class",
-    "description": "Validate that the skill produces a custom DRF permission class with object-level checks, proper integration in a ViewSet, and test coverage.",
-    "prompt": "Create a custom DRF permission class called IsOwnerOrReadOnly that allows read access to any authenticated user but restricts write operations to the object owner. Integrate it into a ProjectViewSet where get_queryset scopes by the authenticated user's organization. Include an APITestCase that verifies both allowed and denied access.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "BasePermission",
-        "description": "Must extend BasePermission for custom permission class definition."
-      },
-      {
-        "type": "contains",
-        "value": "has_object_permission",
-        "description": "Must implement has_object_permission for object-level authorization checks."
-      },
-      {
-        "type": "contains",
-        "value": "get_queryset",
-        "description": "Must override get_queryset to scope data by authenticated user or tenant."
-      },
-      {
-        "type": "contains",
-        "value": "APITestCase",
-        "description": "Must include APITestCase for integration testing of permissions."
-      },
-      {
-        "type": "contains",
-        "value": "permission_classes",
-        "description": "Must assign permission_classes on the ViewSet to wire in the custom permission."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/docker-compose-dev/evals/assertions.md

@@ -1,51 +0,0 @@
-# Docker Compose Dev Eval Assertions
-
-## Eval 1: Multi-Service Dev Environment
-
-This eval tests the core Docker Compose skill: designing a multi-service development environment with hot reload, health checks, networking, and optional tooling profiles.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `volumes:` — Bind mount configuration           | Bind mounts map host source code into containers, enabling hot reload. Without them, every code change requires a full container rebuild. |
-| 2 | contains | `healthcheck:` — Service health checks          | Health checks for PostgreSQL and Redis ensure dependent services wait for actual readiness, not just port availability. Race conditions cause intermittent startup failures. |
-| 3 | contains | `networks:` — Custom network definition         | Custom networks enable service-to-service communication by name via Docker DNS. Default bridge networking requires hardcoded IPs that break across environments. |
-| 4 | contains | `profiles:` — Compose profile usage             | Profiles let developers opt into optional services (pgAdmin) without starting them by default. This saves resources and reduces startup time for daily development. |
-| 5 | contains | `depends_on:` — Service dependency ordering     | `depends_on` with health check conditions prevents application containers from starting before their database and cache dependencies are ready. |
-
-### What a passing response looks like
-
-- A `docker-compose.yml` with four always-on services: `frontend`, `backend`, `postgres`, `redis`.
-- Bind mount volumes mapping `./frontend` to the Next.js container and `./backend` to the FastAPI container.
-- PostgreSQL health check using `pg_isready` and Redis health check using `redis-cli ping`.
-- A custom network (`app-network`) attached to all services.
-- `depends_on` with `condition: service_healthy` for frontend and backend depending on postgres and redis.
-- pgAdmin service with `profiles: ["tools"]` so it only starts with `docker compose --profile tools up`.
-- Port mappings: 3000 for frontend, 8000 for backend, 5432 for PostgreSQL.
-
----
-
-## Eval 2: Production-Parity Configuration
-
-This eval tests the advanced Docker Compose skill: minimizing dev/prod drift with multi-stage builds, resource constraints, debugger support, and CI validation.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `AS dev` — Named build stage for development    | Multi-stage Dockerfiles with named stages let Compose target the dev stage (with debugger, dev deps) while production uses the final stage. One Dockerfile, two purposes. |
-| 2 | contains | `mem_limit` — Memory resource constraint        | Matching production memory limits in dev catches OOM behaviors during development instead of discovering them after deployment to resource-constrained pods. |
-| 3 | contains | `2345` — Delve debugger port                    | Exposing the Delve debugger port enables IDE-attached debugging inside containers, preserving the breakpoint-driven workflow developers expect from local development. |
-| 4 | contains | `cache` — BuildKit cache mount                  | Go module cache mounts persist across builds, reducing rebuild time from minutes to seconds when only application code changes. Without caching, every build re-downloads all modules. |
-| 5 | contains | `target:` — Build target selection              | The Compose `build.target` field selects the dev stage from the multi-stage Dockerfile. Without it, Docker builds the final (production) stage, which lacks dev tools. |
-
-### What a passing response looks like
-
-- A multi-stage Dockerfile with `FROM golang:1.22 AS dev` and `FROM gcr.io/distroless/static AS production` stages.
-- Dev stage installs Delve (`go install github.com/go-delve/delve/cmd/dlv@latest`) and runs with `dlv exec`.
-- BuildKit cache mount: `RUN --mount=type=cache,target=/go/pkg/mod go mod download`.
-- Compose file with `build: { context: ., target: dev }` for the API service.
-- `mem_limit: 512m` and `cpus: "0.5"` on the API service matching production Kubernetes limits.
-- Port 2345 exposed for Delve debugger attachment.
-- A CI job example: `docker compose up --wait && docker compose exec api go test ./... && docker compose down`.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/docker-compose-dev/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "multi-service-dev-environment",
-    "description": "Validate that the skill produces a Docker Compose configuration for a multi-service development environment with hot reload, proper networking, health checks, and developer-friendly tooling.",
-    "input": "Create a Docker Compose development environment for a full-stack application with: a Next.js frontend (port 3000), a FastAPI backend (port 8000), a PostgreSQL database, and a Redis cache. Configure hot reload for both the frontend and backend using bind mounts. Add health checks for PostgreSQL and Redis. Use a custom network so services communicate by name. Include a pgAdmin service behind a Compose profile for optional database management.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "volumes:",
-        "description": "The configuration must use bind mount volumes to map host source directories into containers, enabling hot reload without container rebuilds."
-      },
-      {
-        "type": "contains",
-        "value": "healthcheck:",
-        "description": "Database and cache services must define health checks so that dependent services wait for actual readiness, not just container startup."
-      },
-      {
-        "type": "contains",
-        "value": "networks:",
-        "description": "The configuration must define a custom Docker network so services communicate by service name via Docker DNS rather than hardcoded IPs."
-      },
-      {
-        "type": "contains",
-        "value": "profiles:",
-        "description": "Optional services like pgAdmin must be placed behind Compose profiles so they only start when explicitly requested by the developer."
-      },
-      {
-        "type": "contains",
-        "value": "depends_on:",
-        "description": "Application services must declare depends_on with health check conditions to enforce correct startup ordering and prevent race conditions."
-      }
-    ]
-  },
-  {
-    "name": "production-parity-configuration",
-    "description": "Validate that the skill produces a Compose configuration that minimizes dev/prod drift with multi-stage Dockerfiles, resource limits, and CI-testable setup.",
-    "input": "Refactor an existing Docker Compose development setup to improve production parity. The application is a Go API with a PostgreSQL database. Create a multi-stage Dockerfile with separate dev and prod targets. Add resource limits matching the production Kubernetes pod limits (512Mi memory, 0.5 CPU). Configure the dev stage with Delve debugger support on port 2345. Use BuildKit cache mounts for Go module downloads. Add a CI test job that runs 'docker compose up --wait' to verify the configuration works.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "AS dev",
-        "description": "The Dockerfile must use a named 'dev' build stage so Docker Compose can target it specifically for development builds with debugging tools."
-      },
-      {
-        "type": "contains",
-        "value": "mem_limit",
-        "description": "The Compose configuration must set memory limits to match production constraints, ensuring resource-related bugs surface during development."
-      },
-      {
-        "type": "contains",
-        "value": "2345",
-        "description": "The development configuration must expose the Delve debugger port (2345) so developers can attach IDE debuggers to the running Go process."
-      },
-      {
-        "type": "contains",
-        "value": "cache",
-        "description": "The Dockerfile must use BuildKit cache mounts for Go module downloads to speed up rebuilds when only application code changes."
-      },
-      {
-        "type": "contains",
-        "value": "target:",
-        "description": "The Compose build section must specify 'target: dev' to select the development stage of the multi-stage Dockerfile."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/drizzle-orm/SKILL.md

@@ -1,81 +0,0 @@
----
-name: drizzle-orm
-description: "Use when building or refactoring TypeScript data layers with Drizzle ORM: schema-as-code, relational queries, type-safe SQL, drizzle-kit migrations, and edge/serverless deployment patterns."
----
-# Drizzle ORM
-
-## Purpose
-
-Guide developers through production-grade Drizzle ORM usage including TypeScript-first schema definition, relational query building, type-safe SQL composition, drizzle-kit migration workflows, and deployment patterns for edge and serverless runtimes. This skill ensures type-safe, performant, and migration-safe database layers in TypeScript applications.
-
-## When to Use
-
-- Defining or refactoring Drizzle schema files with `pgTable`, `sqliteTable`, or `mysqlTable`.
-- Building relational queries with `db.query.*` API or composing type-safe SQL with `select()`.
-- Creating, reviewing, or troubleshooting drizzle-kit migration workflows.
-- Deploying Drizzle-backed APIs to edge runtimes (Cloudflare Workers, Vercel Edge, Deno Deploy).
-- Migrating from Prisma, TypeORM, or raw SQL to Drizzle ORM.
-- Tuning query performance, connection pooling, or prepared statement strategies.
-
-## Instructions
-
-1. **Confirm the target database engine and runtime before writing schema code** because Drizzle uses engine-specific schema builders (`pgTable`, `sqliteTable`, `mysqlTable`) that produce different SQL dialects, and mixing them causes build-time type errors and runtime failures.
-
-2. **Define all tables in schema files using the TypeScript-first schema API** because Drizzle derives all TypeScript types directly from schema definitions, making `typeof users.$inferSelect` and `typeof users.$inferInsert` the single source of truth for both database and application types, eliminating type drift.
-
-3. **Use `relations()` declarations for every foreign key relationship** because Drizzle's relational query API (`db.query.users.findMany({ with: { posts: true } })`) requires explicit relation definitions to function, and missing relations silently fall back to returning incomplete data.
-
-4. **Prefer the relational query API for reads that involve joins** because it generates optimized SQL with proper JOIN or subquery strategies, provides fully typed nested results, and eliminates the manual mapping layer that raw `select().from().leftJoin()` requires.
-
-5. **Use the SQL-like `select()` API for writes, aggregations, and complex WHERE clauses** because the relational query API is read-optimized and does not support `INSERT`, `UPDATE`, `DELETE`, `GROUP BY`, or subquery composition, which are core to transactional write paths.
-
-6. **Configure `drizzle-kit` with explicit `schema`, `out`, and `dialect` fields** because ambiguous configuration causes migrations to target the wrong tables or generate empty diffs, and dialect mismatch between config and schema silently produces invalid SQL.
-
-7. **Run `drizzle-kit generate` in CI to detect schema-migration drift** because developers frequently modify schema files without generating a migration, and this drift only surfaces during deployment when the database does not match the schema.
-
-8. **Use `drizzle-kit push` only for prototyping and development databases** because push applies schema changes directly without migration files, making production rollback impossible and leaving no audit trail of schema evolution.
-
-9. **Write migration files with both up and down logic when custom SQL is needed** because drizzle-kit auto-generated migrations handle schema additions but frequently miss data transformations, enum modifications, and index strategy changes that require manual intervention.
-
-10. **Scope database connections to the runtime deployment model** because Cloudflare Workers use D1 or Hyperdrive bindings, Vercel Edge uses connection strings with `@vercel/postgres`, and Node.js uses `database-design` or `better-sqlite3`, each requiring different Drizzle driver initialization.
-
-11. **Use `$inferSelect` and `$inferInsert` types instead of manually defining interfaces** because Drizzle derives these types from the schema at compile time, and manual interfaces drift from the schema as columns are added, renamed, or made nullable.
-
-12. **Use `prepared()` statements for hot-path queries** because prepared statements skip the SQL compilation step on repeated execution, reducing latency by 20-40% in high-throughput endpoints, and Drizzle's `.prepare()` method makes this a one-line optimization.
-
-13. **Validate schema changes against the target database before deploying** because Drizzle generates SQL at build time but does not validate against the live schema, so renaming a column that a deployed migration already renamed will produce a duplicate alteration error at runtime.
-
-14. **Separate read-only queries from write operations at the connection level** because read replicas, connection pooling, and edge caching all depend on clean read/write separation that Drizzle supports through multiple `drizzle()` instances.
-
-15. **Test Drizzle queries against the target database engine, not in-memory mocks** because SQLite, Postgres, and MySQL have different type coercion, JSON handling, and constraint enforcement behaviors that mocks cannot reproduce.
-
-16. **Use transactions for multi-table writes with `db.transaction()`** because Drizzle does not auto-wrap related writes in a transaction, and interleaved failures without transactions leave the database in an inconsistent state that is expensive to diagnose and repair.
-
-## Output Format
-
-Provide implementation guidance, code examples, and configuration as appropriate to the task. Include complete schema definitions, query patterns, migration scripts, and drizzle-kit configuration when the task requires them. Use TypeScript with strict mode throughout.
-
-## References
-
-| File | Load when |
-| --- | --- |
-| `references/schema-definition.md` | Defining or refactoring table schemas, column types, constraints, relations, or type inference patterns. |
-| `references/queries.md` | Writing relational queries, SQL-like queries, transactions, prepared statements, or aggregation patterns. |
-| `references/migrations.md` | Creating, reviewing, or troubleshooting drizzle-kit migrations, push vs generate workflow, or migration chain management. |
-
-## 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 design a Drizzle schema for a multi-tenant SaaS with Postgres"
-- "Review my drizzle-kit migration workflow for production safety"
-
-## Gemini Platform Notes
-
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
-- User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/drizzle-orm/evals/assertions.md

@@ -1,52 +0,0 @@
-# Drizzle ORM Eval Assertions
-
-## Eval 1: Schema Definition with Relations
-
-This eval tests the ability to produce a correctly structured Drizzle ORM schema with table definitions, relations, type inference, and indexes for a multi-entity blog platform.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `pgTable` — Correct table builder               | PostgreSQL requires pgTable. Using the wrong dialect builder produces incompatible SQL and type errors at build time. |
-| 2 | contains | `relations` — Relation declarations              | Drizzle's relational query API (db.query.*) requires explicit relation definitions. Without them, nested queries silently return incomplete data. |
-| 3 | contains | `$inferSelect` — Schema-derived types            | Manual TypeScript interfaces drift from the schema as columns change. $inferSelect and $inferInsert are the single source of truth. |
-| 4 | contains | `references` — Foreign key constraints           | Foreign keys enforce referential integrity at the database level. Relations alone only enable the query API — they do not create constraints. |
-| 5 | contains | `pgEnum` — Native PostgreSQL enum                | Post status as pgEnum enforces valid values at the database level and produces a fully typed column in TypeScript, unlike plain varchar. |
-| 6 | contains | `primaryKey` — Junction table composite key      | Many-to-many junction tables without a composite primary key allow duplicate rows, corrupting the relationship. |
-
-### What a passing response looks like
-
-- A `users` table with email, displayName, and role columns.
-- A `posts` table with title, content, and a `pgEnum` status column (draft/published/archived).
-- A `comments` table with foreign keys to posts and users.
-- A `tags` table and a `postsToTags` junction table with a composite primary key.
-- `relations()` declarations for all entities enabling nested queries.
-- `$inferSelect` and `$inferInsert` type exports for at least the main entities.
-- Indexes on foreign key columns (authorId on posts, postId on comments).
-
----
-
-## Eval 2: Migration Workflow
-
-This eval tests the ability to produce a safe drizzle-kit migration workflow including schema changes, migration generation, custom data migration, and deployment steps.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `drizzle-kit` — Migration tool usage             | Drizzle ORM relies on drizzle-kit for migration management. Omitting it means no structured migration workflow. |
-| 2 | contains | `generate` — Migration file generation           | `drizzle-kit generate` creates versioned SQL files. Using `push` instead skips file creation and makes rollback impossible. |
-| 3 | contains | `pgEnum` — Native enum for status column         | Using pgEnum ensures the database rejects invalid status values. A plain varchar with application validation can be bypassed. |
-| 4 | contains | `transaction` — Atomic data migration            | Data migrations that update existing rows must be wrapped in transactions. Partial updates from failed migrations leave data inconsistent. |
-| 5 | contains | `default` — Default value on new column          | Adding a NOT NULL column without a default to a table with existing rows fails. Defaults ensure backward compatibility during migration. |
-
-### What a passing response looks like
-
-- A `drizzle.config.ts` with schema path, output directory, and dialect.
-- Schema changes: new `orgStatusEnum`, new `organizations` table, nullable `organizationId` on users.
-- Command sequence: `drizzle-kit generate` to create the migration file.
-- Generated SQL reviewed (CREATE TYPE, CREATE TABLE, ALTER TABLE ADD COLUMN).
-- A custom data migration script using `db.transaction()` to set all users to "active" status.
-- Command to apply: `drizzle-kit migrate`.
-- No use of `drizzle-kit push` for production.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/drizzle-orm/evals/evals.json

@@ -1,71 +0,0 @@
-[
-  {
-    "name": "drizzle-schema-definition-with-relations",
-    "description": "Validate that the skill produces correct Drizzle schema definitions with proper table builders, column types, relations, type inference, and index declarations for a multi-entity domain.",
-    "input": "Design a Drizzle ORM schema for a blog platform using PostgreSQL. The domain includes: users (email, display name, role), posts (title, content, status as draft/published/archived, author), comments (content, post, author), and tags with a many-to-many relationship to posts. Include type inference, relations, and indexes on foreign keys. Use pgTable and the relational query API conventions.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "pgTable",
-        "description": "Tables must be defined using pgTable since the target is PostgreSQL. Using sqliteTable or mysqlTable would generate incompatible SQL."
-      },
-      {
-        "type": "contains",
-        "value": "relations",
-        "description": "Relation declarations must be present for the relational query API (db.query.*) to function. Missing relations cause incomplete query results."
-      },
-      {
-        "type": "contains",
-        "value": "$inferSelect",
-        "description": "Type inference must use $inferSelect and $inferInsert from the schema rather than manually defined interfaces, preventing type drift."
-      },
-      {
-        "type": "contains",
-        "value": "references",
-        "description": "Foreign key columns must use .references() to create database-level constraints for referential integrity."
-      },
-      {
-        "type": "contains",
-        "value": "pgEnum",
-        "description": "The post status (draft/published/archived) should use pgEnum to leverage PostgreSQL native enums for type safety at both database and TypeScript levels."
-      },
-      {
-        "type": "contains",
-        "value": "primaryKey",
-        "description": "The many-to-many junction table (posts-to-tags) must have a composite primary key to prevent duplicate associations."
-      }
-    ]
-  },
-  {
-    "name": "drizzle-migration-workflow",
-    "description": "Validate that the skill produces a correct drizzle-kit migration workflow including configuration, generation, custom data migration, and deployment safety practices.",
-    "input": "I have an existing Drizzle schema with a users table (id, email, name, created_at). I need to: (1) add a 'status' enum column (active, suspended, deleted) with default 'active', (2) add an 'organization_id' foreign key column that's nullable for now, (3) create the organizations table, and (4) write a data migration to set all existing users to 'active' status. Show the full drizzle-kit workflow: config, schema changes, generate, custom migration, and apply steps.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "drizzle-kit",
-        "description": "The workflow must reference drizzle-kit commands (generate, migrate, or push) since drizzle-kit is the migration tool for Drizzle ORM."
-      },
-      {
-        "type": "contains",
-        "value": "generate",
-        "description": "The workflow must use drizzle-kit generate (not push) to create migration files, since push is unsafe for production databases."
-      },
-      {
-        "type": "contains",
-        "value": "pgEnum",
-        "description": "The status column must be defined as a pgEnum to leverage PostgreSQL native enums rather than plain varchar, ensuring database-level validation."
-      },
-      {
-        "type": "contains",
-        "value": "transaction",
-        "description": "The data migration must be wrapped in a transaction to ensure atomicity — partial backfills leave the database in an inconsistent state."
-      },
-      {
-        "type": "contains",
-        "value": "default",
-        "description": "The new status column must have a default value ('active') so that existing rows and future inserts without explicit status are handled correctly."
-      }
-    ]
-  }
-]