在專案中設定 Zuke
Zuke 將建置流程定義為一個在 Deno 上執行的 TypeScript 類別。每個目標（target）都是一個類別欄位；目標之間透過 this.<欄位>（絕不使用字串）互相參照。套件從 JSR (jsr:@zuke/...) 而非 npm 匯入。
快速路徑：zuke setup
@zuke/cli 工具會自動建立所有需要的檔案。只需全域安裝一次，然後在目標專案中執行 setup：
deno install -A -g -n zuke jsr:@zuke/cli # 一次性的全域安裝
zuke setup # 在專案根目錄執行
./zuke # 執行建置
不想全域安裝？也可以直接使用以下指令執行相同的設定精靈：
deno run -A jsr:@zuke/cli setup
setup 旗標：--dir <路徑>、--name <類別名稱>、--force（覆蓋已存在的檔案）、--yes（非互動模式）、--launcher-name <名稱>（當 zuke/ 目錄已佔用啟動器名稱時，以不同名稱寫入啟動器——目錄衝突現在會輸出可操作的錯誤訊息，而非直接跳過啟動器）。
若要在沒有 Node 專案 @types/node 雜訊的情況下閱讀 @zuke/* 套件的 API，請執行 zuke doc <套件>（例如 zuke doc core）——它會在隔離的目錄中執行 deno doc。
遷移現有專案：zuke import
如果專案已有 package.json 中的腳本或 Makefile，建議使用 zuke import 而非 setup——它會讀取這些檔案並產生一個 zuke.ts，其中包含每個任務對應的目標，提供一個可立即使用的起點，而非空白的建置：
zuke import # 自動偵測 package.json，然後是 Makefile
zuke import --from makefile # 或指定來源（package.json | makefile）
每個腳本/目標會變成一個 target()；指令會對應到 CmdTasks.exec(...)——這是一個佔位符，不是最終結果：在將其接受之前，請先查看套件目錄（llms.txt 中的 ## Packages 列表，或 zuke-write-build 的速查表中的表格），尋找與該指令匹配的 @zuke/<工具> 包裝器，並以它取代佔位符——保留 CmdTasks.exec 作為一個擁有型別包裝器的工具是一個錯誤，而不是捷徑。&& 鏈會變成循序步驟，run/先決條件委派會變成 .dependsOn(...)，而任何太偏 shell 語法無法翻譯的部分（pipe、重新導向、環境變數賦值）則會保留在 // TODO 後面，讓檔案仍能編譯。它會像 setup 一樣建立啟動器和 deno.json，並接受相同的 --dir、--name、--force、--yes 旗標。之後，使用 zuke-write-build 技能來完成替換任何剩餘產生的 CmdTasks.exec 呼叫，改用型別安全的 *Tasks 包裝器。
zuke setup 會寫入哪些檔案
zuke.ts—— 一個包含範例目標和default目標的入門建置類別。./zuke+./zuke.ps1—— 啟動腳本，用於定位專案並使用PATH上的 Deno 執行zuke.ts。如果缺少 Deno，它們會指向官方安裝文件並直接退出，而不是將安裝腳本 pipe 到 shell 中（這會下載並執行未驗證的程式碼）。一旦deno.lock存在，它們會傳遞--frozen，因此第一次執行會寫入 lockfile，之後每次執行都會驗證它。deno.json—— 合併以加入zuke任務，以及若缺少的fmt/lint/test任務。合併是全部或全無：如果已宣告zuke任務，則完全不動檔案；若檔案無法解析則會跳過並顯示通知。zuke.json——{ "name": "..." }，用來標記 repo 根目錄。.gitignore—— 建立或新增內容，使.zuke/被忽略（快取和持久執行狀態存放於此）；如果.gitignore已涵蓋則保持不變。
執行建置
./zuke # 執行預設目標 (Windows: .\zuke.ps1)
./zuke <目標> # 執行特定目標
./zuke --list # 列出所有目標
./zuke --list --json # 以 JSON 輸出整個建置表面（指令、旗標、目標）
./zuke <目標> --dry-run # 印出計畫但不執行
CLI 是自描述的：./zuke --help 會印出使用語法以及建置的即時目標和參數，讓 AI 代理可以直接發現真實的指令表面，而無需猜測。為了讓 AI 用戶端能透過型別呼叫來操作建置，zuke mcp 會在其上執行一個 Model Context Protocol 伺服器（使用 claude mcp add zuke -- deno run -A zuke.ts mcp 註冊；加上 --allow-run 可讓代理不僅檢查目標，還能執行目標）。
如果已經安裝 Deno，你也可以使用 deno task zuke <目標> 或 deno run -A zuke.ts <目標>。-A 旗標授予權限，因為目標通常會執行程序並操作檔案。這些方式與啟動器並不完全相同：預設產生的 zuke 任務故意省略 --frozen，因此它可能會修復過時的 lockfile，而 ./zuke 則會因為該 lockfile 而失敗。
手動設定（無需 CLI）
在專案根目錄中建立 zuke.ts，擴展 Build，使用 target() 宣告目標，並在底部呼叫 await run(MyBuild)：
import { Build, run, target } from "jsr:@zuke/core";
import { DenoTasks } from "jsr:@zuke/deno";
class CI extends Build {
lint = target().executes(() => DenoTasks.lint());
test = target().dependsOn(this.lint)
.executes(() => DenoTasks.test((s) => s.allowAll()));
default = target().dependsOn(this.test).executes(() => {});
}
await run(CI);
使用 deno run -A zuke.ts test 執行。（若想獲得 ./zuke 啟動器的體驗，建議使用 zuke setup，它會自動為你放入啟動腳本。）
尋找確切的 API——切勿猜測
每個外部工具都有對應的型別安全 *Tasks 包裝器；請勿退而求其次使用 Deno.Command 或手寫 shell。 首先確認包裝器確實存在——llms.txt 的 ## Packages 目錄或 zuke-write-build 的速查表中的表格是回答此問題的唯一方式；逐套件的 deno doc 需要一個名稱作為目標，因此它無法揭示是否存在包裝器。一旦知道套件名稱，取得其確切的簽章：
- 在命令列上指定單一套件：
deno doc jsr:@zuke/<套件>。在消費者專案中偏好使用此方式——它會解析專案實際安裝的版本，因此不會描述該版本不具備的 API。 - 所有套件的整個型別表面都在
llms-full.txt中（由llms.txt索引）——位於 Zuke 儲存庫根目錄本身，或從消費者儲存庫 https://raw.githubusercontent.com/zuke-build/zuke/master/llms-full.txt（索引：https://raw.githubusercontent.com/zuke-build/zuke/master/llms.txt）取得。兩者都追蹤master，因此可能記錄已合併但尚未發佈的符號；使用它們來找出存在哪些內容，然後用deno doc確認簽章。
專案建立完成後，使用 zuke-write-build 技能來新增和編輯目標。