- Home
- Skills
- Gwenwindflower
- .Charmschool
- Deno Cliffy Cli
deno-cliffy-cli_skill
- Shell
7
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
3 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill gwenwindflower/.charmschool --skill deno-cliffy-cli- patterns.md3.8 KB
- SKILL.md3.0 KB
Overview
This skill helps you build structured command-line tools in Deno using the Cliffy command framework. It focuses on typed options, built-in help text, subcommands, and a small project layout that scales from single-file tools to multi-command CLIs. The guidance covers wiring commands, integrating deno.json tasks, and handling heavy or npm dependencies safely.
How this skill works
You create a Command instance from @cliffy/command, register commands and options, and call parse(Deno.args) to run. For multi-command projects, place individual command handlers in a commands/ directory and import or lazy-load them from the entry point. Use deno.json to centralize imports, map npm packages, and define per-command task invocations with appropriate permission flags.
When to use it
- Creating a new Deno CLI with subcommands and typed options
- Refactoring an existing script into a maintainable multi-command tool
- Coordinating deno.json tasks with CLI subcommands and permission scoping
- Adding heavy dependencies (Playwright, Puppeteer) that should not load on every run
- Using npm packages in Deno that require filesystem assets or node-style modules
Best practices
- Keep each command in its own file under commands/ and export a single async function
- Lazy-import heavy or side-effecting dependencies inside action handlers to avoid unnecessary startup costs
- Define imports and npm mappings in deno.json and set nodeModulesDir: "auto" when packages read their own files
- Scope permissions per deno task (avoid --allow-all unless needed) and pass extra CLI flags after -- in deno task invocations
- Document command options and defaults so auto-generated help is useful and consistent
Example use cases
- A developer tool with build, test, and deploy subcommands wired from commands/ files
- A dotfiles manager that applies or removes configurations with per-command permissions
- A web-scraping command that lazy-loads Playwright only when the scrape subcommand runs
- A templating CLI that uses an npm handlebars package and requires nodeModulesDir to read partials
- deno.json tasks that run specific commands with restricted permission flags for CI
FAQ
Lazy-import heavy libraries inside the command's action handler so they load only when that subcommand runs.
When should I use deno.json tasks vs. running the CLI directly?
Use deno.json tasks to pin imports, set nodeModulesDir, and define per-command permission flags. Use the CLI directly for ad-hoc runs or development with full permissions.