@pikku/cli 0.12.90 → 0.12.92

package/skills/pikku-rtl/SKILL.md

@@ -1,219 +0,0 @@
----
-name: pikku-rtl
-description: 'Make a Pikku frontend work in both English (LTR) and Arabic / right-to-left languages. Direction is derived from the active locale, applied once at the document root, and the layout mirrors itself — but only if styling is written flow-relative (margin-inline-start, text-align: start, Mantine ms/me) instead of left/right. TRIGGER when: adding Arabic (or Hebrew/Farsi/Urdu), asked to "support RTL / right-to-left / bidi / mirror the layout", or writing layout styles in an app that may run RTL. Builds on pikku-i18n (an RTL language is just another locale file). DO NOT TRIGGER for backend functions or for LTR-only copy changes.'
-installGroups: [core]
----
-
-# Pikku RTL (Arabic + English)
-
-This skill sits **on top of** `pikku-i18n`. That skill maps a locale to `t()`
-tokens; this one adds the second axis: a locale also has a **direction**.
-Arabic is not special-cased — it is just another locale file (`ar.json`,
-registered `satisfies typeof en`) plus the document being told it is `rtl`.
-
-## The one idea
-
-Set `dir` **once at the document root** from the active locale, then let the
-browser and Mantine mirror everything — _provided_ every custom style is written
-**flow-relative** (start/end), never **physical** (left/right). Get those two
-things right and Arabic, Hebrew, Farsi and Urdu all work with zero per-component
-*layout* code — directional icons still need one manual step, covered below.
-
-## Agent Operating Procedure
-
-1. **Tokens first.** Every visible string is already a `t()` token via
-   `pikku-i18n`. Arabic copy goes in `i18n/ar.json`, mirroring `en.json`'s keys,
-   registered with `satisfies typeof en` so a missing key is a compile error.
-2. **Add the direction helper** to the i18n config (one home for locale→dir):
-   ```ts
-   const RTL_LOCALES = new Set(['ar', 'he', 'fa', 'ur'])
-   export function localeDir(locale: string = defaultLocale): 'rtl' | 'ltr' {
-     return RTL_LOCALES.has(locale.split('-')[0]) ? 'rtl' : 'ltr'
-   }
-   ```
-   (The bundled templates already ship this helper — use it, don't reinvent it.)
-3. **Apply `dir` + `lang` at the root**, once, from the active locale — pick the
-   recipe for your framework below.
-4. **Write every layout style flow-relative.** This is the part that actually
-   makes mirroring work; see the rules. When editing existing UI to be
-   RTL-ready, the job is mostly a search-and-replace of physical properties.
-5. **Flip directional icons** (chevrons, back/forward arrows) — the one thing
-   logical properties can't do for you.
-6. Validate with the app's `tsc`, then load `?i18n-debug` / set `dir` and
-   eyeball that the layout mirrors and nothing is stuck on the wrong edge.
-
-## Flow-relative, not physical — the rules that make it mirror
-
-Use the **inline-axis logical** property; never the physical one:
-
-| Don't (physical)             | Do (flow-relative)                           |
-| ---------------------------- | -------------------------------------------- |
-| `margin-left` / `marginLeft` | `margin-inline-start` / `marginInlineStart`  |
-| `margin-right`               | `margin-inline-end` / `marginInlineEnd`      |
-| `padding-left/right`         | `padding-inline-start/end`                   |
-| `left: 0` / `right: 0`       | `inset-inline-start: 0` / `inset-inline-end` |
-| `text-align: left/right`     | `text-align: start / end`                    |
-| `border-top-left-radius`     | `border-start-start-radius`                  |
-| `float: left/right`          | `float: inline-start / inline-end`           |
-
-In **Mantine**, use the logical style props — they emit the logical CSS above:
-
-| Don't       | Do          |
-| ----------- | ----------- |
-| `ml` / `mr` | `ms` / `me` |
-| `pl` / `pr` | `ps` / `pe` |
-
-Mantine's own components already use logical properties internally, so once the
-direction is set they mirror automatically — you only have to be disciplined in
-**your** styles.
-
-**Leave flexbox and grid alone.** `display:flex` already follows `dir`:
-`justify-content: flex-start` resolves to the right edge under RTL on its own.
-Never "fix" RTL by swapping to `flex-direction: row-reverse` or reordering DOM —
-that double-flips and breaks the moment direction changes. The DOM order is
-logical order; let `dir` handle the visual order.
-
-## Applying direction at the root
-
-### Mantine app (e.g. environment-template)
-
-Mantine ships first-class RTL: wrap the tree in `DirectionProvider` and set the
-matching `dir` on `<html>`.
-
-```tsx
-import { DirectionProvider, MantineProvider } from '@mantine/core'
-import i18n, { detectLocale, localeDir } from './i18n/config'
-
-const locale =
-  typeof window !== 'undefined' ? detectLocale(window.location.pathname) : 'en'
-const dir = localeDir(locale)
-
-if (typeof document !== 'undefined') {
-  document.documentElement.lang = locale
-  document.documentElement.dir = dir // Mantine + browser read this
-}
-
-root.render(
-  <DirectionProvider initialDirection={dir}>
-    <MantineProvider theme={theme} defaultColorScheme="dark">
-      {/* …app… */}
-    </MantineProvider>
-  </DirectionProvider>
-)
-```
-
-To flip direction live (a language switcher) call
-`document.documentElement.setAttribute('dir', localeDir(next))` and Mantine's
-`useDirection().setDirection(dir)`; both read the same value.
-
-### Plain Vite SPA (kanban, test-harness vite-spa)
-
-No Mantine — just put `dir`/`lang` on `<html>` at bootstrap, after the locale is
-detected (the same `detectLocale` the i18n config uses):
-
-```ts
-import { detectLocale, localeDir } from './i18n/config'
-
-const locale = detectLocale(window.location.pathname)
-document.documentElement.lang = locale
-document.documentElement.dir = localeDir(locale)
-```
-
-Everything below inherits `dir` from `<html>`; logical CSS does the mirroring.
-
-### Vite SSR (test-harness vite-ssr)
-
-The worker renders the full HTML, so set `lang`/`dir` on the server `<html>`
-from the **URL** locale (the client inherits it on hydration — no flash):
-
-```tsx
-import { detectLocale, localeDir } from './i18n/config'
-
-const locale = detectLocale(new URL(request.url).pathname)
-const dir = localeDir(locale)
-const html = `<!doctype html>
-<html lang="${locale}" dir="${dir}">
-  …
-</html>`
-```
-
-i18next's active language must match: call `i18n.changeLanguage(locale)` before
-`renderToString` so the SSR'd text and `dir` agree.
-
-### Next.js app-router (test-harness next-ssr / next-static)
-
-Set it on the `<html>` in `app/layout.tsx`. With locale-prefixed routes the
-segment gives the locale; for a single-locale build it's a constant:
-
-```tsx
-import { localeDir, defaultLocale } from './i18n/config'
-
-export default function RootLayout({
-  children,
-}: {
-  children: React.ReactNode
-}) {
-  const locale = defaultLocale // or the [lang] route segment / params
-  return (
-    <html lang={locale} dir={localeDir(locale)}>
-      <body>{children}</body>
-    </html>
-  )
-}
-```
-
-For `output: 'export'` with `/ar` prefixes, derive `locale` from the route
-segment so each statically-exported tree carries the right `dir`.
-
-## Directional icons — the manual bit
-
-Logical properties mirror box layout, **not glyphs**. An icon that points
-somewhere (chevron, back/next arrow, send, undo) must flip under RTL; a
-non-directional icon (search, settings, avatar) must **not**. Flip with the
-`:dir()` selector — no JS, no per-locale branching:
-
-```css
-:dir(rtl) .icon-directional {
-  transform: scaleX(-1);
-}
-```
-
-Or in CSS-in-JS / inline, gate on the resolved direction:
-`transform: localeDir(locale) === 'rtl' ? 'scaleX(-1)' : undefined`.
-Prefer logical icon components if your icon set ships them.
-
-## Arabic typography niceties
-
-- **Font:** the default Latin stack renders Arabic with the system fallback,
-  which is inconsistent. Add an Arabic-capable family (e.g. _Noto Sans Arabic_,
-  _IBM Plex Sans Arabic_) to `font-family` so both scripts look intentional.
-- **Numerals:** don't hardcode digits. Format numbers/dates with
-  `Intl.NumberFormat`/`Intl.DateTimeFormat` (or i18next formatters) given the
-  active locale, so Western vs Arabic-Indic digits follow the locale choice.
-- **Line height:** Arabic diacritics sit tall — a slightly larger `line-height`
-  on Arabic body text avoids clipping. Keep it locale-scoped, not global.
-
-## Adding Arabic to an existing app — checklist
-
-1. `i18n/ar.json` mirroring `en.json`; register
-   `ar: { translation: ar satisfies typeof en }` and add `'ar'` to
-   `supportedLocales`. (Type-complete or it won't compile — the deploy blocks.)
-2. Confirm the `localeDir` helper includes `ar` (it does by default).
-3. Confirm the root sets `dir` from the locale (recipe above).
-4. Sweep the app's styles: replace every `left/right`, `ml/mr`, `text-align:
-left` with the flow-relative equivalent; revert any manual `row-reverse`.
-5. Flip directional icons.
-6. `tsc`, then load the Arabic route and verify the whole layout mirrors —
-   sidebar on the right, text right-aligned, arrows pointing the other way.
-
-## What NOT to do
-
-- Don't use physical `left`/`right` (or `ml`/`mr`) in any new layout style — even
-  in an English-only app. Writing logical from the start is the seam Arabic
-  slots into, exactly like tokens are for copy.
-- Don't fake RTL with `flex-direction: row-reverse`, reversed DOM order, or
-  per-locale `if (rtl)` layout branches. Set `dir` once; let layout follow.
-- Don't set `dir` on individual components — it belongs on `<html>` so the whole
-  document (and Mantine) agrees.
-- Don't translate Arabic copy outside the `t()` token system; an RTL language is
-  a normal locale, governed by `pikku-i18n`.

package/skills/pikku-scenario/SKILL.md

@@ -1,215 +0,0 @@
----
-name: pikku-scenario
-description: >-
-  Use when writing or running Pikku scenarios, or when asked to test Pikku functions or improve
-  test coverage. A scenario (pikkuScenario) drives the app the way users do — steps run as actors
-  over the real transport against a running server — so a flow doubles as an e2e test and a
-  staged/production health check. Covers scenario.do / expectEventually / expectError /
-  expectService, actors and environments in pikku.config.json, SCENARIO_ACTOR_SECRET, the
-  `pikku scenario list|run` commands, live function coverage via `pikku dev --coverage`, and
-  plain unit tests for pure function logic. TRIGGER when: user asks about scenarios, testing a
-  Pikku function, test coverage, end-to-end flows, or health checks. DO NOT TRIGGER when: user
-  asks about browser/UI e2e (that is @pikku/cucumber, out of scope), running an existing test
-  suite (use Bash), or CI configuration.
-installGroups: [core]
----
-
-# Pikku Scenarios
-
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Discover before editing: `pikku scenario list` for what exists, `pikku info functions --verbose` for what a scenario can call.
-2. Identify the source files that own the behavior. Do not start by reading generated output, `.pikku`, `node_modules`, or build artifacts.
-3. Make the smallest source change that satisfies the task. Keep generated files generated.
-4. Validate with the narrowest relevant command first, then `pikku all --tsc` when functions, wirings or schemas may have changed.
-5. If validation fails, fix the source cause and rerun. Do not paper over generated errors by editing generated files.
-
-**`pikku tests` does not exist.** It was removed in #865 — scenarios own coverage now. Any reference you find to it is stale.
-
-## What a scenario is
-
-A scenario is a `pikkuScenario` export that drives the app **as real actors over the real transport**, against a running server. That is what lets one artifact serve as both an e2e test and a staged/production health check.
-
-Consequences that matter, and bite if ignored:
-
-- **There is no state reset.** A scenario runs against a live server. Scope what you create (unique ids, your own rows) and never assume a clean database.
-- **Every step needs an actor.** `scenario.do(...)` without `{ actor }` throws `Scenario tried to run '<rpc>' as an internal step…`. There is no bare internal-RPC step.
-- **Actors must be configured and signed in**, or the scenario cannot run.
-
-Scenarios live in `srcDirectories` like any other function — by convention `*.scenario.ts`.
-
-## Writing one
-
-`pikkuScenario` comes from the **generated** workflow types, not `@pikku/core`:
-
-```typescript
-import { pikkuScenario } from '#pikku/workflow/pikku-workflow-types.gen.js'
-
-export const orderSupportScenario = pikkuScenario<
-  { value?: number },
-  { doubled: number; message: string }
->({
-  title: 'Order support (scenario)',
-  tags: ['scenario'],
-  func: async ({ logger }, data, { scenario, actors }) => {
-    if (!actors?.shopper || !actors?.support) {
-      throw new Error(
-        'orderSupportScenario needs run actors (shopper + support) — run via `pikku scenario run <environment>`'
-      )
-    }
-
-    const doubled = await scenario.do(
-      'shopper doubles their order',
-      'doubleValue',
-      { value: data?.value ?? 21 },
-      { actor: actors.shopper }
-    )
-
-    const settled = await scenario.expectEventually(
-      'support sees the greeting settle',
-      'formatMessage',
-      { greeting: 'Hello', name: 'Support' },
-      (out: { message: string }) => out.message.length > 0,
-      { actor: actors.support, within: '5s', interval: 50 }
-    )
-
-    return { doubled: doubled.result, message: settled.message }
-  },
-})
-```
-
-A scenario takes the same config fields as a workflow (`title`, `description`, `tags`, `input`/`output`, `auth`, `permissions`, `middleware`, `version`, …). The third argument is the scenario context: `{ scenario, actors }`.
-
-### The scenario API
-
-| Call | Purpose |
-| --- | --- |
-| `scenario.do(step, rpc, data, { actor })` | Run an RPC as that actor. The step name is what appears in the run output. |
-| `scenario.expectEventually(step, rpc, data, predicate, { actor, within, interval })` | Poll until `predicate(out)` passes or `within` elapses. For anything asynchronous — queues, workers, eventual state. |
-| `scenario.expectError(step, rpc, data, { actor, matches })` | Assert the call **fails**. For fault injection and negative paths. |
-| `scenario.expectService(step, 'service.method', { actor, calledWith })` | Assert a stubbed service was called. Requires the server to run with `--test`. |
-
-`expectEventually` is **scenario-only**. Calling it from a `pikkuWorkflowFunc` is a critical inspector error (`PKU675`) pointing you at `pikkuScenario`.
-
-Prefer `expectEventually` over sleeping. There is no `beforeEach`/`afterEach` — a scenario is a plain async function.
-
-## Configuration
-
-Actors and environments live in `pikku.config.json`:
-
-```json
-{
-  "scenarios": {
-    "actors": {
-      "shopper": {
-        "email": "shopper@actors.local",
-        "name": "Shopper",
-        "jobTitle": "First-time buyer",
-        "personality": "Impatient shopper who abandons slow checkouts"
-      },
-      "support": { "email": "support@actors.local", "name": "Support" }
-    },
-    "environments": {
-      "local": {
-        "apiUrl": "http://localhost:4077",
-        "signInPath": "/api/auth/sign-in/actor"
-      }
-    }
-  }
-}
-```
-
-- `environments.<name>.apiUrl` is required. `signInPath` defaults to `/auth/sign-in/actor`, `rpcPath` to `/rpc`.
-- **`SCENARIO_ACTOR_SECRET` is an environment variable and never goes in `pikku.config.json`.** It signs actors in. `pikku scenario run` throws without it; a server auto-building actors warns and runs without them.
-
-## Running
-
-```bash
-pikku scenario list                       # name [tags] + description; takes no options
-SCENARIO_ACTOR_SECRET=… pikku scenario run local
-SCENARIO_ACTOR_SECRET=… pikku scenario run local --flows orderSupportScenario
-SCENARIO_ACTOR_SECRET=… pikku scenario run local --tags smoke,scenario
-```
-
-`run` takes the environment as a **required positional** — the key from `scenarios.environments`. `--flows`/`-f` filters by scenario name, `--tags`/`-t` by tag (match-any).
-
-Output is `PASS <name> (<ms>) → <output>` / `FAIL <name> (<ms>): <error>`, then `N/M scenarios passed against '<env>'`.
-
-**Exit code is 1** if any scenario fails *or* if no scenario matched the filter — a typo'd `--flows` is a hard error, not a silent zero-run pass. It throws outright on an unknown environment, an unknown flow name, or a missing `SCENARIO_ACTOR_SECRET`.
-
-## Coverage
-
-Coverage is attributed by running scenarios against a server that is collecting it. It is **not** derived from unit tests.
-
-Prerequisites in `pikku.config.json`:
-
-```json
-{ "scaffold": { "scenarios": "auth" }, "verboseMeta": true }
-```
-
-`scaffold.scenarios` generates the coverage and stub RPCs into your project (`pikkuScenarioTakeLiveCoverage`, `pikkuScenarioResetLiveCoverage`, `pikkuScenarioResetStubs`, `pikkuScenarioGetStubCalls`), so scenario runs work against any server. `verboseMeta` is required — the coverage RPC reads the verbose functions meta and returns `null` without it.
-
-```bash
-pikku dev --coverage                                   # V8 precise coverage, in-process
-pikku dev --coverage --test                            # also enable stubs (needed for expectService)
-SCENARIO_ACTOR_SECRET=… pikku scenario run local --coverage
-```
-
-The run resets coverage before each scenario and snapshots after, writing **`<outDir>/coverage/scenario-coverage.json`**:
-
-```jsonc
-{ "generatedAt": "…", "environment": "local", "scenarios": { "<name>": { /* FunctionCoverageReport */ } } }
-```
-
-Coverage is best-effort: it disables itself with a warning if the server is not collecting or the first actor cannot invoke, and it needs at least one configured actor. If you get no coverage, check those first.
-
-**There is no AI-prompt output.** The old `--ai-out` flag died with `pikku tests`; nothing replaced it. To find what needs work, read `scenario-coverage.json` yourself and cross-reference `pikku meta functions list` for input/output schemas.
-
-### Filling coverage
-
-1. `pikku scenario run <env> --coverage`, then read `<outDir>/coverage/scenario-coverage.json` to see what is unexercised.
-2. `pikku meta functions list` for those functions' schemas.
-3. Write a `pikkuScenario` that reaches them **through a real user flow** with an actor — not a scenario per function. Scenarios are flows; coverage is a consequence.
-4. Re-run to confirm.
-
-## Unit tests for pure logic
-
-Scenarios are the repo-idiomatic way to test functions, and the only thing that contributes to live coverage. For pure logic with heavy branching, a plain unit test calling `func` directly is still valid and cheap:
-
-```typescript
-import { describe, test } from 'node:test'
-import assert from 'node:assert'
-
-describe('createTodo', () => {
-  test('creates a todo', async () => {
-    const services = { todoStore: { add: async (title: string) => ({ id: '1', title }) } }
-    const result = await createTodo.func(services as any, { title: 'Buy milk' })
-    assert.equal(result.title, 'Buy milk')
-  })
-})
-```
-
-```bash
-node --import tsx --test src/**/*.test.ts
-```
-
-Services are plain objects — a Pikku function is pure business logic, so a mock is just the shape the function destructures. Build real services via the `pikkuServices` / `pikkuWireServices` factories when a test needs them.
-
-## Red flags
-
-| Smell | Why it's wrong |
-| --- | --- |
-| `pikku tests …` | Removed in #865. Use `pikku scenario`. |
-| `.feature` files / Gherkin for function tests | Scenarios are TypeScript, not Gherkin. The in-process cucumber function world was deleted. |
-| `scenario.do(...)` with no `{ actor }` | Throws. Every step runs as somebody. |
-| A scenario per function | Scenarios are user flows. One flow covers many functions; that is the point. |
-| Assuming a clean database | There is no state reset — it may be a staging server. Scope what you create. |
-| `sleep()` before asserting | Use `expectEventually`. |
-| `expectEventually` in a `pikkuWorkflowFunc` | `PKU675` — scenario-only. |
-| Coverage silently 0 | Server not run with `--coverage`, `verboseMeta` off, `scaffold.scenarios` unset, or no actors configured. |
-
-`@pikku/cucumber` is a **browser/e2e** harness (`Actor`, `BrowserWorld`, `PersonaData`, `DbUtils`) — out of scope here.
-
-See `pikku-concepts` for the core mental model.

package/skills/pikku-schedule/SKILL.md

@@ -1,57 +0,0 @@
----
-name: pikku-schedule
-description: >-
-  Use when setting up in-memory cron scheduling in a Pikku app. Covers InMemorySchedulerService
-  for running scheduled tasks. TRIGGER when: code uses InMemorySchedulerService,
-  PikkuTaskScheduler, or user asks about in-memory scheduling, cron jobs without external
-  dependencies, or @pikku/schedule. DO NOT TRIGGER when: user asks about cron wiring (use
-  pikku-cron) or queue-based scheduling with BullMQ/PgBoss (use pikku-queue).
-installGroups: [core]
----
-
-# Pikku Schedule (In-Memory Scheduler)
-
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Discover before editing. Prefer OpenCode tools such as `pikku-meta` when available; otherwise run the relevant `pikku meta ... --json` command and inspect only the focused output you need.
-2. Identify the source files that own the behavior. Do not start by reading generated output, `.pikku`, `node_modules`, vendored packages, or broad build artifacts.
-3. Make the smallest source change that satisfies the task. Keep generated files generated, and avoid hand-editing SDKs, schema output, or typegen.
-4. Validate with the narrowest relevant command first, then run `pikku-verify` or `pikku all` when functions, wirings, schemas, or generated clients may have changed.
-5. If validation fails, fix the source cause and rerun validation. Do not paper over generated errors by editing generated files.
-
-`@pikku/schedule` provides an in-memory cron scheduler for running Pikku scheduled functions without external dependencies like Redis or PostgreSQL.
-
-## Installation
-
-```bash
-yarn add @pikku/schedule
-```
-
-## API Reference
-
-### `InMemorySchedulerService`
-
-```typescript
-import { InMemorySchedulerService } from '@pikku/schedule'
-
-const scheduler = new InMemorySchedulerService()
-```
-
-Implements the scheduler service interface. Schedules are held in memory — they do not survive process restarts. Suitable for development and single-instance deployments.
-
-## Usage Patterns
-
-### Basic Setup
-
-```typescript
-import { InMemorySchedulerService } from '@pikku/schedule'
-
-const createSingletonServices = pikkuServices(async (config) => {
-  const scheduler = new InMemorySchedulerService()
-  return { config, scheduler }
-})
-```
-
-For distributed or persistent scheduling, use BullMQ (`BullSchedulerService`) or PgBoss (`PgBossSchedulerService`) from the queue packages instead. See `pikku-queue` for details.

package/skills/pikku-schema-ajv/SKILL.md

@@ -1,62 +0,0 @@
----
-name: pikku-schema-ajv
-description: >-
-  Use when setting up JSON schema validation with AJV in a Pikku app. Covers AjvSchemaService for
-  request/response validation. TRIGGER when: code uses AjvSchemaService, user asks about AJV, JSON
-  schema validation, or @pikku/schema-ajv. DO NOT TRIGGER when: user asks about Cloudflare Workers
-  schema validation (use pikku-schema-cfworker).
-installGroups: [core]
----
-
-# Pikku Schema AJV (JSON Schema Validation)
-
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Discover before editing. Prefer OpenCode tools such as `pikku-meta` when available; otherwise run the relevant `pikku meta ... --json` command and inspect only the focused output you need.
-2. Identify the source files that own the behavior. Do not start by reading generated output, `.pikku`, `node_modules`, vendored packages, or broad build artifacts.
-3. Make the smallest source change that satisfies the task. Keep generated files generated, and avoid hand-editing SDKs, schema output, or typegen.
-4. Validate with the narrowest relevant command first, then run `pikku-verify` or `pikku all` when functions, wirings, schemas, or generated clients may have changed.
-5. If validation fails, fix the source cause and rerun validation. Do not paper over generated errors by editing generated files.
-
-`@pikku/schema-ajv` provides JSON schema validation using [AJV](https://ajv.js.org/). Implements the `SchemaService` interface from `@pikku/core`. This is the default schema validator for Node.js environments.
-
-## Installation
-
-```bash
-yarn add @pikku/schema-ajv
-```
-
-## API Reference
-
-### `AjvSchemaService`
-
-```typescript
-import { AjvSchemaService } from '@pikku/schema-ajv'
-
-const schema = new AjvSchemaService(logger: Logger)
-```
-
-**Methods:**
-
-- `compileSchema(schema: string, value: any): void` — Compile and register a JSON schema
-- `validateSchema(schemaName: string, json: any): void` — Validate data against a compiled schema (throws on failure)
-- `getSchemaNames(): Set<string>` — Get all registered schema names
-- `getSchemaKeys(schemaName: string): string[]` — Get property keys for a schema
-
-## Usage Patterns
-
-### With Pikku Services
-
-```typescript
-import { AjvSchemaService } from '@pikku/schema-ajv'
-
-const createSingletonServices = pikkuServices(async (config) => {
-  const logger = new ConsoleLogger()
-  const schema = new AjvSchemaService(logger)
-  return { config, logger, schema }
-})
-```
-
-Pikku automatically uses the schema service to validate function inputs and outputs when schemas are defined in your function definitions.

package/skills/pikku-schema-cfworker/SKILL.md

@@ -1,63 +0,0 @@
----
-name: pikku-schema-cfworker
-description: >-
-  Use when setting up JSON schema validation for Cloudflare Workers in a Pikku app. Covers
-  CFWorkerSchemaService as a lightweight alternative to AJV. TRIGGER when: code uses
-  CFWorkerSchemaService, user asks about schema validation on Cloudflare Workers, or
-  @pikku/schema-cfworker. DO NOT TRIGGER when: user asks about AJV schema validation (use
-  pikku-schema-ajv).
-installGroups: [core, fabric]
----
-
-# Pikku Schema CFWorker (Cloudflare Workers Validation)
-
-## Agent Operating Procedure
-
-Use this skill as an execution checklist, not reference material.
-
-1. Discover before editing. Prefer OpenCode tools such as `pikku-meta` when available; otherwise run the relevant `pikku meta ... --json` command and inspect only the focused output you need.
-2. Identify the source files that own the behavior. Do not start by reading generated output, `.pikku`, `node_modules`, vendored packages, or broad build artifacts.
-3. Make the smallest source change that satisfies the task. Keep generated files generated, and avoid hand-editing SDKs, schema output, or typegen.
-4. Validate with the narrowest relevant command first, then run `pikku-verify` or `pikku all` when functions, wirings, schemas, or generated clients may have changed.
-5. If validation fails, fix the source cause and rerun validation. Do not paper over generated errors by editing generated files.
-
-`@pikku/schema-cfworker` provides JSON schema validation using [@cfworker/json-schema](https://github.com/cfworker/cfworker), a lightweight validator compatible with Cloudflare Workers (no `eval` or `new Function`). Implements the `SchemaService` interface from `@pikku/core`.
-
-## Installation
-
-```bash
-yarn add @pikku/schema-cfworker
-```
-
-## API Reference
-
-### `CFWorkerSchemaService`
-
-```typescript
-import { CFWorkerSchemaService } from '@pikku/schema-cfworker'
-
-const schema = new CFWorkerSchemaService(logger: Logger)
-```
-
-**Methods:**
-
-- `compileSchema(schema: string, value: any): void` — Compile and register a JSON schema
-- `validateSchema(schemaName: string, json: any): void` — Validate data against a compiled schema (throws on failure)
-- `getSchemaNames(): Set<string>` — Get all registered schema names
-- `getSchemaKeys(schemaName: string): string[]` — Get property keys for a schema
-
-## Usage Patterns
-
-### With Cloudflare Workers
-
-```typescript
-import { CFWorkerSchemaService } from '@pikku/schema-cfworker'
-
-const createSingletonServices = pikkuServices(async (config) => {
-  const logger = new ConsoleLogger()
-  const schema = new CFWorkerSchemaService(logger)
-  return { config, logger, schema }
-})
-```
-
-Use this instead of `@pikku/schema-ajv` when deploying to Cloudflare Workers, as AJV uses `eval` which is not permitted in the Workers runtime.