automaintainer: search for and add new CLI tools as bundled plugins to supe…#6
automaintainer: search for and add new CLI tools as bundled plugins to supe…#6javimosch wants to merge 3 commits into
Conversation
📝 WalkthroughWalkthroughRefines dotbot and gum plugin metadata/schemas and adds complete jj and jo plugin definitions with install guidance, command mappings, and quickstart documentation. ChangesPlugin System Updates
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Automaintainer Review Verdict: APPROVED
All 11 files well-formed, no code quality issues. |
|
Approved by automaintainer review team — ready for human merge |
|
Automaintainer Review Verdict: APPROVED Summary:
CI note: Both CI runs fail with External review: coderabbitai review in progress — no actionable feedback yet. No human reviews. Changes are correct, safe, and follow existing plugin conventions. |
|
Approved by automaintainer review team — auto-merging |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 49ed9e3f4d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "adapter": "process", | ||
| "adapterConfig": { | ||
| "command": "jo", | ||
| "passthrough": true, |
There was a problem hiding this comment.
With passthrough: true, the process adapter forwards only __rawArgs and ignores declared flags (cli/adapters/process.js:176-179), while the CLI checks required args before it copies remaining positionals into __rawArgs (cli/supercli.js:965-984). That makes both natural invocations broken: sc jo json create name=John is rejected as missing --pairs, and sc jo json create --pairs name=John spawns jo without the pair. Mark pairs as positional/use normal process arg handling, or remove this typed wrapper and rely on raw jo _ _ passthrough.
Useful? React with 👍 / 👎.
| "command": "jj", | ||
| "cwd": "invoke_cwd", | ||
| "baseArgs": ["log"], | ||
| "passthrough": true, |
There was a problem hiding this comment.
For exact commands with passthrough: true, the process adapter ignores all declared args and forwards only remaining positionals (cli/adapters/process.js:176-179), so the inspected flags in this manifest are not honored. For example, sc jj commit create --message foo is routed with empty __rawArgs and runs just jj commit, which can prompt/fail instead of using the message; the same applies to --limit, --dry-run, and the other wrapped flags. Use normal process arg mapping for these typed commands, or drop the declared args and force raw jj _ _ passthrough.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (2)
plugins/jj/plugin.json (2)
18-18: 💤 Low valueUpdate the plugin installation path to be more generic.
Lines 10 and 18 reference
./plugins/jjwhich assumes the command is run from the repository root. This path will fail if the user runs the command from a different directory or has installed the plugin elsewhere.💡 Consider a more flexible installation instruction
- "supercli plugins install ./plugins/jj --on-conflict replace --json" + "supercli plugins install <path-to-jj-plugin> --on-conflict replace --json"Or document that the command should be run from the repository root.
Also applies to: 10-10
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@plugins/jj/plugin.json` at line 18, The installation command in plugin.json uses a hardcoded "./plugins/jj" path which breaks if the user is not in the repo root; update the command string(s) that contain the literal "./plugins/jj" to use a generic placeholder (e.g. "<path-to-plugin>" or "path/to/plugin") or a package name (e.g. "jj") so the instruction is directory-agnostic, and ensure you change all occurrences of the "./plugins/jj" token in plugin.json (the command string shown) or add an explicit note that the command must be run from the repository root.
293-307: 💤 Low valueClarify the behavior of the catch-all passthrough command.
The passthrough command at lines 293-307 uses
"resource": "_"and"action": "_"which appears to be a catch-all pattern. However, the interaction between this catch-all and the specific command handlers above is not documented.Consider adding a comment or expanding the description to clarify:
- When this handler is invoked vs specific handlers
- How argument routing works for passthrough
- Whether this is intended as a fallback or primary interface
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@plugins/jj/plugin.json` around lines 293 - 307, Update the passthrough handler entry for namespace "jj" with a clearer description (or an added "notes" field) that documents when the catch-all with "resource": "_" and "action": "_" is invoked versus specific handlers, how arguments are routed to the underlying command (i.e., all unmatched resource/action/args are forwarded to the "jj" CLI because "passthrough": true and "cwd" uses "invoke_cwd"), and explicitly state that this entry is intended as a fallback for any commands not matched by earlier specific resource/action handlers; reference the existing fields ("namespace": "jj", "resource": "_", "action": "_", "adapterConfig.passthrough") when making the description change.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@plugins/jj/install-guidance.json`:
- Line 2: The "plugin" field in install-guidance.json is a string ("jj") but
must match the schema used in plugin.json (an array); update the "plugin" entry
in install-guidance.json to be an array (e.g., ["jj"]) so the field type aligns
with the schema and parsing will be consistent.
In `@plugins/jj/skills/quickstart/SKILL.md`:
- Line 57: Update the quickstart examples to use the correct jj CLI usage:
replace the incorrect `jj git init` example with `jj git init --git-repo=.` to
initialize Jujutsu in an existing Git repository (colocated workspace), and
change the `jj new -m "my feature"` example because `jj new` does not accept
`-m`—either show `jj new jj describe -m "my feature"` or use `jj commit -m "my
feature"` as the correct alternative in the docs.
In `@plugins/jo/install-guidance.json`:
- Line 2: The "plugin" field in install-guidance.json is a string ("plugin":
"jo") but must match the schema used in plugin.json where "plugin" is an array
("plugin": ["jo"]); update install-guidance.json to make the "plugin" value an
array containing "jo" so the field types are consistent (look for the "plugin"
key in install-guidance.json and change its value to ["jo"] to match the schema
defined in plugin.json).
- Line 8: Replace the incorrect cargo install suggestion "Or: cargo install jo"
in the install guidance (the string "Or: cargo install jo") because jo is a C
tool and not a Rust crate; update that entry to "Or: cargo install jf" or remove
the cargo-based guidance entirely so the JSON no longer suggests installing jo
via cargo.
In `@plugins/jo/plugin.json`:
- Around line 9-22: There are three problems: conflicting install_guidance
between the two files, an incorrect install step suggesting `cargo install jo`,
and a command mismatch for `jo json create` where args[0] (`pairs`) is required
but adapterConfig.passthrough is true so the value won't be forwarded. Fix by:
(1) choose one canonical source for install_guidance (keep a single definition
and remove the duplicate) and make the `plugin` field type consistent (`"jo"` or
`["jo"]`) and unify the `note` text between plugin.json and
install-guidance.json; (2) remove the incorrect `cargo install jo` step and
update install_steps to only valid installers/binaries (Homebrew, apt,
downloading releases) and ensure the `check` and `binary` entries are correct;
(3) for the `jo json create` command, either disable adapterConfig.passthrough
and marshal `pairs` into argv so the required args[0] is passed to the process
adapter, or keep passthrough and make `pairs` not required and accept its values
from __rawArgs (or mark the command as passthrough-positional), ensuring the CLI
validation and adapter wiring (args[0] `pairs`, adapterConfig.passthrough, and
use of __rawArgs) are consistent.
- Around line 51-70: The command schema uses adapterConfig.passthrough: true so
SuperCLI forwards positional tokens via __rawArgs and does not populate schema
args; update plugins/jo/plugin.json by making the "pairs" arg optional (or
remove it) and add a note in its description that key=value tokens must be
provided positionally (e.g., name=John age=30), and either remove/relax the
"pretty" and "array" flags (since passthrough ignores --pretty/--array) or
change the adapterConfig to not use passthrough and instead map "pretty" -> -p
and "array" -> -a so the flags are translated into the underlying jo invocation.
In `@plugins/jo/skills/quickstart/SKILL.md`:
- Line 40: Update the two example usages of the jo tool so they use documented
key-path and JSON/array forms instead of plain space-separated key=value
strings: replace the nested-object example `jo name=John address="city=New York
zip=10001"` with a key-path or JSON form (e.g., `jo -p address.city="New York"
-p address.zip=10001` or `jo name=John address='{"city":"New
York","zip":10001}'`), and change the array example `jo -a name=John name=Jane`
to the documented bracket form (e.g., `jo -a name[]=John name[]=Jane`) or the
exact `-a` behavior supported by jo; ensure examples use `-p`, `[]` key-paths,
or JSON-starting values to demonstrate nesting and arrays consistently.
---
Nitpick comments:
In `@plugins/jj/plugin.json`:
- Line 18: The installation command in plugin.json uses a hardcoded
"./plugins/jj" path which breaks if the user is not in the repo root; update the
command string(s) that contain the literal "./plugins/jj" to use a generic
placeholder (e.g. "<path-to-plugin>" or "path/to/plugin") or a package name
(e.g. "jj") so the instruction is directory-agnostic, and ensure you change all
occurrences of the "./plugins/jj" token in plugin.json (the command string
shown) or add an explicit note that the command must be run from the repository
root.
- Around line 293-307: Update the passthrough handler entry for namespace "jj"
with a clearer description (or an added "notes" field) that documents when the
catch-all with "resource": "_" and "action": "_" is invoked versus specific
handlers, how arguments are routed to the underlying command (i.e., all
unmatched resource/action/args are forwarded to the "jj" CLI because
"passthrough": true and "cwd" uses "invoke_cwd"), and explicitly state that this
entry is intended as a fallback for any commands not matched by earlier specific
resource/action handlers; reference the existing fields ("namespace": "jj",
"resource": "_", "action": "_", "adapterConfig.passthrough") when making the
description change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1ff1d924-1e4f-4cf8-949e-65407b49a2f0
📒 Files selected for processing (11)
plugins/dotbot/plugin.jsonplugins/gum/plugin.jsonplugins/gum/skills/quickstart/SKILL.mdplugins/jj/install-guidance.jsonplugins/jj/meta.jsonplugins/jj/plugin.jsonplugins/jj/skills/quickstart/SKILL.mdplugins/jo/install-guidance.jsonplugins/jo/meta.jsonplugins/jo/plugin.jsonplugins/jo/skills/quickstart/SKILL.md
| @@ -0,0 +1,13 @@ | |||
| { | |||
| "plugin": "jj", | |||
There was a problem hiding this comment.
Fix type inconsistency for the plugin field.
Line 2 defines "plugin": "jj" as a string, but in plugin.json line 10, the same field is defined as "plugin": ["jj"] (an array). This schema inconsistency could cause parsing issues.
🔧 Align with plugin.json schema
- "plugin": "jj",
+ "plugin": ["jj"],📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "plugin": "jj", | |
| "plugin": ["jj"], |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/jj/install-guidance.json` at line 2, The "plugin" field in
install-guidance.json is a string ("jj") but must match the schema used in
plugin.json (an array); update the "plugin" entry in install-guidance.json to be
an array (e.g., ["jj"]) so the field type aligns with the schema and parsing
will be consistent.
|
|
||
| ```bash | ||
| # Initialize jj in a Git repo | ||
| jj git init |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What are the correct commands to initialize Jujutsu in a Git repository and create a new change with a message?
💡 Result:
To initialize Jujutsu in an existing Git repository, use the following command from the root of your Git repository: jj git init --git-repo=. This command sets up a colocated Jujutsu workspace [1][2][3]. A colocated workspace allows you to use both Jujutsu and Git commands interchangeably in the same directory, as Jujutsu will automatically import and export changes to and from the Git repository [1][2][4]. To create a new change with a specific message, you can use either of the following methods: 1. Using jj new: Create a new empty change and then immediately describe it: jj new jj describe -m "Your commit message here" 2. Using jj commit: If you have changes in your working copy, you can create a new change with a message in a single command: jj commit -m "Your commit message here" Note that in the Jujutsu workflow, jj new creates a new, empty change on top of your current work, while jj commit functions similarly to "describe" followed by "new" (it snapshots changes, sets the message, and creates a new change on top) [5][6][7].
Citations:
- 1: https://docs.jj-vcs.dev/latest/git-compatibility/
- 2: https://github.com/martinvonz/jj/blob/main/docs/git-compatibility.md
- 3: https://v5.chriskrycho.com/essays/jj-init/
- 4: https://man.archlinux.org/man/jj-git-init.1.en
- 5: https://man.archlinux.org/man/extra/jujutsu/jj-new.1.en
- 6: https://steveklabnik.github.io/jujutsu-tutorial/hello-world/creating-new-changes.html
- 7: https://man.archlinux.org/man/jj-commit.1.en.txt
Fix incorrect jj CLI examples in quickstart
- Line 57 (
jj git init): update tojj git init --git-repo=.for initializing Jujutsu in an existing Git repository (colocated workspace). - Line 66 (
jj new -m "my feature"):jj newdoesn’t take-m—usejj new jj describe -m "my feature"orjj commit -m "my feature"instead.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/jj/skills/quickstart/SKILL.md` at line 57, Update the quickstart
examples to use the correct jj CLI usage: replace the incorrect `jj git init`
example with `jj git init --git-repo=.` to initialize Jujutsu in an existing Git
repository (colocated workspace), and change the `jj new -m "my feature"`
example because `jj new` does not accept `-m`—either show `jj new jj describe -m
"my feature"` or use `jj commit -m "my feature"` as the correct alternative in
the docs.
| @@ -0,0 +1,14 @@ | |||
| { | |||
| "plugin": "jo", | |||
There was a problem hiding this comment.
Fix type inconsistency for the plugin field.
Line 2 defines "plugin": "jo" as a string, but in plugin.json line 10, the same field is defined as "plugin": ["jo"] (an array). This schema inconsistency could cause parsing issues.
🔧 Align with plugin.json schema
- "plugin": "jo",
+ "plugin": ["jo"],📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "plugin": "jo", | |
| "plugin": ["jo"], |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/jo/install-guidance.json` at line 2, The "plugin" field in
install-guidance.json is a string ("plugin": "jo") but must match the schema
used in plugin.json where "plugin" is an array ("plugin": ["jo"]); update
install-guidance.json to make the "plugin" value an array containing "jo" so the
field types are consistent (look for the "plugin" key in install-guidance.json
and change its value to ["jo"] to match the schema defined in plugin.json).
| "install_steps": [ | ||
| "brew install jo", | ||
| "Or: apt install jo", | ||
| "Or: cargo install jo", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Is the jo JSON output tool available as a Rust cargo package?
💡 Result:
The jo JSON output tool is not a Rust cargo package. The original jo utility is a command-line tool written in C [1][2][3]. While jo itself is not available on crates.io, there is a Rust-based alternative called jf that performs a similar function of creating JSON from the command line [4]. Like jo, jf can be installed via cargo using the command cargo install jf [4]. Additionally, various Rust-based tools exist for working with JSON in CLI and agent environments (such as llm-json-repair [5] and agentcast-rs [6]), but they are distinct from the specific jo implementation [1][2].
Citations:
- 1: https://github.com/jpmens/jo/blob/master/README.md
- 2: https://github.com/jpmens/jo/
- 3: https://news.ycombinator.com/item?id=30224063
- 4: https://github.com/sayanarijit/jf
- 5: https://dev.to/mukundakatta/llm-json-repair-three-pass-local-json-repair-for-llm-responses-in-rust-m8f
- 6: https://dev.to/mukundakatta/agentcast-rs-repair-validate-and-retry-llm-json-output-in-rust-1aac
Fix install guidance for jo
cargo install jo won’t work: jo is a C command-line tool and isn’t available as a Rust crate for cargo install. Update that option (line 8) to cargo install jf or remove the cargo install guidance.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/jo/install-guidance.json` at line 8, Replace the incorrect cargo
install suggestion "Or: cargo install jo" in the install guidance (the string
"Or: cargo install jo") because jo is a C tool and not a Rust crate; update that
entry to "Or: cargo install jf" or remove the cargo-based guidance entirely so
the JSON no longer suggests installing jo via cargo.
| "install_guidance": { | ||
| "plugin": ["jo"], | ||
| "binary": "jo", | ||
| "check": "which jo", | ||
| "install_steps": [ | ||
| "brew install jo", | ||
| "Or: apt install jo", | ||
| "Or: cargo install jo", | ||
| "Or download binary from https://github.com/jpmens/jo/releases", | ||
| "Verify: jo --version", | ||
| "supercli plugins install ./plugins/jo --on-conflict replace --json" | ||
| ], | ||
| "note": "Source: https://github.com/jpmens/jo (4.8k stars). Written in C. Also available via Homebrew, apt, and cargo." | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Compare install_guidance in plugin.json vs install-guidance.json
# Extract install_guidance from plugin.json
jq '.install_guidance' plugins/jo/plugin.json > /tmp/jo_plugin_guidance.json
# Compare with standalone file
echo "=== Differences between plugin.json install_guidance and install-guidance.json ==="
diff -u <(jq -S '.' plugins/jo/install-guidance.json) <(jq -S '.' /tmp/jo_plugin_guidance.json) || trueRepository: javimosch/supercli
Length of output: 251
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Extract install_guidance from plugin.json
jq -S '.install_guidance' plugins/jo/plugin.json > /tmp/jo_plugin_install_guidance.json
# Normalize standalone install-guidance.json (it may already be an install_guidance object)
jq -S '.' plugins/jo/install-guidance.json > /tmp/jo_standalone_install_guidance.json
echo "sha256 plugin.json.install_guidance:"
sha256sum /tmp/jo_plugin_install_guidance.json
echo "sha256 standalone install-guidance.json:"
sha256sum /tmp/jo_standalone_install_guidance.json
echo "=== Unified diff (plugin.json.install_guidance vs standalone install-guidance.json) ==="
diff -u /tmp/jo_standalone_install_guidance.json /tmp/jo_plugin_install_guidance.json || trueRepository: javimosch/supercli
Length of output: 168
🏁 Script executed:
#!/bin/bash
set -euo pipefail
jq -S '.install_guidance' plugins/jo/plugin.json > /tmp/jo_plugin_install_guidance.json
jq -S '.' plugins/jo/install-guidance.json > /tmp/jo_standalone_install_guidance.json
python3 - <<'PY'
import hashlib, pathlib
def sha256(p):
h=hashlib.sha256()
h.update(pathlib.Path(p).read_bytes())
return h.hexdigest()
print("sha256 plugin.json.install_guidance:", sha256("/tmp/jo_plugin_install_guidance.json"))
print("sha256 standalone install-guidance.json:", sha256("/tmp/jo_standalone_install_guidance.json"))
PY
echo "=== Unified diff (plugin.json.install_guidance vs standalone install-guidance.json) ==="
diff -u /tmp/jo_standalone_install_guidance.json /tmp/jo_plugin_install_guidance.json || trueRepository: javimosch/supercli
Length of output: 930
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "---- plugins/jo/plugin.json (first 120 lines) ----"
nl -ba plugins/jo/plugin.json | sed -n '1,140p'
echo
echo "---- plugins/jo/plugin.json (install_guidance section) ----"
nl -ba plugins/jo/plugin.json | sed -n '1,120p' | rg -n "install_guidance|\"install_guidance\"|\"pairs\"|json create|cargo install|check|which jo|download binary" || true
echo
echo "---- plugins/jo/install-guidance.json (full) ----"
nl -ba plugins/jo/install-guidance.jsonRepository: javimosch/supercli
Length of output: 174
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "---- plugins/jo/plugin.json (first 200 lines) ----"
cat -n plugins/jo/plugin.json | sed -n '1,200p'
echo
echo "---- plugin.json: lines matching install_guidance / pairs / cargo install / jo commands ----"
cat -n plugins/jo/plugin.json | rg -n "install_guidance|\"install_guidance\"|\"pairs\"|json create|cargo install|check|which jo|download binary|github.com/jpmens/jo" || true
echo
echo "---- plugins/jo/install-guidance.json (full) ----"
cat -n plugins/jo/install-guidance.json | sed -n '1,220p'Repository: javimosch/supercli
Length of output: 4363
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find where "adapter": "process" is implemented and how args are mapped.
rg -n --hidden --no-ignore-vcs '"adapter"\s*:\s*"process"|process.*adapter|passthrough' . \
-S --glob='*.{rs,ts,js,jsx,tsx,py,json,md,yml,yaml,go}' || true
# Narrow to core command execution/passthrough logic.
rg -n --hidden --no-ignore-vcs 'passthrough' . -S --glob='*.{rs,ts,js,jsx,tsx,py}' || true
# Try to locate JSON create command routing (may show how "pairs" is used).
rg -n --hidden --no-ignore-vcs '"json"\s*,\s*"create"|"json create"|action"\s*:\s*"create"' . \
-S --glob='*.{rs,ts,js,jsx,tsx,py}' || trueRepository: javimosch/supercli
Length of output: 50376
🌐 Web query:
jpmens jo cargo install jo
💡 Result:
The utility jo, created by Jan-Piet Mens, is not a Rust-based tool and cannot be installed using cargo install jo [1][2][3]. jo is a C-based command-line utility used for creating JSON objects [1][4][3]. It is typically installed via package managers on various operating systems or by building from source [1][3]. Recommended installation methods include: - Homebrew (macOS/Linux): brew install jo [1][3] - Linux (Debian/Ubuntu): apt-get install jo [1][3] - Snap: snap install jo [1][5][3] - MacPorts: sudo port install jo [1][2] - Gentoo: emerge jo [1][3] - Scoop (Windows): scoop install jo [1][2] If you wish to build it from the repository, the process requires a C compiler and Autotools [1][2][3]: git clone https://github.com/jpmens/jo.git cd jo autoreconf -i./configure make check make install
Citations:
- 1: https://github.com/jpmens/jo/blob/master/README.md
- 2: https://github.com/jpmens/jo
- 3: https://hub.docker.com/r/jpmens/jo
- 4: https://github.com/jpmens/jo/blob/master/snapcraft.yaml
- 5: https://snapcraft.io/jo
🌐 Web query:
jo (jpmens) usage key=value pairs command line
💡 Result:
The jo command-line utility, created by Jan-Piet Mens, is used to generate JSON output from a shell [1][2]. By default, it interprets arguments as key=value pairs to construct a JSON object [1][3]. Core Key=Value Usage - Basic Object Creation: Provide arguments in the format key=value. The utility automatically attempts to guess the data type (string, number, or null) for the value [1][4]. $ jo name=JP number=17 {"name":"JP","number":17} - Boolean Values: Use the key@value syntax for boolean JSON elements [1][3]. If the value begins with T, t, or a number greater than zero, it results in true; otherwise, it results in false [4][3]. $ jo hungry@0 {"hungry":false} - Nested Objects: You can nest jo invocations by using command substitution. It is recommended to double-quote these sub-invocations to handle spaces correctly [1]. $ jo name=JP object="$(jo fruit='Blood Orange')" {"name":"JP","object":{"fruit":"Blood Orange"}} - Arrays: Use the -a option to interpret a list of words as array values instead of an object [1][5]. $ jo -a 1 2 3 [1][4][3] Advanced Features - Reading from Files: If a value starts with @, jo reads the content from the specified file [4][5]. You can also use: to interpret file contents as JSON [3][5]. $ jo program=jo authors=@AUTHORS {"program":"jo","authors":"..."} - Deduplication: By default, jo appends duplicate object keys. Use the -D option to deduplicate and keep only the last value provided for a key [1][5]. $ jo -D a=1 a=3 {"a":3} - Escaping: To use literal characters that jo interprets (like @, %, or:), escape them with a backslash [4][5]. $ jo twitter='`@jpmens' {"twitter":"@jpmens`"}
Citations:
- 1: https://github.com/jpmens/jo/blob/master/jo.md
- 2: https://github.com/jpmens/jo
- 3: https://manpages.debian.org/bullseye/jo/jo.1.en.html
- 4: https://manpages.ubuntu.com/manpages/jammy/man1/jo.1.html
- 5: https://man.archlinux.org/man/jo.1.en.txt
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Find where install_guidance is consumed =="
rg -n --hidden --no-ignore-vcs 'install_guidance|install-guidance' cli server . \
--glob='*.{js,ts,tsx,rs,py}' -S | head -n 200
echo
echo "== Inspect cli/supercli.js mapping of args around lines ~930-1020 =="
sed -n '900,1050p' cli/supercli.js
echo
echo "== Inspect process adapter implementation (search for 'adapter === \"process\"' ) =="
rg -n --hidden --no-ignore-vcs 'adapter\s*===\s*[\"'\'']process[\"'\'']|adapter:\s*[\"'\'']process[\"'\'']|case\s*[\"'\'']process[\"'\'']' server cli . \
-S --glob='*.js' | head -n 200
echo
echo "== Search for passthrough handling when building argv =="
rg -n --hidden --no-ignore-vcs 'passthrough.*baseArgs|baseArgs.*passthrough|argv|spawn|command.*passthrough' server cli . \
-S --glob='*.js' | head -n 200Repository: javimosch/supercli
Length of output: 9912
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Locate normalizeInstallGuidance in cli/plugin-install-guidance.js =="
rg -n "function normalizeInstallGuidance|normalizeInstallGuidance" cli/plugin-install-guidance.js
echo
echo "== Show around normalizeInstallGuidance implementation =="
sed -n '400,560p' cli/plugin-install-guidance.js
echo
echo "== Locate where __rawArgs is used =="
rg -n '"__rawArgs"' . --glob='*.{js,ts,tsx}' -S
echo
echo "== Locate process adapter argv/spawn building =="
rg -n '"adapter"\s*:\s*"process"|adapterConfig\.command|passthrough === true|passthrough"' server cli --glob='*.{js,ts,tsx}' -S | head -n 200
echo
echo "== Search for spawn/exec usage in process adapter path =="
rg -n 'spawn\(|execFile\(|exec\(|spawnSync\(' server cli --glob='*.{js,ts,tsx}' -S | head -n 200Repository: javimosch/supercli
Length of output: 5454
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Find __rawArgs usage (include JS/TS) =="
rg -n "__rawArgs" cli server --glob='*.js' --glob='*.ts' -S || true
echo
echo "== Find execute() implementation and where adapters are invoked =="
rg -n "function execute\\(|const execute\\s*=|execute\\(" cli server --glob='*.js' --glob='*.ts' -S | head -n 200
echo
echo "== Find adapters for adapterConfig.command (process adapter) =="
rg -n "adapterConfig\\.(command|baseArgs|passthrough)|command:\\s*.*adapterConfig" cli server --glob='*.js' -S | head -n 200
echo
echo "== Locate process adapter code (likely spawns subprocess) =="
rg -n "class .*Process|process adapter|adapter.*process|\"process\".*adapter|case \"process\"" server cli --glob='*.js' -S | head -n 200Repository: javimosch/supercli
Length of output: 4173
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "---- cli/adapters/process.js (relevant section 110-220) ----"
sed -n '110,220p' cli/adapters/process.js
echo
echo "---- cli/adapters/process.js (relevant section 220-360) ----"
sed -n '220,360p' cli/adapters/process.jsRepository: javimosch/supercli
Length of output: 9340
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Locate userFlags() in cli/supercli.js =="
rg -n "function userFlags\\(|const userFlags" cli/supercli.js
echo
echo "== Show around userFlags() implementation =="
rg -n "function userFlags\\(|const userFlags" cli/supercli.js | head -n 20 | cut -d: -f1 | head -n 1 | awk '{print $1}' >/tmp/uf_line.txt
uf_line=$(cat /tmp/uf_line.txt)
start=$((uf_line-60))
end=$((uf_line+120))
sed -n "${start},${end}p" cli/supercli.js
echo
echo "== Inspect how positional[] and rawArgs are built in cli/supercli.js =="
rg -n "const positional|positional =" cli/supercli.js | head -n 50
echo
echo "== Show around positional parsing =="
# print a window around first positional assignment
pos_line=$(rg -n "const positional|positional =" cli/supercli.js | head -n 1 | cut -d: -f1)
start=$((pos_line-60))
end=$((pos_line+120))
sed -n "${start},${end}p" cli/supercli.jsRepository: javimosch/supercli
Length of output: 8229
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find where positional args are collected
rg -n "positional\.push\\(" cli/supercli.js
# Find where flags are parsed into the 'flags' object
rg -n "flags\\s*\\[|flags\\.|process\\.argv" cli/supercli.js | head -n 200
# Show a reasonable window around argv parsing (first occurrence of process.argv usage)
argv_line=$(rg -n "process\\.argv" cli/supercli.js | head -n 1 | cut -d: -f1)
start=$((argv_line-80))
end=$((argv_line+160))
sed -n "${start},${end}p" cli/supercli.js
echo
echo "---- show remaining positional parsing near where positional is declared ----"
pos_decl=$(rg -n "const positional = \\[\\]" cli/supercli.js | head -n 1 | cut -d: -f1)
start2=$((pos_decl-60))
end2=$((pos_decl+140))
sed -n "${start2},${end2}p" cli/supercli.jsRepository: javimosch/supercli
Length of output: 3165
Fix install guidance drift and jo command/installer correctness
plugins/jo/plugin.json(install_guidance, lines 9-22) andplugins/jo/install-guidance.jsonboth defineinstall_guidance, but they don’t match (notediffers andpluginis["jo"]vs"jo"), creating conflicting sources of truth.plugins/jo/plugin.jsoninstall steps includecargo install jo, butjois a C-based utility (not a Rust crate), so this step won’t work.plugins/jo/plugin.jsonjo json createmarksargs[0](pairs) as required while also settingadapterConfig.passthrough: true; in this mode SuperCLI forwards only remaining positional args (__rawArgs) to theprocessadapter, so the--pairsvalue won’t be passed through tojo(and positionalkey=valuetokens won’t satisfy the requiredpairscheck). Adjust the command to forwardpairscorrectly (e.g., make it true passthrough positional, or passpairsinto argv in non-passthrough mode).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/jo/plugin.json` around lines 9 - 22, There are three problems:
conflicting install_guidance between the two files, an incorrect install step
suggesting `cargo install jo`, and a command mismatch for `jo json create` where
args[0] (`pairs`) is required but adapterConfig.passthrough is true so the value
won't be forwarded. Fix by: (1) choose one canonical source for install_guidance
(keep a single definition and remove the duplicate) and make the `plugin` field
type consistent (`"jo"` or `["jo"]`) and unify the `note` text between
plugin.json and install-guidance.json; (2) remove the incorrect `cargo install
jo` step and update install_steps to only valid installers/binaries (Homebrew,
apt, downloading releases) and ensure the `check` and `binary` entries are
correct; (3) for the `jo json create` command, either disable
adapterConfig.passthrough and marshal `pairs` into argv so the required args[0]
is passed to the process adapter, or keep passthrough and make `pairs` not
required and accept its values from __rawArgs (or mark the command as
passthrough-positional), ensuring the CLI validation and adapter wiring (args[0]
`pairs`, adapterConfig.passthrough, and use of __rawArgs) are consistent.
| "args": [ | ||
| { | ||
| "name": "pairs", | ||
| "type": "string", | ||
| "required": true, | ||
| "description": "Key=value pairs (e.g. name=John age=30)" | ||
| }, | ||
| { | ||
| "name": "pretty", | ||
| "type": "boolean", | ||
| "required": false, | ||
| "description": "Pretty-print output" | ||
| }, | ||
| { | ||
| "name": "array", | ||
| "type": "boolean", | ||
| "required": false, | ||
| "description": "Force array output" | ||
| } | ||
| ] |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
How does the jo command-line tool accept key-value pairs as arguments?
💡 Result:
The jo command-line tool accepts key-value pairs as arguments primarily in the format key=value [1][2]. When these pairs are passed to the tool, jo automatically interprets them as elements within a JSON object [1][3]. Key operational details include: * Type Inference: By default, jo attempts to guess the data type of the value (string, number, or null) [1][2]. * Explicit Type Handling: * key=value: Standard assignment, often treated as a string [4]. * key:=value: Often used to explicitly force non-string types like numbers, booleans, or nulls [4]. * key@value: Specifically used for boolean JSON elements; the value is evaluated as true or false based on its content (e.g., T, t, or a positive numeric value) [1][3]. * Advanced Data Input: The tool supports special prefixes for values to handle complex data: * @file: Reads the contents of a file as a literal string [1][2]. * %file: Reads and base64-encodes the contents of a file [1][3]. * :file: Interprets the file contents as JSON and inserts the resulting object/array [1][3]. * Nesting and Paths: You can create nested JSON objects by specifying object paths if the -d option is used (e.g., jo -d. a.b=1) [1][2]. * Array Mode: By using the -a option, jo interprets the provided words as elements in a JSON array rather than key-value pairs in an object [1][3]. Users should be aware that shell quoting is important when passing these arguments to ensure special characters are handled correctly by the shell before they reach the tool [5][4].
Citations:
- 1: https://man.archlinux.org/man/jo.1.en.txt
- 2: https://github.com/jpmens/jo/blob/master/jo.md
- 3: https://manpages.ubuntu.com/manpages/jammy/man1/jo.1.html
- 4: https://linuxcommandlibrary.com/man/jo
- 5: https://lobste.rs/s/3xuscw/jo_construct_json_objects_on_command_line
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the jo plugin manifest around the referenced lines and search for passthrough usage
sed -n '1,120p' plugins/jo/plugin.json
echo "----"
rg -n "\"passthrough\"|passthrough" plugins/jo/plugin.json plugins/jo -S || true
echo "----"
# Find any shared framework docs/usages for "passthrough" in the repo
rg -n "\"passthrough\"|passthrough" . -S --glob '!**/node_modules/**' --glob '!**/dist/**' --glob '!**/build/**' --glob '!**/.git/**' | head -n 200Repository: javimosch/supercli
Length of output: 34074
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Focus on supercli-zig-cli code paths for passthrough and argument forwarding
rg -n "passthrough" supercli-zig-cli/src -S
echo "---- main.zig relevant sections"
sed -n '430,560p' supercli-zig-cli/src/main.zig
echo "---- main.zig command arg handling"
sed -n '920,1040p' supercli-zig-cli/src/main.zig
echo "---- executor.zig relevant sections"
sed -n '1,220p' supercli-zig-cli/src/executor.zig
sed -n '220,420p' supercli-zig-cli/src/executor.zig
# Find where command args are built from manifest args
rg -n "adapterConfig|baseArgs|args\\[|manifest|command\\.args|parsed\\.positional" supercli-zig-cli/src -S | head -n 200Repository: javimosch/supercli
Length of output: 29424
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show how manifest args are converted to actual argv and where passthrough affects it
rg -n "handleExecuteCommand\\(|build.*argv|argv|baseArgs|args\\b|CommandArgs|positional" supercli-zig-cli/src -S
# Print likely relevant helper functions around handleExecuteCommand
rg -n "fn handleExecuteCommand" -n supercli-zig-cli/src/main.zig supercli-zig-cli/src/*.zig
# If the function isn't in main.zig, search for "handleExecuteCommand" usages
rg -n "handleExecuteCommand" supercli-zig-cli/src -S
# Print sections around any match location
matches=$(rg -n "handleExecuteCommand" supercli-zig-cli/src -S | cut -d: -f1 | sort -u)
echo "---- files with handleExecuteCommand: $matches"
for f in $matches; do
echo "==== $f"
line=$(rg -n "handleExecuteCommand" $f -S | head -n1 | cut -d: -f2)
start=$((line-60)); end=$((line+160));
sed -n "${start},${end}p" "$f"
done
# Look at config for args parsing if any
rg -n "struct .*Arg|type .*Arg|required" supercli-zig-cli/src -S | head -n 200Repository: javimosch/supercli
Length of output: 11329
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect how `passthrough: true` changes argv construction/forwarding for non-namespace commands
rg -n "passthrough" supercli-zig-cli/src -S
echo "---- main.zig (relevant around passthrough args plumbing)"
sed -n '430,620p' supercli-zig-cli/src/main.zig
echo "---- main.zig (passthrough command routing + arg slices)"
sed -n '920,1040p' supercli-zig-cli/src/main.zig
echo "---- executor.zig (how passthrough affects process spawn)"
sed -n '1,260p' supercli-zig-cli/src/executor.zig
sed -n '260,520p' supercli-zig-cli/src/executor.zig
# Find where manifest `args` are converted into argv, and where `passthrough` merges in extra tokens
rg -n "handleExecuteCommand\\(|build.*argv|argv|baseArgs|adapterConfig|cmd_.*args|positional" supercli-zig-cli/src -S
rg -n "handleExecuteCommand" supercli-zig-cli/src -SRepository: javimosch/supercli
Length of output: 39251
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate and print parseArgs implementation in supercli-zig-cli/src/main.zig
rg -n "fn parseArgs\\b" -S supercli-zig-cli/src/main.zig
line=$(rg -n "fn parseArgs\\b" supercli-zig-cli/src/main.zig | head -n1 | cut -d: -f1)
start=$((line-60)); end=$((line+220))
sed -n "${start},${end}p" supercli-zig-cli/src/main.zigRepository: javimosch/supercli
Length of output: 2039
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="supercli-zig-cli/src/main.zig"
# Print parseArgs line with number only, then extract numeric line
line_num=$(rg -n "fn parseArgs\\b" "$file" | head -n1 | cut -d: -f1)
echo "parseArgs at line $line_num"
start=$((line_num-60))
end=$((line_num+260))
sed -n "${start},${end}p" "$file"Repository: javimosch/supercli
Length of output: 1924
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="supercli-zig-cli/src/main.zig"
line_num=$(rg -n "fn parseArgs\\b" "$file" | head -n1 | cut -d: -f1)
start=$((line_num-60))
if [ "$start" -lt 1 ]; then start=1; fi
end=$((line_num+260))
echo "parseArgs at line $line_num (showing $start-$end)"
sed -n "${start},${end}p" "$file"Repository: javimosch/supercli
Length of output: 12800
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="supercli-zig-cli/src/main.zig"
# Show where argv is parsed into positional/raw_args and how dispatch slices passthrough args
sed -n '620,760p' "$file"
sed -n '760,940p' "$file"
sed -n '940,1020p' "$file"Repository: javimosch/supercli
Length of output: 16559
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate Node adapter/process implementation and schema-to-argv mapping
rg -n "adapters/process|process\\.js" -S . --glob '!**/node_modules/**' || true
rg -n "passthrough" -S cli src . --glob '!**/node_modules/**' || true
rg -n "parseArgDefs|arg_defs|required.*pairs|\"positional\"" -S . --glob '!**/node_modules/**' || true
# If we have JS/TS sources, inspect suspected files
fd -e js -e ts -e mjs -e cjs -e jsx -e tsx . | head -n 50Repository: javimosch/supercli
Length of output: 50438
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the relevant mapping logic in cli/supercli.js
file="cli/supercli.js"
rg -n "map remaining positional args|passthrough positional arguments|__rawArgs|remainingPositionalArgs" "$file"
# Print around those sections
sed -n '900,1040p' "$file"
sed -n '1040,1120p' "$file"
# Show relevant passthrough handling in cli/adapters/process.js
file2="cli/adapters/process.js"
rg -n "passthroughMode|__rawArgs|passthroughArgs|args\\.push\\(\\.\\.\\.|cfg\\.passthrough" "$file2"
sed -n '120,240p' "$file2"
sed -n '240,420p' "$file2"
# Also inspect how positional args/flags are parsed into __rawArgs in cli/supercli.js
rg -n "__rawArgs" "$file"Repository: javimosch/supercli
Length of output: 18398
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="cli/supercli.js"
# Show helper(s) that parse CLI argv into {positional, rawArgs, flags/userFlags}
rg -n "function userFlags\\b|function parse|positional\\s*=|rawArgs\\b|remainingPositionalArgs\\b" "$file" | head -n 80
# Print around the userFlags() definition and remainingPositionalArgs section
sed -n '760,1040p' "$file"
# Print execute() call-site context: how positional/rawArgs were produced
sed -n '820,1010p' "$file"
# Also inspect earlier part where flags are parsed into userFlags()
sed -n '880,980p' "$file"Repository: javimosch/supercli
Length of output: 19497
🏁 Script executed:
#!/bin/bash
set -euo pipefail
cat -n plugins/jo/plugin.json | sed -n '1,140p'Repository: javimosch/supercli
Length of output: 3185
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="cli/supercli.js"
sed -n '1,140p' "$file"
sed -n '140,260p' "$file"
sed -n '260,420p' "$file"Repository: javimosch/supercli
Length of output: 12875
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="cli/adapters/process.js"
rg -n "function toCliFlags|toCliFlags\\b|nonTtyBaseArgs|__positionalArgs" "$file"
sed -n '1,220p' "$file"
sed -n '220,340p' "$file"Repository: javimosch/supercli
Length of output: 12567
🌐 Web query:
jo command options pretty-print output (-p?) and array mode (-a?)
💡 Result:
For the jo command (jo creates JSON from key/value args): -p: Pretty-print the JSON output (instead of the default terse one-line output). [1][2] -a: Interpret the list of words as array values and produce a JSON array instead of an object. [1][2] Example from the jo manual: jo -p -a * outputs a pretty-printed JSON array. [1]
Citations:
🌐 Web query:
Does jo support long options like --pretty or --array in addition to -p and -a?
💡 Result:
No, the jo command-line tool does not support long options like --pretty or --array [1][2][3]. It relies exclusively on short, single-letter options [1][4]. According to the official documentation, the supported flags for these behaviors are: -p: Enables pretty-printing of the JSON output [1][3]. -a: Directs jo to interpret arguments as an array instead of an object [2][4]. Other global options for jo are also strictly single-character, such as -B (to disable boolean/null interpretation), -D (to deduplicate keys), -e (to ignore empty stdin), -n (to omit keys with empty values), -v (to show the version), and -V (to show the version as a JSON object) [1][2][5].
Citations:
- 1: https://man.archlinux.org/man/jo.1.en.txt
- 2: https://github.com/jpmens/jo/blob/master/jo.md
- 3: https://manpages.ubuntu.com/manpages/jammy/man1/jo.1.html
- 4: https://manpages.debian.org/bullseye/jo/jo.1.en.html
- 5: https://man.archlinux.org/man/jo.1.en.raw
Fix jo json create argument schema to match passthrough behavior.
plugins/jo/plugin.json sets adapterConfig.passthrough: true, so SuperCLI forwards only the remaining positional tokens to jo via __rawArgs; it does not map schema args into the underlying CLI invocation. With pairs marked required: true, a natural call like supercli jo json create name=John age=30 (positional key=value tokens) will fail validation because uFlags.pairs is never set in passthrough mode. Also, pretty/array (long-form schema flags) won’t affect jo since passthrough mode ignores them; jo expects -p and -a (not --pretty/--array).
- Make
pairsnot required (or remove it) and document thatname=John age=30must be provided as positional tokens. - Either remove/relax
prettyandarrayin this passthrough command, or switch away frompassthroughand explicitly mappretty -> -pandarray -> -a.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/jo/plugin.json` around lines 51 - 70, The command schema uses
adapterConfig.passthrough: true so SuperCLI forwards positional tokens via
__rawArgs and does not populate schema args; update plugins/jo/plugin.json by
making the "pairs" arg optional (or remove it) and add a note in its description
that key=value tokens must be provided positionally (e.g., name=John age=30),
and either remove/relax the "pretty" and "array" flags (since passthrough
ignores --pretty/--array) or change the adapterConfig to not use passthrough and
instead map "pretty" -> -p and "array" -> -a so the flags are translated into
the underlying jo invocation.
| jo name=John age=30 active=true | ||
|
|
||
| # Nested objects | ||
| jo name=John address="city=New York zip=10001" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the correct syntax for creating nested objects and arrays using the jo command-line tool?
💡 Result:
To create nested objects and arrays with the jo command-line tool, you can use command substitution, direct nesting syntax, or object paths [1][2][3]. Command Substitution You can create nested structures by invoking jo within a subshell for the value of a key [1][3]. It is generally recommended to double-quote these subshells to handle spaces correctly [1]: $ jo -p name=JP object="$(jo fruit=Orange point="$(jo x=10 y=20)")" { "name": "JP", "object": { "fruit": "Orange", "point": { "x": 10, "y": 20 } } } Direct Nesting Syntax You can define nested keys using bracket notation (e.g., key[subkey]=value) [1][2]. To create an array, use the [] suffix [1][2]: $ jo -p name=Jane point[]=1 point[]=2 geo[lat]=10 geo[lon]=20 { "name": "Jane", "point": [1][2], "geo": { "lat": 10, "lon": 20 } } Object Paths Alternatively, you can use a delimiter (defaulting to a dot when using the -d flag) to specify paths [1][3]: $ jo -p -d. name=Jane point[]=1 point[]=2 geo.lat=10 geo.lon=20 { "name": "Jane", "point": [1][2], "geo": { "lat": 10, "lon": 20 } } Note: If the first character of a value is an open brace { or bracket [, jo will attempt to decode the remainder as JSON [2][3]. Additionally, using a colon (:) as a prefix allows you to interpret the contents of a file as JSON [2][3].
Citations:
- 1: https://github.com/jpmens/jo/blob/master/jo.md
- 2: https://manpages.debian.org/bullseye/jo/jo.1.en.html
- 3: https://manpages.ubuntu.com/manpages/jammy/man1/jo.1.html
Fix jo nested-object/array syntax examples to match documented key-path/[] forms
- Line 40 (
address="city=New York zip=10001") doesn’t reflect documented nesting;jonesting is done via key paths (e.g.,address[city]=.../geo.lat=...using-p), or by providing JSON when the value starts with{/[—not a plainkey=valuestring. - Line 43 (
jo -a name=John name=Jane) doesn’t match the documented array syntax (key[]=v key[]=v); update it to the[]key-path form or align it with the exact, documented-abehavior.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@plugins/jo/skills/quickstart/SKILL.md` at line 40, Update the two example
usages of the jo tool so they use documented key-path and JSON/array forms
instead of plain space-separated key=value strings: replace the nested-object
example `jo name=John address="city=New York zip=10001"` with a key-path or JSON
form (e.g., `jo -p address.city="New York" -p address.zip=10001` or `jo
name=John address='{"city":"New York","zip":10001}'`), and change the array
example `jo -a name=John name=Jane` to the documented bracket form (e.g., `jo -a
name[]=John name[]=Jane`) or the exact `-a` behavior supported by jo; ensure
examples use `-p`, `[]` key-paths, or JSON-starting values to demonstrate
nesting and arrays consistently.
jo creates JSON from key=value pairs on the command line. Source: https://github.com/jpmens/jo (4.8k stars)
jj is a Git-compatible VCS that is both simple and powerful. Source: https://github.com/jj-vcs/jj (29k stars)
javimosch
force-pushed
the
am/am-0e131c-tfuh40
branch
from
49ed9e3 to
8c2bfce
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
plugins/gum/plugin.json (1)
340-340:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winCatch-all description reads as an unfilled template.
"_ _ via gum"looks like a placeholder where theresource/action(_/_) were substituted literally, producing an unhelpful user-facing string. The prior"Passthrough to gum CLI"was clearer.📝 Proposed fix
- "description": "_ _ via gum", + "description": "Passthrough to gum CLI",🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@plugins/gum/plugin.json` at line 340, The "description" field in plugin.json currently contains a placeholder string "\"_ _ via gum\"" which is unhelpful; update the description value to a meaningful, user-facing sentence (for example reuse the prior clearer text "Passthrough to gum CLI" or construct "Run gum commands via CLI") by editing the "description" property in plugins/gum/plugin.json so it no longer contains the literal underscores and instead describes the plugin's purpose.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@plugins/gum/plugin.json`:
- Line 340: The "description" field in plugin.json currently contains a
placeholder string "\"_ _ via gum\"" which is unhelpful; update the description
value to a meaningful, user-facing sentence (for example reuse the prior clearer
text "Passthrough to gum CLI" or construct "Run gum commands via CLI") by
editing the "description" property in plugins/gum/plugin.json so it no longer
contains the literal underscores and instead describes the plugin's purpose.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2a2cc6a1-3112-4130-81da-0cca62b1c4fe
📒 Files selected for processing (11)
plugins/dotbot/plugin.jsonplugins/gum/plugin.jsonplugins/gum/skills/quickstart/SKILL.mdplugins/jj/install-guidance.jsonplugins/jj/meta.jsonplugins/jj/plugin.jsonplugins/jj/skills/quickstart/SKILL.mdplugins/jo/install-guidance.jsonplugins/jo/meta.jsonplugins/jo/plugin.jsonplugins/jo/skills/quickstart/SKILL.md
✅ Files skipped from review due to trivial changes (3)
- plugins/gum/skills/quickstart/SKILL.md
- plugins/jo/meta.json
- plugins/jo/skills/quickstart/SKILL.md
🚧 Files skipped from review as they are similar to previous changes (6)
- plugins/jo/install-guidance.json
- plugins/jj/skills/quickstart/SKILL.md
- plugins/jj/meta.json
- plugins/jj/install-guidance.json
- plugins/jo/plugin.json
- plugins/jj/plugin.json
|
Closing — CI was broken (missing test script). Fixed in 71d4d39. Fresh AM runs on new master will produce clean PRs. |
1 participant
Automated maintenance run by automaintainer.
Focus: search for and add new CLI tools as bundled plugins to supercli. For each plugin: search GitHub for non-interactive CLI tools (stars>100, rust/go/python), create plugin files (plugin.json, meta.json, install-guidance.json, skills/quickstart/SKILL.md), validate JSON, commit with conventional commit message. Target 2 plugins per session.
Branch:
am/am-0e131c-tfuh40Summary by CodeRabbit
New Features
Documentation