mandrel 1.57.0

package/.agents/skills/stack/architecture/structured-output-zod/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: structured-output-zod
+description:
+  Validates external and structured data with Zod schemas. Use when accepting
+  untrusted input at API boundaries, validating environment variables on
+  startup, parsing third-party responses, or generating typed shapes via
+  `z.infer`. Parse, don't validate.
+vendor: zod
+---
+
+# Skill: Structured Output (Zod)
+
+## Policy Capsule
+
+- Define every external or structured data shape as a Zod schema before it is processed or stored.
+- Derive TypeScript types from schemas via `z.infer`; never hand-author a parallel `type` for the same shape.
+- Parse untrusted input with `z.parse()` or `z.safeParse()` — do not pass raw values past the boundary.
+- Validate every incoming request body and query parameter at the application boundary.
+- Validate `process.env` at startup with a Zod schema so missing or malformed config fails fast.
+- Compose complex schemas with `.extend()`, `.merge()`, and `.pick()` to keep shapes DRY.
+- Use `z.coerce.*` deliberately for form and query inputs; do not coerce in trusted server-to-server paths.
+
+Guidelines for ensuring system reliability through schema validation and typed
+safety.
+
+## 1. Core Principles
+
+- **Schema First:** Always define data shapes with Zod before processing or
+  storing external data.
+- **Type Safety:** Leverage Zod's `z.infer` to automatically generate TypeScript
+  types from your schemas.
+- **Parse, Don't Validate:** Use `z.parse()` or `z.safeParse()` to transform
+  untrusted input into trusted, typed objects.
+
+## 2. Technical Standards
+
+- **API Validation:** Validate every incoming request body and query parameter
+  at the application boundary.
+- **Environment Variables:** Use Zod to validate `process.env` on startup to
+  fail fast if critical config is missing.
+- **Database Schemas:** In systems like Drizzle or Turso collections, use Zod
+  schemas to ensure data integrity during writes.
+
+## 3. Best Practices
+
+- **Error Messages:** Provide user-friendly, specific error messages via Zod's
+  custom error formatting.
+- **Composition:** Build complex schemas using `.extend()`, `.merge()`, and
+  `.pick()` to maintain DRY principles in your types.
+- **Coercion:** Use Zod coercion (`z.coerce.number()`) carefully to handle
+  string inputs from forms or query parameters.

package/.agents/skills/stack/architecture/subagent-orchestration/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: subagent-orchestration
+description:
+  Coordinates complex tasks via task-isolated subagents. Use when one objective
+  is too large for a single agent or when independent work streams should run
+  concurrently with minimal context bleed. One objective per subagent;
+  summarize before returning to keep the main context window clean.
+---
+
+# Skill: Subagent Orchestration
+
+## Policy Capsule
+
+- Dispatch one objective per subagent; never bundle unrelated goals into a single delegation.
+- Hand each subagent only the minimum context (files, docs, goal) required — no broad context dumps.
+- Specify the expected return format explicitly (JSON summary, diff, bullet list) in every handoff.
+- Verify the subagent's output before incorporating it; treat returned artifacts as untrusted until checked.
+- Run non-dependent subagents in parallel; serialize only when one subagent's output is required input for another.
+- Require a concise summary back from each subagent to keep the main context window clean.
+- Investigate subagent failures rather than retrying blindly with the same prompt.
+
+Internal protocol for managing complex tasks through the creation and
+coordination of subagents.
+
+## 1. Core Principles
+
+- **Task Isolation:** One objective per subagent. Do not overload a subagent
+  with multiple unrelated tasks.
+- **Minimal Context:** Provide only the necessary context (files, docs, specific
+  goal) to keep the subagent focused and token-efficient.
+- **Verification:** The main agent must always verify the subagent's output
+  before incorporating it into the final solution.
+
+## 2. Operation Standards
+
+- **Handoffs:** When delegating, clearly state the expected return format (e.g.,
+  "Return a JSON summary", "Provide a diff for file X").
+- **Error Handling:** If a subagent fails or returns an ambiguous result,
+  investigate the failure rather than retrying blindly.
+- **Parallelism:** Use subagents to perform non-dependent tasks concurrently
+  (e.g., auditing three different modules simultaneously).
+
+## 3. Best Practices
+
+- **State Sync:** Ensure the main agent's mental model remains the source of
+  truth if multiple subagents modify the codebase.
+- **Summarization:** Require subagents to provide a concise summary of their
+  findings to prevent the main context window from being flooded.

package/.agents/skills/stack/backend/cloudflare-hono-architect/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: cloudflare-hono-architect
+description:
+  Prevents Node.js module hallucinations in Cloudflare Worker (V8 isolate)
+  edge environments. Use when writing Hono routes deployed to Workers — prefer
+  Web APIs (Fetch, Web Crypto) over Node built-ins (`fs`, `path`,
+  `child_process`, `crypto`), and access bindings via Hono's `c.env`.
+vendor: cloudflare
+---
+
+# Cloudflare Worker & Hono Architect
+
+## Policy Capsule
+
+- Never import Node.js built-ins (`fs`, `path`, `child_process`, Node's `crypto`) in Worker code — they do not exist in the V8 isolate runtime.
+- Use the Web Crypto API for hashing, signing, and random bytes; do not reach for `node:crypto`.
+- Access bindings (env vars, R2 buckets, KV, Queues, D1) only through Hono's context (`c.env`), never through `process.env`.
+- Prefer Web platform APIs (`fetch`, `Request`, `Response`, `URLPattern`) over Node-flavored equivalents.
+- Treat any import that resolves to a Node-only polyfill as a hallucination — surface and remove it.
+
+**Description:** Prevents Node.js module hallucinations in edge environments.
+
+**Instruction:** The API is built with Hono and deployed to Cloudflare Workers
+(V8 Isolates).
+
+- YOU MUST NOT use standard Node.js built-ins (e.g., `fs`, `path`,
+  `child_process`).
+- If cryptography is needed, use the standard Web Crypto API, not Node's
+  `crypto`.
+- Access all environment variables, R2 buckets, and Queues strictly through the
+  Hono Context bindings (`c.env`).

package/.agents/skills/stack/backend/cloudflare-hono-architect/examples/route-template.ts

@@ -0,0 +1,33 @@
+import { zValidator } from '@hono/zod-validator';
+import { Hono } from 'hono';
+import { z } from 'zod';
+
+// EXAMPLE: Strict Cloudflare environment bindings
+type Bindings = {
+  DB: D1Database;
+  STRIPE_SECRET_KEY: string;
+  MY_QUEUE: Queue;
+};
+
+const app = new Hono<{ Bindings: Bindings }>();
+
+// EXAMPLE: Route with strict Zod validation and c.env access
+app.post(
+  '/api/example',
+  zValidator(
+    'json',
+    z.object({
+      title: z.string().min(1),
+    }),
+  ),
+  async (c) => {
+    const { title } = c.req.valid('json');
+    const _db = c.env.DB; // Access via Cloudflare bindings, NOT process.env
+
+    // Implementation here...
+
+    return c.json({ success: true, title }, 201);
+  },
+);
+
+export default app;

package/.agents/skills/stack/backend/cloudflare-queue-manager/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: cloudflare-queue-manager
+description:
+  Ensures idempotent and resilient background job execution on Cloudflare
+  Queues. Use when writing consumer handlers — design for at-least-once
+  delivery, wrap processing in try/catch with `message.retry()`, and order
+  cascading deletes so the database row drops last.
+vendor: cloudflare
+---
+
+# Cloudflare Queue Lifecycle Manager
+
+## Policy Capsule
+
+- Design every consumer handler to be idempotent; assume at-least-once delivery and treat duplicate messages as expected.
+- Wrap message processing in `try/catch`; never let an unhandled throw kill the worker mid-batch.
+- Use `message.retry()` for transient failures rather than crashing the whole consumer.
+- For cascading deletions, delete third-party assets (Mux, R2, external APIs) first and the database row last to avoid orphans.
+- Log each message ID and processing outcome so retried duplicates are traceable across replays.
+
+**Description:** Ensures idempotent and resilient background job execution.
+
+**Instruction:** You are writing consumer logic for Cloudflare Queues.
+
+- Always assume messages can be delivered more than once; design all worker
+  logic for strict idempotency.
+- Wrap processing logic in `try/catch` blocks.
+- If a sub-task fails (e.g., deleting a video from a third-party API), do NOT
+  crash the whole worker. Log the error and use `message.retry()` strategically.
+- For cascading deletions, ensure the database deletion happens LAST, only after
+  third-party assets (Mux, R2) are confirmed deleted, to avoid orphaned data.

package/.agents/skills/stack/backend/cloudflare-workers/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: cloudflare-workers
+description:
+  Builds and deploys high-performance edge logic on Cloudflare Workers. Use
+  when working within Workers' 128MB memory and 5–50ms CPU constraints,
+  integrating KV/R2/D1 storage, or writing Wrangler-managed edge-first
+  request/response code.
+vendor: cloudflare
+---
+
+# Skill: Cloudflare Workers
+
+## Policy Capsule
+
+- Respect the Worker resource envelope: 128MB memory and 5–50ms CPU per invocation; design code paths to fit inside it.
+- Configure and deploy via Wrangler; do not hand-roll deployment scripts.
+- Pick the right storage primitive: KV for simple key-value, R2 for object storage, D1 for relational data.
+- Use the standard Fetch API for outgoing HTTP; never reach for Node-flavored HTTP clients.
+- Store secrets with `wrangler secret`; never commit secrets to source.
+- Minimize sub-requests per invocation to stay under platform limits.
+- Stream large payloads via `TransformStream`; never buffer them entirely into memory.
+- Install a global error handler so a single failing request does not take down the worker.
+
+Guidelines for building and deploying high-performance serverless logic at the
+edge.
+
+## 1. Core Principles
+
+- **Edge First:** Run code as close to the user as possible.
+- **Resource Constraints:** Be mindful of the 128MB memory limit and the strict
+  CPU time limits (e.g., 5-50ms) for workers.
+- **Cold Starts:** Workers have near-zero cold starts, but external resource
+  initialization must be optimized.
+
+## 2. Technical Standards
+
+- **Routing:** Use `Wrangler` for configuration and local development.
+- **Storage Integration:** Use `KV` for simple key-value needs, `R2` for object
+  storage, and `D1` for relational data.
+- **Fetch API:** Always use the standard Fetch API for outgoing network
+  requests.
+- **Security:** Use `wrangler secret` for environment variables and API keys.
+
+## 3. Best Practices
+
+- **Sub-requests:** Minimize the number of sub-requests per worker invocation to
+  stay within limits.
+- **Streaming:** Use the `TransformStream` API for processing large payloads
+  without loading everything into memory.
+- **Error Handling:** Implement robust global error handlers to prevent total
+  worker failure on a single request error.

package/.agents/skills/stack/backend/highlevel-crm/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: highlevel-crm
+description:
+  Integrates with the HighLevel (GoHighLevel) CRM API v2 and its automation
+  engine. Use when synchronizing data via OAuth 2.0, building custom widgets,
+  handling sub-account `locationId` scoping, or implementing webhook-driven
+  workflows with rate-limit-aware retries.
+vendor: highlevel
+---
+
+# Skill: HighLevel CRM (GoHighLevel)
+
+## Policy Capsule
+
+- Integrate with HighLevel exclusively through API v2 over OAuth 2.0; never hardcode credentials.
+- Manage `access_token` and `refresh_token` rotation in code — assume tokens expire and refresh proactively.
+- Include `locationId` on every API request to scope writes to the correct sub-account.
+- Prefer HighLevel's native automation engine; reach for custom code only when native workflows cannot express the requirement.
+- Implement exponential-backoff retry to respect HighLevel's API rate limits.
+- Use email as the primary key for contact deduplication; do not rely on CRM-internal IDs for cross-system joins.
+- Drive event-driven flows through HighLevel webhooks rather than polling.
+- Test integrations against a sandbox sub-account before pointing them at live data.
+
+Protocols for integrating with the HighLevel CRM API (v2) and building custom
+widgets/automations.
+
+## 1. Core Principles
+
+- **API-First Integration:** Use the HighLevel API v2 for all data
+  synchronization, focusing on OAuth 2.0 security.
+- **Workflow Automation:** Leverage HighLevel's internal automation engine
+  effectively; only use custom code when native workflows are insufficient.
+- **Data Integrity:** Ensure all custom fields, tags, and contacts are mapped
+  accurately to prevent data corruption.
+
+## 2. Technical Standards
+
+- **OAuth 2.0:** Securely manage `access_token` and `refresh_token` flows. Never
+  hardcode credentials.
+- **Webhooks:** Use webhooks to trigger application logic when events occur in
+  CRM (e.g., contact created, opportunity moved).
+- **Rate Limiting:** Implement exponential backoff and retry logic to respect
+  HighLevel's API rate limits.
+- **Location Context:** Always include the `locationId` in your API requests to
+  ensure data is scoped to the correct sub-account.
+
+## 3. Best Practices
+
+- **Custom Fields:** Use unique, descriptive names for custom fields and mapping
+  keys to avoid collisions.
+- **Contact Sync:** Use email addresses as the primary identifier for contact
+  deduplication.
+- **Testing:** Always use a sandbox/test sub-account in HighLevel before
+  deploying integrations to live accounts.

package/.agents/skills/stack/backend/sqlite-drizzle-expert/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: sqlite-drizzle-expert
+description:
+  Enforces SQLite dialect for Drizzle ORM and Turso (libSQL). Use when writing
+  schema or queries with `drizzle-orm/sqlite-core` — avoid PostgreSQL-only
+  types (`serial`, `jsonb`, `uuid`), use `text()` for IDs and dates, and
+  define relations explicitly via the `relations` API.
+vendor: drizzle
+---
+
+# SQLite Drizzle Expert
+
+## Policy Capsule
+
+- Import only from `drizzle-orm/sqlite-core`; never mix in PostgreSQL or MySQL Drizzle modules.
+- Never use Postgres-only types (`serial`, `jsonb`, `uuid`) — SQLite does not implement them.
+- Use `text()` for IDs, enums, and date columns.
+- Use `integer({ mode: 'boolean' })` for booleans; SQLite has no native boolean type.
+- Define every relation explicitly with Drizzle's `relations` API rather than relying on implicit foreign-key inference.
+
+**Description:** Enforces SQLite dialect for Drizzle ORM and Turso.
+
+**Instruction:** You are modifying a Turso (libSQL) database using Drizzle ORM.
+You MUST strictly use `drizzle-orm/sqlite-core`.
+
+- NEVER use PostgreSQL-specific types like `serial`, `jsonb`, or `uuid`.
+- Use `text()` for IDs, Enums, and dates.
+- Use `integer({ mode: 'boolean' })` for booleans.
+- Ensure all relations are explicitly defined using Drizzle's `relations` API.

package/.agents/skills/stack/backend/sqlite-drizzle-expert/examples/schema-template.ts

@@ -0,0 +1,30 @@
+import { relations, sql } from 'drizzle-orm';
+import { integer, sqliteTable, text } from 'drizzle-orm/sqlite-core';
+
+// EXAMPLE: Standard SQLite table optimized for Turso
+export const users = sqliteTable('users', {
+  id: text('id').primaryKey(), // DO NOT use uuid() or serial()
+  email: text('email').notNull().unique(),
+  isActive: integer('is_active', { mode: 'boolean' }).default(true), // SQLite boolean workaround
+  createdAt: text('created_at').default(sql`CURRENT_TIMESTAMP`).notNull(),
+});
+
+export const posts = sqliteTable('posts', {
+  id: text('id').primaryKey(),
+  authorId: text('author_id')
+    .notNull()
+    .references(() => users.id, { onDelete: 'cascade' }),
+  content: text('content').notNull(),
+});
+
+// EXAMPLE: Explicit relations definition
+export const usersRelations = relations(users, ({ many }) => ({
+  posts: many(posts),
+}));
+
+export const postsRelations = relations(posts, ({ one }) => ({
+  author: one(users, {
+    fields: [posts.authorId],
+    references: [users.id],
+  }),
+}));

package/.agents/skills/stack/backend/stripe-integration/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: stripe-integration
+description:
+  Implements secure Stripe payments and subscription billing. Use when handling
+  card data (PCI compliance via Elements/Checkout), verifying webhook
+  signatures, attaching `idempotencyKey` to mutations, or treating the
+  server-side webhook as the source of truth for entitlement changes.
+vendor: stripe
+---
+
+# Skill: Stripe Payments & Billing
+
+## Policy Capsule
+
+- Never let raw card data touch your servers; collect payment details through Stripe Elements or Checkout.
+- Treat the server-side webhook as the source of truth for entitlement changes; never trust client-side success redirects.
+- Verify the `Stripe-Signature` header against the raw request body using the configured webhook secret before parsing any payload.
+- Attach an `idempotencyKey` to every Stripe API mutation to prevent duplicate charges on retry.
+- Use the official `stripe` Node SDK for backend calls; do not hand-roll HTTP requests.
+- Store Stripe object IDs (Customer, Price, Subscription) in your database — never store PCI-sensitive card data.
+- Log Stripe event IDs for traceability, but exclude sensitive customer data from logs.
+- Use Stripe's test environment and test cards for all development and QA.
+
+Standard procedures for secure and robust payment + subscription billing
+integration using Stripe.
+
+## 1. Core Principles
+
+- **PCI Compliance:** Never let sensitive card data touch your servers. Use
+  Stripe Elements or Checkout.
+- **Webhooks are Mandatory:** Never rely on successful client-side redirects to
+  confirm payments. Always verify via webhooks. Webhook handlers MUST verify the
+  `Stripe-Signature` header using the raw request body and the configured
+  webhook secret before parsing any data.
+- **Idempotency:** Every Stripe API mutation MUST include an `idempotencyKey` to
+  prevent duplicate charges or state changes during network retries.
+- **Server is Source of Truth:** Never trust client-side success states for
+  granting access or upgrading tiers; always rely on the asynchronous
+  server-side webhook to update the database.
+
+## 2. Technical Standards
+
+- **Stripe SDK:** Use the official `stripe` Node.js library for backend
+  operations.
+- **Elements / Checkout:** Use Stripe Elements for custom-branded checkout or
+  Checkout for the fastest implementation.
+- **Error Handling:** Gracefully handle payment failures, card declines, and
+  expired sessions.
+
+## 3. Best Practices
+
+- **Test Mode:** Use Stripe's test environment and test card numbers for all
+  development and QA.
+- **Logging:** Log Stripe event IDs for troubleshooting, but exclude any
+  sensitive customer data.
+- **Sub-records:** Store Stripe IDs (Customer ID, Price ID, Subscription ID) in
+  your database, not PCI-sensitive data.

package/.agents/skills/stack/backend/stripe-integration/scripts/listen-stripe.sh

@@ -0,0 +1,9 @@
+#!/bin/bash
+# Description: Forwards Stripe webhooks to the local Cloudflare Worker environment.
+# Prerequisite: Ensure stripe-cli is installed and authenticated.
+
+echo "Starting Stripe webhook forwarding to local Hono API..."
+echo "Ensure your worker is running on port 8787"
+
+# Replace 8787 with the actual port your local Cloudflare worker uses
+stripe listen --forward-to localhost:8787/v1/webhooks/stripe

package/.agents/skills/stack/backend/turso-sqlite/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: turso-sqlite
+description:
+  Develops with Turso's distributed SQLite (libSQL) platform. Use when working
+  with the `@libsql/client` driver — leverage edge replicas for low-latency
+  reads, route writes to the primary, and use parameterized queries plus a
+  versioned migration tool (drizzle-kit, atlas) for schema changes.
+vendor: turso
+---
+
+# Skill: Turso (SQLite)
+
+## Policy Capsule
+
+- Use the `@libsql/client` driver for all database operations; do not mix in other SQLite clients.
+- Always use parameterized queries (`?` or `:name`); never interpolate user input into SQL strings.
+- Route reads to the nearest edge replica and writes to the primary; do not write to a replica.
+- Manage schema changes through a versioned migration tool (`drizzle-kit`, `atlas`) checked into git; never hand-mutate production schema.
+- Reuse the libSQL client instance within a worker invocation to avoid repeated handshake overhead.
+- Audit slow queries with `EXPLAIN QUERY PLAN` and add indexes where the plan shows a full scan on a large table.
+
+Rules for developing with Turso's distributed SQLite database platform.
+
+## 1. Core Principles
+
+- **Edge Efficiency:** Leverage Turso's low-latency distribution for edge
+  applications.
+- **SQLite Simplicity:** Use standard SQL syntax. SQLite is powerful—don't
+  over-engineer with complex ORMs unless necessary.
+- **Replication:** Understand the primary/replica architecture for
+  geographically distributed workloads.
+
+## 2. Technical Standards
+
+- **Driver Usage:** Use the `@libsql/client` driver for all database operations.
+- **Parameterized Queries:** Never use string interpolation for queries. Always
+  use placeholders (`?` or `:name`) to prevent SQL injection.
+- **Migrations:** Use a structured migration tool (e.g., `drizzle-kit` or
+  `atlas`) to manage schema changes versioned in git.
+
+## 3. Best Practices
+
+- **Connection Management:** Reuse database client instances within a worker
+  invocation to minimize handshake overhead.
+- **Read-Local, Write-Primary:** Direct read operations to the nearest replica
+  and write operations to the primary instance.
+- **Profiling:** Use `EXPLAIN QUERY PLAN` to audit slow queries and ensure
+  proper indexing of large tables.

package/.agents/skills/stack/frontend/astro/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: astro
+description:
+  Builds ultra-fast content-driven websites with Astro. Use when defaulting to
+  SSG, opting into SSR only for dynamic data, picking the most restrictive
+  `client:*` hydration directive, leveraging Server Islands (`server:defer`),
+  Astro Actions for type-safe mutations, and the Content Layer with Zod-
+  validated collections.
+vendor: astro
+---
+
+# Skill: Astro (Iron)
+
+## Policy Capsule
+
+- Default to SSG; opt into SSR only when a route requires per-request dynamic data.
+- Ship zero JS by default — `.astro` components must not bundle client JavaScript unless a `client:*` directive is set explicitly.
+- For personalized or dynamic islands, prefer `server:defer` (Server Islands) over shipping a fully hydrated client island.
+- Use the most restrictive hydration directive that meets the interaction: `client:load` only for immediate interactivity, `client:visible` for below-the-fold, `client:idle` for non-critical logic.
+- Handle data mutations and form submissions through Astro Actions, not ad-hoc fetch handlers, to preserve type safety.
+- Source content through the Content Layer API with Zod-validated collections in `src/content/config.ts`.
+- Use the built-in `<Image />` and `<Picture />` components for image optimization rather than raw `<img>` tags.
+- Inject SEO metadata (`title`, `meta`, `og:image`, `canonical`) from a shared layout component.
+
+Guidelines and best practices for building ultra-fast content-driven websites
+using Astro.
+
+## 1. Core Principles
+
+- **Static First:** Default to SSG (Static Site Generation). Use SSR only when
+  dynamic user data or real-time interaction is required.
+- **Island Architecture:** Use standard HTML for most of the page.
+- **Server Islands (Astro 5):** Use the `server:defer` directive for components
+  that depend on personalized or dynamic data.
+- **Astro Actions:** Use built-in Actions for all data mutations and form
+  submissions to ensure type-safety.
+- **Zero JS by Default:** Ensure components use `.astro` syntax and do not ship
+  any JavaScript to the client unless explicitly requested via `client:*`
+  directives.
+
+## 2. Technical Standards
+
+- **Component Structure:**
+  - Logic (JS/TS) in the component script (top `---` fence).
+  - Markup in the HTML template.
+  - Scoped CSS in the `<style>` block.
+- **Content Layer API:** Always use the new Content Layer for data sourcing.
+  Manage collections via `src/content/config.ts` with Zod schema validation for
+  all metadata.
+- **Hydration Directives:** Use the most restrictive directive possible:
+  - `client:load` for immediate interactivity.
+  - `client:visible` for elements below the fold.
+  - `client:idle` for non-critical logic.
+
+## 3. Best Practices
+
+- **Image Optimization:** Always use the `<Image />` or `<Picture />` components
+  for automatic format conversion and resizing.
+- **Metadata/SEO:** Use a layout component to inject standard SEO tags (`title`,
+  `meta`, `og:image`, `canonical`).
+- **View Transitions:** Use Astro's built-in view transitions for SPA-like
+  navigation without the performance overhead.

package/.agents/skills/stack/frontend/astro-react-island-strategist/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: astro-react-island-strategist
+description:
+  Maintains strict boundaries between Astro server components and React client
+  islands in hybrid Astro/React workspaces. Use when keeping `.astro` files
+  for static HTML/SEO and `.tsx` for interactive islands — embed React only
+  with explicit `client:*` directives and pass serializable props.
+vendor: astro
+---
+
+# Astro & React Island Strategist
+
+## Policy Capsule
+
+- Use `.astro` files for static HTML generation, routing, and SEO; do not reach for React when Astro suffices.
+- Use React `.tsx` files only for genuinely interactive UI islands, not for static rendering.
+- Embed a React component in Astro only with an explicit `client:*` directive (`client:load`, `client:idle`, `client:visible`).
+- Pick the most restrictive `client:*` directive that satisfies the interaction — prefer `client:idle` or `client:visible` over `client:load` whenever possible.
+- Pass only serializable data as props across the Astro → React island boundary; never pass functions or class instances.
+
+**Description:** Maintains strict boundaries between Astro server components and
+React client islands.
+
+**Instruction:** For the `@repo/web` workspace:
+
+- Use `.astro` files strictly for static HTML generation, routing, and SEO.
+- Use React `.tsx` files ONLY for highly interactive UI components (islands).
+- When embedding a React component in an Astro file, you MUST explicitly use
+  client directives (e.g., `client:load` or `client:idle`).
+- Only pass serializable data as props from Astro to React.

package/.agents/skills/stack/frontend/expo-react-native-developer/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: expo-react-native-developer
+description:
+  Prevents DOM element usage in React Native (Expo) workspaces. Use when
+  writing components for Expo apps — `<View>`, `<Text>`, `<TouchableOpacity>`
+  instead of `<div>`/`<span>`/`<p>`, no `window`/`document`, and styling
+  through the project's established solution.
+vendor: expo
+---
+
+# Expo React Native Developer
+
+## Policy Capsule
+
+- Never use HTML DOM elements (`<div>`, `<span>`, `<p>`, `<button>`, etc.) inside Expo or React Native components.
+- Use React Native primitives instead: `<View>`, `<Text>`, `<TouchableOpacity>`, `<Pressable>`, `<ScrollView>`.
+- Never reference browser globals (`window`, `document`, `localStorage`) in React Native code paths.
+- Route all styling through the project's established styling solution; do not introduce a parallel CSS pipeline.
+- Treat the `@repo/mobile` workspace as DOM-free — any DOM symbol that appears is a hallucination and must be replaced.
+
+**Description:** Prevents DOM element usage in React Native.
+
+**Instruction:** For the `@repo/mobile` workspace:
+
+- YOU MUST NOT use HTML DOM elements like `<div>`, `<span>`, or `<p>`.
+- Use strict React Native primitives: `<View>`, `<Text>`, `<TouchableOpacity>`,
+  etc.
+- Ensure all styling uses the established styling solution.
+- Never use `window` or `document` objects.

package/.agents/skills/stack/frontend/google-analytics-v4/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: google-analytics-v4
+description:
+  Implements privacy-compliant event tracking with Google Analytics 4. Use
+  when wiring analytics that must comply with GDPR/CCPA via Consent Mode V2 —
+  `snake_case` event names, no PII to GA servers, GTM-driven event firing,
+  and DebugView verification before deploy.
+vendor: google
+---
+
+# Skill: Google Analytics 4 (GA4)
+
+## Policy Capsule
+
+- Implement Consent Mode V2 and respect GDPR/CCPA; never send PII to GA servers.
+- Track meaningful business actions (e.g. `start_checkout`, `share_article`) rather than relying solely on page views.
+- Use `snake_case` for every event name and parameter — GA4 enforces this convention.
+- Fire all events through Google Tag Manager rather than embedding measurement IDs directly in application code.
+- Define critical user attributes (e.g. `user_type`, `pricing_plan`) as custom dimensions on the GA4 property.
+- Verify every new event in GA4 DebugView before deploying to production.
+- Filter development and internal traffic out of the production GA4 property.
+- Keep IP anonymization enabled and configure cross-domain tracking when traffic spans multiple origins.
+
+Guidelines for privacy-compliant and data-driven event tracking using GA4.
+
+## 1. Core Principles
+
+- **Privacy Compliance:** Adhere to GDPR and CCPA. Implement Consent Mode V2 and
+  never send PII to GA servers.
+- **Event-Driven:** Focus on meaningful user actions (e.g., "start_checkout",
+  "share_article") rather than just page views.
+- **Data Accuracy:** Filter out development and internal traffic from production
+  property data.
+
+## 2. Technical Standards
+
+- **GTM Integration:** Use Google Tag Manager for event firing to decouple
+  marketing tags from core application code.
+- **Custom Dimensions:** Define critical data points (e.g., `user_type`,
+  `pricing_plan`) as custom dimensions in the GA4 property.
+- **Enhanced Measurement:** Leverage GA4's built-in tracking for scrolls,
+  outbound clicks, and site searches.
+
+## 3. Best Practices
+
+- **Naming Convention:** Use `snake_case` for event names and parameters.
+- **Debug View:** Use the GA4 DebugView in the browser to verify events fire
+  correctly before deploying.
+- **Anonymization:** Ensure IP anonymization is enabled (default in GA4) and
+  cross-domain tracking is configured if necessary.