scaffold-zig-cli

Scaffold Zig CLI

Generate the full boilerplate for a new Zig CLI project.

Workflow

1. Gather Project Information

If the user provided a project name in their request, use it as the project name and skip asking for it. Still ask for the remaining parameters unless already provided in the user's initial request.

Ask the user for these parameters:

• Project name -- kebab-case, used as the binary name and directory name (e.g., my-tool)
• Short description -- one sentence, used in the README

Validate the project name before using it anywhere. It becomes a directory name and a binary name, and step 3 passes it to mkdir and cd, so it must match [a-z0-9]+(-[a-z0-9]+)*: lowercase alphanumeric segments joined by single hyphens, nothing else. Reject anything else and ask again rather than repairing it.

That pattern is doing real work, not tidiness. A name beginning with a hyphen, -tool for instance, reads as options to mkdir -p and cd instead of as a path. A name containing / scaffolds into a different directory than the one reported. . and .. escape the target entirely. A name with whitespace or a shell metacharacter splits into several arguments. Quote the name wherever it reaches a command as well, so the pattern is the guarantee rather than the only defence.

Reject one more set the pattern lets through: the Windows reserved device names, which are con, prn, aux, nul, com1 through com9, and lpt1 through lpt9. The ranges start at 1, not 0: com0 and lpt0 are ordinary names and Microsoft's naming rules do not list them. Windows reserves the rest regardless of the extension, so con cannot be a directory, and con.exe and con.txt cannot be written or extracted either. The release workflow cross-compiles a Windows target and packages PROJECT-NAME.exe into a zip, so a project named con produces an archive nobody on Windows can unpack. Match them case-insensitively against the whole name; a name that merely contains one, like con-tool, is fine.