Tooling
Scaffold, generate, and check an Askr project with the published CLI and Vite plugin.
Example
Run the published CLI through the project package boundary and review generated artifacts before committing them.
npx @askrjs/cli@latest add page audit-log
npx @askrjs/cli@latest add action approve-request --route /requests/{id}
npx @askrjs/cli@latest openapi --check
npx @askrjs/cli@latest ssg --config ./ssg.config.ts --output ./distCLI workflow
The askr binary from @askrjs/cli covers the project lifecycle from one entry point: create and add scaffold application code; analyze, check, doctor, and repair validate it; database, openapi, and ssg cover generated contracts and delivery; and outdated, update, and upgrade handle dependency maintenance. Run askr --help for the generated current command list, or askr <command> --help for command-specific flags. Every subcommand hangs off the single askr executable -- there are no separate compatibility binaries like askr-create or askr-add.
Vite integration
@askrjs/vite supplies the plugin pair that teaches a normal Vite project Askr's JSX and template conventions: askr() handles the browser build, and askrServer({ entry }), imported from the @askrjs/vite/server subpath, wires up server rendering. Both plugins expose only a stable name field in their published types (askr:vite and askr:server) rather than Vite's own recursive Plugin type, so a bundler like vite-plus that inspects plugin arrays doesn't end up comparing two different copies of that type. In practice you list both in vite.config.ts: plugins: [askr(), askrServer({ entry: 'src/server/entry-server.ts' })].
Generated artifacts
CLI commands write real, ready-to-run files rather than TODO-filled stubs. askr create produces a full project tree plus .askr/blueprint.json and .askr/builder-brief.md describing which template was picked and why, and askr add page/add action register new files directly into src/pages/app/_routes.tsx or src/pages/public/_routes.tsx depending on --branch. askr openapi writes a deterministic YAML document by loading a TypeScript module's default export and calling its toOpenApiDocument() method, and askr ssg writes a static HTML tree plus an incremental-build manifest. All of these writes are atomic, so a crash mid-run doesn't leave a half-written artifact behind.
Safe updates
askr outdated, update, and upgrade are read-only discovery followed by opt-in write: outdated lists what's available without touching anything, update applies only safe range changes, and upgrade additionally allows major bumps for stable packages and breaking minor bumps for 0.x packages — targeting whatever version the registry's latest tag currently resolves to, with no cap at one major version per run, so a 1.x package can jump straight to 4.x in a single upgrade if that's what's published. Upgrade enforces peer requirements by default; --force/-f deliberately selects tag targets without those compatibility checks. None of the three commands touches a lockfile, runs installs or lifecycle scripts, or edits overrides, resolutions, catalogs, or packageManager metadata; they only rewrite dependency version strings in package.json.