Your build and your CI are one typed file. And your agent can run it.
zuke.build · README · Docs · Packages on JSR · Examples
import { Build, cicd, run, target } from "@zuke/core";
import { DenoTasks } from "@zuke/deno";
class MyBuild extends Build {
ci = cicd({ provider: "github" }); // the pipeline, generated and verified
lint = target().executes(() => DenoTasks.lint());
test = target()
.dependsOn(this.lint) // this.lint, not "lint": a rename is a refactor
.executes(() => DenoTasks.test((s) => s.allowAll().coverage("cov")));
default = target().dependsOn(this.test).executes(() => {});
}
await run(MyBuild);No bespoke DSL. No YAML by hand. No scripts/*.sh nobody dares touch. One
TypeScript file, with full editor support, that Zuke turns into a dependency
graph, runs in order, and compiles into your CI workflow on every run.
# 1. Install the CLI (pick one)
deno install -A -g -n zuke jsr:@zuke/cli # from JSR, any OS with Deno
brew install zuke-build/tap/zuke # Homebrew, no Deno needed up front
# 2. Scaffold, run, and generate CI
zuke setup # writes zuke.ts + the ./zuke launcher
zuke # runs the build (or ./zuke, no install needed)
zuke generate-ci # writes .github/workflows/ci.yml from the buildAlready have package.json scripts or a Makefile? zuke import turns them
into a zuke.ts with a target per script.
| Typed, refactor-safe dependencies | Targets reference each other with this.clean, never "clean". A typo is a compile error, not a 3 a.m. surprise. |
| Never write CI YAML again | cicd({ provider: "github" }) generates GitHub Actions, GitLab CI, Azure Pipelines, or Bitbucket YAML. fanOut: true makes every target its own job wired by needs: edges. generate-ci --check fails CI when it drifts. |
| Run it locally, exactly as CI does | ./zuke ci is the same target the workflow runs. One gate, not a hand-maintained subset. |
| Let your agent run the build | ./zuke mcp serves the build over the Model Context Protocol: an agent lists the targets, reads the graph, and runs one with typed parameters. |
| A typed wrapper for every tool | 68 packages: a tiny core, the CLI, and a *Tasks object per tool whose settings lambdas mirror the real flags. |
| Injection-safe shell | The $ tagged template from @zuke/core/shell tokenises interpolated values into argv entries, never a concatenated string. |
| Zero runtime dependencies | The published packages depend on nothing. The test suite runs with no network at all. |
Every external tool is a namespaced *Tasks object configured with a settings
lambda that mirrors the real CLI, so DenoTasks.test((s) => s.allowAll()) reads
like deno test --allow-all and the flags are type-checked.
| Category | Packages |
|---|---|
| Runtimes & package managers | deno · node · npm · npx · pnpm · yarn · bun |
| Bundlers & monorepo | vite · tsup · tsdown · storybook · turbo · nx |
| TypeScript runners & compilers | tsc · tsc-alias · tsx |
| Frameworks & code generation | nest · openapi-ts · orval · redocly |
| AI coding, review & self-healing | ai · claude · codex · gemini |
| Lint, format & quality | eslint · oxlint · biome · dprint · cspell · knip · dpdm · shellcheck · husky · lint-staged |
| Test, coverage & browsers | vitest · jest · playwright · cypress · codecov |
| Containers & orchestration | docker · docker-compose · kubectl · kustomize · helm · argo-rollouts · canary |
| Cloud & infrastructure | aws · az · gcloud · terraform · tofu · prometheus · otel |
| Version control, registry & CI | git · gh · jsr · release-please · homebrew · chocolatey |
| Code signing & supply chain | apple · signpath · security |
| Engine & plugins | core · cli · cmd · console · docs · qr |
Every one of them lives under
@zuke on JSR. The full matrix with live badges is in
Packages, and
the complete typed surface of every package is one file:
llms-full.txt.
Three ways a model joins the build, each one a typed target with refactor-safe dependencies:
- Drive the coding CLIs.
@zuke/claude,@zuke/codexand@zuke/geminirun Claude Code, OpenAI Codex and Gemini CLI non-interactively, with the API key riding aparameter().secret()that Zuke masks in CI output. - AI code review that breaks the build.
@zuke/aireads the diff, returns a structured assessment, posts it to the pull request, and fails the run when the risk crosses your threshold. - Self-healing targets. Attach
.recoverWith(aiFixer(…))to any target. On failure it diagnoses from the error and the diff, posts a committable suggestion, or applies the fix and re-runs the real command to verify.
test = target()
.executes(() => DenoTasks.test((s) => s.allowAll()))
.recoverWith(aiFixer((f) => f.provider("openai").apiKey(this.key)));Two portable Agent Skills, zuke-setup and
zuke-write-build, teach a coding assistant to scaffold Zuke and write a
zuke.ts with the typed wrappers instead of guessing the API:
/plugin marketplace add zuke-build/zuke && /plugin install zuke@zuke # Claude Code
codex plugin marketplace add zuke-build/zuke && codex plugin add zuke@zuke
gemini extensions install https://github.com/zuke-build/zuke
The Zuke Build action hardens the runner, checks the repository out, and runs a target:
steps:
- uses: zuke-build/zuke@v1
with:
target: ci| Repository | What it is |
|---|---|
| zuke | The engine, the zuke CLI, 68 typed packages, the docs, and Zuke's own build (zuke.ts), which is a runnable example |
| zuke-build.github.io | The website at zuke.build |
| homebrew-tap | The Homebrew formula behind brew install zuke-build/tap/zuke |
Running Zuke at your company? Open a pull request adding your logo to
assets/users/,
or say hello in an issue.
Questions, ideas, or just want to say hi? Open an issue, write to contact@zuke.build, or wear the build from the swag shop.
If Zuke is useful to you, star the repo. It helps others find the project. ⭐
Inspired by NUKE for .NET. Made in Bulgaria 🇧🇬. MIT licensed.