jg-command

Invocation

This skill runs only when the developer invokes it. Execute its workflow with the available tools. Do not explain it, simulate it, return equivalent shell commands, or ask for confirmation of actions this skill already authorizes.

Treat the text supplied with the invocation as arguments, constraints, or context, and honor qualifications that limit or defer execution.

If repository access or a capability the workflow needs is unavailable, or one of its stopping conditions is reached, report the blocker and stop. Never simulate success.

Release runtime resources and remove disposable scratch output this skill deliberately created, including after a failure, while preserving evidence needed to investigate unresolved failures. Report anything retained within this skill’s output format. This cleanup is a narrow exception to the skill’s write limits. It does not authorize creating other resources, changing reviewed or pre-existing files, removing unexpected changes, or cleaning up earlier work. Every other write is defined by this skill’s workflow.

This skill’s own rules about supplied material take precedence over this section.

Workflow

Turn the task supplied with the invocation into a few shell commands for the machine they will run on, explain exactly what each one does and how risky it is, and run the one the developer picks. Shell commands are this skill’s output, not a replacement for its workflow. Run nothing except the read-only checks in steps 2 and 4, the preview in step 7, and the command the developer picks.

1. Request. Take the task from the supplied text, including any target it names, such as “on Alpine”, “for my Debian server”, or “POSIX sh”. Without a task, ask for one and stop. When a detail changes which files or data a command touches and no safe assumption exists, ask one question first. Otherwise, state the assumption in the option’s description.
2. Target. Without a stated target, detect the machine and shell the command will run on, using read-only checks only: /etc/os-release, or uname -s and sw_vers on macOS, the developer’s $SHELL and its version, the working directory, and command -v for each tool an option would use.
   • When the target is another machine and its system is unstated, assume Ubuntu with bash and say so.
   • Write commands for bash and other sh-family shells, such as zsh, dash, and BusyBox ash. For any other detected shell, such as fish or PowerShell, write bash commands, say so, and run them with bash when it is installed. Otherwise, they are print-only.
3. Options. Offer 2 to 4 options that differ in a real way, such as portable versus a faster tool, preview versus act, or sorted versus raw, with the recommended one first. Offer one option when only one sensible command exists, and say so.
   • Give each option a label of at most 5 words, the command, one sentence on exactly what it does, including any assumption, the tools it needs, and its risk labels: read-only, changes files, irreversible, needs sudo, uses the network, or runs remote code.
   • A command is irreversible when it deletes or overwrites data with no copy, rewrites published history, or changes disks, partitions, or system state that can’t be undone.
   • Use only installed tools. A better tool that isn’t installed may be named in one line. Never install it.
   • For anything that changes or deletes, make the first option a read-only preview that shows what would be affected. Every preview is read-only.
   • Quote every expansion, handle names with spaces and newlines, for example with -print0 and xargs -0, and put -- before paths. Write options that run unchanged in bash and in the detected shell whenever possible.
   • Never pipe a download into a shell. Offer to download it, inspect it, and then run it.
   • When the task needs more than a short pipeline, such as loops, error handling, or many steps, say a script fits better and offer to write it as a normal task instead of a long one-liner.
4. Checks. Before presenting, check every flag against the installed tool’s --help output or man page, check syntax with bash -n or the target shell’s -n, and run shellcheck when it is installed. Never run an option to test it. Mark an option for a target other than this machine as unverified.
5. Other platforms. Decide which other common platforms would need a different command, such as Debian or Ubuntu, Fedora or RHEL, Arch, Alpine or BusyBox, macOS, or POSIX sh, and name them in one line, such as “Differs on: macOS, Alpine”. Write a variant only when the developer asks for one or named that target.
6. Present. Print the options as text, so they stay in the scrollback and can be copied: first a line with the detected target, the working directory, and the tools found, then the numbered options. Then ask which one to run:
   • Offer only the options that can run here as choices, and say how to run the print-only ones.
   • Use the host’s multiple-choice question tool when it has one, with one choice per option showing its label and risk labels, and leave its free-text answer for changes such as “same, but for macOS”. Otherwise, ask for the option’s number in a message.
   • In a non-interactive run, print the options and stop without running any.
   • A sandbox or permission setting that would block a command here is not a reason to stop. Present the options anyway, because running the pick goes through the host’s approval, which can ask to allow it.
   • When no option can run here, say how to run one instead of asking which: in the developer’s own terminal, or with ! <command> in Claude Code.
   • A reply that changes the request produces new options.
7. Run the pick. Picking an option authorizes running exactly that command once, on this machine, except that an irreversible command also needs the confirmation below.
   • Run it exactly as shown, from the working directory in the target line, through the host’s shell tool, so its approval prompt and sandbox apply. Never bypass them, escalate, or change the command. Run it in the detected shell when the option relies on a feature of that shell.
   • Never run these options. Print them and say how to run them instead: options for another machine, commands that need sudo, interactive programs such as top, ssh, or editors, and commands that never end on their own, such as tail -f or watch.
   • For an irreversible pick, first run its read-only preview. Then ask once more, naming exactly what will be lost: the affected paths and their count. Run the command only on a clear yes. When the preview shows that nothing would be affected, say so and don’t run the command.
8. Report. Report the exit status and the output. For large output, show the lines that matter and say how many were left out. On a failure, explain the cause from the output and offer adjusted options. Never retry a command that changes state on its own. Then stop.

An example of the printed options:

Target: Ubuntu 24.04, bash 5.2 · in /home/dev/project · found: find, sort, numfmt, du

1. Largest first, readable sizes                       read-only
   find . -path ./.git -prune -o -type f -size +100M -printf '%s\t%p\n' | sort -nr | numfmt --to=iec --field=1
   Lists files over 100 MiB outside .git, largest first, with sizes such as 120M.

2. Disk usage with du                                  read-only
   find . -path ./.git -prune -o -type f -size +100M -exec du -h -- {} + | sort -rh
   Lists the same files with the disk space each one uses, which is smaller for sparse files.

3. POSIX sh                                            read-only
   find . -path ./.git -prune -o -type f -size +204800 -exec ls -l -- {} +
   Works with any POSIX find, showing sizes in bytes, unsorted.

Differs on: macOS (BSD find has no -printf), Alpine (BusyBox find).