@askrjs/cli 0.0.2 → 0.0.4

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

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

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

@@ -1,76 +0,0 @@
----
-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/skills/askr-cli-vite/agents/openai.yaml

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

@@ -1,82 +0,0 @@
----
-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/skills/askr-dashboard-charts/agents/openai.yaml

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