Nushell Pro
Write, review, and harden Nushell (.nu) scripts and pipelines with idiomatic patterns and security checks instead of guessing shell conventions.
Overview
Nushell Pro is an agent skill most often used in Build (also Ship testing/review and Ship security) that enforces idiomatic, secure, maintainable Nushell scripting across write, review, refactor, and Bash-conversion task
Install
npx skills add https://github.com/hustcer/nushell-pro --skill nushell-proWhat is this skill?
- Seven-step operating workflow for new scripts, reviews, refactors, Bash-to-Nu conversion, modules, security audits, and
- Deep references for string formats, security hardening, type system, pipelines, and performance
- Enforces idiomatic naming, type annotations, and functional style for maintainable .nu code
- Catches security issues around untrusted input, external commands, paths, and destructive operations
- Helps convert Bash/POSIX scripts to idiomatic Nushell
- Seven-step operating workflow for Nushell write, review, refactor, conversion, module design, security audit, and debugg
Adoption & trust: 615 installs on skills.sh; 5 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are editing .nu scripts without a consistent checklist for idioms, types, pipelines, or security around external input and shell escapes.
Who is it for?
Solo builders maintaining Nushell modules, data pipelines, or agent-invoked shell automation who want review-grade guidance without hiring a shell specialist.
Skip if: Teams that only use Bash or PowerShell with no .nu files, or one-off commands where you will not reuse or audit the script.
When should I use this skill?
Writing, reviewing, auditing, or refactoring Nushell (.nu) scripts, modules, custom commands, pipelines, Bash/POSIX conversion, or any .nu file editing.
What do I get? / Deliverables
Your Nushell code follows project conventions, passes structured review criteria, and avoids common security and performance pitfalls before you ship or operate scripts.
- Reviewed or refactored .nu source
- Security and idiomatic fix recommendations aligned to skill references
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Shell automation and data pipelines land in Build when you wire scripts, modules, and CLI workflows into your product or agent tooling. Integrations is the canonical shelf for language-specific scripting skills that connect data, commands, and local automation outside a single app layer.
Where it fits
Draft a new .nu module that ingests CSV and exposes custom commands for your agent to call.
Run a structured code review on pipeline logic before tagging a CLI release.
Audit untrusted path arguments and external command usage before deploying automation on a shared machine.
Debug a failing pipeline and refactor toward idiomatic error handling without reverting to Bash patterns.
How it compares
Use as a procedural review playbook for Nushell—not a generic POSIX shell cheat sheet or an MCP server integration.
Common Questions / FAQ
Who is nushell-pro for?
Indie developers and agent users who author or maintain Nushell scripts, custom commands, and pipelines and want idiomatic style plus security-aware review in one skill.
When should I use nushell-pro?
Use it during Build when integrating CLI automation; during Ship when reviewing or auditing scripts before release; and during Operate when debugging production .nu failures or hardening paths that touch untrusted input.
Is nushell-pro safe to install?
Treat it like any third-party skill: review the Security Audits panel on this Prism page and skim referenced guidance before letting an agent run destructive or external-command paths in your environment.
SKILL.md
READMESKILL.md - Nushell Pro
# Nushell Pro — Best Practices & Security Skill Write idiomatic, performant, secure, and maintainable Nushell scripts. This skill enforces Nushell conventions, catches security issues, and helps avoid common pitfalls. ## Operating Workflow Use this sequence whenever writing, reviewing, refactoring, or converting Nushell code: 1. Identify the task type: new script, code review, refactor, Bash conversion, module design, security audit, or debugging. 2. Read the existing `.nu` files and nearby project conventions before changing code. 3. Load only the reference files needed for the task: - String quoting, interpolation, escaping, regex, or globs -> [String Formats](references/string-formats.md) - Security, untrusted input, external commands, paths, credentials, or destructive operations -> [Security](references/security.md) - Review-only requests -> [Script Review](references/script-review.md) - Bash/POSIX conversion -> [Bash to Nushell](references/bash-to-nushell.md) - Modules, exports, scripts, or tests -> [Modules & Scripts](references/modules-and-scripts.md) - Types, records, tables, lists, or conversions -> [Data & Type System](references/data-and-types.md) - Streaming, `peek`, `parse`, `par-each`, performance, closures, or version-sensitive command behavior -> [Advanced Patterns](references/advanced-patterns.md) - Large datasets, Polars dataframes, columnar analytics, heavy group-by/join -> [Dataframes](references/dataframes.md) - Common mistakes and fixes -> [Anti-Patterns](references/anti-patterns.md) 4. Apply the critical checks in this file first, then use references for details. 5. Validate parseability with `nu -c 'source path/to/file.nu'` for modules or `nu path/to/script.nu` for scripts when the command is safe to run. 6. Summarize security findings first, then correctness/style/performance changes. If validation fails -> read the Nushell diagnostic, fix the syntax or type signature, and rerun the smallest safe validation command. If a command has side effects -> validate only parseability or use a fixture/temp directory. If a reference conflicts with local project style -> keep project style unless it violates safety, parseability, or Nushell semantics. STOP CHECKPOINT: Before approving code that runs external commands, deletes files, reads credentials, mutates `$env`, or executes user-provided paths/patterns, explicitly confirm the safe argument boundaries and failure behavior. ## Core Principles 1. **Think in pipelines** — Data flows through pipelines; prefer functional transformations over imperative loops 2. **Immutability first** — Use `let` by default; only use `mut` when functional alternatives don't apply 3. **Structured data** — Nushell works with tables, records, and lists natively; leverage structured data over string parsing 4. **Static parsing** — All code is parsed before execution; `source`/`use` require parse-time constants 5. **Implicit return** — The last expression's value is the return value; no need for `echo` or `return` 6. **Scoped environment** — Environment changes are local to their block; use `def --env` when caller-side changes are needed 7. **Type safety** — Annotate parameter types and input/output signatures for better error detection and documentation 8. **Prefer `match` for branching** — Use `matc