Fetches nushell-pro from hustcer/nushell-pro and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/nushell-pro
Restart Cursor to activate nushell-pro. Access via /nushell-pro in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
# Fetch user data from the API
#
# Retrieves user information by ID and returns
# a structured record with all available fields.
@example 'Fetch user by ID' { fetch-user 42 }
@category 'network'
def fetch-user [
id: int # The user's unique identifier
--verbose (-v) # Show detailed request info
]: nothing -> record {
# implementation
}
Parameter guidelines
Maximum 2 positional parameters; use flags for the rest
Provide both long and short flag names: --output (-o): string
Use default values: def greet [name: string = 'World']
Use ? for optional positional params: def greet [name?: string]
Use rest params for variadic input: def multi-greet [...names: string]
Use def --wrapped to wrap external commands and forward unknown flags
{name: 'Alice', age: 30} # Create record
$rec1 | merge $rec2 # Merge (right-biased)
[$r1 $r2 $r3] | into record # Merge many records
$rec | update name {|r| $'Dr. ($r.name)' } # Update field
$rec | insert active true # Insert field
$rec | upsert count {|r| ($r.count? | default 0) + 1 } # Update or insert
$rec | reject password secret_key # Remove fields
$rec | select name age email # Keep only these fields
$rec | items {|k, v| $'($k): ($v)' } # Iterate key-value pairs
$rec | transpose key val # Convert to table
Working with tables
$table | where age > 25 # Filter rows
$table | insert retired {|row| $row.age > 65 } # Add column
$table | rename -c {age: years} # Rename column
$table | group-by status --to-table # Group by field
$table | transpose name data # Transpose rows/columns
$table | join $other_table user_id # Inner join
$table | join --left $other user_id # Left join
Working with lists
$list | enumerate | where {|e| $e.index > 5 } # Filter with index
$list | reduce --fold 0 {|it, acc| $acc + $it } # Accumulate
$list | window 3 # Sliding window
$list | chunks 100 # Process in batches
$list | flatten # Flatten nested lists
Null safety
$record.field? # Returns null if missing (no error)
$record.field? | default 'N/A' # Provide fallback
if ($record.field? != null) { } # Check existence
$list | default -e $fallback # Default for empty collections
Pipeline & Functional Patterns
Prefer functional over imperative
# Bad — imperative with mutable variable
mut total = 0
for item in $items { $total += $item.price }
# Good — functional pipeline
$items | get price | math sum
# Bad — mutable counter
mut i = 0
for file in (ls) { print $'($i): ($file.name)'; $i += 1 }
# Good — enumerate
ls | enumerate | each {|it| $'($it.index): ($it.item.name)' }
Iteration patterns
# each: transform each element
$list | each {|item| $item * 2 }
# each --flatten: stream outputs (turns list<list<T>> into list<T>)
ls *.txt | each --flatten {|f| open $f.name | lines } | find 'TODO'
# each --keep-empty: preserve null results
[1 2 3] | each --keep-empty {|e| if $e == 2 { 'found' } }
# par-each: parallel processing (I/O or CPU-bound)
$urls | par-each {|url| http get $url }
$urls | par-each --threads 4 {|url| http get $url }
# reduce: accumulate (first element is initial acc if no --fold)
[1 2 3 4] | reduce {|it, acc| $acc + $it }
# generate: create values from arbitrary sources without mut
generate {|state| { out: ($state * 2), next: ($state + 1) } } 1 | first 5
Row conditions vs closures
# Row conditions — short-hand syntax, auto-expands $it
ls | where type == file # Simple and readable
$table | where size > 100 # Expands to: $it.size > 100
# Closures — full flexibility, can be stored and reused
let big_files = {|row| $row.size > 1mb }
ls | where $big_files
$list | where {$in > 10} # Use $in or parameter
Use row conditions for simple field comparisons; use closures for complex logic or reusable conditions.
Pipeline input with $in
def double-all []: list<int> -> list<int> {
$in | each {|x| $x * 2 }
}
# Capture $in early when needed later (it's consumed on first use)
def process []: table -> table {
let input = $in
let count = $input | length
$input | first ($count // 2)
}
Variable Best Practices
Prefer immutability
let config = (open config.toml)
let names = $config.users | get name
# Acceptable — mut when no functional alternative
mut retries = 0
loop {
if (try-connect) { break }
$retries += 1
if $retries >= 3 { error make {msg: 'Connection failed'} }
sleep 1sec
}
Constants for parse-time values
const lib_path = 'src/lib.nu'
source $lib_path # Works: const is resolved at parse time
let lib_path = 'src/lib.nu'
source $lib_path # Error: let is runtime only
Closures cannot capture mut
mut count = 0
ls | each {|f| $count += 1 } # Error! Closures can't capture mut
# Solutions:
ls | length # Use built-in commands
[1 2 3] | reduce {|x, acc| $acc + $x } # Use reduce
for f in (ls) { $count += 1 } # Use a loop if mutation truly needed
Double-quoted interpolation: $"tab:\t($value)\n" (only with escapes)
Modules & Scripts
Module structure
my-module/
├── mod.nu # Module entry point
├── utils.nu # Submodule
└── tests/
└── mod.nu # Test module
Export rules
Only export definitions are public; non-exported are private
Use export def main when command name matches module name
Use export use submodule.nu * to re-export submodule commands
Use export-env for environment setup blocks
Script with main command and subcommands
#!/usr/bin/env nu
# Build the project
def "main build" [--release (-r)] {
print 'Building...'
}
# Run tests
def "main test" [--verbose (-v)] {
print 'Testing...'
}
def main [] {
print 'Usage: script.nu <build|test>'
}
For stdin access in shebang scripts: #!/usr/bin/env -S nu --stdin
Error Handling
Custom errors with span info
def validate-age [age: int] {
if $age < 0 or $age > 150 {
error make {
msg: 'Invalid age value'
label: {
text: $'Age must be between 0 and 150, got ($age)'
span: (metadata $age).span
}
}
}
$age
}
try/catch and graceful degradation
let result = try {
http get $url
} catch {|err|
print -e $'Request failed: ($err.msg)'
null
}
# Use complete for detailed external command error info
let result = (^some-external-cmd | complete)
if $result.exit_code != 0 {
print -e $'Error: ($result.stderr)'
}
Suppress errors with do -i
do -i (ignore errors) runs a closure and suppresses any errors, returning null on failure. do -c (capture errors) catches errors and returns them as values.
# Ignore errors — returns null if the closure fails
do -i { rm non_existent_file }
# Use as a concise fallback
let val = (do -i { open config.toml | get setting } | default 'fallback')
# Capture errors as values (instead of aborting the pipeline)
let result = (do -c { ^some-cmd })
When to use each approach:
do -i — Fire-and-forget, or when you only need a default on failure
do -c — Catch errors as values to abort downstream pipeline on failure
try/catch — When you need to inspect or log the error
complete — When you need exit code + stdout + stderr from external commands
Testing
Using std assert
use std/assert
for t in [[input expected]; [0 0] [1 1] [2 1] [5 5]] {
assert equal (fib $t.input) $t.expected
}
Custom assertions
def "assert even" [number: int] {
assert ($number mod 2 == 0) --error-label {
text: $'($number) is not an even number'
span: (metadata $number).span
}
}
Debugging Techniques
$value | describe # Inspect type
$data | each {|x| print $x; $x } # Print intermediate values (pass-through)
timeit { expensive-command } # Measure execution time
metadata $value # Inspect span and other metadata
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
