zuke-setup

Set up Zuke in a project

Zuke defines builds as a TypeScript class run on Deno. Each target is a class field; targets reference each other by this.<field> (never strings). Packages are imported from JSR (jsr:@zuke/...), not npm.

The fast path: zuke setup

The @zuke/cli tool scaffolds everything. Install it once, then run setup in the target project:

deno install -A -g -n zuke jsr:@zuke/cli   # once, globally
zuke setup                                  # in the project root
./zuke                                       # run the build

No global install? The same wizard runs directly:

deno run -A jsr:@zuke/cli setup

setup flags: --dir <path>, --name <ClassName>, --force (overwrite existing files), --yes (non-interactive), --launcher-name <name> (write the launcher under a different name when a zuke/ directory already occupies it — a directory collision now fails with an actionable error instead of silently skipping the launcher).

Running as an agent, always pass --yes: it skips every interactive question, including the closing "star the Zuke repository?" prompt — that question is for a human at a terminal, and an agent must never answer it (or star anything) on the user's behalf.

To read a @zuke/* package's API without a Node repo's @types/node noise, run zuke doc <package> (e.g. zuke doc core) — it runs deno doc in an isolated directory.

Migrating an existing project: zuke import

If the project already has package.json scripts or a Makefile, prefer zuke import over setup — it reads them and generates a zuke.ts with a target per task, a working starting point instead of a blank build:

zuke import                  # auto-detects package.json, then a Makefile
zuke import --from makefile   # or pin the source (package.json | makefile)

Each script/target becomes a target(); a command maps to CmdTasks.exec(...) — a placeholder, not the destination: before accepting it, check the package catalogue (llms.txt's ## Packages list, or the table in zuke-write-build's cheatsheet) for a @zuke/<tool> wrapper matching that command and replace the placeholder with it — leaving CmdTasks.exec in place for a tool that has a typed wrapper is a bug, not a shortcut. An && chain becomes sequential steps, a run/prerequisite delegation becomes .dependsOn(...), and anything too shell-specific to translate (pipes, redirects, env assignments) is preserved behind a // TODO so the file still compiles. It scaffolds the launchers and deno.json exactly like setup, and takes the same --dir, --name, --force, --yes flags. Afterwards, use the zuke-write-build skill to finish replacing any remaining generated CmdTasks.exec calls with typed *Tasks wrappers.