Use the Current cdkd Checkout

Build the current checkout and use it from another CDK project for testing. For everything that happens AFTER the binary is chosen — deployment boundary, preview, wait modes, verification, destructive-operation guards — read and follow plugins/cdkd-skills/skills/cdkd/SKILL.md; it applies identically whether the binary is a built checkout or a published release.

Build the checkout

From the cdkd repository root, build the CLI:

vp run build

If the checkout has not been set up, follow CONTRIBUTING.md first: trust and install the pinned mise tools, run vp env install, and run vp install. Use the repository-pinned development runtime instead of replacing the build command.

Resolve and report the absolute CLI path:

echo "$(pwd)/dist/cli.js"

Invoke it from another project

Prefer direct invocation for one-off testing because it does not modify the user's shell or global packages:

node /absolute/path/to/cdkd/dist/cli.js --version

When the user explicitly wants cdkd available globally, offer the repository's pnpm link workflow:

pnpm setup
# Open a new shell, or reload the shell configuration that pnpm updated.
pnpm link --global
cdkd --version

Run pnpm setup only when needed; it updates shell configuration. Rebuilding with vp run build updates the linked binary without re-linking. To remove the link, run pnpm unlink --global @go-to-k/cdkd or pnpm rm --global @go-to-k/cdkd.

When giving commands for another CDK project, make them copy-pasteable and use either cdkd or the real absolute node .../dist/cli.js path consistently. If the user wants a published release instead of this checkout, follow the install section of the distributed skill linked above.