@askrjs/cli 0.0.2

package/dist/skills/askr-app-builder/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: askr-app-builder
+description: Use when building or substantially extending an Askr application, choosing scaffolds, planning app architecture, combining routing, state, data, UI primitives, theming, charts, SSR/SSG, or deciding which more specific Askr skill should guide the work.
+---
+
+# Askr App Builder
+
+Use this only when a task spans multiple owned workflows and no single narrower skill is enough. This is a planning and dispatch skill, not the default starting point for everyday feature work.
+
+## Use This When
+
+- A new feature spans routing, data ownership, UI composition, and validation together.
+- You need to choose a scaffold or template path before implementation.
+- You need to break a broad feature into smaller owned slices.
+- The task touches multiple branches, features, and render surfaces at once.
+
+## Do Not Use This First When
+
+- The task is only about one route, one component, one async owner, or one UI surface.
+- File ownership is unclear but still local; use `askr-project-structure` instead.
+- The hard problem is already clearly routing, state, theming, auth, or validation.
+
+## Inspect First
+
+- `AGENTS.md` when it exists
+- `package.json`
+- `src/main.tsx`
+- The top-level route registry and nearest branch layout
+- Existing `src/features`, `src/adapters`, `src/shared`, and `src/styles` ownership
+- Existing tests for the surfaces involved
+
+## Plan The Slice
+
+1. Pick the template or existing app baseline.
+2. Identify the route owner, layout owner, feature owner, adapter owner, and validation owner.
+3. Split the work into smaller slices that can each be guided by one narrower skill.
+4. Apply those narrower skills in sequence instead of keeping the whole task under this one.
+5. End with `askr-testing-determinism` once the slices are implemented.
+
+## Choose The Baseline
+
+- New product app: `askr create startkit <name>`.
+- Minimal interactive app: `spa`.
+- Server-rendered app: `ssr`.
+- Static or docs site: `ssg`.
+- Existing app: follow its current route, layout, style, and test conventions before introducing new ones.
+
+## Route The Work To Narrower Skills
+
+- File placement or ownership: `askr-project-structure`.
+- Route tree, metadata, shell boundaries, navigation: `askr-routing-layouts`.
+- Local state or keyed rendering: `askr-runtime-reactivity`.
+- Route-owned async reads: `askr-resources-data`.
+- Shared keyed reads and writes: `askr-query-mutation`.
+- Async truth states: `askr-error-loading-empty`.
+- CRUD workflow: `askr-forms-tables-crud`.
+- Auth and access: `askr-auth-access`.
+- Theming and UI composition: `askr-theming` and `askr-ui-composition`.
+- Realtime or event streams: `askr-realtime-streaming`.
+- SSR or SSG: `askr-ssr-ssg`.
+- Final validation: `askr-testing-determinism`.
+
+## Copy This Shape
+
+```text
+route owner      -> src/pages/app/_routes.tsx
+layout owner     -> src/pages/app/_layout.tsx
+feature owner    -> src/features/agents/
+adapter owner    -> src/adapters/agents-client.ts
+validation owner -> tests/ or nearest package test script
+```
+
+## Never Do These
+
+- React-shaped defaults such as `useEffect` data loading or implicit mutable state.
+- Mixing route registration, data transport, layout shell, and visual theme logic in one component.
+- Treating this skill as a substitute for narrower workflow skills.
+- Raw interactive HTML when an `@askrjs/ui` primitive owns the behavior.
+- App-local layout, shell, card, nav, feedback, or form primitives when `@askrjs/themes` already owns the surface.
+- Hardcoded `--ak-*` token literals in runtime TypeScript or JavaScript.
+
+## Validate
+
+- The app has one clear route tree.
+- Route branches, layouts, feature workflows, adapters, shared helpers, UI behavior, and theme concerns sit in separate layers.
+- Loading, empty, error, disabled, and narrow-screen states are explicit.
+- `npm run check` or the closest available project check passes.
+
+## Done When
+
+- The chosen template path still matches the app surface.
+- Each slice is routed to one narrower skill.
+- Route, layout, feature, adapter, shared, and theme concerns are separated.
+- No foreign framework defaults or invented primitives slipped in.
+
+## Handoff
+
+- Use the narrower skill that owns the next slice.
+- Use `askr-testing-determinism` before finalizing the assembled result.

package/dist/skills/askr-app-builder/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Askr App Builder"
+  short_description: "Build idiomatic Askr applications"
+  default_prompt: "Use $askr-app-builder to plan and build an idiomatic Askr app."

package/dist/skills/askr-auth-access/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: askr-auth-access
+description: Use when building Askr authentication, session loading, public/app route branches, protected layouts, role and permission requirements, redirects, login/logout, and access-denied UX.
+---
+
+# Askr Auth Access
+
+Use this for authentication and authorization in route-first Askr apps. The goal is explicit route policy, explicit session resolution, and no token or permission logic leaking into pages.
+
+## Inspect First
+
+- `src/pages/_routes.tsx`, `src/pages/public/_routes.tsx`, and `src/pages/app/_routes.tsx`
+- `src/pages/public/_layout.tsx` and `src/pages/app/_layout.tsx`
+- Existing session, token, and user helpers in `src/shared` or `src/features/auth`
+- Router auth resolver configuration
+
+## Use This When
+
+- You need guest-only and authenticated route branches.
+- You need route-level auth or permission requirements.
+- You need login, logout, redirect, or forbidden behavior.
+- You need to keep access checks out of page-local component logic.
+
+## Do This In Order
+
+1. Keep public and authenticated branches explicit in the route tree.
+2. Put an `AuthRequirement` on the narrowest route group or route that owns the policy.
+3. Resolve session state before rendering protected data or destructive controls.
+4. Redirect unauthenticated users to login with a return target when useful.
+5. Show a signed-in forbidden state when the user is authenticated but lacks permission.
+6. Keep token storage, refresh, and header policy in auth helpers or adapters, not components.
+
+## Copy This Shape
+
+```tsx
+import { requireAnonymous, requireUser } from "@askrjs/auth";
+
+group({ layout: AuthLayout, auth: requireAnonymous() }, () => {
+  registerAuthRoutes();
+});
+
+group({ layout: AppLayout, auth: requireUser() }, () => {
+  registerAppRoutes();
+});
+```
+
+## Never Do These
+
+- Per-page auth checks duplicated across protected routes.
+- Rendering protected app data before session resolution.
+- Putting token storage or API auth header logic in components.
+- Treating roles and permissions as visual-only state.
+- Client-only authorization decisions for sensitive server actions.
+- Silent redirects when the user is signed in but lacks access.
+
+## Validate
+
+- Public and app branches are explicit.
+- Protected routes have a function-based auth requirement in the route tree.
+- Access-denied, loading, and redirect behavior are tested.
+- Auth state is available to adapters without leaking transport details into UI.
+
+## Done When
+
+- Session resolution is explicit before protected data renders.
+- Auth and authorization live in route requirements or auth workflows, not scattered through pages.
+- Unauthorized, redirect, and signed-out states are all covered.
+- Sensitive transport or token logic did not leak into UI components.
+
+## Handoff
+
+- Use `askr-routing-layouts` when auth changes also reshape the route tree.
+- Use `askr-api-integration` when auth headers, session refresh, or adapter policy is changing.
+- Use `askr-observability-debugging` when denial reasons or audit trails must stay visible.

package/dist/skills/askr-auth-access/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Askr Auth Access"
+  short_description: "Model auth branches and access"
+  default_prompt: "Use $askr-auth-access to add authentication and route access."

package/dist/skills/askr-cli-vite/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: askr-cli-vite
+description: Use when scaffolding Askr projects with @askrjs/cli, choosing spa/ssr/ssg/startkit templates, configuring @askrjs/vite, JSX import source, Vite build setup, generated app customization, or fixing transform wiring.
+---
+
+# Askr CLI Vite
+
+Use this only when the task is scaffold choice, initial project setup, or repair of Vite and transform wiring. It is not a normal feature-work skill after the app is already on the canonical path.
+
+## Use This When
+
+- Choosing between `spa`, `ssr`, `ssg`, and `startkit`.
+- Fixing `@askrjs/vite` plugin wiring or JSX import-source setup.
+- Repairing generated `package.json`, `vite.config.ts`, or `tsconfig` settings.
+- Adjusting scaffolded build integration without changing runtime architecture.
+
+## Inspect First
+
+- `docs/create.md`
+- `docs/workflows.md`
+- Existing `package.json`, `vite.config.ts`, and `tsconfig.json`
+- The nearest matching template under `templates/`
+
+## Start From The Closest Template
+
+- `startkit`: default for new product apps with dashboard, accounts, settings, login, themes, icons, and common checks.
+- `spa`: minimal client-rendered interactive app.
+- `ssr`: server-rendered app boundary.
+- `ssg`: static generation scaffold with `ssg.config.ts`.
+
+## Do This In Order
+
+1. Choose the closest template instead of starting from raw Vite.
+2. Preserve generated Vite wiring unless the app has a concrete build requirement.
+3. Keep `askr()` as the owning plugin for Askr JSX and transforms.
+4. Keep runtime route, data, and component decisions out of build config.
+5. Treat generated files as app-owned after scaffold, not immutable.
+6. Validate scripts and transforms before moving on to feature work.
+
+## Copy This Shape
+
+```ts
+import { defineConfig } from "vite";
+import { askr } from "@askrjs/vite";
+
+export default defineConfig({
+  plugins: [askr()],
+});
+```
+
+## Never Do These
+
+- Duplicating JSX transform setup in Vite, `tsconfig`, and custom esbuild config.
+- Choosing `startkit` for a tiny isolated demo when `spa` fits better.
+- Treating CLI-generated files as immutable.
+- Adding runtime route or data decisions to build config.
+
+## Validate
+
+- `vite.config.ts` uses `askr()`.
+- `package.json` scripts match the selected template.
+- `tsconfig` JSX settings match template conventions.
+- `npm run dev`, `npm run build`, and available checks pass after setup.
+
+## Done When
+
+- The template matches the runtime boundary the app actually needs.
+- Vite wiring stays package-owned and minimal.
+- Generated files are ready for normal workflow skills.
+- No runtime architecture leaked into build config.
+
+## Handoff
+
+- Use `askr-app-builder` only when the task is still a broad app brief.
+- Use `askr-ssr-ssg` when the render boundary is the hard part.
+- Use the normal route, data, or UI workflow skills once the scaffold exists.

package/dist/skills/askr-cli-vite/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Askr CLI Vite"
+  short_description: "Scaffold and configure Askr apps"
+  default_prompt: "Use $askr-cli-vite to scaffold or configure an askr Vite app."

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

@@ -0,0 +1,82 @@
+---
+name: askr-dashboard-charts
+description: Use when building askr dashboards, stat cards, activity feeds, product metrics, tables, async feedback, and @askrjs/charts visualizations such as area, bar, line, donut, heatmap, timeline, gauges, and chart chrome.
+---
+
+# Askr Dashboard Charts
+
+Use this for product dashboards and metric-heavy screens. The goal is route-owned data, deterministic metric formatting, and charts that answer product questions without inventing parallel UI systems.
+
+## Use This When
+
+- You are building a dashboard, metrics screen, stat-card surface, or chart-heavy route.
+- The page needs resource-owned async loading plus chart composition.
+- Charts and tables must share the same formatter logic.
+- You need loading, empty, and error truth on a dense metrics screen.
+
+## Inspect First
+
+- `templates/startkit/src/pages/workspace/dashboard.tsx`
+- Existing stat card, table, empty state, and chart styles
+- Existing format helpers in `src/shared`
+- Existing route or feature owners for the metrics you need
+
+## Choose The Owner
+
+- The route or page owns high-level loading and composition.
+- `src/components/shared` owns reusable stat cards, page headers, tables, and empty states.
+- `src/features/<domain>` owns domain-specific dashboard panels and metric workflows.
+- `src/shared` owns formatting helpers so cards, tables, and charts stay consistent.
+
+## Do This In Order
+
+1. Load dashboard data in the route or feature container with `resource()` unless the data must be shared across screens.
+2. Keep metric formatting in shared helpers.
+3. Use `@askrjs/charts` components for chart visuals and keep CSS imported at the app boundary.
+4. Pair charts with labels, summaries, or tables when precision matters.
+5. Keep loading, empty, error, and refresh states explicit.
+
+## Copy This Shape
+
+```tsx
+import { resource } from "@askrjs/askr/resources";
+import { AreaChart, ChartPanel, ChartShell } from "@askrjs/charts/components";
+
+const dashboard = resource(({ signal }) => loadDashboard({ signal }), []);
+
+if (dashboard.pending && !dashboard.value) return <p>Loading dashboard...</p>;
+if (dashboard.error) return <p role="alert">Unable to load dashboard.</p>;
+
+<ChartShell title="Revenue" description="Last 7 days">
+  <ChartPanel title="Trend">
+    <AreaChart label="Revenue trend" data={dashboard.value.revenue} />
+  </ChartPanel>
+</ChartShell>;
+```
+
+## Never Do These
+
+- Inline mock metrics inside page JSX.
+- Hardcoded chart colors in runtime code.
+- Decorative charts that do not answer a product question.
+- Dense dashboards without loading, empty, and error states.
+
+## Validate
+
+- Cards and charts share formatter logic.
+- The page scans cleanly at mobile, tablet, and desktop widths.
+- Chart data has stable labels and keys.
+- Loading, empty, error, and refresh states are visible.
+
+## Done When
+
+- Route-owned loading and chart composition are clear.
+- Metric formatting is shared and deterministic.
+- Charts support the page's product question instead of decorating it.
+- Async states remain explicit on the dashboard surface.
+
+## 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/dist/skills/askr-dashboard-charts/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Askr Dashboard Charts"
+  short_description: "Build dashboards and charts"
+  default_prompt: "Use $askr-dashboard-charts to build dashboard metrics and charts."

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

@@ -0,0 +1,86 @@
+---
+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/dist/skills/askr-design-system/agents/openai.yaml

@@ -0,0 +1,4 @@
+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/dist/skills/askr-env-config/SKILL.md

@@ -0,0 +1,74 @@
+---
+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/dist/skills/askr-env-config/agents/openai.yaml

@@ -0,0 +1,4 @@
+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/dist/skills/askr-error-loading-empty/SKILL.md

@@ -0,0 +1,89 @@
+---
+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/dist/skills/askr-error-loading-empty/agents/openai.yaml

@@ -0,0 +1,4 @@
+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."