@cubis/foundry 0.3.83 → 0.3.84

package/workflows/skills/remix/references/progressive-enhancement.md

@@ -1,159 +0,0 @@
-# Progressive Enhancement
-
-Load this when implementing optimistic UI, useFetcher, useNavigation, pending states, or forms that must work without JavaScript.
-
-## The Progressive Enhancement Model
-
-Remix forms work as standard HTML forms by default. When JavaScript loads, Remix enhances them with client-side navigation, pending UI, and optimistic updates. This means every form works without JavaScript and gets better with it.
-
-### Standard Form (Works Without JS)
-
-```tsx
-import { Form } from "@remix-run/react";
-
-// <Form> renders a <form> in HTML. Without JS, it submits normally.
-// With JS, Remix intercepts the submission for a client-side navigation.
-export default function ContactForm() {
-  return (
-    <Form method="post" action="/contact">
-      <input name="email" type="email" required />
-      <textarea name="message" required />
-      <button type="submit">Send</button>
-    </Form>
-  );
-}
-```
-
-## useNavigation for Pending UI
-
-`useNavigation` tracks the state of the current page navigation (not fetcher submissions).
-
-```tsx
-import { Form, useNavigation } from "@remix-run/react";
-
-export default function SubmitForm() {
-  const navigation = useNavigation();
-  const isSubmitting = navigation.state === "submitting";
-  const isLoading = navigation.state === "loading";
-
-  return (
-    <Form method="post">
-      <input name="title" disabled={isSubmitting} />
-      <button type="submit" disabled={isSubmitting}>
-        {isSubmitting ? "Saving..." : "Save"}
-      </button>
-    </Form>
-  );
-}
-```
-
-### Navigation States
-
-| State | Meaning |
-| --- | --- |
-| `idle` | No navigation in progress |
-| `submitting` | A form is being submitted (action is running) |
-| `loading` | Loaders are running after action completes or after a link click |
-
-### Accessing Pending Form Data
-
-```tsx
-const navigation = useNavigation();
-
-// Access the form data being submitted for optimistic UI
-if (navigation.state === "submitting") {
-  const pendingTitle = navigation.formData?.get("title");
-  // Render the pending title optimistically
-}
-```
-
-## useFetcher for Non-Navigation Mutations
-
-`useFetcher` submits to an action without changing the URL. Use it for inline edits, toggles, and background operations.
-
-```tsx
-import { useFetcher } from "@remix-run/react";
-
-function LikeButton({ postId, liked }: { postId: string; liked: boolean }) {
-  const fetcher = useFetcher();
-
-  // Optimistic: use pending data if available, fall back to server data
-  const optimisticLiked = fetcher.formData
-    ? fetcher.formData.get("liked") === "true"
-    : liked;
-
-  return (
-    <fetcher.Form method="post" action="/api/like">
-      <input type="hidden" name="postId" value={postId} />
-      <input type="hidden" name="liked" value={String(!optimisticLiked)} />
-      <button type="submit" aria-pressed={optimisticLiked}>
-        {optimisticLiked ? "Unlike" : "Like"}
-      </button>
-    </fetcher.Form>
-  );
-}
-```
-
-### Fetcher States
-
-| State | Meaning |
-| --- | --- |
-| `idle` | No fetcher operation in progress |
-| `submitting` | The fetcher is submitting to an action |
-| `loading` | The fetcher is revalidating after the action completed |
-
-### Multiple Independent Fetchers
-
-Each `useFetcher()` call creates an independent instance. Multiple fetchers can be in-flight simultaneously without interfering.
-
-```tsx
-function TaskList({ tasks }) {
-  return tasks.map((task) => <TaskRow key={task.id} task={task} />);
-}
-
-function TaskRow({ task }) {
-  const fetcher = useFetcher(); // Each row has its own fetcher
-
-  return (
-    <fetcher.Form method="post" action="/api/tasks/toggle">
-      <input type="hidden" name="taskId" value={task.id} />
-      <button>{task.done ? "Undo" : "Complete"}</button>
-    </fetcher.Form>
-  );
-}
-```
-
-## useFetcher for Data Loading
-
-`useFetcher` can also load data without navigation, useful for search-as-you-type and comboboxes.
-
-```tsx
-function CitySearch() {
-  const fetcher = useFetcher<typeof loader>();
-
-  return (
-    <div>
-      <fetcher.Form method="get" action="/api/cities">
-        <input
-          name="q"
-          type="search"
-          onChange={(e) => fetcher.submit(e.currentTarget.form)}
-        />
-      </fetcher.Form>
-      {fetcher.data?.cities.map((city) => (
-        <p key={city.id}>{city.name}</p>
-      ))}
-    </div>
-  );
-}
-```
-
-## Choosing Between Form, useFetcher, and useSubmit
-
-| Use case | Tool | Reason |
-| --- | --- | --- |
-| Full-page form submission | `<Form>` | Triggers navigation, updates URL, enables back button |
-| Inline edit / toggle / like | `useFetcher` | No URL change, no scroll reset, independent state |
-| Programmatic submission | `useSubmit` | Form submission from a click handler or effect |
-| Search / filter | `<Form method="get">` | Updates URL search params, works with back button |
-| Autocomplete / typeahead | `useFetcher` with `GET` | Loads data without URL change or history entry |

package/workflows/skills/remix/references/resource-routes.md

@@ -1,177 +0,0 @@
-# Resource Routes
-
-Load this when implementing API endpoints, webhooks, file downloads, image generation, RSS feeds, sitemaps, or any route that returns non-HTML responses.
-
-## What Are Resource Routes?
-
-A resource route is a route module that exports a `loader` or `action` but no `default` component. It serves raw responses (JSON, CSV, XML, binary) at a URL without rendering HTML.
-
-Resource routes share the same file naming, authentication, session handling, and deployment infrastructure as UI routes.
-
-## Common Resource Route Patterns
-
-### JSON API Endpoint
-
-```tsx
-// app/routes/api.posts.tsx — GET /api/posts
-import { json, type LoaderFunctionArgs } from "@remix-run/node";
-import { requireApiKey } from "~/utils/auth.server";
-import { getPosts } from "~/models/post.server";
-
-export async function loader({ request }: LoaderFunctionArgs) {
-  await requireApiKey(request);
-
-  const url = new URL(request.url);
-  const page = parseInt(url.searchParams.get("page") ?? "1", 10);
-  const limit = parseInt(url.searchParams.get("limit") ?? "20", 10);
-
-  const { posts, total } = await getPosts({ page, limit });
-
-  return json(
-    { data: posts, meta: { page, limit, total } },
-    {
-      headers: {
-        "Cache-Control": "public, max-age=60",
-      },
-    }
-  );
-}
-```
-
-### CSV File Download
-
-```tsx
-// app/routes/reports.export[.csv].tsx — GET /reports/export.csv
-import type { LoaderFunctionArgs } from "@remix-run/node";
-import { requireUserId } from "~/utils/auth.server";
-import { getReportData } from "~/models/report.server";
-
-export async function loader({ request }: LoaderFunctionArgs) {
-  const userId = await requireUserId(request);
-  const data = await getReportData(userId);
-
-  const csv = [
-    "Date,Revenue,Orders",
-    ...data.map((row) => `${row.date},${row.revenue},${row.orders}`),
-  ].join("\n");
-
-  return new Response(csv, {
-    headers: {
-      "Content-Type": "text/csv; charset=utf-8",
-      "Content-Disposition": 'attachment; filename="report.csv"',
-    },
-  });
-}
-```
-
-The bracket escape `[.csv]` in the filename makes the route URL `/reports/export.csv` instead of treating the dot as a route separator.
-
-### Webhook Receiver
-
-```tsx
-// app/routes/webhooks.stripe.tsx — POST /webhooks/stripe
-import type { ActionFunctionArgs } from "@remix-run/node";
-import Stripe from "stripe";
-import { handleStripeEvent } from "~/services/stripe.server";
-
-export async function action({ request }: ActionFunctionArgs) {
-  const payload = await request.text();
-  const signature = request.headers.get("stripe-signature");
-
-  if (!signature) {
-    return new Response("Missing signature", { status: 400 });
-  }
-
-  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
-  let event: Stripe.Event;
-
-  try {
-    event = stripe.webhooks.constructEvent(
-      payload,
-      signature,
-      process.env.STRIPE_WEBHOOK_SECRET!
-    );
-  } catch {
-    return new Response("Invalid signature", { status: 400 });
-  }
-
-  await handleStripeEvent(event);
-  return new Response("OK", { status: 200 });
-}
-```
-
-### RSS Feed
-
-```tsx
-// app/routes/rss[.]xml.tsx — GET /rss.xml
-import type { LoaderFunctionArgs } from "@remix-run/node";
-import { getRecentPosts } from "~/models/post.server";
-
-export async function loader({ request }: LoaderFunctionArgs) {
-  const posts = await getRecentPosts(20);
-  const baseUrl = new URL(request.url).origin;
-
-  const rss = `<?xml version="1.0" encoding="UTF-8"?>
-<rss version="2.0">
-  <channel>
-    <title>My Blog</title>
-    <link>${baseUrl}</link>
-    <description>Latest blog posts</description>
-    ${posts
-      .map(
-        (post) => `
-    <item>
-      <title>${escapeXml(post.title)}</title>
-      <link>${baseUrl}/blog/${post.slug}</link>
-      <pubDate>${new Date(post.publishedAt).toUTCString()}</pubDate>
-      <description>${escapeXml(post.excerpt)}</description>
-    </item>`
-      )
-      .join("")}
-  </channel>
-</rss>`;
-
-  return new Response(rss, {
-    headers: {
-      "Content-Type": "application/rss+xml; charset=utf-8",
-      "Cache-Control": "public, max-age=3600",
-    },
-  });
-}
-
-function escapeXml(str: string): string {
-  return str
-    .replace(/&/g, "&amp;")
-    .replace(/</g, "&lt;")
-    .replace(/>/g, "&gt;")
-    .replace(/"/g, "&quot;");
-}
-```
-
-### Health Check
-
-```tsx
-// app/routes/api.healthcheck.tsx — GET /api/healthcheck
-import { json } from "@remix-run/node";
-import { prisma } from "~/db.server";
-
-export async function loader() {
-  try {
-    await prisma.$queryRaw`SELECT 1`;
-    return json({ status: "ok", database: "connected" });
-  } catch {
-    return json(
-      { status: "error", database: "disconnected" },
-      { status: 503 }
-    );
-  }
-}
-```
-
-## Key Considerations
-
-- **No default export** -- if you accidentally add a default component export, the route becomes a UI route and Remix renders HTML with the component.
-- **Same auth patterns** -- resource routes have access to `request.headers`, cookies, and sessions. Use the same authentication helpers as UI routes.
-- **Caching** -- resource routes benefit from `Cache-Control` headers because they often serve static-ish data (feeds, reports, images).
-- **CORS** -- if the resource route serves a cross-origin API, add CORS headers in the loader response and handle `OPTIONS` preflight in a separate `action` or `loader` check.
-- **Rate limiting** -- resource routes exposed as APIs should include rate limiting because they are more likely to be called programmatically.

package/workflows/skills/remix/references/routing-conventions.md

@@ -1,78 +0,0 @@
-# Routing Conventions
-
-Load this when designing route hierarchies, using flat file naming, pathless routes, layout routes, or migrating from Remix v1 to v2 conventions.
-
-## Flat File Routing (Remix v2 Default)
-
-Remix v2 uses dot-delimited flat file naming. All route files live in `app/routes/` without folder nesting.
-
-### Naming Rules
-
-| File name | URL path | Parent layout |
-| --- | --- | --- |
-| `_index.tsx` | `/` | `root.tsx` |
-| `about.tsx` | `/about` | `root.tsx` |
-| `blog.tsx` | `/blog` (layout) | `root.tsx` |
-| `blog._index.tsx` | `/blog` (index) | `blog.tsx` |
-| `blog.$slug.tsx` | `/blog/:slug` | `blog.tsx` |
-| `blog.$slug.edit.tsx` | `/blog/:slug/edit` | `blog.$slug.tsx` |
-| `blog_.archive.tsx` | `/blog/archive` | `root.tsx` (trailing `_` opts out of layout) |
-| `_auth.tsx` | (no URL segment, layout only) | `root.tsx` |
-| `_auth.login.tsx` | `/login` | `_auth.tsx` |
-| `_auth.register.tsx` | `/register` | `_auth.tsx` |
-
-### Key Conventions
-
-- **Dots (`.`) create nesting** -- `blog.$slug.tsx` is a child of `blog.tsx`.
-- **Trailing underscore (`_`) opts out of the parent layout** -- `blog_.archive.tsx` does not nest inside `blog.tsx`.
-- **Leading underscore (`_`) creates a pathless layout** -- `_auth.tsx` wraps `_auth.login.tsx` and `_auth.register.tsx` without adding a URL segment.
-- **`$param` creates a dynamic segment** -- `blog.$slug.tsx` matches `/blog/anything`.
-- **`_index.tsx` is the index route** -- renders when the parent URL matches exactly with no additional segments.
-- **Brackets escape special characters** -- `sitemap[.]xml.tsx` matches `/sitemap.xml`.
-
-### Layout Routes vs Index Routes
-
-A layout route (`blog.tsx`) renders when any child matches. It must include `<Outlet />` to render child content. An index route (`blog._index.tsx`) renders when the parent URL matches exactly.
-
-```tsx
-// app/routes/blog.tsx -- Layout route
-import { Outlet } from "@remix-run/react";
-
-export default function BlogLayout() {
-  return (
-    <div className="blog-layout">
-      <Sidebar />
-      <main>
-        <Outlet /> {/* Child routes render here */}
-      </main>
-    </div>
-  );
-}
-```
-
-### Route Module Exports
-
-Every route module can export these:
-
-| Export | Purpose |
-| --- | --- |
-| `loader` | Server-side GET data fetching |
-| `action` | Server-side non-GET mutations |
-| `default` | React component to render |
-| `ErrorBoundary` | Error UI for this route segment |
-| `meta` | `<title>` and `<meta>` tags |
-| `headers` | HTTP response headers |
-| `links` | `<link>` tags for stylesheets and preloads |
-| `handle` | Arbitrary data for `useMatches()` |
-| `shouldRevalidate` | Control when the loader re-runs |
-
-### Resource Routes
-
-A route module that exports a `loader` or `action` but no `default` component is a resource route. It serves raw data (JSON, CSV, images) at a URL without rendering HTML.
-
-```tsx
-// app/routes/api.healthcheck.tsx -- Resource route
-export async function loader() {
-  return new Response("OK", { status: 200 });
-}
-```

package/workflows/skills/remix/references/streaming-defer.md

@@ -1,138 +0,0 @@
-# Streaming with Defer
-
-Load this when implementing `defer`, `Await`, `Suspense`, streaming SSR, or handling slow data sources without blocking TTFB.
-
-## How Streaming Works in Remix
-
-When a loader returns `defer()`, Remix sends the initial HTML immediately with resolved data inline and `<script>` placeholders for deferred promises. As deferred promises resolve on the server, Remix streams HTML chunks that replace the placeholders. The browser progressively renders content without a full page reload.
-
-## Basic Defer Pattern
-
-```tsx
-import { defer, type LoaderFunctionArgs } from "@remix-run/node";
-import { Await, useLoaderData } from "@remix-run/react";
-import { Suspense } from "react";
-
-export async function loader({ request }: LoaderFunctionArgs) {
-  const userId = await requireUserId(request);
-
-  // Critical data: await it (included in initial HTML)
-  const user = await getUser(userId);
-
-  // Non-critical data: do NOT await (streamed later)
-  const recommendations = getRecommendations(userId); // Returns a Promise
-  const activityFeed = getActivityFeed(userId);        // Returns a Promise
-
-  return defer({ user, recommendations, activityFeed });
-}
-
-export default function Dashboard() {
-  const { user, recommendations, activityFeed } = useLoaderData<typeof loader>();
-
-  return (
-    <div>
-      {/* Renders immediately — user is already resolved */}
-      <h1>Hello, {user.name}</h1>
-
-      {/* Streams in when recommendations resolve */}
-      <Suspense fallback={<RecommendationsSkeleton />}>
-        <Await resolve={recommendations} errorElement={<ErrorFallback />}>
-          {(data) => <RecommendationsList items={data} />}
-        </Await>
-      </Suspense>
-
-      {/* Streams in when activity feed resolves */}
-      <Suspense fallback={<ActivitySkeleton />}>
-        <Await resolve={activityFeed} errorElement={<ErrorFallback />}>
-          {(data) => <ActivityFeed items={data} />}
-        </Await>
-      </Suspense>
-    </div>
-  );
-}
-```
-
-## Rules for Defer
-
-1. **Await critical data, defer non-critical data** -- Only defer data that is not needed for the initial meaningful render. The user should see useful content immediately.
-
-2. **Every `<Await>` must be inside a `<Suspense>`** -- Suspense provides the fallback UI while the promise is pending. Missing Suspense causes an unhandled error.
-
-3. **Use `errorElement` for per-promise error handling** -- Without errorElement, a rejected promise propagates to the route ErrorBoundary, potentially breaking the entire page.
-
-4. **Deferred data is not available on the initial server render** -- The Suspense fallback is what renders in the initial HTML. The resolved content arrives via streaming chunks.
-
-5. **Defer only works with streaming-capable runtimes** -- Node.js, Deno, and Cloudflare Workers support streaming. Some hosting platforms buffer the response and negate the benefit.
-
-## Error Handling with Await
-
-```tsx
-<Suspense fallback={<Skeleton />}>
-  <Await
-    resolve={analytics}
-    errorElement={<AnalyticsUnavailable />}
-  >
-    {(data) => <AnalyticsChart data={data} />}
-  </Await>
-</Suspense>
-```
-
-The `errorElement` renders when the deferred promise rejects. It receives the error via `useAsyncError()`:
-
-```tsx
-import { useAsyncError } from "@remix-run/react";
-
-function AnalyticsUnavailable() {
-  const error = useAsyncError();
-  console.error("Analytics failed:", error);
-
-  return (
-    <div className="error-panel">
-      <p>Analytics are temporarily unavailable.</p>
-      <a href="." reloadDocument>Retry</a>
-    </div>
-  );
-}
-```
-
-## Type Safety with Defer
-
-```tsx
-// TypeScript infers the deferred types correctly
-export async function loader() {
-  const user = await getUser();           // Resolved: User
-  const stats = getStats();               // Deferred: Promise<Stats>
-
-  return defer({ user, stats });
-}
-
-// In the component:
-const { user, stats } = useLoaderData<typeof loader>();
-// user: User (resolved value)
-// stats: Promise<Stats> (must use <Await> to resolve)
-```
-
-## Streaming Response Headers
-
-When using `defer`, set response headers in the defer call:
-
-```tsx
-return defer(
-  { user, analytics },
-  {
-    headers: {
-      "Cache-Control": "private, no-store",
-      "X-Custom-Header": "value",
-    },
-  }
-);
-```
-
-Streaming responses cannot use `headers()` export for Content-Type because the response has already started.
-
-## When NOT to Defer
-
-- Data required for the page title, meta tags, or SEO content -- search engines may not execute streamed JavaScript.
-- Data that determines the layout or routing -- deferred data is not available during SSR, so layout-dependent data must be awaited.
-- Authentication checks -- always await auth checks to prevent rendering protected content in the initial HTML.
-- Data that takes less than 50ms -- the overhead of streaming setup negates the benefit for fast data sources.

package/workflows/skills/requesting-code-review/SKILL.md

@@ -1,73 +0,0 @@
----
-name: requesting-code-review
-description: "Use when preparing code for review, writing PR descriptions, selecting reviewers, structuring changes for easy review, or managing review timelines."
-license: MIT
-metadata:
-  author: cubis-foundry
-  version: "3.0"
-compatibility: "Claude Code, Codex, GitHub Copilot"
----
-
-# Requesting Code Review
-
-## Purpose
-
-Maximize the value of every code review by preparing changes for easy, efficient review. This skill turns review requests from a passive "please look at my code" into a structured communication that gives reviewers the context they need to provide fast, high-quality feedback — reducing review cycles, minimizing back-and-forth, and shipping changes faster with fewer defects.
-
-## When to Use
-
-- Preparing a pull request for review and writing a clear, complete PR description
-- Deciding who to assign as reviewers based on domain expertise and availability
-- Structuring commits and file changes so reviewers can follow the logic progressively
-- Managing review timelines when changes are urgent or blocking other work
-- Determining whether to use draft PRs, stacked PRs, or ready-for-review workflows
-- Adding self-review annotations and inline comments to reduce reviewer cognitive load
-
-## Instructions
-
-1. **Self-review before requesting** — walk through your own diff line by line before assigning reviewers, because catching obvious issues yourself (typos, debug logs, accidental file inclusions) prevents wasted reviewer cycles and builds trust that your PRs are worth reviewing carefully.
-
-2. **Write clear PR descriptions with context** — include what changed, why it changed, how it was tested, and any risks or trade-offs, because reviewers who understand the intent behind changes give more relevant feedback and catch issues that a context-free review would miss.
-
-3. **Keep PRs small and focused** — limit each PR to a single logical change (one feature, one bug fix, one refactor), because PRs over 400 lines get slower, shallower reviews with more missed defects, while PRs under 200 lines get reviewed 3x faster with higher-quality feedback.
-
-4. **Add inline comments on tricky decisions** — annotate your own PR with comments on non-obvious choices, workarounds, and known complexity, because proactive explanation prevents reviewers from wasting time asking "why?" on decisions you can explain upfront.
-
-5. **Select appropriate reviewers** — choose reviewers based on domain expertise, recent context with the affected code, and current workload, because assigning the right person gets you faster, more relevant feedback while assigning too many people diffuses responsibility.
-
-6. **Provide context about testing approach** — describe what was tested, how it was tested (manual, unit, integration, E2E), and what was deliberately not tested and why, because reviewers who understand the testing approach can focus their review on untested areas and skip re-verifying covered paths.
-
-7. **Highlight areas needing careful review** — explicitly call out the sections of your change that carry the most risk, complexity, or uncertainty, because directing reviewer attention to high-value areas produces better feedback than hoping they independently identify what matters most.
-
-8. **Manage review timelines and urgency** — communicate the urgency level (blocking deployment, time-sensitive fix, routine feature) and desired review timeline, because reviewers prioritize based on perceived urgency and silent PRs sit at the bottom of the queue.
-
-9. **Structure commits for progressive review** — organize commits in a logical sequence (refactor first, then feature, then tests) so reviewers can follow the evolution of the change, because commit-by-commit review reveals the reasoning behind the final diff better than reviewing the squashed result.
-
-10. **Document known limitations** — explicitly state what this PR does not do, what technical debt it introduces, and what follow-up work is planned, because undocumented limitations become forgotten debt and reviewers who know the scope can evaluate completeness accurately.
-
-11. **Include screenshots for UI changes** — add before/after screenshots, GIFs, or screen recordings for any user-facing visual changes, because reviewers cannot assess UI correctness from code alone and visual evidence eliminates an entire category of back-and-forth.
-
-12. **Link related issues** — reference the issue, ticket, or discussion that motivated the change using closing keywords (Fixes #123, Closes #456), because traceability from PR to requirement enables reviewers to verify the change addresses the original problem and automates issue lifecycle.
-
-13. **Use draft vs ready-for-review intentionally** — open a draft PR when you want early directional feedback on an incomplete approach, and mark ready-for-review only when the change is complete and self-reviewed, because mixing these signals wastes reviewer time on unfinished work or delays feedback on work that needs early course-correction.
-
-14. **Set review expectations** — specify what kind of feedback you need (architecture direction, security audit, quick sanity check, full deep review), because reviewers who know the expected depth can calibrate their effort and provide the specific type of feedback you actually need.
-
-## Output Format
-
-When preparing a review request, provide:
-
-1. **PR title** — concise summary of the change in imperative mood (under 72 characters)
-2. **Description** — what changed, why, and how, structured with clear headings
-3. **Testing summary** — what was tested, how, and what was not tested
-4. **Risk assessment** — areas of highest risk or uncertainty that need careful review
-5. **Reviewer recommendation** — who should review and why, with urgency level
-6. **Review guidance** — what type of feedback is needed and any specific areas to focus on
-
-## References
-
-| File | Purpose |
-|------|---------|
-| `references/pr-description-patterns.md` | Templates and examples for writing effective PR descriptions across different change types |
-| `references/reviewer-selection.md` | How to select the right reviewers based on expertise, workload, and change characteristics |
-| `references/self-review-checklist.md` | Step-by-step checklist for self-reviewing your changes before requesting external review |

package/workflows/skills/requesting-code-review/evals/assertions.md

@@ -1,52 +0,0 @@
-# Requesting Code Review Eval Assertions
-
-## Eval 1: PR Description Quality
-
-This eval tests whether the skill produces a well-structured PR description with sufficient context, risk assessment, testing details, and review guidance for a feature change that touches multiple areas.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                          |
-|---|----------|-------------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| 1 | contains | `cache` — Core feature description              | The PR description must clearly describe the caching feature being added, as this is the central change.|
-| 2 | contains | `Redis` — Implementation technology             | Reviewers need to know the specific technology to evaluate the approach and check for Redis-specific issues (connection pooling, memory limits, serialization). |
-| 3 | contains | `auth` — Risk area identification               | The auth middleware reordering is the highest-risk part of this change. Failing to highlight it means the reviewer may not scrutinize it. |
-| 4 | contains | `invalidation` — Cache consistency strategy     | Cache invalidation is the hardest part of caching. The description must address how stale data is prevented. |
-| 5 | contains | `test` — Testing approach description           | Reviewers need to know what was tested and how, so they can focus review effort on untested areas. |
-| 6 | contains | `review` — Review guidance and expectations     | The request must specify what feedback is needed and where reviewers should focus their attention. |
-
-### What a passing response looks like
-
-- Includes a concise PR title summarizing the caching feature.
-- Provides a structured description with What/Why/How sections.
-- Calls out the auth middleware reordering as a high-risk area needing careful review.
-- Describes the cache invalidation strategy and its trade-offs.
-- Includes a testing section covering unit tests, integration tests, and manual verification.
-- Recommends a reviewer with backend/infrastructure expertise.
-- Specifies the desired review depth and focus areas.
-
----
-
-## Eval 2: Reviewer Selection and Timeline
-
-This eval tests whether the skill correctly selects reviewers based on expertise and availability, and communicates appropriate urgency for a security fix.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                          |
-|---|----------|-------------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| 1 | contains | `Bob` — Primary reviewer selection              | Bob is the best primary reviewer: frontend expertise, availability, and original code context. |
-| 2 | contains | `Alice` — Security sign-off                     | Alice should be involved as security team lead, even if her review comes after initial approval. |
-| 3 | contains | `urgent` — Urgency communication                | The review request must clearly communicate that this is time-sensitive due to an active vulnerability. |
-| 4 | contains | `XSS` — Vulnerability identification            | The vulnerability type must be clearly stated so reviewers understand the threat model. |
-| 5 | contains | `sanitiz` — Fix approach description            | The sanitization approach must be described so reviewers can evaluate completeness and correctness. |
-
-### What a passing response looks like
-
-- Recommends Bob as the primary reviewer due to availability and frontend expertise.
-- Recommends Alice as a secondary reviewer for security sign-off after her meetings.
-- Does not recommend waking Dave (different timezone, 11pm) for a non-critical-infrastructure fix.
-- Notes Carol is too new to be the primary reviewer for a security fix but could be added for learning.
-- Communicates clear urgency with a specific timeline (review by end of day).
-- Includes a PR description that clearly states the XSS vulnerability and the sanitization fix.
-- Suggests a two-phase approval: Bob for immediate merge, Alice for post-merge security audit if timeline requires.