@cubis/foundry 0.3.83 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/rag-patterns/references/vector-stores.md

@@ -1,242 +0,0 @@
-# Vector Stores
-
-## Overview
-
-The vector store is the persistence and retrieval engine for embeddings. Choosing the right store depends on scale, query patterns, operational model (managed vs. self-hosted), and feature requirements (filtering, multi-tenancy, hybrid search). This reference compares major options and provides configuration guidance.
-
-## Comparison Matrix
-
-| Store | Type | Max vectors | Filtering | Hybrid search | Multi-tenancy | Managed option | Open-source |
-|-------|------|-------------|-----------|---------------|---------------|----------------|-------------|
-| Pinecone | Managed SaaS | Billions | Metadata filters | Sparse vectors | Namespaces | Yes (only) | No |
-| Qdrant | Self-hosted / Cloud | Billions | Payload filters | Named sparse vectors | Collection-level | Qdrant Cloud | Yes |
-| Weaviate | Self-hosted / Cloud | Billions | GraphQL filters | BM25 built-in | Class-level | Weaviate Cloud | Yes |
-| pgvector | PostgreSQL extension | Millions | SQL WHERE | Full-text search via pg | PostgreSQL schemas | Any PG host | Yes |
-| Chroma | Embedded / Client-server | Millions | Metadata filters | No native | Collection-level | No | Yes |
-| Milvus | Self-hosted / Cloud | Billions | Expression filters | Sparse vectors | Partition-level | Zilliz Cloud | Yes |
-
-## Selection Guide
-
-### When to Choose Pinecone
-
-- You want zero operational overhead and are willing to pay for managed infrastructure.
-- Your query patterns are standard (vector similarity + metadata filtering).
-- You need serverless scaling that handles burst traffic automatically.
-- You do NOT need self-hosted deployment for data residency.
-
-### When to Choose Qdrant
-
-- You need hybrid search with native sparse vector support.
-- You want the flexibility of self-hosted with a cloud option for production.
-- You need rich payload filtering with indexed fields.
-- You want gRPC for high-throughput batch operations.
-
-### When to Choose pgvector
-
-- Your application already uses PostgreSQL and you want to avoid adding another service.
-- Your corpus is under 5 million vectors.
-- You need transactional consistency between vector operations and relational data.
-- You want to leverage existing PostgreSQL tooling (backups, monitoring, replication).
-
-### When to Choose Weaviate
-
-- You want built-in hybrid search (BM25 + vector) without managing a separate sparse index.
-- You use GraphQL heavily and want a native GraphQL query API.
-- You need built-in vectorization modules (bring your own model or use integrated ones).
-
-### When to Choose Chroma
-
-- You are prototyping or building a local development environment.
-- Your corpus is small (under 1 million vectors).
-- You want an embedded store that runs in-process with no external dependencies.
-
-## Pinecone Configuration
-
-```python
-from pinecone import Pinecone, ServerlessSpec
-
-pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"])
-
-# Create index
-pc.create_index(
-    name="knowledge-base",
-    dimension=1536,
-    metric="cosine",
-    spec=ServerlessSpec(
-        cloud="aws",
-        region="us-east-1"
-    )
-)
-
-index = pc.Index("knowledge-base")
-
-# Upsert with metadata
-index.upsert(
-    vectors=[
-        {
-            "id": "chunk-001",
-            "values": embedding_vector,
-            "metadata": {
-                "doc_type": "api_reference",
-                "product": "payments",
-                "version": "2.1",
-                "text": chunk_text[:40960]  # Pinecone metadata limit
-            }
-        }
-    ],
-    namespace="production"
-)
-
-# Query with metadata filter
-results = index.query(
-    vector=query_embedding,
-    top_k=50,
-    filter={
-        "doc_type": {"$eq": "api_reference"},
-        "version": {"$gte": "2.0"}
-    },
-    include_metadata=True,
-    namespace="production"
-)
-```
-
-## pgvector Configuration
-
-```sql
--- Enable extension
-CREATE EXTENSION IF NOT EXISTS vector;
-
--- Create table with vector column
-CREATE TABLE chunks (
-    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    text TEXT NOT NULL,
-    embedding vector(1536) NOT NULL,
-    doc_type TEXT NOT NULL,
-    title TEXT,
-    section TEXT,
-    created_at TIMESTAMPTZ DEFAULT now()
-);
-
--- Create IVFFlat index for approximate nearest neighbor search
-CREATE INDEX ON chunks USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);
-
--- For higher accuracy at the cost of slower index build, use HNSW
-CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops)
-    WITH (m = 16, ef_construction = 200);
-
--- Query with filter
-SELECT id, text, doc_type, title,
-       1 - (embedding <=> $1::vector) AS similarity
-FROM chunks
-WHERE doc_type = 'api_reference'
-ORDER BY embedding <=> $1::vector
-LIMIT 50;
-```
-
-### pgvector Performance Tuning
-
-```sql
--- Increase work_mem for vector operations
-SET work_mem = '256MB';
-
--- For IVFFlat: set probes (higher = more accurate, slower)
-SET ivfflat.probes = 10;  -- Default 1, recommended 5-20
-
--- For HNSW: set ef_search (higher = more accurate, slower)
-SET hnsw.ef_search = 100;  -- Default 40, recommended 64-200
-```
-
-### pgvector Scaling Limits
-
-| Metric | Recommended limit | Beyond this |
-|--------|-------------------|-------------|
-| Vector count | 5 million | Consider dedicated vector store |
-| Dimensions | 2000 | Performance degrades significantly |
-| Concurrent queries | 50 | Connection pooling required |
-| Index build time | 30 min for 1M vectors | Plan for maintenance windows |
-
-## Qdrant Configuration
-
-```python
-from qdrant_client import QdrantClient, models
-
-client = QdrantClient(
-    url="https://your-cluster.qdrant.io",
-    api_key=os.environ["QDRANT_API_KEY"]
-)
-
-# Create collection with HNSW configuration
-client.create_collection(
-    collection_name="knowledge_base",
-    vectors_config=models.VectorParams(
-        size=1536,
-        distance=models.Distance.COSINE,
-        on_disk=True  # For large collections, store vectors on disk
-    ),
-    hnsw_config=models.HnswConfigDiff(
-        m=16,
-        ef_construct=200,
-        full_scan_threshold=10000
-    ),
-    optimizers_config=models.OptimizersConfigDiff(
-        indexing_threshold=20000  # Start indexing after 20K points
-    )
-)
-
-# Create payload indices for fast filtering
-client.create_payload_index(
-    collection_name="knowledge_base",
-    field_name="doc_type",
-    field_schema=models.PayloadSchemaType.KEYWORD
-)
-
-# Query with payload filter
-results = client.query_points(
-    collection_name="knowledge_base",
-    query=query_embedding,
-    query_filter=models.Filter(
-        must=[
-            models.FieldCondition(
-                key="doc_type",
-                match=models.MatchValue(value="api_reference")
-            )
-        ]
-    ),
-    limit=50,
-    with_payload=True
-)
-```
-
-## Index Types and Trade-offs
-
-| Index type | Build time | Query speed | Memory | Accuracy | Best for |
-|-----------|-----------|-------------|--------|----------|----------|
-| Flat (brute force) | None | Slow (O(n)) | Low | 100% | < 10K vectors |
-| IVFFlat | Medium | Fast | Medium | 95-99% | 10K - 1M vectors |
-| HNSW | Slow | Fastest | High | 98-99.5% | > 100K vectors, low latency |
-| PQ (Product Quantization) | Slow | Fast | Lowest | 90-95% | > 10M vectors, memory constrained |
-
-## Multi-Tenancy Patterns
-
-### Namespace Isolation (Pinecone)
-
-Each tenant gets a namespace within the same index. Cheap to create, queries are scoped by namespace.
-
-### Collection Per Tenant (Qdrant, Weaviate)
-
-Each tenant gets a separate collection. Strong isolation but higher resource overhead.
-
-### Metadata Filtering (All Stores)
-
-All tenants share an index with a `tenant_id` metadata field. Cheapest but relies on filter performance.
-
-**Recommendation:** Use metadata filtering for < 100 tenants, namespace isolation for 100-10K tenants, and collection-per-tenant for tenants with strict data isolation requirements.
-
-## Backup and Recovery
-
-- **Pinecone:** Managed backups via collections API. Restore creates a new index.
-- **Qdrant:** Snapshot API for full collection backup. Restore from snapshot.
-- **pgvector:** Standard PostgreSQL backup (pg_dump). Full transactional consistency.
-- **Weaviate:** Backup API with S3/GCS targets.
-
-Always test restore procedures before production deployment. A backup you have never restored is not a backup.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/react/evals/assertions.md

@@ -1,50 +0,0 @@
-# React 19+ -- Eval Assertions
-
-## Eval 01: use() hook with Suspense for data fetching
-
-This eval validates correct usage of the React 19 `use()` hook with Suspense boundaries for promise-based data fetching.
-
-### Assertions
-
-| # | Type | Target | Rationale |
-|---|------|--------|-----------|
-| 1 | contains | `use(` | Verifies the skill uses the React 19 `use()` hook to read promises. `use()` replaces the `useEffect` + `useState` data fetching pattern with Suspense integration and can be called conditionally. |
-| 2 | contains | `<Suspense` | Verifies the skill wraps the data-consuming component in a `<Suspense>` boundary. Without Suspense, `use()` would suspend to the nearest ancestor boundary or crash the tree. |
-| 3 | contains | `fallback` | Verifies a fallback prop is provided to Suspense. The fallback renders while the promise is pending, providing a loading skeleton to the user. |
-| 4 | pattern | `ErrorBoundary\|error.boundary\|componentDidCatch` | Verifies the skill includes error handling. Promise rejections from `use()` propagate to the nearest Error Boundary, so one must be present to prevent full-tree crashes. |
-| 5 | pattern | `interface\|type\s+\w+\s*=` | Verifies the skill defines TypeScript types for props. Explicit typing ensures the promise shape and component API are documented and enforced at compile time. |
-
-### What a passing response looks like
-
-A passing response creates:
-- A `UserProfile` component that calls `use(userPromise)` to read the resolved user data
-- A parent component or wrapper that passes the promise and wraps `UserProfile` in `<Suspense fallback={<Skeleton />}>`
-- An `ErrorBoundary` component (class-based or from `react-error-boundary`) wrapping the Suspense boundary
-- TypeScript interfaces for `User` (name, email, avatar) and the component props (`{ userPromise: Promise<User> }`)
-- No `useEffect` or `useState` for data fetching
-
----
-
-## Eval 02: Form with useActionState and useOptimistic
-
-This eval validates correct implementation of React 19 form handling with `useActionState` for state management and `useOptimistic` for instant UI feedback.
-
-### Assertions
-
-| # | Type | Target | Rationale |
-|---|------|--------|-----------|
-| 1 | contains | `useActionState` | Verifies the skill uses `useActionState` to manage form action state. This hook encapsulates the action, pending state, and previous result in a single API. |
-| 2 | contains | `useOptimistic` | Verifies the skill uses `useOptimistic` for instant feedback. Optimistic updates make the UI feel responsive while the server processes the mutation, with automatic revert on failure. |
-| 3 | pattern | `action[=:]\|<form.*action` | Verifies the skill passes the action to a form element. React 19 form actions integrate with the `action` prop for built-in pending states and progressive enhancement. |
-| 4 | pattern | `useFormStatus\|pending` | Verifies the skill tracks pending state. A loading indicator on the submit button prevents double submission and provides feedback. |
-| 5 | contains | `'use server'` | Verifies the skill includes a server action. The mutation handler must run on the server for data persistence and security. |
-
-### What a passing response looks like
-
-A passing response provides:
-- A server action marked with `'use server'` that saves a todo and returns the updated list
-- A Client Component using `useActionState` bound to the server action
-- `useOptimistic` to immediately append the new todo to the displayed list
-- A `<form action={formAction}>` that passes the action state handler
-- A `SubmitButton` component using `useFormStatus` to show pending state
-- Error handling that reverts the optimistic update when the server action fails

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

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "react-eval-01",
-    "name": "use() hook with Suspense for data fetching",
-    "description": "Validate that the skill correctly guides implementation of the React 19 use() hook with Suspense boundaries for promise-based data fetching.",
-    "prompt": "Create a React 19 UserProfile component that receives a user data promise as a prop and reads it with the use() hook. Wrap it in a Suspense boundary with a skeleton fallback. Include an ErrorBoundary for fetch failures. The component should display name, email, and avatar. Type all props with TypeScript interfaces.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "use(",
-        "description": "Must use the React 19 use() hook to read the promise instead of useEffect + useState pattern"
-      },
-      {
-        "type": "contains",
-        "value": "<Suspense",
-        "description": "Must wrap the component in a Suspense boundary since use() suspends rendering until the promise resolves"
-      },
-      {
-        "type": "contains",
-        "value": "fallback",
-        "description": "Must provide a fallback prop to Suspense for displaying a loading skeleton while data loads"
-      },
-      {
-        "type": "pattern",
-        "value": "ErrorBoundary|error.boundary|componentDidCatch",
-        "description": "Must include an Error Boundary to catch and display fetch failures gracefully"
-      },
-      {
-        "type": "pattern",
-        "value": "interface|type\\s+\\w+\\s*=",
-        "description": "Must define TypeScript interfaces or type aliases for component props to ensure type safety"
-      }
-    ]
-  },
-  {
-    "id": "react-eval-02",
-    "name": "Form with useActionState and useOptimistic",
-    "description": "Validate that the skill correctly implements a React 19 form using useActionState for state management and useOptimistic for instant UI feedback.",
-    "prompt": "Build a React 19 todo list with an add-todo form. Use useActionState to handle form submission with a server action that saves the todo. Use useOptimistic to show the new todo immediately in the list before the server responds. Handle the error case by reverting the optimistic update. Include a pending state indicator on the submit button using the useFormStatus hook.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "useActionState",
-        "description": "Must use useActionState to manage form action state including pending state and previous results"
-      },
-      {
-        "type": "contains",
-        "value": "useOptimistic",
-        "description": "Must use useOptimistic to provide instant UI feedback before the server action completes"
-      },
-      {
-        "type": "pattern",
-        "value": "action[=:]|<form.*action",
-        "description": "Must pass the action function to a form element's action prop for React 19 form handling"
-      },
-      {
-        "type": "pattern",
-        "value": "useFormStatus|pending",
-        "description": "Must track pending state to disable the submit button and show a loading indicator during submission"
-      },
-      {
-        "type": "contains",
-        "value": "'use server'",
-        "description": "Must include a server action marked with 'use server' for the form mutation handler"
-      }
-    ]
-  }
-]

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

@@ -1,95 +0,0 @@
----
-name: react-native
-description: "Use when building cross-platform mobile applications with React Native and Expo. Invoke for New Architecture (Fabric, TurboModules), Expo SDK 52+, native module bridging, navigation, and mobile performance optimization."
-license: MIT
-metadata:
-  author: cubis-foundry
-  version: "3.0"
-compatibility: "Claude Code, Codex, GitHub Copilot"
----
-# React Native with Expo
-
-Senior mobile engineer specializing in React Native 0.76+ New Architecture and Expo SDK 52+ for production cross-platform applications on iOS and Android.
-
-## Purpose
-
-Provide authoritative guidance on building production React Native applications using the New Architecture (Fabric renderer, TurboModules) with Expo as the development platform. This skill covers native module bridging, type-safe navigation with deep linking, performance profiling, and deployment to app stores.
-
-## When to Use
-
-- Creating new React Native projects with Expo SDK 52+
-- Migrating existing apps to the New Architecture (Fabric + TurboModules)
-- Building or consuming native modules and Expo modules
-- Implementing stack/tab/drawer navigation with deep linking
-- Profiling and optimizing rendering performance on mobile
-- Writing tests for React Native components and navigation flows
-- Configuring EAS Build and EAS Submit for app store deployment
-
-## Instructions
-
-1. **Initialize projects with `npx create-expo-app`** using the latest Expo SDK 52+ template, because Expo provides a managed workflow that handles native toolchain complexity while still allowing bare-workflow escape hatches when needed.
-
-2. **Enable the New Architecture in `app.json`** by setting `"newArchEnabled": true` for both iOS and Android, because the New Architecture (Fabric + TurboModules) provides synchronous native calls, concurrent rendering support, and eliminates the legacy bridge bottleneck.
-
-3. **Use Fabric components instead of legacy Paper components** wherever available, because Fabric renders on the UI thread with C++ shared ownership, reducing bridge serialization overhead and enabling interruptible rendering.
-
-4. **Create native modules with the TurboModule system** using codegen-typed specs, because TurboModules are lazily loaded, type-safe at the native boundary, and avoid the startup cost of eagerly registering all legacy native modules.
-
-5. **Build custom native functionality as Expo Modules** using the Expo Modules API (`expo-modules-core`), because Expo Modules provide a unified Swift/Kotlin API that generates correct TurboModule bindings and works in both managed and bare workflows.
-
-6. **Implement navigation with Expo Router** using file-based routing in the `app/` directory, because Expo Router provides automatic deep linking, type-safe routes, and universal links support out of the box without manual linking configuration.
-
-7. **Configure deep linking schemes** in `app.json` (`scheme` field) and verify with `npx uri-scheme`, because deep links that work in development but fail in production are a common cause of user-facing bugs and broken marketing flows.
-
-8. **Handle navigation state persistence and restoration** by implementing `onStateChange` and `initialState` on the root navigator, because users expect to return to their previous screen after the app is killed and restarted from a background state.
-
-9. **Separate business logic from UI using custom hooks and context** rather than embedding logic in screen components, because screen components change frequently with navigation refactors while business logic should remain stable and testable.
-
-10. **Profile rendering performance with React DevTools and Flipper** using the `<Profiler>` component and the Fabric performance overlay, because mobile devices have constrained CPU/GPU and janky frames (>16ms) directly impact user retention.
-
-11. **Optimize list rendering with `FlashList`** instead of `FlatList` for large datasets, because FlashList recycles native views and reduces JS-to-native bridge calls, achieving consistent 60fps on mid-range devices.
-
-12. **Minimize JS bundle size** by enabling Hermes engine, using `import()` for lazy screens, and tree-shaking unused exports, because large bundles increase cold-start time on Android devices by 200-500ms per megabyte.
-
-13. **Write component tests with Jest and React Native Testing Library** using `@testing-library/react-native`, because testing against the component tree (not implementation details) catches regressions while allowing refactoring freedom.
-
-14. **Test navigation flows with Detox or Maestro** for E2E coverage on real device behavior, because navigation state machines, gesture handlers, and native transitions cannot be fully validated in a JS-only test environment.
-
-15. **Configure EAS Build profiles** (`development`, `preview`, `production`) in `eas.json`, because each build profile needs different signing credentials, environment variables, and optimization flags that must not leak across environments.
-
-16. **Implement over-the-air updates with `expo-updates`** for JavaScript-only changes, because OTA updates bypass app store review cycles and allow critical bug fixes to reach users within minutes instead of days.
-
-## Output Format
-
-When delivering React Native + Expo code:
-
-1. **Screen components** -- `.tsx` files in `app/` directory following Expo Router file conventions
-2. **Native modules** -- Expo Module definitions with Swift/Kotlin implementations and TypeScript bindings
-3. **Navigation configuration** -- Deep linking schemes, typed route params, and navigation guards
-4. **Test files** -- `.test.tsx` files with RNTL for components and Detox/Maestro specs for E2E
-5. **Build configuration** -- `app.json`, `eas.json`, and environment-specific config files
-6. **Brief rationale** -- One-sentence explanation for each architectural decision
-
-## References
-
-Load detailed guidance based on context:
-
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| New Architecture | `references/new-architecture.md` | Fabric, TurboModules, codegen, migration |
-| Navigation | `references/navigation.md` | Expo Router, deep linking, typed routes, guards |
-| Native Modules | `references/native-modules.md` | Expo Modules API, Swift/Kotlin bridging, codegen |
-| Testing | `references/testing.md` | Jest, RNTL, Detox, Maestro, mocking native APIs |
-| Performance | `references/performance.md` | Hermes, FlashList, profiling, bundle optimization |
-
-## Copilot Platform Notes
-
-- Custom agents are defined in `.github/agents/*.md` with YAML frontmatter: `name`, `description`, `tools`, `model`, `handoffs`.
-- Agent `handoffs` field enables guided workflow transitions (e.g., `@project-planner` → `@orchestrator`).
-- Skill files are stored under `.github/skills/` (skill markdown) and `.github/prompts/` (prompt files).
-- Path-scoped instructions in `.github/instructions/*.instructions.md` provide file-pattern-targeted guidance via `applyTo` frontmatter.
-- User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
-- Frontmatter keys `context: fork` and `allowed-tools` are not natively supported; guidance is advisory.
-- Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.
-- MCP configuration lives in `.vscode/mcp.json`. MCP skill tools are available when configured.
-- Rules file: `.github/copilot-instructions.md` — broad and stable, not task-specific.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/react-native/evals/assertions.md

@@ -1,50 +0,0 @@
-# React Native with Expo -- Eval Assertions
-
-## Eval 01: Navigation with deep linking
-
-This eval validates correct implementation of Expo Router navigation with deep linking, typed parameters, and cold-start handling.
-
-### Assertions
-
-| # | Type | Target | Rationale |
-|---|------|--------|-----------|
-| 1 | pattern | `app/.*\.(tsx\|ts)` | Verifies the skill uses file-based routing in the `app/` directory. Expo Router requires route files in `app/` to generate the navigation tree automatically. |
-| 2 | contains | `scheme` | Verifies the skill configures a deep linking scheme. The `scheme` field in `app.json` registers the URL protocol (e.g., `myapp://`) that the OS routes to the app. |
-| 3 | pattern | `\[id\]\|useLocalSearchParams\|useGlobalSearchParams` | Verifies the skill implements typed dynamic route parameters. Product detail requires an `id` param accessed via Expo Router's typed search param hooks. |
-| 4 | pattern | `Tabs\|Tab\|_layout` | Verifies the skill implements tab navigation. The Home screen requires a tab layout defined in an `_layout.tsx` file using Expo Router's `<Tabs>` component. |
-| 5 | pattern | `Linking\|linking\|useURL\|expo-linking` | Verifies the skill handles incoming deep links. Cold-start deep link handling requires `expo-linking` or Expo Router's built-in URL resolution to read the initial URL. |
-
-### What a passing response looks like
-
-A passing response provides:
-- An `app/_layout.tsx` root layout with navigation container setup
-- An `app/(tabs)/_layout.tsx` tab navigator for Home
-- An `app/product/[id].tsx` screen with `useLocalSearchParams<{ id: string }>()`
-- Deep link scheme configuration in `app.json` (`"scheme": "myapp"`)
-- Cold-start handling that reads the initial URL and navigates to the correct screen
-- TypeScript type definitions for all route parameters
-
----
-
-## Eval 02: Native module bridging with Expo Modules
-
-This eval validates correct creation of a custom Expo Module with native Swift/Kotlin implementations and TypeScript bindings.
-
-### Assertions
-
-| # | Type | Target | Rationale |
-|---|------|--------|-----------|
-| 1 | pattern | `Module\|ExpoModule\|expo-modules-core` | Verifies the skill uses the Expo Modules API. Expo Modules provide a unified module definition API that generates TurboModule-compatible bindings for both platforms. |
-| 2 | pattern | `UIImpactFeedbackGenerator\|UIKit\|haptic` | Verifies the skill includes the iOS native implementation. On iOS, haptic feedback requires `UIImpactFeedbackGenerator` from UIKit with the correct feedback style. |
-| 3 | pattern | `VibrationEffect\|Vibrator\|android\.os` | Verifies the skill includes the Android native implementation. On Android, haptic feedback requires `VibrationEffect` (API 26+) or the legacy `Vibrator` service. |
-| 4 | pattern | `Function\|AsyncFunction\|function\(` | Verifies the skill defines module functions using Expo's function registration API. Each exposed method must be registered via `Function("name") { ... }` in the module definition. |
-| 5 | pattern | `export.*triggerImpact\|import.*ExpoHaptics` | Verifies the skill provides TypeScript exports and demonstrates consumption. The module must have a TypeScript facade that consumers import, preserving type safety. |
-
-### What a passing response looks like
-
-A passing response provides:
-- An `ExpoHapticsModule.ts` definition using `expo-modules-core` API
-- A `ExpoHapticsModule.swift` iOS implementation using `UIImpactFeedbackGenerator` with `.light`, `.medium`, `.heavy` styles
-- A `ExpoHapticsModule.kt` Android implementation using `VibrationEffect.createOneShot()` with appropriate amplitudes
-- TypeScript type definitions for the `triggerImpact(style)` function with the union type parameter
-- An example React Native component that imports and calls the module

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/react-native/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "react-native-eval-01",
-    "name": "Navigation with deep linking",
-    "description": "Validate that the skill correctly guides implementation of Expo Router navigation with deep linking, typed route parameters, and universal link handling.",
-    "prompt": "Set up Expo Router navigation for a React Native app with the following screens: Home (tabs), Product Detail (stack with id param), and Settings (drawer). Configure deep linking so that `myapp://product/123` opens the Product Detail screen. Include TypeScript types for all route params and handle the case where a deep link arrives while the app is in a killed state.",
-    "assertions": [
-      {
-        "type": "pattern",
-        "value": "app/.*\\.(tsx|ts)",
-        "description": "Must use file-based routing in the app/ directory following Expo Router conventions"
-      },
-      {
-        "type": "contains",
-        "value": "scheme",
-        "description": "Must configure a deep linking scheme (e.g., in app.json or app.config.ts) for universal/deep link handling"
-      },
-      {
-        "type": "pattern",
-        "value": "\\[id\\]|useLocalSearchParams|useGlobalSearchParams",
-        "description": "Must implement typed dynamic route parameters for the product detail screen"
-      },
-      {
-        "type": "pattern",
-        "value": "Tabs|Tab|_layout",
-        "description": "Must implement tab-based navigation using Expo Router layout files"
-      },
-      {
-        "type": "pattern",
-        "value": "Linking|linking|useURL|expo-linking",
-        "description": "Must handle incoming deep links including cold-start scenarios using Expo Linking or equivalent"
-      }
-    ]
-  },
-  {
-    "id": "react-native-eval-02",
-    "name": "Native module bridging with Expo Modules",
-    "description": "Validate that the skill correctly guides creation of a custom native module using the Expo Modules API with Swift/Kotlin implementations and TypeScript bindings.",
-    "prompt": "Create an Expo Module called `ExpoHaptics` that exposes a `triggerImpact(style: 'light' | 'medium' | 'heavy')` method. Implement the Swift code for iOS using UIImpactFeedbackGenerator and the Kotlin code for Android using VibrationEffect. Include the TypeScript type definitions and show how to consume the module from a React Native component. Ensure the module uses TurboModule codegen specs.",
-    "assertions": [
-      {
-        "type": "pattern",
-        "value": "Module|ExpoModule|expo-modules-core",
-        "description": "Must use the Expo Modules API (expo-modules-core) for defining the native module"
-      },
-      {
-        "type": "pattern",
-        "value": "UIImpactFeedbackGenerator|UIKit|haptic",
-        "description": "Must include iOS Swift implementation using UIImpactFeedbackGenerator for haptic feedback"
-      },
-      {
-        "type": "pattern",
-        "value": "VibrationEffect|Vibrator|android\\.os",
-        "description": "Must include Android Kotlin implementation using VibrationEffect or Vibrator for haptic feedback"
-      },
-      {
-        "type": "pattern",
-        "value": "Function|AsyncFunction|function\\(",
-        "description": "Must define module functions using Expo Modules function registration API"
-      },
-      {
-        "type": "pattern",
-        "value": "export.*triggerImpact|import.*ExpoHaptics",
-        "description": "Must provide TypeScript exports and show consumption from a React Native component"
-      }
-    ]
-  }
-]