@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/playwright-persistent-browser/references/state-management.md

@@ -1,268 +0,0 @@
-# State Management
-
-Load this reference when choosing persistence strategies, serializing browser state, or restoring sessions from saved data.
-
-## State Layers
-
-Browsers store state at multiple layers. Understanding which layer holds your session data determines the persistence strategy.
-
-| Layer | Scope | Persistence API | Typical content |
-| --- | --- | --- | --- |
-| Cookies | Origin + path | `storageState()` | Session IDs, auth tokens, preferences |
-| localStorage | Origin | `storageState()` | User settings, cached data, feature flags |
-| sessionStorage | Origin + tab | Manual extraction | Temporary form data, wizard state |
-| IndexedDB | Origin | Manual extraction | Large datasets, offline cache |
-| Cache API | Origin | Not extractable | HTTP response cache, service worker cache |
-| HTTP cache | Origin | Not extractable | Cached assets (images, scripts, styles) |
-
-## storageState — The Standard Approach
-
-Playwright's `storageState()` captures cookies and localStorage in a single JSON structure.
-
-### Saving state
-
-```typescript
-// Save after authentication
-await context.storageState({ path: 'auth-state.json' });
-```
-
-### Restoring state
-
-```typescript
-// Create a new context with saved state
-const context = await browser.newContext({
-  storageState: 'auth-state.json',
-});
-```
-
-### What storageState captures
-
-```json
-{
-  "cookies": [
-    {
-      "name": "session",
-      "value": "abc123",
-      "domain": ".example.com",
-      "path": "/",
-      "expires": 1710000000,
-      "httpOnly": true,
-      "secure": true,
-      "sameSite": "Lax"
-    }
-  ],
-  "origins": [
-    {
-      "origin": "https://example.com",
-      "localStorage": [
-        { "name": "theme", "value": "dark" },
-        { "name": "locale", "value": "en-US" }
-      ]
-    }
-  ]
-}
-```
-
-### What storageState does NOT capture
-
-- sessionStorage (tab-scoped, not context-scoped)
-- IndexedDB data
-- Cache API entries
-- Service worker registrations
-- HTTP cache
-- Browser extension state
-
-## sessionStorage Extraction
-
-sessionStorage is scoped to a single tab and is lost when the tab closes. To persist it:
-
-```typescript
-// Extract sessionStorage from a specific page
-const sessionData = await page.evaluate(() => {
-  const data: Record<string, string> = {};
-  for (let i = 0; i < sessionStorage.length; i++) {
-    const key = sessionStorage.key(i)!;
-    data[key] = sessionStorage.getItem(key)!;
-  }
-  return data;
-});
-
-// Save to file
-fs.writeFileSync('session-storage.json', JSON.stringify(sessionData));
-```
-
-```typescript
-// Restore sessionStorage in a new page
-const sessionData = JSON.parse(fs.readFileSync('session-storage.json', 'utf-8'));
-
-await page.addInitScript((data) => {
-  for (const [key, value] of Object.entries(data)) {
-    sessionStorage.setItem(key, value as string);
-  }
-}, sessionData);
-
-await page.goto('https://example.com');
-```
-
-## IndexedDB Extraction
-
-For applications that store significant data in IndexedDB (offline-first apps, PWAs):
-
-```typescript
-// Extract IndexedDB data
-const idbData = await page.evaluate(async () => {
-  const dbNames = await indexedDB.databases();
-  const result: Record<string, any> = {};
-
-  for (const { name } of dbNames) {
-    if (!name) continue;
-    const db = await new Promise<IDBDatabase>((resolve, reject) => {
-      const req = indexedDB.open(name);
-      req.onsuccess = () => resolve(req.result);
-      req.onerror = () => reject(req.error);
-    });
-
-    const stores: Record<string, any[]> = {};
-    for (const storeName of db.objectStoreNames) {
-      const tx = db.transaction(storeName, 'readonly');
-      const store = tx.objectStore(storeName);
-      stores[storeName] = await new Promise((resolve, reject) => {
-        const req = store.getAll();
-        req.onsuccess = () => resolve(req.result);
-        req.onerror = () => reject(req.error);
-      });
-    }
-
-    result[name] = stores;
-    db.close();
-  }
-
-  return result;
-});
-```
-
-## State Validation
-
-Restored state may be invalid (expired tokens, revoked sessions, schema changes). Always validate before using.
-
-### Validation patterns
-
-```typescript
-async function isSessionValid(page: Page): Promise<boolean> {
-  // Pattern 1: Check a protected endpoint
-  const response = await page.goto('https://app.com/api/me');
-  if (!response || response.status() === 401) return false;
-
-  // Pattern 2: Check for login redirect
-  await page.goto('https://app.com/dashboard');
-  if (page.url().includes('/login')) return false;
-
-  // Pattern 3: Check for a logged-in UI element
-  const logoutButton = page.getByRole('button', { name: /log out/i });
-  return await logoutButton.isVisible({ timeout: 3000 }).catch(() => false);
-}
-```
-
-### State freshness check
-
-Add a timestamp to your state file to detect stale state without making a network request:
-
-```typescript
-interface PersistedState {
-  storageState: any;
-  savedAt: string;
-  expiresAt: string;
-}
-
-function isStateExpired(state: PersistedState): boolean {
-  return new Date(state.expiresAt) < new Date();
-}
-```
-
-## Checkpoint Strategy
-
-For long-running workflows, save state at regular intervals:
-
-```typescript
-class CheckpointManager {
-  private interval: NodeJS.Timeout | null = null;
-
-  startPeriodicCheckpoints(context: BrowserContext, filePath: string, intervalMs: number) {
-    this.interval = setInterval(async () => {
-      try {
-        await context.storageState({ path: filePath });
-        console.log(`Checkpoint saved at ${new Date().toISOString()}`);
-      } catch (error) {
-        console.warn('Checkpoint failed:', error);
-      }
-    }, intervalMs);
-  }
-
-  stopCheckpoints() {
-    if (this.interval) {
-      clearInterval(this.interval);
-      this.interval = null;
-    }
-  }
-}
-```
-
-### Checkpoint rotation
-
-Keep multiple checkpoint files to recover from corruption:
-
-```typescript
-async function saveRotatingCheckpoint(
-  context: BrowserContext,
-  baseDir: string,
-  maxCheckpoints: number = 5
-) {
-  const timestamp = Date.now();
-  const filePath = path.join(baseDir, `checkpoint-${timestamp}.json`);
-  await context.storageState({ path: filePath });
-
-  // Remove old checkpoints beyond the limit
-  const files = fs.readdirSync(baseDir)
-    .filter((f) => f.startsWith('checkpoint-'))
-    .sort()
-    .reverse();
-
-  for (const file of files.slice(maxCheckpoints)) {
-    fs.unlinkSync(path.join(baseDir, file));
-  }
-}
-```
-
-## State Migration
-
-When the application changes its storage schema, old state files may become incompatible. Handle this:
-
-```typescript
-interface StateFile {
-  version: number;
-  storageState: any;
-}
-
-function migrateState(state: StateFile): StateFile {
-  if (state.version === 1) {
-    // v1 -> v2: cookie name changed from "sid" to "session_id"
-    state.storageState.cookies = state.storageState.cookies.map((c: any) => ({
-      ...c,
-      name: c.name === 'sid' ? 'session_id' : c.name,
-    }));
-    state.version = 2;
-  }
-  return state;
-}
-```
-
-## Decision Matrix
-
-| Need | Strategy | Complexity |
-| --- | --- | --- |
-| Reuse login across tests | `storageState` in global setup | Low |
-| Persist session across runs | `storageState` to file + validation | Medium |
-| Persist session + form data | `storageState` + sessionStorage extraction | Medium |
-| Persist offline app data | `storageState` + IndexedDB extraction | High |
-| Survive browser restarts | `launchPersistentContext` with user data dir | Medium |
-| Distributed session sharing | `storageState` to Redis/S3 | High |

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

@@ -1,52 +0,0 @@
-# Prisma Eval Assertions
-
-## Eval 1: Schema Design with Relations and Migrations
-
-This eval tests the ability to design a Prisma 6+ schema for a multi-tenant SaaS with proper relations, indexes, enums, and a safe migration workflow including additive schema changes.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `@relation` — Explicit relation annotations | Prisma requires explicit `@relation` annotations with `fields` and `references` for ambiguous relations. Omitting them on self-relations or multiple relations to the same model produces schema validation errors that block migration. |
-| 2 | contains | `@@index` — Schema-defined indexes | Indexes defined in the Prisma schema are tracked by `prisma migrate diff`. Indexes created with raw SQL outside the schema are invisible to Prisma, causing migration drift between environments and missed performance optimizations. |
-| 3 | contains | `enum` — Prisma-native enums | Schema-defined enums generate database-level enum types (Postgres) or CHECK constraints (MySQL/SQLite), enforcing valid values at the database layer. String fields with application-level validation can be bypassed by direct database access. |
-| 4 | contains | `prisma migrate` — Migration workflow commands | Using `migrate dev` in development and `migrate deploy` in production ensures migration files are generated interactively, reviewed before commit, and applied atomically in CI/CD without generating new migrations in production. |
-| 5 | contains | `@@unique` — Composite uniqueness constraints | Unique constraints prevent duplicate data at the database level. Without them, concurrent requests can create duplicate organization memberships or duplicate label names that application-level checks would miss due to race conditions. |
-
-### What a passing response looks like
-
-- Models: `Organization`, `User`, `OrganizationMember` (join table with role), `Project`, `Task`, `Label`, `TaskLabel` (or implicit M2M).
-- `OrganizationMember` has `@@unique([userId, organizationId])` to prevent duplicate memberships.
-- `Task` model has `priority` and `status` as Prisma enums with defined values.
-- `@@index([status])`, `@@index([assigneeId])`, `@@index([dueDate])` on the Task model.
-- All relations use `@relation(fields: [...], references: [...])`.
-- Migration workflow: `npx prisma migrate dev --name init` for initial setup, `npx prisma migrate dev --name add-labels` for the labels feature.
-- Generated migration SQL is reviewed before committing to version control.
-- `prisma migrate deploy` used in CI/CD pipeline.
-
----
-
-## Eval 2: Edge Deployment with Advanced Queries
-
-This eval tests the ability to configure Prisma for edge runtime deployment and write efficient Prisma Client queries including select/include, transactions, cursor-based pagination, and aggregations.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `include` — Controlled relation loading | Prisma returns all scalar fields and no relations by default. Using `include` or `select` explicitly controls the data shape, preventing over-fetching (wasted bandwidth) and under-fetching (additional queries or null references). |
-| 2 | contains | `$transaction` — Atomic multi-step writes | Interactive transactions hold a database-level transaction across multiple Prisma queries. Without them, creating a task and assigning it in separate calls risks partial writes where the task exists but the assignment fails. |
-| 3 | contains | `cursor` — Cursor-based pagination | Offset pagination breaks when data changes between requests (duplicates, skipped items). Cursor-based pagination provides stable pages using a unique, sortable field as the pagination anchor. |
-| 4 | contains | `accelerate` — Edge runtime compatibility | The Prisma query engine is a Rust binary that cannot run in V8-only edge environments. Prisma Accelerate provides a managed proxy that the lightweight edge client communicates with, enabling edge deployment without the engine binary. |
-| 5 | contains | `groupBy` — Database-level aggregation | Aggregating task counts by status with `groupBy` executes a single SQL GROUP BY query. Fetching all tasks and counting in application code transfers unnecessary data and scales poorly with dataset size. |
-
-### What a passing response looks like
-
-- Datasource configured with `prisma://` URL for Prisma Accelerate with `directUrl` for migrations.
-- Generator configured with `@prisma/client` and edge-compatible output.
-- Project query uses `include: { tasks: { include: { assignee: true }, select: { _count: { select: { labels: true } } } } }`.
-- Transaction: `prisma.$transaction(async (tx) => { const task = await tx.task.create(...); await tx.taskAssignment.create(...); return task; })`.
-- Cursor pagination: `prisma.task.findMany({ take: 20, cursor: { id: lastId }, skip: 1, orderBy: { createdAt: 'desc' } })`.
-- Aggregation: `prisma.task.groupBy({ by: ['status'], _count: { id: true } })`.
-- Connection pool configured with `connection_limit` and `pool_timeout` parameters.

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

@@ -1,68 +0,0 @@
-{
-  "evals": [
-    {
-      "name": "schema-design-with-relations-and-migrations",
-      "description": "Validate that the skill produces a Prisma 6+ schema with proper model definitions, relations, indexes, enums, and a migration workflow for a multi-tenant SaaS application.",
-      "input": "Design a Prisma schema for a multi-tenant project management SaaS. Tenants have organizations with members (users can belong to multiple organizations with roles). Organizations have projects, projects have tasks with assignees, priorities (enum), statuses (enum), and due dates. Include proper indexes for common query patterns (tasks by status, tasks by assignee, tasks due soon). Show the migration workflow for initial setup and for adding a new 'labels' feature (many-to-many between tasks and labels). Use PostgreSQL as the provider.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "@relation",
-          "description": "All relations must use explicit @relation annotations with fields and references to prevent ambiguous relation errors and ensure Prisma can generate correct foreign key constraints."
-        },
-        {
-          "type": "contains",
-          "value": "@@index",
-          "description": "The schema must define indexes with @@index on frequently queried columns (status, assigneeId, dueDate) to ensure the database can serve common query patterns without full table scans."
-        },
-        {
-          "type": "contains",
-          "value": "enum",
-          "description": "Priority and status must be defined as Prisma enums rather than string fields to enforce valid values at the database level and generate type-safe TypeScript union types in the client."
-        },
-        {
-          "type": "contains",
-          "value": "prisma migrate",
-          "description": "The response must include prisma migrate commands (migrate dev for development, migrate deploy for production) demonstrating the proper migration workflow for schema changes."
-        },
-        {
-          "type": "contains",
-          "value": "@@unique",
-          "description": "The schema must use @@unique constraints for natural uniqueness (e.g., user-organization membership, label name per organization) to prevent duplicate data at the database level."
-        }
-      ]
-    },
-    {
-      "name": "edge-deployment-with-advanced-queries",
-      "description": "Validate that the skill produces Prisma Client queries with proper select/include, transactions, and edge deployment configuration for a serverless API with connection pooling.",
-      "input": "Configure a Prisma 6+ project for deployment to Vercel Edge Functions with Prisma Accelerate. Then write Prisma Client queries for: (1) fetching a project with its tasks, assignees, and label counts using select/include, (2) a transaction that creates a task and assigns it to a user atomically, (3) a paginated task list with cursor-based pagination, and (4) an aggregation query for task count by status. Show the datasource configuration, client generation, and connection pooling setup.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "include",
-          "description": "Queries must use include or select to control relation loading, avoiding the default behavior of returning all scalars without relations which causes either over-fetching or missing data."
-        },
-        {
-          "type": "contains",
-          "value": "$transaction",
-          "description": "Multi-step writes must use prisma.$transaction() to ensure atomicity, preventing partial writes where a task is created but the assignment fails."
-        },
-        {
-          "type": "contains",
-          "value": "cursor",
-          "description": "The paginated query must use cursor-based pagination with a cursor parameter and take/skip, providing stable page results regardless of concurrent data modifications."
-        },
-        {
-          "type": "contains",
-          "value": "accelerate",
-          "description": "The edge deployment configuration must reference Prisma Accelerate for connection pooling and query engine proxy, since the Rust query engine cannot run in V8-only edge runtimes."
-        },
-        {
-          "type": "contains",
-          "value": "groupBy",
-          "description": "The aggregation query must use Prisma's groupBy or aggregate API to compute task counts by status at the database level rather than fetching all tasks and counting in application code."
-        }
-      ]
-    }
-  ]
-}

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/prompt-engineering/evals/assertions.md

@@ -1,49 +0,0 @@
-# Prompt Engineering Eval Assertions
-
-## Eval 1: System Prompt Design for Code Assistant
-
-This eval tests the skill's ability to design a production-ready system prompt with role definition, constraints, output format, few-shot examples, and safety guardrails for a Python code assistant.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `role` -- explicit role definition | Without a role definition, the model defaults to generic assistant behavior. The role calibrates expertise, vocabulary, and confidence level for Python-specific output. |
-| 2 | contains | `NEVER` -- explicit prohibitions | Positive instructions ("try to avoid filesystem access") are weaker than explicit prohibitions ("NEVER access the filesystem unless explicitly requested"). Guardrails must be unambiguous. |
-| 3 | contains | `def ` -- Python function in examples | Few-shot examples must demonstrate the exact output format. A code assistant prompt without code examples leaves the model guessing about formatting, type annotations, and docstring style. |
-| 4 | contains | `docstring` -- docstring requirement | This is a hard requirement from the spec. The prompt must both instruct and demonstrate docstring usage so the model consistently includes them in every function. |
-| 5 | contains | `reasoning` -- chain-of-thought instruction | The spec requires the assistant to explain reasoning before code. This must be an explicit instruction, not an assumption that the model will naturally explain itself. |
-
-### What a passing response looks like
-
-- A system prompt with clearly labeled sections: Role, Task, Constraints, Output Format, Examples.
-- Role defined as a Python expert with type annotation and PEP 8 expertise.
-- Constraints section with explicit NEVER/DO NOT rules for filesystem and network access.
-- Output format specifying: (1) reasoning explanation, then (2) code block with type annotations and docstrings.
-- 2-3 few-shot examples showing user request -> reasoning -> typed Python function with docstring.
-- Examples spanning difficulty: a simple utility function, a function with error handling, and an edge case (e.g., request involving filesystem access that gets appropriately refused).
-
----
-
-## Eval 2: Structured Output Extraction
-
-This eval tests the skill's ability to design a robust extraction pipeline with JSON schema enforcement, validation, and fallback handling for customer feedback analysis.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `json` -- JSON output format | Structured extraction must produce machine-parseable JSON, not prose descriptions of the extracted fields. JSON enables deterministic downstream processing. |
-| 2 | contains | `enum` -- constrained field values | Unconstrained fields (e.g., free-text sentiment) produce inconsistent values across runs. Enums enforce consistency and prevent the model from inventing categories. |
-| 3 | contains | `validation` -- output validation logic | LLMs do not guarantee schema compliance. Without validation, malformed outputs propagate as silent data corruption in the pipeline. |
-| 4 | contains | `fallback` -- error recovery strategy | Production systems must handle extraction failures gracefully. A pipeline that crashes on malformed JSON is not production-grade. |
-| 5 | contains | `example` -- few-shot extraction example | Examples are the most reliable way to enforce output format. A complete input/output example reduces schema violations by 60-80% compared to instructions alone. |
-
-### What a passing response looks like
-
-- A system prompt with the JSON schema embedded and an explicit instruction to respond only with valid JSON.
-- A JSON Schema definition with required fields, enum constraints, and string length limits.
-- 1-2 few-shot examples showing customer email input and the expected JSON output.
-- Validation code that: parses JSON, checks required fields, validates enum values, checks string lengths.
-- A fallback strategy: (a) retry with a simplified prompt, (b) extract partial fields from malformed output, (c) flag for human review if all retries fail.
-- Notes on model differences: Claude responds well to XML-fenced examples, GPT-4 responds well to function-calling mode for structured output.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/prompt-engineering/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "system-prompt-design-for-code-assistant",
-    "description": "Validate that the skill produces a well-structured system prompt for a code assistant with proper role definition, constraints, output format, examples, and guardrails.",
-    "input": "Design a system prompt for a code assistant that helps developers write Python code. The assistant must: (1) generate type-annotated Python 3.12+ code, (2) include docstrings for all functions, (3) follow PEP 8 style, (4) refuse to generate code that accesses the filesystem or network unless explicitly requested, (5) explain its reasoning before providing code. The prompt should be production-ready and include 2-3 few-shot examples.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "role",
-        "description": "The system prompt must define an explicit role (e.g., 'You are a Python code assistant') to set the model's expertise calibration and response style."
-      },
-      {
-        "type": "contains",
-        "value": "NEVER",
-        "description": "Safety constraints must be stated as explicit prohibitions (NEVER, DO NOT, MUST NOT) rather than positive suggestions, because models follow explicit prohibitions more reliably."
-      },
-      {
-        "type": "contains",
-        "value": "def ",
-        "description": "The prompt must include at least one few-shot example showing a complete Python function with type annotations and docstring, demonstrating the exact output format expected."
-      },
-      {
-        "type": "contains",
-        "value": "docstring",
-        "description": "The prompt must explicitly require docstrings since this is a stated requirement. The instruction and at least one example must demonstrate docstring usage."
-      },
-      {
-        "type": "contains",
-        "value": "reasoning",
-        "description": "The prompt must instruct the model to explain its reasoning before providing code, implementing the chain-of-thought requirement from the specification."
-      }
-    ]
-  },
-  {
-    "name": "structured-output-extraction",
-    "description": "Validate that the skill produces a robust structured output extraction strategy with JSON schema, validation, error handling, and fallback patterns for extracting data from unstructured LLM responses.",
-    "input": "Design a structured output extraction pipeline for a system that processes customer feedback emails and extracts: sentiment (positive/negative/neutral), urgency (low/medium/high/critical), product_name (string), issue_category (from a fixed enum: billing, technical, account, feature_request, other), and a summary (1-2 sentences). The extraction must work reliably with Claude and GPT-4. Provide the prompt design, JSON schema, validation logic, and fallback handling for malformed outputs.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "json",
-        "description": "The extraction must produce JSON output with a defined schema, not free-form text that requires post-processing to extract structured data."
-      },
-      {
-        "type": "contains",
-        "value": "enum",
-        "description": "The schema must enforce enum constraints for sentiment, urgency, and issue_category to prevent the model from inventing categories outside the allowed set."
-      },
-      {
-        "type": "contains",
-        "value": "validation",
-        "description": "The pipeline must include output validation logic (JSON schema validation, type checking, enum membership) because LLMs do not guarantee schema compliance."
-      },
-      {
-        "type": "contains",
-        "value": "fallback",
-        "description": "The pipeline must include a fallback strategy for malformed outputs (retry with simplified prompt, return partial extraction, flag for human review) because LLMs occasionally produce unparseable responses."
-      },
-      {
-        "type": "contains",
-        "value": "example",
-        "description": "The prompt must include at least one complete few-shot example showing a customer email and the expected JSON output, because examples are more reliable than instructions for format compliance."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/python-best-practices/evals/assertions.md

@@ -1,33 +0,0 @@
-# Python Best Practices — Eval Assertions
-
-## Eval 1: Typing Migration (python-typing-migration)
-
-This eval tests whether the skill correctly migrates legacy typing idioms to Python 3.13+ modern syntax.
-
-### Assertions
-
-1. **PEP 695 type parameter syntax** — The response must use the new `class Foo[T]:` and `def bar[K, V](...)` syntax introduced in PEP 695 instead of creating explicit `TypeVar` bindings. This is the defining feature of modern Python generics.
-
-2. **Optional replaced with union syntax** — `Optional[T]` must become `T | None`. The pipe union syntax is shorter, clearer, and consistent with how unions appear in `isinstance` checks and `match` statements.
-
-3. **Lowercase built-in generics** — `List[T]` must become `list[T]`, `Dict[K, V]` must become `dict[K, V]`. Since Python 3.9, built-in collections are directly subscriptable, and the `typing` module versions are legacy.
-
-4. **Union replaced with pipe syntax** — `Union[str, int, None]` must become `str | int | None`. The PEP 604 union syntax has been available since Python 3.10 and is the standard form.
-
-5. **Removed TypeVar and Generic imports** — The explicit `T = TypeVar('T')` declarations and `from typing import Generic` must be removed because PEP 695 scopes type parameters directly to the class or function, making manual `TypeVar` creation unnecessary.
-
-## Eval 2: Async Service Implementation (python-async-service)
-
-This eval tests whether the skill produces a well-structured async worker with modern concurrency patterns.
-
-### Assertions
-
-1. **TaskGroup for structured concurrency** — The response must use `asyncio.TaskGroup` (Python 3.11+) rather than bare `asyncio.create_task` or `asyncio.gather`. TaskGroup propagates exceptions and cancels sibling tasks on failure.
-
-2. **Graceful shutdown handling** — The service must handle SIGTERM by setting a shutdown event or cancelling the TaskGroup. Production services must drain in-flight work before exiting rather than terminating abruptly.
-
-3. **Async context managers for resources** — Connection pools for Redis and PostgreSQL must be managed with `async with` blocks to guarantee cleanup even under cancellation or exception.
-
-4. **Structured error handling** — The response must define custom exception types or use explicit exception handling rather than bare `except:` or `except Exception:`. Error handling strategy must be visible and intentional.
-
-5. **Structured logging with context** — Log entries must include contextual information (message IDs, worker names, operation durations) because structured logs with context are essential for debugging production async services.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/python-best-practices/evals/evals.json

@@ -1,54 +0,0 @@
-[
-  {
-    "id": "python-typing-migration",
-    "prompt": "I have a Python 3.10 codebase using `from typing import TypeVar, Optional, List, Dict, Union`. Migrate the following module to Python 3.13+ modern typing idioms:\n\n```python\nfrom typing import TypeVar, Optional, List, Dict, Union, Generic\n\nT = TypeVar('T')\nK = TypeVar('K')\nV = TypeVar('V')\n\nclass Repository(Generic[T]):\n    def __init__(self, items: List[T]) -> None:\n        self._items = items\n\n    def find(self, predicate) -> Optional[T]:\n        for item in self._items:\n            if predicate(item):\n                return item\n        return None\n\n    def find_all(self, predicate) -> List[T]:\n        return [item for item in self._items if predicate(item)]\n\ndef merge_dicts(a: Dict[K, V], b: Dict[K, V]) -> Dict[K, V]:\n    result: Dict[K, V] = {}\n    result.update(a)\n    result.update(b)\n    return result\n\ndef process_value(value: Union[str, int, None]) -> str:\n    if value is None:\n        return 'empty'\n    return str(value)\n```",
-    "assertions": [
-      {
-        "type": "content",
-        "value": "type parameter syntax with square brackets on the class or function definition (e.g., `class Repository[T]:` or `def merge_dicts[K, V]`)"
-      },
-      {
-        "type": "content",
-        "value": "replaces Optional[T] with T | None union syntax"
-      },
-      {
-        "type": "content",
-        "value": "replaces List[T] and Dict[K, V] with lowercase built-in generics list[T] and dict[K, V]"
-      },
-      {
-        "type": "content",
-        "value": "replaces Union[str, int, None] with str | int | None"
-      },
-      {
-        "type": "content",
-        "value": "removes the explicit TypeVar declarations and the Generic import since PEP 695 scopes type parameters to the class/function"
-      }
-    ]
-  },
-  {
-    "id": "python-async-service",
-    "prompt": "Design an async Python worker service that reads messages from a Redis stream, processes them, and writes results to PostgreSQL. Requirements: structured concurrency with TaskGroup, graceful shutdown on SIGTERM, connection pooling for both Redis and PostgreSQL, and proper error handling. Target Python 3.13+.",
-    "assertions": [
-      {
-        "type": "content",
-        "value": "uses asyncio.TaskGroup for structured concurrency to manage worker coroutines"
-      },
-      {
-        "type": "content",
-        "value": "implements graceful shutdown handling via asyncio signal handlers or a shutdown Event triggered by SIGTERM"
-      },
-      {
-        "type": "content",
-        "value": "uses async context managers (async with) for connection pool lifecycle management"
-      },
-      {
-        "type": "content",
-        "value": "defines explicit exception types or uses structured error handling rather than bare except clauses"
-      },
-      {
-        "type": "content",
-        "value": "includes structured logging with contextual information such as message IDs or worker identifiers"
-      }
-    ]
-  }
-]