@1aboveio/skills 0.20.2 → 0.20.4

package/skills/engineering/ensure-coverage/evals/evals.json

@@ -1,125 +0,0 @@
-{
-  "skill_name": "ensure-coverage",
-  "evals": [
-    {
-      "id": 1,
-      "name": "unmapped-mutation-route-baseline",
-      "prompt": "Someone on my team shipped a /settings/integrations page last sprint with a 'Connect account' form on it. There's no ADR and no PRD for it \u2014 it just got added. There is one Playwright test for the page and it passes. Our coverage audit reports we're green because every ADR in docs/adr is covered. Are we actually covered here? And more generally, how should features like this \u2014 added without any spec written ahead of time \u2014 be handled by our coverage system so they don't slip through?",
-      "expected_output": "Explains that no ADR/PRD does NOT mean no test obligation: every surface gets a baseline floor from its (kind, class). Identifies /settings/integrations as a reachable mutation/write-form route needing a browser-journey (fill form -> backend accepts -> durable state). Treats the single passing Playwright test as a suspect to inspect (likely over-mocked via page.route/route.fulfill). Describes a default baseline contract by surface type rather than waiting on a spec, and that orphan/ownership is a warn while the test obligation is the hard gate.",
-      "files": [],
-      "assertions": [
-        {
-          "text": "States that the absence of an ADR/PRD does not remove the test obligation (surfaces carry a baseline regardless of ownership)"
-        },
-        {
-          "text": "Identifies the page as a reachable mutation/write-form surface requiring a browser-level journey (fill the real form, backend accepts, durable state changes)"
-        },
-        {
-          "text": "Treats the single passing Playwright test as a suspect and asks to inspect it for first-party interception (page.route/route.fulfill) -> Over-mocked, not Covered"
-        },
-        {
-          "text": "Proposes a default baseline keyed on surface type (read/detail/mutation), applied automatically rather than waiting on someone to author a spec"
-        },
-        {
-          "text": "Notes that 'every ADR covered' is not the same as 'every surface covered' (requirement-inward breadth misses un-ADR'd surfaces)"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "name": "exclusion-governance-and-smoke",
-      "prompt": "Our route coverage tool is complaining about a pile of pages and endpoints with no journey tests: a /pricing marketing page, a /signup form, and an /api/_seed endpoint that's only used by CI to seed test data. The team's plan is to just exclude all of them from the coverage tool so the build goes green. Is that acceptable? What's the right policy for each one?",
-      "expected_output": "Distinguishes legitimately excludable surfaces (static /pricing, internal /api/_seed) from ones that must keep coverage (/signup is a reachable write form -> cannot be excluded). Static content page keeps a render-health (browser-level reachability) floor — the level formerly named smoke — not zero test. render-health must be a real browser load, not an HTTP-200/API ping. Exclusions require a category + reason and are surfaced in a visible census, never silent. A reachable mutation surface can never be excluded to dodge a journey.",
-      "files": [],
-      "assertions": [
-        {
-          "text": "Refuses a blanket exclusion; evaluates each surface separately by reachability and class"
-        },
-        {
-          "text": "Says /signup (a reachable write form) cannot be excluded and still needs a mutation-form journey"
-        },
-        {
-          "text": "Allows excluding /pricing but keeps a render-health floor (does not let a content page ship with zero test)"
-        },
-        {
-          "text": "Specifies render-health is browser-level (page loads and renders), not an API/HTTP-200 check"
-        },
-        {
-          "text": "Requires each exclusion to carry a category + reason and be visible (census), not silently dropped"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "name": "settings-models-coverage-audit",
-      "prompt": "We have a /settings/models page and its APIs governed by a couple of ADRs, and some Playwright tests that pass. I have a nagging feeling the coverage isn't real. How would you audit whether this is actually covered?",
-      "expected_output": "Regression check carried from iteration-1: refuses green CI as proof, inspects actual test code, flags route.fulfill/page.route interception as Over-mocked, runs requirement-inward breadth, names load-bearing behaviors, recommends real-DB integration + journey tests.",
-      "files": [],
-      "assertions": [
-        {
-          "text": "Refuses to treat green CI as proof; inspects actual test code (Evidence Hierarchy)"
-        },
-        {
-          "text": "Flags route.fulfill/page.route interception as the likely cause (Over-mocked)"
-        },
-        {
-          "text": "Runs requirement-inward breadth (surface inventory, Orphan/Unrealized/Stale)"
-        },
-        {
-          "text": "Names load-bearing behaviors (per-org persistence, permission/tenant, no-secret)"
-        },
-        {
-          "text": "Recommends replacing mocked specs with real-DB integration + journey tests"
-        }
-      ]
-    },
-    {
-      "id": 4,
-      "name": "presentation-invisible-button-and-overflow",
-      "prompt": "We have a React dashboard at /dashboard. Last release a 'Save' button shipped that is technically present and clickable \u2014 our Playwright journey does getByRole('button',{name:'Save'}).click() and the test is green \u2014 but the button is nearly the same light-grey as the page background, so users literally can't see it. We also got a report that on mobile a data table runs off the right edge of the screen. Our coverage dashboard is all green. How is that possible, and what should our test criteria require so this whole class of bug can't pass green again?",
-      "expected_output": "Explains that a DOM-driven journey passes whether or not the control is visually perceivable, so functional coverage is structurally blind to invisible/overflowing UI. Introduces presentation obligations proven against the REAL rendered page: perceivability (WCAG contrast, e.g. axe-core) and spatial (no horizontal overflow at mobile+desktop viewports). Notes a DOM-only/JSDOM assertion does not count (Over-mocked); disabled controls are state-aware-exempt; ambiguous contrast (text over image/gradient) abstains to a blocking Unverified. Crucially, the answer should invoke the SKILL-SPECIFIC semantics (real-render-or-Over-mocked, exact-match levels, abstain->Unverified for gradient contrast, state-exempt disabled controls, gated allowlist for intentional overflow) \u2014 not just the general idea of 'add contrast and overflow checks', which a capable model proposes unaided.",
-      "files": [],
-      "assertions": [
-        {
-          "text": "Diagnoses both bugs as a distinct Presentation-axis concern that the functional DOM journey is structurally blind to (the green journey is necessary but not sufficient)"
-        },
-        {
-          "text": "Requires the perceivability/spatial checks be proven against a REAL rendered page and states a DOM-only/JSDOM assertion is graded Over-mocked, not Covered"
-        },
-        {
-          "text": "States a functional browser-journey does NOT satisfy the presentation obligation \u2014 presentation:spatial / presentation:perceivability is a separate, exact-match required level"
-        },
-        {
-          "text": "Handles ambiguity/intent correctly: contrast on text over an image/gradient abstains to a blocking Unverified (not a silent pass), and disabled controls are state-exempt from the contrast check"
-        },
-        {
-          "text": "Treats intentional horizontal scroll (e.g. a carousel) as suppressible only via a gated allowlist (category + reason, surfaced in a census), never silently ignored"
-        }
-      ]
-    },
-    {
-      "id": 5,
-      "name": "presentation-navorphan-and-payfields-shift",
-      "prompt": "Two things are bugging me. (1) We built a /reports/export page; it loads fine and is behind auth guards, but QA says no menu or link anywhere points to it, so real users can't find it. Our route coverage tool lists it as 'reachable' and green. (2) On checkout, the Stripe embedded card fields load a moment late and shove the rest of the layout downward when they appear. What's wrong with calling /reports/export 'covered', and what should our coverage actually require for both of these?",
-      "expected_output": "Distinguishes guard-chain reachability (URL loads past auth) from navigational reachability (a user can click their way to it) \u2014 guard-reachable is not the same as navigationally reachable; /reports/export is a navigational orphan. Requires a nav-orphan check (route-manifest minus the crawl-reachable set). For Stripe: a temporal/layout-shift obligation; notes the cross-origin iframe specifics (top-page CLS is blind to it; use before/after geometry gated on a provider-ready signal against the provider sandbox) and that this runs in a non-blocking lane that is tracked (Unverified), not silently ignored.",
-      "files": [],
-      "assertions": [
-        {
-          "text": "Distinguishes guard-chain reachability (loads past auth) from navigational reachability (a user can click to it); the route is a navigational orphan despite being guard-reachable"
-        },
-        {
-          "text": "Requires a nav-orphan check: route-manifest set minus the set reachable by crawling the rendered navigation"
-        },
-        {
-          "text": "Identifies the Stripe issue as a layout-shift/temporal obligation"
-        },
-        {
-          "text": "Notes the cross-origin iframe nuance (top-page CLS cannot see inside it; use before/after geometry gated on a provider-ready signal, against the provider sandbox)"
-        },
-        {
-          "text": "Notes the third-party/payfields check is tracked (non-blocking lane + Unverified), not silently passed or silently dropped"
-        }
-      ]
-    }
-  ]
-}

package/skills/engineering/rush-issues/evals/evals.json

@@ -1,65 +0,0 @@
-{
-  "skill_name": "rush-issues",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "Dry-run only: do not modify Git, spawn workers, open a PR, or contact a provider. Plan a rush run for epic #2400 against main with six routine units: #2401 API parser, #2402 CLI adapter (depends on #2401), #2403 docs, #2404 unit tests, #2405 smoke journey, #2406 migration notes. Show the first user-visible task plan and the concrete explorer/implement/combine/review/CICD briefs and state transitions you would use. All six units are required by the original spec. Available models include openai/gpt-5.6-terra@high and openai/gpt-5.5@high.",
-      "expected_output": "A dry-run artifact that displays the complete task map before heavy work, uses shared exploration, schedules at most four isolated unit workspaces while respecting #2402's dependency, combines all six units into one PR, performs independent factual review, and records 30-minute/retry/profiling behavior.",
-      "files": [],
-      "expectations": [
-        "Displays a task plan containing all six units before exploration or implementation.",
-        "Records #2402 as blocked on #2401 and schedules runnable work continuously with at most four active workers.",
-        "Assigns every implementation unit its own branch and isolated Git workspace.",
-        "Uses one shared exploration pack and selects gpt-5.6-terra@high for exploration and a distinct gpt-5.5@high reviewer when available.",
-        "Combines only after all six mapped units succeed and opens exactly one whole-spec PR.",
-        "Runs one independent code-review stage that establishes facts independently of producer claims.",
-        "States the two-retry and 30-minute diagnosis/resume behavior and profiles wall, effective, and wait time."
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "Dry-run only: do not modify Git, spawn workers, open a PR, or contact a provider. Simulate a rush run with required units A, B, and C. B and C succeed. A fails validation twice and its current task reaches 30 minutes. Later, after all units are implemented, the producer's PR body claims every test is green, but an independently run test reveals a real defect. Show exact task-plan transitions, whether/when combination is allowed, the review/fix loop, and CICD handling if the first two CI fix attempts also fail.",
-      "expected_output": "A dry-run artifact where A expires into diagnosis and resumes in its preserved workspace, B/C do not become a partial PR, combination waits for A, review establishes facts independently rather than trusting producer evidence, every changed HEAD is validated and freshly reviewed, and two failed CI cycles trigger diagnosis and continuation.",
-      "files": [],
-      "expectations": [
-        "Transitions A's expired attempt to diagnosing after two failures or 30 minutes while preserving A's workspace and branch.",
-        "Records a changed hypothesis or plan before resetting the local retry counter and resuming A.",
-        "Does not combine B and C into a partial PR; combination waits until A, B, and C all succeed.",
-        "Treats producer test claims as untrusted and uses the independent reviewer’s own test result as the fact.",
-        "Fixes the review defect on the combined branch, validates the fix, and performs a fresh review of the new HEAD.",
-        "After two failed CI fix cycles, diagnoses and continues on the same PR branch rather than abandoning or reducing scope.",
-        "Invalidates the prior review after any code-changing CI fix and obtains a fresh independent review of the new HEAD before enqueue or merge.",
-        "Uses one planRevision for each persisted task-plan transition, profiling event, and displayed board so counters and HEAD cannot disagree.",
-        "Shows task-plan checkpoints and profiling for retries, diagnosis, wall/effective activity, and external wait."
-      ]
-    },
-    {
-      "id": 3,
-      "prompt": "Dry-run only: do not modify Git, spawn workers, open a PR, or contact a provider. Plan a rush run for a high-risk money migration epic against main. Show preflight, task planning, implementation, combination, review, and CICD. The work must remain one whole-spec PR even though repository hazard guidance classifies every unit high-risk.",
-      "expected_output": "A dry-run artifact whose preflight asks only for model choice and target branch through the shared preflight module, retains every high-risk unit in Rush, applies deeper model/testing/review obligations, uses sandbox-compatible Git workspaces, and produces one combined PR without redirecting to another workflow.",
-      "files": [],
-      "expectations": [
-        "Uses the shared preflight module for only model choice and target-branch confirmation.",
-        "Does not redirect to resolve-issues or remove high-risk units from the Rush task map.",
-        "Uses risk only to strengthen model selection, implementation, validation, and review depth.",
-        "Keeps the entire high-risk epic within the one-branch, one-PR Rush workflow.",
-        "For sandboxed Git-mutating Pi workers, uses a self-contained clone workspace rather than a linked worktree whose Git metadata is outside the sandbox."
-      ]
-    },
-    {
-      "id": 4,
-      "prompt": "Dry-run only: do not modify Git, submit a cluster job, spawn workers, open a PR, or contact a provider. Plan a rush run for an epic that changes a PySpark warehouse transformation, partition schema, and backfill watermark. The repository exposes its production entry point with --validate-only and a staging cluster using read-only credentials. Show the ordering from combined validation through review and what happens if a review or CI fix changes HEAD.",
-      "expected_output": "A dry-run artifact that classifies the run as warehouse-canary required, validates the combined branch, runs the real entry point in staged read-only validate-only mode on that exact HEAD before review, proves zero publication side effects, and invalidates/repeats the canary after every code or configuration HEAD change.",
-      "files": [],
-      "expectations": [
-        "Records warehouseCanaryRequired and a concrete classification reason in the task plan.",
-        "Runs the staged read-only canary after combined tests/validation and before independent review.",
-        "Binds the canary command or artifact and durable result to the exact combined 40-character HEAD.",
-        "Uses the real production entry point, staging/canary execution surface, bounded source scope, read-only credentials, and --validate-only.",
-        "Requires explicit publication skip, zero output records/bytes, and no table commit, checkpoint, watermark, offset, scheduler, or other state mutation.",
-        "Blocks instead of waiving the stage if read-only execution cannot be proven.",
-        "Invalidates the prior canary result after any code/configuration commit and reruns validation plus canary before review, enqueue, or merge."
-      ]
-    }
-  ]
-}

package/skills/engineering/rush-release/evals/evals.json

@@ -1,58 +0,0 @@
-{
-  "skill_name": "rush-release",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "Dry-run only: do not modify Git, push a tag, or contact a publisher. Plan a GitHub Flow release from main. origin/main tip is pending CI; the previous first-parent commit abcdef1 is green. Commits since v1.4.0 are feat: export csv and fix: timezone. package.json is 1.4.0. Publisher is npm. Show the frozen SHA, changelog, SemVer, tag target, and watch command you would use after confirmation.",
-      "expected_output": "A dry-run plan that freezes abcdef1 rather than the pending tip, proposes a minor bump to 1.5.0 from the feat, writes changelog entries for both commits, merges the metadata cut through the queue, tags the verified merged main SHA only if its tree exactly equals the cut tree, and watches npm view rather than a Cloud Build traffic shift.",
-      "files": [],
-      "expectations": [
-        "Freezes the green SHA abcdef1 instead of the pending origin/main tip.",
-        "Proposes a minor SemVer bump to 1.5.0 because of feat: export csv.",
-        "Includes changelog entries derived from both the feat and the fix.",
-        "Tags only the queue-verified merged main SHA whose tree exactly equals the version-cut tree.",
-        "Watches npm publish (npm view) and does not describe a 0% traffic candidate or GitFlow release branch.",
-        "Presents one complete-plan confirmation covering cut, PR delivery, tag push, and publisher watch, with no staged confirmations."
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "Dry-run only. Main is protected. Latest green HEAD is 2222222. Plan says v2.0.0 from a breaking change. The metadata PR merges through the queue as 3333333 and its tree exactly equals the approved cut. The repository has a verified Cloud Run staged contract: RC tags deploy immutable candidates with --no-traffic and final tags do not deploy. After you would push v2.0.0-rc.1, Cloud Build returns FAILURE. What do you tag, how do you push it, and what happens after the failed watch?",
-      "expected_output": "A dry-run that verifies 3333333 is on main and tree-identical to the cut, tags merged SHA 3333333 with annotated v2.0.0-rc.1, pushes that fully qualified ref with --no-verify, watches Cloud Build for the RC tag and exact SHA, then on FAILURE leaves the RC tag immutable, keeps v2.0.0 unused, and hands back with production untouched.",
-      "files": [],
-      "expectations": [
-        "Creates an annotated v2.0.0-rc.1 tag on the verified merged main SHA 3333333.",
-        "Pushes the fully-qualified RC tag ref with --no-verify.",
-        "Watches Cloud Build filtered by the RC tag and exact merged SHA.",
-        "On FAILURE, leaves the RC tag immutable and production untouched.",
-        "Does not create the final v2.0.0 tag or claim the final version is burned."
-      ]
-    },
-    {
-      "id": 3,
-      "prompt": "Dry-run only. origin/main moved after the candidate was frozen: green SHA is 3333333, then an ungreen commit 4444444 landed on main. How do you cut 1.2.3 so the ungreen commit is not in the tag? Publisher is both Cloud Build and npm.",
-      "expected_output": "A dry-run that branches from 3333333 and commits metadata only, but refuses publication because a merge containing 4444444 cannot be tree-identical to the approved cut. It creates no tag, waits for a new eligible main state, then restarts candidate selection and the changelog/SemVer plan before watching either publisher.",
-      "files": [],
-      "expectations": [
-        "Branches the cut from frozen SHA 3333333.",
-        "Refuses to rebase or merge the later ungreen commit into the tagged object.",
-        "Creates no tag while the only merged result would contain unplanned commit 4444444.",
-        "Restarts the changelog and SemVer plan from a new eligible main state before watching Cloud Build and npm.",
-        "Does not squash-merge the metadata PR onto moved main."
-      ]
-    },
-    {
-      "id": 4,
-      "prompt": "Dry-run only. One complete Cloud Run release plan was already confirmed. Candidate v1.8.0-rc.1 for merged SHA aaaaaaa is at 0%, incumbent revision old-42 is at 100%, and prod-preview is fresh, read-only, and ALIVE. Describe the rest of the release if the shift reaches candidate revision new-43 at 100% but prod-active is DEAD. Do not ask another question.",
-      "expected_output": "A dry-run that rechecks candidate identity and the 0/100 split, shifts under the existing authorization, observes the failed live smoke, automatically restores old-42 to 100%, verifies the restored incumbent with prod-active, leaves v1.8.0 final unused and the RC tag immutable, and hands back without another confirmation.",
-      "files": [],
-      "expectations": [
-        "Does not request a second exposure, rollback, or finalization confirmation.",
-        "Rechecks fresh ALIVE evidence, candidate identity, and candidate 0% / incumbent 100% immediately before shifting.",
-        "Treats prod-active DEAD after the shift as a post-exposure failure.",
-        "Automatically restores old-42 and verifies it at 100% with a prod-active ALIVE result.",
-        "Leaves the final v1.8.0 tag unused and v1.8.0-rc.1 immutable."
-      ]
-    }
-  ]
-}

package/skills/fullstack/shadcn/evals/evals.json

@@ -1,90 +0,0 @@
-{
-  "skill_name": "shadcn",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "I'm building a Next.js app with shadcn/ui (base-nova preset, lucide icons). Create a settings form component with fields for: full name, email address, and notification preferences (email, SMS, push notifications as toggle options). Add validation states for required fields.",
-      "expected_output": "A React component using FieldGroup, Field, ToggleGroup, data-invalid/aria-invalid validation, gap-* spacing, and semantic colors.",
-      "files": [],
-      "expectations": [
-        "Uses FieldGroup and Field components for form layout instead of raw div with space-y",
-        "Uses Switch for independent on/off notification toggles (not looping Button with manual active state)",
-        "Uses data-invalid on Field and aria-invalid on the input control for validation states",
-        "Uses gap-* (e.g. gap-4, gap-6) instead of space-y-* or space-x-* for spacing",
-        "Uses semantic color tokens (e.g. bg-background, text-muted-foreground, text-destructive) instead of raw colors like bg-red-500",
-        "No manual dark: color overrides"
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "Create a dialog component for editing a user profile. It should have the user's avatar at the top, input fields for name and bio, and Save/Cancel buttons with appropriate icons. Using shadcn/ui with radix-nova preset and tabler icons.",
-      "expected_output": "A React component with DialogTitle, Avatar+AvatarFallback, data-icon on icon buttons, no icon sizing classes, tabler icon imports.",
-      "files": [],
-      "expectations": [
-        "Includes DialogTitle for accessibility (visible or with sr-only class)",
-        "Avatar component includes AvatarFallback",
-        "Icons on buttons use the data-icon attribute (data-icon=\"inline-start\" or data-icon=\"inline-end\")",
-        "No sizing classes on icons inside components (no size-4, w-4, h-4, etc.)",
-        "Uses tabler icons (@tabler/icons-react) instead of lucide-react",
-        "Uses asChild for custom triggers (radix preset)"
-      ]
-    },
-    {
-      "id": 3,
-      "prompt": "Create a dashboard component that shows 4 stat cards in a grid. Each card has a title, large number, percentage change badge, and a loading skeleton state. Using shadcn/ui with base-nova preset and lucide icons.",
-      "expected_output": "A React component with full Card composition, Skeleton for loading, Badge for changes, semantic colors, gap-* spacing.",
-      "files": [],
-      "expectations": [
-        "Uses full Card composition with CardHeader, CardTitle, CardContent (not dumping everything into CardContent)",
-        "Uses Skeleton component for loading placeholders instead of custom animate-pulse divs",
-        "Uses Badge component for percentage change instead of custom styled spans",
-        "Uses semantic color tokens instead of raw color values like bg-green-500 or text-red-600",
-        "Uses gap-* instead of space-y-* or space-x-* for spacing",
-        "Uses size-* when width and height are equal instead of separate w-* h-*"
-      ]
-    },
-    {
-      "id": 4,
-      "prompt": "Our signup form needs real validation. It's a Next.js App Router app on shadcn (radix-nova, lucide). Fields are email, password, confirm password. We use react-hook-form with a zod resolver. When a field fails, show the message under it in red, and make sure screen readers actually announce it — our a11y audit flagged that our current form errors are silent.",
-      "expected_output": "A client component using FieldGroup/Field, FieldError (not FieldDescription) for messages, data-invalid on Field and aria-invalid on the control driven from formState.errors.",
-      "files": [],
-      "expectations": [
-        "Error messages render in FieldError, not FieldDescription",
-        "Does not hand-roll an error element such as a <p className=\"text-destructive\"> or a custom role=alert div",
-        "Field receives data-invalid driven from the form's error state",
-        "The control receives aria-invalid driven from the same error state",
-        "Uses FieldGroup + Field for layout rather than div with space-y-* or grid gap-*",
-        "Includes the \"use client\" directive, since react-hook-form needs client-side state"
-      ]
-    },
-    {
-      "id": 5,
-      "prompt": "I need a /admin/orders page in our Next.js App Router app (shadcn radix-nova, pnpm, lucide icons). It has to list orders with filtering by status, sorting by date and total, and pagination — and the filters need to survive a refresh and be shareable as a link, because support staff paste these URLs to each other. Orders table is big, ~400k rows, so it can't all come down to the browser.",
-      "expected_output": "Installs the DiceUI data-table from a working registry URL, wires an RSC page that parses searchParams and queries server-side, and a client table component using useDataTable with a required pageCount.",
-      "files": [],
-      "expectations": [
-        "Any shadcn add command for the data table uses a registry URL ending in .json (an extensionless diceui.com/r/ URL 404s)",
-        "Passes pageCount to useDataTable rather than omitting it or relying on client-side pagination",
-        "Filtering, sorting and pagination are performed in the server query, not over an in-memory array of all rows",
-        "Filterable columns set enableColumnFilter: true and supply column meta (label/variant, plus options for select filters)",
-        "Wraps the app with NuqsAdapter or notes it is already required for URL state",
-        "The page component reads searchParams on the server; only the table component is a client component",
-        "Parses sort on the server with the shipped getSortingStateParser (or an equivalent nuqs loader) rather than treating the sort param as a plain field:asc string, since it is JSON-encoded",
-        "Flags or installs zod, which lib/parsers.ts imports but the registry item does not declare"
-      ]
-    },
-    {
-      "id": 6,
-      "prompt": "we're on shadcn and i customized components/ui/button.tsx a while back (added a 'warning' variant and tweaked the focus ring). upstream has moved on and i want the new button improvements without losing my changes. also we're switching the whole app off lucide to tabler icons. what's the safe way to do both?",
-      "expected_output": "Uses add --dry-run/--diff to review upstream changes and merge manually rather than --overwrite, and uses migrate icons --from lucide --to tabler rather than hand-editing imports.",
-      "files": [],
-      "expectations": [
-        "Uses shadcn add button --dry-run and/or --diff to inspect upstream changes before writing",
-        "Does not run --overwrite without flagging that local customizations would be lost and asking first",
-        "Does not fetch button.tsx from GitHub or any raw source URL to diff manually",
-        "Recommends shadcn migrate icons --from lucide --to tabler instead of manually rewriting import statements",
-        "Notes that iconLibrary in components.json should end up as tabler so future added components match"
-      ]
-    }
-  ]
-}

package/skills/payment/fraud-analysis/evals/evals.json

@@ -1,40 +0,0 @@
-{
-  "skill_name": "fraud-analysis",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "Analyze transfers.csv. The transactions passed login and MFA, but customers later confirmed they did not initiate them. Most transfers followed a password reset and new beneficiary setup. Find rules we can apply before transfer execution.",
-      "expected_output": "Routes to third-party fraud with account-takeover mechanism and bank-transfer context; separates technical authentication from customer consent; excludes later customer confirmation from pre-transfer features; proposes point-in-time access, beneficiary, and transfer features."
-    },
-    {
-      "id": 2,
-      "prompt": "Analyze collections_and_payouts.xlsx for customers who knowingly receive funds from many unrelated payers and rapidly cash out to linked beneficiaries. Confirmed investigation outcomes identify participating account holders.",
-      "expected_output": "Routes to first-party fraud with payment-collection and payout contexts; uses confirmed knowing participation as the label; engineers point-in-time fan-in, fan-out, collection-to-payout, account, device, and graph features; reports hold/review workload, delay, legitimate-customer impact, and exposure."
-    },
-    {
-      "id": 3,
-      "prompt": "Analyze bank_transfers.csv for APP scams. Customers themselves sent the payments after impersonation calls. We have later scam claims, reimbursement decisions, beneficiary data, warning interactions, and transfer timestamps.",
-      "expected_output": "Routes to authorized payment scam with APP subtype and bank-transfer context; treats customers as deceived victims; distinguishes claims and reimbursement decisions from decision-time features; evaluates warnings, confirmation, review, delay, completion, and reimbursement impact."
-    },
-    {
-      "id": 4,
-      "prompt": "Review card_auths.csv and propose pre-authorization rules for confirmed stolen-card transactions. It includes BIN, token, amount, CVV response, AVS response, issuer decline code, 3DS result, and chargeback outcome.",
-      "expected_output": "Routes to third-party fraud and card-payment; preserves card/BIN/history feature guidance; excludes current CVV, AVS, authorization response, 3DS result, and chargeback outcome at pre-auth; evaluates block, 3DS, or monitor actions with correct authorization denominators."
-    },
-    {
-      "id": 5,
-      "prompt": "Analyze suspicious payout accounts. Some may be knowing mules, some may be scam victims, and some may have been taken over. The file has behavior flags but no completed investigations or customer-consent evidence.",
-      "expected_output": "Keeps archetype unclassified rather than forcing mule, scam, or ATO attribution; treats behavior flags as proxy signals; avoids a blended confirmed-fraud label; limits severe actions and clearly states attribution and evidence gaps."
-    },
-    {
-      "id": 6,
-      "prompt": "Use outcome.csv where the existing case_result column has CONFIRMED_FRAUD, LEGITIMATE, and PENDING. Treat CONFIRMED_FRAUD as positive and analyze the rules.",
-      "expected_output": "Records file-column provenance; maps CONFIRMED_FRAUD to positive, LEGITIMATE to negative, and PENDING to unlabeled rather than negative; reports all counts and computes the base rate over labeled mature rows."
-    },
-    {
-      "id": 7,
-      "prompt": "For transfers.csv, define positives as accounts with at least three payouts within one hour after receiving funds. Find first-party fraud rules.",
-      "expected_output": "Pre-flight recognizes a user-defined positive condition and asks the user to define the negative condition before profile selection or supervised analysis; does not treat every other account as negative; leaves unmatched rows unlabeled."
-    }
-  ]
-}

package/skills/payment/tld-detection/evals/evals.json

@@ -1,107 +0,0 @@
-{
-  "skill_name": "tld-detection",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "We think some merchants are stuffing TLD volume through a normal MCC. Authorizations_2026-03.csv has descriptors, MCC, BIN country, amount, currency, timestamp, and response codes. Find potential TLD clusters.",
-      "expected_output": "Deduplicates auths without a US-BIN filter; partitions by normalized descriptor; detects exact currency-amount pairs with explicit absolute residual caps; freezes membership; compares each cluster with the same descriptor after removing that cluster; assigns High, Medium, or Low investigation priority; and quantifies exposure by risk tier and descriptor.",
-      "expectations": [
-        "Uses normalized descriptor as the partition key and does not use BIN country as a membership key.",
-        "Uses adjacent currency-specific absolute residual caps with sensitivity evidence and no percentage tolerance.",
-        "Requires at least three theoretical levels with a fixed 2x relationship between adjacent levels.",
-        "Reports only currency-amount pairs with at least 100 exact-member attempts and compares each with the same descriptor after removing that cluster.",
-        "Reports Top 3 issuing banks and BIN countries only after membership is frozen.",
-        "Assigns every identified cluster High, Medium, or Low risk without treating the tier as confirmation of TLD.",
-        "Sorts results High to Medium to Low and reports exact-member exposure separately by tier and descriptor.",
-        "Keeps run-specific methodology in a separate linked document.",
-        "Provides a Verdict of at most three sentences without confirmed-laundering language."
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "Same descriptor seems to mix several ticket sizes that look like 9.99, 19.99, 39.99, 79.99. Another TLD name might be split across three billing descriptors. Cluster the book and tell me if those patterns hold.",
-      "expected_output": "Builds descriptor partitions and identifies qualifying currency-amount pairs independently inside them using at least three theoretical levels and a fixed 2x relationship; matching amounts across descriptors never merge membership.",
-      "expectations": [
-        "Builds descriptor partitions before currency-amount pairs.",
-        "Requires at least three theoretical levels and rejects non-2x relationships.",
-        "Requires at least 100 exact-member attempts before reporting a cluster.",
-        "Reports materially different currency-amount pairs under one descriptor.",
-        "Assesses MCC fit without calling a descriptor fabricated."
-      ]
-    },
-    {
-      "id": 3,
-      "prompt": "For each detected currency-amount pair, compare its behavior with the rest of the same descriptor.",
-      "expected_output": "Keeps BIN country out of the membership key, freezes exact membership, builds a same-descriptor baseline by removing only that cluster, compares the required rates and Top 3 dimensions, reports both BIN-country conditional shares, and charts transaction date and BIN-country local-hour distributions against that baseline.",
-      "expectations": [
-        "Does not partition detection by BIN country.",
-        "Uses the same descriptor after removing the current cluster as baseline.",
-        "Reports authorization success rate and suspected fraud as a share of attempts for Cluster and Baseline.",
-        "In each cluster definition, the anchor table reports attempts, authorization success rate, and suspected-fraud share for every theoretical level, including levels with fewer than 30 attempts.",
-        "For each Top 3 cluster BIN country, reports its share of the cluster and the cluster's share of all attempts in the same descriptor-country slice.",
-        "Treats exact 100% single-country concentration as a standout, Mixed as neutral, and country-slice coverage as descriptive without a risk threshold.",
-        "Charts transaction-date and BIN-country local-hour shares for Cluster and Baseline, normalizing each series independently."
-      ]
-    },
-    {
-      "id": 4,
-      "prompt": "Inside descriptor ACME, USD 10.00 is followed by 19.99 with 180 attempts, 20.00 with 40 attempts, and then 39.99. Build the potential TLD ladders.",
-      "expected_output": "Uses an explicit USD adjacent absolute residual cap; selects a primary exact anchor deterministically; may retain another exact anchor at the same theoretical level only if it clears the stated multi-anchor support floor; and applies exact descriptor, currency, and amount membership afterward.",
-      "expectations": [
-        "Runs ladder discovery only inside descriptor ACME.",
-        "Uses absolute adjacent residuals rather than percentage matching.",
-        "Selects the highest-count candidate as the primary anchor.",
-        "Retains an additional anchor only when it independently clears the declared support floor.",
-        "Never assigns every amount in a tolerance interval to the ladder."
-      ]
-    },
-    {
-      "id": 5,
-      "prompt": "Inside one descriptor I see an approximate EUR x2 amount pattern, but its selected exact amount keys total only 96 authorization attempts. Should it be reported?",
-      "expected_output": "Does not report the 96-attempt family; records it below threshold, keeps its transactions outside reported clusters, publishes its ranking, and does not invent a cluster from MCC or comparison features.",
-      "expectations": [
-        "Does not report the 96-attempt family.",
-        "Keeps its rows outside reported clusters.",
-        "Does not invent a cluster from comparison features.",
-        "Still provides a no-ladder Verdict of at most three sentences."
-      ]
-    },
-    {
-      "id": 6,
-      "prompt": "Descriptors ALPHA and BETA both have the exact USD 9.99, 19.99, 39.99 ladder with over 100 attempts, across several BIN countries. Should those transactions become one cluster?",
-      "expected_output": "Creates two descriptor-local currency-amount pairs, permits the same exact amounts in both descriptors, keeps their membership and same-descriptor baselines separate, and reports each independently.",
-      "expectations": [
-        "Creates two ladders because descriptor is the partition boundary.",
-        "Permits the same exact pairs in different descriptor ladders.",
-        "Does not merge matching fingerprints across descriptors.",
-        "Does not merge membership, metrics, or baselines.",
-        "Treats BIN country as post-membership reporting data."
-      ]
-    },
-    {
-      "id": 7,
-      "prompt": "USD 14.xx amounts are representative, but one percentage tolerance becomes too wide at larger amounts. Detect the ladders without sweeping a numeric interval into membership.",
-      "expected_output": "Runs a documented absolute-cap sensitivity grid, uses a currency-specific adjacent residual cap, searches every descriptor-local rung-pool seed, allows only sufficiently supported exact multi-anchors, rejects upper rungs outside the absolute cap, and freezes exact membership before BIN-country attribution.",
-      "expectations": [
-        "Does not use a percentage tolerance.",
-        "Reports the tested cap grid and selected cap.",
-        "Uses finite exact anchor sets with a stated multi-anchor support floor.",
-        "Rejects an upper rung whose adjacent residual exceeds the cap.",
-        "Computes BIN-country reporting values only after exact membership is frozen."
-      ]
-    },
-    {
-      "id": 8,
-      "prompt": "One cluster is 100% US BIN and covers 21.3% of its descriptor's US BIN attempts. Another is mixed and covers 33.8% of one descriptor-country slice. Grade and order the risk.",
-      "expected_output": "Treats the exact 100% single-country concentration as a standout and uses 21.3% only to explain its scale; treats Mixed as neutral and 33.8% as descriptive rather than a threshold; combines independent structural and behavioral evidence; assigns High, Medium, or Low risk; and sorts High to Medium to Low.",
-      "expectations": [
-        "Does not classify Mixed as Weak or automatically lower its risk tier.",
-        "Does not infer risk from a 20%, 33.8%, or other country-slice coverage threshold.",
-        "Requires exact 100% single-country composition for the BIN-country standout.",
-        "Reports cluster composition and descriptor-country slice coverage as separate conditional percentages.",
-        "Uses at least one independent corroborating characteristic before making a 100% single-country cluster High risk.",
-        "Preserves stable cluster IDs while sorting High to Medium to Low."
-      ]
-    }
-  ]
-}