CLI reference

Installing kurotako provides the tako binary. Run it with your package runner (npx tako …, bunx tako …, pnpm exec tako …). The standalone @kurotako/cli package ships the same binary and the programmatic entry point for embedding the CLI in a script.

tako                       print help
tako --version | -v        print the CLI version
tako --help | -h           usage (works per sub-command too)
tako init      [--config <path>] [--force] [--monorepo | --no-monorepo]
tako init      --package-base [--packages-dir <dir>]
tako generate  [--config <path>] [--watch] [--dry-run]
tako validate  [--config <path>]
tako check     [--config <path>]

Global option

Flag	Meaning
--config <path>	path to the config file; forwarded to loadConfig. Default: ./tako.config.ts resolved by walking up from the current directory.

tako init

Writes a commented tako.config.ts.

• Always targets the current directory (it does not walk up). --config <path> overrides the target path.
• Refuses to overwrite an existing file. --force replaces it.
• No prompts, no schema auto-detection.
• --monorepo writes the workspace-oriented skeleton (schema in a sub-project, one outputs[] entry per sub-project); --no-monorepo forces the single-project skeleton. With neither flag, tako init auto-detects: it walks up to the nearest package.json and picks the monorepo skeleton when that file has a workspaces key (array or { packages: [...] }) or a pnpm-workspace.yaml sits next to it. See Using tako in a monorepo.
• --package-base [--packages-dir <dir>] writes tsconfig.base.json and tsup.config.base.ts one level above <dir> (default ./packages), the files that mode package requires, instead of the config. It never overwrites: an existing tsconfig.base.json, or any existing tsup.config.base.{ts,js,mjs,cjs}, is kept.

tako generate

Runs the full pipeline: loadConfig → parse each source → merge and validate the IR → run every generator (private dependencies first) → write the files → run hooks.afterEmit.

Flag	Effect
--watch	stay running; regenerate on every config or watched schema change. A failed cycle is reported and watching continues.
--dry-run	run every check and report how many files would be written; nothing is written and afterEmit is skipped.

Fail-fast: the first error stops the run (except under --watch, which keeps going).

tako validate

The same checks as generate up to — but not including — emission. Exercises parsing, IR validation and every generate() call, then stops before the writer. Prints config and schema are valid and exits 0, or exits 1 on the first TakoError. This is the CI-facing verb.

tako check

Drift guard. Runs the pipeline in plan mode (no writes, no afterEmit), then compares the planned output against what is on disk. Exit 0 when they match, exit 1 on any drift. Use it in CI to catch a committed generated/ tree that is out of date with the schema.

Exit codes

Code	Meaning
0	success
1	a TakoError (config, parse, generate, write) or, for check, detected drift

Programmatic use

@kurotako/cli also exports runCli(argv) and the reporter / error helpers for embedding the CLI in a script or a test. See the @kurotako/cli API reference.