lirantal/nodejs-cli-apps-best-practices/nodejs-cli-best-practices

This skill operates in two modes — audit for reviewing existing CLI code and development guide for building new features or tools.

Critical

Always read references/best-practices.md before producing any output. It contains the complete reference for all 41 practices with code examples and recommended packages. It is the source of truth for both modes — do not rely on general knowledge alone, as several practices (specific package recommendations, §X.X numbering, configuration precedence order) are specific to this guide.

Determining the mode

Audit mode

Systematically compare the provided code against the practices in references/best-practices.md. Focus on what is verifiable from the code. Use judgment to mark practices as not applicable (➖) when there's genuinely no way to assess them from static analysis (e.g., Docker support when the project shows no distribution intent).

Prioritize by user impact — a missing exit code (§6.4) or absent --version flag (§9.1) affects every user and every CI pipeline; missing Docker image (§4.1) is low priority for most projects.

Audit report format

## Node.js CLI Best Practices Audit
 
### Summary
✅ N practices followed  ⚠️ N need attention  ❌ N not implemented  ➖ N not applicable
 
---
 
### 1. Command Line Experience
| # | Practice | Status | Finding |
|---|----------|--------|---------|
| 1.1 | Respect POSIX args | ✅ | Uses yargs with proper short/long aliases |
| 1.2 | Build empathic CLIs | ❌ | No interactive fallback when required args absent |
...
 
[Repeat for each section with applicable practices]
 
---
 
### Priority recommendations
 
**High priority** (user-facing or CI-breaking):
- **§6.4 Exit codes** — `process.exit()` called without a code
  ```js
  // Fix
  process.exit(1); // on error
  process.exit(0); // on success
  ```
 
**Medium priority**:
- ...
 
**Low priority / nice to have**:
- ...

Keep findings concise and tied to specific code patterns. Always include a concrete fix with code for each ❌.

Development guide mode

When building a new CLI feature or tool, don't wait to be asked — surface relevant best practices immediately based on what the user is building.

For a "building a CLI from scratch" request, organize guidance by development phase:

1. Project setup (§7.1, §7.3, §4.4, §2.2): bin object, shebang, files field, shrinkwrap
2. Argument design (§1.1, §1.2, §1.7, §1.9, §3.4): POSIX compliance, empathic fallbacks, zero-config, help output, config precedence
3. I/O and interoperability (§3.1, §3.2, §3.5, §3.6, §3.7, §4.2): STDIN, structured output, gated interactivity, STDOUT/STDERR separation, shell completion, graceful degradation
4. Error handling (§6.1–§6.5): trackable codes, actionable messages, debug mode, exit codes
5. UX polish (§1.4, §1.5, §1.6): colors, rich interactions, hyperlinks
6. Versioning (§9.1–§9.7): --version flag, semver, changelog
7. Security (§10.1): argument injection

For a targeted feature request (e.g., "add error handling", "add a --json flag"), surface only the directly relevant practices.

Development guidance format

## Node.js CLI best practices for [feature/topic]
 
### Checklist
- [ ] §X.Y Practice name — one-line explanation of why it matters
 
### Implementation
[Concrete, copy-pasteable code]
 
### Recommended packages
- `package-name` — when and why to use it
  npm install package-name
 
### Common mistakes
- What not to do → why it breaks → what to do instead

Quick reference: which section applies

Examples

Example 1: Audit mode

User says: "Audit my Node.js CLI against best practices. Here's my entry file and package.json."

Actions:

1. Read references/best-practices.md
2. Examine the provided files against each applicable practice
3. Produce the structured audit report with per-section table and priority recommendations

Example 2: Development guide mode (new CLI from scratch)

User says: "I'm building a Node.js CLI that parses log files and outputs a summary table. It needs to work cross-platform and I want to publish it on npm."

Actions:

1. Read references/best-practices.md
2. Identify all practices relevant to this CLI type (cross-platform, npm-published, table output)
3. Organize guidance by development phase (project setup → argument design → I/O → errors → UX → versioning → security)

Example 3: Development guide mode (targeted feature)

User says: "My CLI is crashing and just dumping stack traces. How do I add proper error handling?"

Actions:

1. Read references/best-practices.md sections §6.1–§6.5
2. Surface only the directly relevant practices
3. Provide a concrete, copy-pasteable error handling wrapper

Common mistakes to avoid