@askrjs/cli 0.0.3 → 0.0.4

package/skills/askr-dashboard-charts/SKILL.md

@@ -1,99 +0,0 @@
----
-name: askr-dashboard-charts
-description: Build product dashboards and metric-heavy Askr routes with route-owned async state, shared formatting, and typed @askrjs/charts plots. Use for stat cards, mixed charts, live or follow-latest data, zoom, brush, selection, accessible summaries, and chart exports.
----
-
-# Askr Dashboard Charts
-
-Build dashboards that answer product questions without inventing parallel data, UI, or formatting systems.
-
-## Inspect First
-
-- Inspect the route or feature that owns the data.
-- Inspect existing cards, tables, empty states, chart tokens, and format helpers.
-- Inspect the nearest existing typed plot. In a generated SPA, start with `src/pages/app/admin-home.tsx`; in the CLI source, use `templates/spa/src/pages/app/admin-home.tsx`.
-
-## Keep Ownership Clear
-
-- Keep loading, empty, error, refresh, and composition state in the route or feature container.
-- `src/components/shared` owns reusable stat cards, page headers, tables, and empty states.
-- `src/features/<domain>` owns metric workflows and transforms.
-- `src/shared` owns formatting helpers so cards, tables, and charts stay consistent.
-- Keep row types app-owned; do not import package-owned datum types.
-
-## Work In Order
-
-1. Load dashboard data with `resource()` unless a wider owner already exists.
-2. Model stable row keys and missing values before choosing marks.
-3. Create each typed plot namespace once at module scope.
-4. Compose the smallest plot that answers the product question.
-5. Import `@askrjs/charts/styles` once at the app boundary.
-6. Pair plots with summaries or on-demand data tables when precision matters.
-
-## Compose A Typed Plot
-
-```tsx
-import { createPlot } from "@askrjs/charts";
-
-type ThroughputRow = {
-  id: string;
-  timestamp: Date;
-  completed: number;
-  movingAverage: number;
-};
-
-const ThroughputPlot = createPlot<ThroughputRow>();
-
-<ThroughputPlot.Root
-  data={rows}
-  rowKey="id"
-  label="Completed runs over time"
-  title="Run throughput"
-  description="Completed runs with a moving average."
->
-  <ThroughputPlot.Bar x="timestamp" y="completed" />
-  <ThroughputPlot.Line x="timestamp" y="movingAverage" />
-  <ThroughputPlot.Point x="timestamp" y="movingAverage" />
-  <ThroughputPlot.Zoom axes="x" />
-  <ThroughputPlot.Brush axis="x" modifier="shift" />
-</ThroughputPlot.Root>;
-```
-
-## Handle Mixed, Live, And Interactive Data
-
-- Use named scales and dual axes only when a mixed plot compares different units.
-- Pass a reactive data getter for changing rows and update arrays with `appendPlotRows`, `upsertPlotRows`, `removePlotRows`, or `trimPlotRows`.
-- Configure follow-latest by row count or time; let user pan or zoom pause following and provide an explicit `resumeLive()` action.
-- Keep `view` and `selection` controlled when route or shared state owns them; otherwise use plot-local state.
-- Add zoom, brush, legend filtering, or `onActivate` only when the workflow needs that interaction.
-- Keep source and transformed exports distinguishable, and preserve access to visible or selected rows.
-
-## Avoid
-
-- Inline mock metrics inside page JSX.
-- Hardcoded chart colors in runtime code.
-- Decorative charts that do not answer a product question.
-- Calling `createPlot()` inside a component or using unstable row keys.
-- Treating missing or non-finite values as zero.
-- Dense dashboards without loading, empty, and error states.
-
-## Validate
-
-- Verify cards, tables, tooltips, and exports share formatter logic; keep summaries and tooltip formatters valid for empty or missing rows.
-- Verify mobile and desktop layouts in light and dark themes.
-- Verify keyboard inspection, selection, zoom, brush, and the on-demand data table when used.
-- Verify live updates retain stable selections and pause follow-latest after user navigation.
-- Run the app's targeted tests and typecheck before its full acceptance command.
-
-## Done When
-
-- Route-owned async states remain explicit.
-- Typed rows and stable keys drive the plot.
-- The plot supports the product question without becoming a component gallery.
-- Accessible summaries and precise data remain available without relying on canvas pixels.
-
-## Handoff
-
-- Use `askr-resources-data` when async ownership is the real blocker.
-- Use `askr-theming` when the hard part is shell and visual coherence.
-- Use `askr-testing-determinism` before closing responsive or stateful chart changes.

package/skills/askr-dashboard-charts/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Dashboard Charts"
-  short_description: "Compose typed Askr dashboard plots"
-  default_prompt: "Use $askr-dashboard-charts to build an accessible typed dashboard plot."

package/skills/askr-design-system/SKILL.md

@@ -1,86 +0,0 @@
----
-name: askr-design-system
-description: Use when creating product-grade Askr interfaces, design-system rules, density, page hierarchy, navigation, forms, tables, panels, action placement, tokens, dark mode, responsive behavior, and operational UI polish.
----
-
-# Askr Design System
-
-Use this only when a repeated product pattern must become shared across multiple screens. This is not the default starting skill for a single UI task.
-
-## Inspect First
-
-- Existing `src/styles`, tokens, theme imports, and shared components.
-- `src/components/shared` before adding new UI building blocks.
-- `@askrjs/themes` primitives already in use.
-- Target product audience and primary workflows.
-
-## Use This When
-
-- The same pattern repeats across three or more screens.
-- Theme primitives alone are not enough to express a product-specific shared pattern.
-- You need consistent density, hierarchy, and action placement across the app.
-- You are about to create a reusable product component, not just style one page.
-
-## Product UI Defaults
-
-- Prefer quiet, dense, scannable SaaS/admin interfaces.
-- Use page headers, toolbars, panels, forms, tables, and clear action hierarchy.
-- Keep primary actions close to the object or workflow they affect.
-- Use icons for familiar tool actions and text for consequential commands.
-- Use tokens and semantic slots rather than one-off visual styles.
-- Before inventing a component, check `@askrjs/themes` layout, control, surface, feedback, shell, nav, and overlay exports.
-
-## Do This In Order
-
-1. Prove the pattern is repeated enough to deserve extraction.
-2. Start from existing theme primitives and shared styles.
-3. Extract the smallest product-specific shared component or CSS recipe that removes repetition.
-4. Keep tokens in CSS and keep workflow logic out of design-system components.
-5. Validate the pattern in light, dark, responsive, empty, error, and disabled states.
-
-## Start From These Primitives
-
-- Page width/rhythm: `Container`, `Section`.
-- Vertical and horizontal composition: `Stack`, `Inline`, `Flex`.
-- Responsive groups: `Block`.
-- Low-level layout: `Box`, `Spacer`, `AspectRatio`.
-- Product surfaces: `Card`, `Alert`, `Badge`, `ListGroup`, `Separator`, `Skeleton`.
-- Forms/actions: `Button`, `ButtonGroup`, `Close`, `Field`, `FieldHint`, `FieldError`, `InputGroup`.
-- Async states: `EmptyState`, `Spinner`, plus query/resource state-specific copy.
-- App chrome: `Shell`, `ShellNav`, `ShellMain`, `Header`, `Sidebar`, `Navbar`.
-- Navigation: `Nav`, `NavLink`, `NavGroup`, `NavBrand`, `Breadcrumb`, `Pagination`.
-- Menus: themed `Dropdown`, `Menu`, and `Menubar` from `@askrjs/themes/components`.
-
-## Never Do These
-
-- Route layouts own shell chrome.
-- Shared components own repeatable product surfaces.
-- Page sections should be unframed layout regions; use cards/panels for repeated items or contained tools.
-- Do not wrap cards inside cards; use `Section`, `Container`, `Stack`, and `Block` for page-level composition.
-- Tables and forms should be compact but readable.
-- Long labels must wrap or truncate intentionally.
-- Marketing-page composition for operational apps.
-- Decorative gradients, oversized hero panels, or low-density cards in work surfaces.
-- Hardcoded colors and spacing outside tokens.
-- Component variants that duplicate what CSS state or slots should handle.
-- App-local design-system clones of theme primitives.
-- Custom CSS grids or flex wrappers when `Block`, `Flex`, `Inline`, or `Stack` already express the layout.
-
-## Validate
-
-- Mobile, tablet, desktop, light, and dark modes are considered.
-- Focus, hover, disabled, loading, empty, and error states feel consistent.
-- Text does not overflow buttons, cards, navs, tables, or overlays.
-- The interface optimizes repeated use, not only first impression.
-
-## Done When
-
-- A repeated product pattern became shared without creating a second component catalog.
-- Theme primitives still provide the baseline behavior and styling model.
-- The extracted pattern improves coherence across real repeated screens.
-
-## Handoff
-
-- Use `askr-theming` when the next step is token or shell styling.
-- Use `askr-ui-composition` when the next step is interactive behavior.
-- Use `askr-testing-determinism` before closing broad visual-system changes.

package/skills/askr-design-system/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Design System"
-  short_description: "Shape polished product UI"
-  default_prompt: "Use $askr-design-system to design an Askr product surface."

package/skills/askr-env-config/SKILL.md

@@ -1,74 +0,0 @@
----
-name: askr-env-config
-description: Use when configuring Askr apps with environment variables, API base URLs, feature flags, deployment config, local mocks, generated client configuration, and separating config from runtime state.
----
-
-# Askr Env Config
-
-Use this for environment-specific application configuration. The goal is one typed config boundary, explicit public values, and no env reads scattered through UI code.
-
-## Use This When
-
-- You need API base URLs, feature flags, deployment config, or client configuration.
-- The app has local mocks, staging behavior, or environment-specific stream endpoints.
-- You need missing required config to fail early.
-- You want tests to override config deterministically.
-
-## Inspect First
-
-- Existing Vite or runtime environment usage and app config helpers
-- Generated API client configuration
-- Local mock data and development-only switches
-- Deployment target requirements
-
-## Put Config In One Boundary
-
-- Parse and validate config in `src/shared/config` or the repo's existing shared config module.
-- Pass API base URLs and auth providers into `src/adapters`.
-- Keep feature flags readable from features and pages without coupling them to transport details.
-- Keep secrets out of client bundles.
-
-## Do This In Order
-
-1. Define a typed config object for the public values the client needs.
-2. Validate required values at app startup.
-3. Pass config into adapters and shared helpers instead of reading env values ad hoc.
-4. Keep local mocks explicit and easy to disable.
-5. Name and document reconnect intervals, stale thresholds, or polling settings centrally when the app is event-driven.
-
-## Copy This Shape
-
-```ts
-export const appConfig = {
-  apiBaseUrl: requireEnv("VITE_API_BASE_URL"),
-  enableMocks: import.meta.env.VITE_ENABLE_MOCKS === "true",
-  streamReconnectMs: Number(import.meta.env.VITE_STREAM_RECONNECT_MS ?? 3000),
-};
-```
-
-## Never Do These
-
-- Reading env variables directly in many components.
-- Shipping server secrets to the browser.
-- Hidden dev mocks that change production behavior.
-- Feature flags that fork route structure unpredictably.
-
-## Validate
-
-- Missing required config fails early with a useful message.
-- API adapters receive config through one boundary.
-- Local, staging, and production config paths are obvious.
-- Tests can override config deterministically.
-
-## Done When
-
-- Public config is typed and centralized.
-- Env reads no longer leak through UI files.
-- Event-driven timing or fallback config is explicit where relevant.
-- Secret and public config boundaries are clear.
-
-## Handoff
-
-- Use `askr-api-integration` when config shapes adapter behavior.
-- Use `askr-realtime-streaming` when reconnect or polling config is the hard part.
-- Use `askr-testing-determinism` when config override behavior needs validation.

package/skills/askr-env-config/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Env Config"
-  short_description: "Configure env and feature flags"
-  default_prompt: "Use $askr-env-config to configure an Askr app environment."

package/skills/askr-error-loading-empty/SKILL.md

@@ -1,89 +0,0 @@
----
-name: askr-error-loading-empty
-description: Use when designing Askr loading, empty, error, stale, refreshing, pending-write, retry, disabled, partial-data, and eventual-consistency UX across routes, tables, forms, dashboards, queries, and mutations.
----
-
-# Askr Error Loading Empty
-
-Use this whenever a feature touches async data or failure states. The goal is one truthful UI meaning per async state.
-
-## Use This When
-
-- You added a `resource()`, `createQuery()`, or `createMutation()` path.
-- The screen can load, refresh, fail, be empty, or lag behind a write.
-- The UX currently hides too much behind one spinner or one toast.
-- The user needs truthful state during eventual consistency.
-
-## Inspect First
-
-- The owner of the async state.
-- Existing shared alert, empty-state, skeleton, toast, and status components.
-- Query fields such as `loading`, `refreshing`, `stale`, and `consistency`.
-- Mutation fields such as `pending`, `error`, `result`, and `status`.
-
-## Use This Vocabulary
-
-- Initial loading: no usable data yet.
-- Refreshing: old data is visible while new data loads.
-- Empty: request succeeded but no records match.
-- Error: request failed and user needs recovery or explanation.
-- Partial: some data is usable, some failed or is still loading.
-- Pending write: command accepted but read model may not reflect it yet.
-- Stale: current read model is known or suspected to be behind.
-
-## Do This In Order
-
-1. Render a distinct state for initial load, empty, error, refresh, and pending write.
-2. Keep useful old data visible during refresh when it is safe to do so.
-3. Use truthful copy such as `refreshing`, `saved, syncing`, or `reconnecting`.
-4. Disable only the actions that are actually unsafe.
-5. Prefer row-level or local status when only one record is stale or pending.
-
-## Copy This Shape
-
-```tsx
-if (accounts.pending && !accounts.value) {
-  return <p>Loading accounts...</p>;
-}
-
-if (accounts.error && !accounts.value) {
-  return <p role="alert">Unable to load accounts.</p>;
-}
-
-return (
-  <section>
-    <Show when={accounts.refreshing || accounts.consistency === "pending-write"}>
-      <p role="status">Saved, syncing...</p>
-    </Show>
-
-    <Show when={(accounts.value?.items.length ?? 0) === 0}>
-      <p>No accounts matched this filter.</p>
-    </Show>
-
-    <AccountsTable rows={accounts.value?.items ?? []} />
-  </section>
-);
-```
-
-- One spinner for every async state.
-- Empty states that hide errors.
-- Toast-only errors for important failed workflows.
-- Claiming a write is fully complete before the read side confirms it.
-- Clearing useful data during refresh.
-- Global blocking UI when only one row or one mutation is actually stale.
-
-## Validate
-
-- Initial, refresh, empty, error, stale, and pending-write states are distinct.
-- Retry paths call the real owner.
-- Important failures are visible without depending only on color or toast.
-- Copy tells the truth about eventual consistency.
-
-## Done When
-
-- The screen no longer hides multiple async truths behind one spinner.
-
-## Handoff
-
-- Use `askr-query-mutation` or `askr-resources-data` when the owning state model is still unclear.
-- Use `askr-accessibility` when announcements, focus, or row-level status semantics need review.

package/skills/askr-error-loading-empty/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Error Loading Empty"
-  short_description: "Design async UX states clearly"
-  default_prompt: "Use $askr-error-loading-empty to design async UI states."

package/skills/askr-file-upload-artifacts/SKILL.md

@@ -1,77 +0,0 @@
----
-name: askr-file-upload-artifacts
-description: Use when building Askr file uploads, generated artifacts, progress, previews, validation, storage adapters, downloads, open flows, virus-scan or processing states, and event-sourced artifact readiness.
----
-
-# Askr File Upload Artifacts
-
-Use this for uploads, downloads, previews, and generated files. The goal is one clear upload workflow, explicit processing truth, and no loss of progress or readiness state.
-
-## Use This When
-
-- You need file selection, upload, processing, preview, or download flows.
-- Artifacts may be generated asynchronously after upload.
-- You need progress, retry, cancellation, or readiness reconciliation.
-- Validation rules include type, size, count, privacy, or retention.
-
-## Inspect First
-
-- Adapter support for upload URLs, multipart uploads, or artifact APIs
-- Feature workflow for create, upload, process, and download
-- File validation rules: type, size, count, privacy, retention
-- Artifact processing states and event stream support
-
-## Choose The Boundary
-
-- `src/adapters`: upload transport, signed URL calls, artifact downloads.
-- `src/features/<feature>`: validation, upload workflow, and artifact query or mutation state.
-- `src/components/shared`: reusable file picker, progress list, and preview shell.
-- `src/shared`: size formatting, safe filename helpers, and error normalization.
-
-## Do This In Order
-
-1. Keep file validation explicit before upload starts.
-2. Model selection, uploading, processing, ready, and failure as separate states.
-3. Preserve upload ID, artifact ID, processing job ID, and last event ID when readiness is asynchronous.
-4. Treat upload completion and artifact readiness as separate truths.
-5. Allow retry or refresh without duplicating uploads where possible.
-
-## Copy This Shape
-
-```ts
-type ArtifactStatus =
-  | "selected"
-  | "uploading"
-  | "processing"
-  | "ready"
-  | "failed-validation"
-  | "failed-upload"
-  | "failed-processing";
-```
-
-## Never Do These
-
-- Pretending an artifact is ready immediately after upload when processing is asynchronous.
-- Client-only validation as the only protection.
-- Losing progress and error state on route-local rerenders.
-- Download links without accessible names or file metadata.
-
-## Validate
-
-- Validation, upload, processing, ready, and failure states are visible.
-- Upload cancellation or retry behavior is explicit.
-- Large files and unsupported types fail clearly.
-- Artifact readiness is reconciled from server state.
-
-## Done When
-
-- Upload completion and artifact readiness are modeled separately.
-- Progress and error state survive the owning workflow.
-- Artifact metadata is preserved for retries and reconciliation.
-- Users can understand whether a file is uploaded, processing, ready, or failed.
-
-## Handoff
-
-- Use `askr-api-integration` when signed URLs or artifact APIs are the hard part.
-- Use `askr-error-loading-empty` when the hard part is presenting processing and failure truth.
-- Use `askr-testing-determinism` before closing upload and retry behavior.

package/skills/askr-file-upload-artifacts/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr File Upload Artifacts"
-  short_description: "Handle uploads and artifacts"
-  default_prompt: "Use $askr-file-upload-artifacts to build file workflows."

package/skills/askr-forms-tables-crud/SKILL.md

@@ -1,98 +0,0 @@
----
-name: askr-forms-tables-crud
-description: Use when building askr CRUD screens, forms, validation, filters, tables, pagination, selection, bulk actions, confirmation dialogs, row actions, resource/query data flow, and feature folder boundaries.
----
-
-# Askr Forms Tables CRUD
-
-Use this for create, read, update, archive, filter, paginate, and edit workflows. The goal is a predictable split between route composition, feature workflow state, and transport boundaries.
-
-## Inspect First
-
-- The nearest page that owns a table or form.
-- The nearest feature folder for the same domain.
-- The adapter or service that owns transport.
-- Existing tests that cover filtering, submission, or destructive actions.
-
-## Use This When
-
-- You are adding a list, detail, create, edit, archive, or bulk-action flow.
-- You need filters, pagination, selection, or row actions.
-- You need field validation and server validation errors.
-- You need a safe destructive action flow.
-
-## Pick The Owner
-
-- The route or page composes the screen.
-- The feature folder owns filters, form state, table columns, queries, and mutations.
-- The adapter owns fetch, update, archive, and DTO mapping.
-- Shared helpers own cross-cutting formatting and validation helpers when reused.
-
-## Copy This Shape
-
-```text
-src/pages/app/users.tsx
-src/features/users/user-table.tsx
-src/features/users/user-filters.tsx
-src/features/users/user-form.tsx
-src/features/users/users.query.ts
-src/features/users/users.mutation.ts
-src/adapters/users-client.ts
-src/shared/format.ts
-```
-
-Routes compose the screen. Features own domain UI and workflow state. Adapters own transport. Shared helpers own cross-cutting formatting or validation utilities.
-
-## Do This In Order
-
-1. Choose the async owner first: `resource()` for route-owned reads, `createQuery()` for shared keyed reads, and `createMutation()` for writes.
-2. Keep filters, pagination, dialog state, and selected IDs in local `state()` pairs, and read or write each one through its `[getter, setter]` pair.
-3. Keep field validation and submit handling explicit in the feature layer.
-4. Confirm destructive actions before archive or delete.
-5. Refresh or invalidate after create, update, archive, or delete.
-
-## Table Rules
-
-- Use stable row keys, never index keys for records.
-- Put feature-specific columns in the feature folder.
-- Use `selector()` for keyed row selection fanout when the table is large or hot.
-- Provide loading, empty, error, and disabled action states.
-- Keep formatting in `src/shared/format.ts` or a domain feature helper.
-
-## Form Rules
-
-- Keep form state local unless multiple routes need it.
-- Put validation rules in `src/features/<feature>` when domain-specific, or `src/shared` when cross-cutting.
-- Use `@askrjs/ui` form controls for behavior and accessibility.
-- Disable submit while pending and surface field or form errors explicitly.
-
-- API clients in table, form, or generic UI components.
-- Bound live or frequently updating rows so tables and timelines do not churn the whole DOM.
-- Keep filtering, sorting, and pagination state together in the feature workflow instead of scattering it across route files.
-- Business rules in reusable primitives.
-- Hidden destructive actions without confirmation.
-- Duplicated pagination/filter logic across route files.
-- A table component that imports a raw API client and mutates records directly from row actions.
-- A form that shows only a toast on submit failure and never maps field errors back to inputs.
-- Pagination, sorting, and filter state duplicated in multiple route pages.
-
-## Validate
-
-- CRUD ownership boundaries are obvious.
-- Every async path has loading, error, retry, or disabled feedback.
-- Selection, bulk actions, and destructive actions are keyboard reachable.
-- Submit handlers preserve pending state and field or form errors.
-- Record rows use stable keys.
-
-## Done When
-
-- Form, table, mutation, and adapter ownership are separated.
-- Field errors, form errors, pending state, and success state are all visible.
-- Selection, filters, sorting, and destructive actions are keyboard reachable.
-- Rows keep stable identity and large updates do not force whole-list churn.
-
-## Handoff
-
-- Use `askr-query-mutation` when the form or table state becomes shared keyed state across screens.
-- Use `askr-accessibility` when validation, focus, or destructive-action UX is the hard part.
-- Use `askr-testing-determinism` to validate submit, retry, selection, and list identity behavior.

package/skills/askr-forms-tables-crud/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Forms Tables CRUD"
-  short_description: "Build CRUD forms and tables"
-  default_prompt: "Use $askr-forms-tables-crud to build a CRUD workflow in askr."

package/skills/askr-mental-model/SKILL.md

@@ -1,109 +0,0 @@
----
-name: askr-mental-model
-description: Use when an AI agent or developer needs the canonical Askr mental model, including what Askr is, what it is not, how core primitives fit together, and which React-style assumptions must be rejected.
----
-
-# Askr Mental Model
-
-Use this before building or reviewing Askr code when primitive choice is unclear. This skill exists to keep agents on the native Askr path and off React-shaped defaults.
-
-## Use This When
-
-- Primitive choice is unclear.
-- The task looks like React, hooks, or a generic SPA by default.
-- You need to decide who owns local state, async reads, or writes.
-- You need one obvious Askr-native shape before editing.
-
-## Inspect First
-
-- `AGENTS.md` when it exists
-- `src/main.tsx`
-- The nearest route file and layout file
-- The nearest existing feature that solves a similar problem
-- Existing tests for the touched surface
-
-## What Askr Expects
-
-- Route-first ownership.
-- Synchronous route components.
-- Explicit runtime primitives for state, derived state, lifecycle-owned async work, shared server state, and writes.
-- Honest UI for loading, empty, error, stale, and pending-write states.
-
-## What Askr Is Not
-
-- Not a React hooks runtime.
-- Not a place to default to `useEffect` data loading.
-- Not a reason to add React Router, TanStack Query, or a global state library first.
-- Not a place to clone solved `Button`, `Card`, `Sidebar`, `EmptyState`, or shell primitives before checking the existing theme and UI layers.
-
-## Pick The Primitive
-
-- Local mutable UI state: use `state()` as a `[getter, setter]` pair.
-- Computed value from reactive reads: use `derive()`.
-- One source fans out to many keyed readers: use `selector()`.
-- One route or container owns an async read lifecycle: use `resource()`.
-- Shared keyed server state used across screens: use `createQuery()`.
-- Writes with pending, error, and reconciliation state: use `createMutation()`.
-- Keyed or dynamic list identity matters: use `For`.
-
-## Copy This Shape
-
-```tsx
-import { derive, selector, state } from "@askrjs/askr";
-import { For } from "@askrjs/askr/control";
-
-const [selectedId, setSelectedId] = state<string | null>(null);
-const isSelected = selector(selectedId);
-const items = derive(() => [
-  { id: "queued", label: "Queued" },
-  { id: "running", label: "Running" },
-  { id: "done", label: "Done" },
-]);
-
-export default function RunFilterBar() {
-  return (
-    <nav aria-label="Run status filters">
-      <For each={items()} by={(item) => item.id}>
-        {(item) => (
-          <button
-            type="button"
-            aria-pressed={isSelected(item.id)}
-            onClick={() => setSelectedId(item.id)}
-          >
-            {item.label}
-          </button>
-        )}
-      </For>
-    </nav>
-  );
-}
-```
-
-## Reject These Shapes
-
-- React imports or hook-shaped state as the default solution.
-- Effect-driven loading when the UI depends on the async result.
-- Treating getters like plain values instead of callable reads.
-- Creating runtime helpers conditionally.
-- Defaulting to `.map()` for large or dynamic keyed lists where `For` should own identity.
-- Hiding data transport, mapping, and mutations inside pages or presentational components.
-
-## Validate
-
-- Primitive choice is explainable in one sentence.
-- Route components remain synchronous.
-- Keyed UI uses stable IDs.
-- No React runtime imports or hook defaults slipped in.
-- Async state truth is explicit where the user can observe it.
-
-## Done When
-
-- The code reads like Askr, not like translated React.
-- No invented primitives or parallel state layers were added.
-- The next narrower skill is obvious from the changed surface.
-
-## Handoff
-
-- Use `askr-routing-layouts` when the next step is route ownership or shell structure.
-- Use `askr-resources-data` or `askr-query-mutation` when the next step is async ownership.
-- Use `askr-runtime-reactivity` when the next step is local state or keyed rendering behavior.

package/skills/askr-mental-model/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Askr Mental Model"
-  short_description: "Learn the canonical Askr runtime model"
-  default_prompt: "Use $askr-mental-model before building or reviewing Askr application code."