Repository navigation
fix: resolve CLI as altimate or altimate-code (1.1.1) - #8
Conversation
Standalone installs (curl, Homebrew, PowerShell) expose only the `altimate` binary; npm exposes both names. The skills and commands hard-required `altimate-code` and reported the CLI as missing on standalone installs. Resolve either name in every invocation and list both install methods. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`command -v` reports alias text or a function name before the PATH binary, so a user alias such as `alias altimate-code=altimate` was captured as the binary path and every run failed. The resolver now drops the candidate's alias/function in a subshell before looking it up, which also accepts relative PATH entries, and exits 127 with a clear message when neither name is installed. It runs before mktemp so a missing CLI leaves no temp file behind. Review scope tables now use the resolved binary, and recovery messages name `altimate`, which both install methods provide. Adds tests/resolve-cli.sh, which checks every resolver copy is identical and resolves correctly in bash and zsh. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| 1. **Verify altimate-code is installed:** | ||
| ```bash | ||
| command -v altimate-code | ||
| command -v altimate-code || command -v altimate |
There was a problem hiding this comment.
WARNING: Redundant pre-check does not ignore aliases or shell functions
Step 1 runs command -v altimate-code || command -v altimate without clearing aliases or shell functions, whereas the inline resolver in Step 3 explicitly strips them via unalias and unset -f before exiting 127 if neither binary is on PATH. Because each Bash tool call runs in a fresh shell and Step 3 already performs the authoritative check before mktemp, this separate Step 1 check is redundant (requiring an extra tool round-trip) and inconsistent with Step 3 when a broken alias or function exists.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
There was a problem hiding this comment.
Agreed, and fixed in 032fa43. That separate command -v step came from this PR and could be satisfied by an alias or shell function that the resolver ignores. Step 1 no longer runs its own check: it relies on the resolver, which runs first and exits 127 with altimate-code CLI not found, and that exit points to the install message. The same change is in all four files. tests/resolve-cli.sh passes in bash and zsh.
| ## Workflow | ||
|
|
||
| 1. **Verify altimate-code is on PATH.** Run `command -v altimate-code`. If nothing is returned, tell the user: `"altimate-code is not installed. Install with 'npm install -g altimate-code' (Node 20+), then run 'altimate-code' once to configure your provider and warehouse auth."` — then STOP. | ||
| 1. **Verify altimate-code is on PATH.** Run `command -v altimate-code || command -v altimate`. If nothing is returned, tell the user: `"altimate-code is not installed. Install with 'npm install -g altimate-code' (Node 20+) or 'curl -fsSL https://www.altimate.sh/install | bash', then run 'altimate' once to configure your provider and warehouse auth."` — then STOP. |
There was a problem hiding this comment.
WARNING: Separate command -v pre-check is redundant with the inline resolver and does not ignore aliases/functions
Step 1 instructs running command -v altimate-code || command -v altimate first and also provides the inline for ALTIMATE_NAME in ... resolver block below it that strips aliases/functions and exits 127 when neither binary is found. Running a separate command -v call first adds an extra Bash tool invocation and does not protect against aliases or shell functions the way the inline loop does.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
There was a problem hiding this comment.
Agreed, and fixed in 032fa43. That separate command -v step came from this PR and could be satisfied by an alias or shell function that the resolver ignores. Step 1 no longer runs its own check: it relies on the resolver, which runs first and exits 127 with altimate-code CLI not found, and that exit points to the install message. The same change is in all four files. tests/resolve-cli.sh passes in bash and zsh.
| ## You MUST follow this workflow | ||
|
|
||
| 1. **Verify altimate-code is on PATH** with `command -v altimate-code`. If it returns nothing, jump to "Not installed" below and stop. | ||
| 1. **Verify altimate-code is on PATH** with `command -v altimate-code || command -v altimate`. The CLI ships under two names: the npm package exposes both `altimate-code` and `altimate`, while the standalone curl/Homebrew/PowerShell installers expose only `altimate`. Either name is the same CLI. If neither resolves, jump to "Failure modes" below and stop. |
There was a problem hiding this comment.
WARNING: Step 1 command -v check is redundant with the Step 2 resolver and does not strip aliases/functions
Step 1 runs command -v altimate-code || command -v altimate, while Step 2 already resolves ALTIMATE_BIN (ignoring aliases and functions) before mktemp and exits 127 with altimate-code CLI not found if neither binary is on PATH (matching the symptom in the Failure modes table). Removing the separate command -v pre-check avoids an extra shell invocation and ensures consistent alias-safe resolution.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
There was a problem hiding this comment.
Agreed, and fixed in 032fa43. That separate command -v step came from this PR and could be satisfied by an alias or shell function that the resolver ignores. Step 1 no longer runs its own check: it relies on the resolver, which runs first and exits 127 with altimate-code CLI not found, and that exit points to the install message. The same change is in all four files. tests/resolve-cli.sh passes in bash and zsh.
| ## You MUST follow this workflow | ||
|
|
||
| 1. **Verify altimate-code is on PATH** with `command -v altimate-code`. If it returns nothing, jump to "Failure modes" below and stop. | ||
| 1. **Verify altimate-code is on PATH** with `command -v altimate-code || command -v altimate`. If neither resolves, jump to "Failure modes" below and stop. |
There was a problem hiding this comment.
WARNING: Separate command -v pre-check is redundant with the inline resolver and does not strip aliases/functions
Step 1 instructs verifying PATH with command -v altimate-code || command -v altimate, even though the inline resolver immediately below already checks both binary names (ignoring aliases and functions) and exits 127 with altimate-code CLI not found when neither is installed.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
There was a problem hiding this comment.
Agreed, and fixed in 032fa43. That separate command -v step came from this PR and could be satisfied by an alias or shell function that the resolver ignores. Step 1 no longer runs its own check: it relies on the resolver, which runs first and exits 127 with altimate-code CLI not found, and that exit points to the install message. The same change is in all four files. tests/resolve-cli.sh passes in bash and zsh.
| expect "$sh" "$STUBS/both" '' 0 'ran altimate-code' | ||
| expect "$sh" "$STUBS/neither" '' 127 'altimate-code CLI not found (tried altimate-code, altimate)' | ||
| expect "$sh" "$STUBS/only-altimate" "$ALIAS_SETUP" 0 'ran altimate' | ||
| expect "$sh" "$STUBS/only-altimate" "$ALIAS_SETUP; altimate() { echo function; }" 0 'ran altimate' |
There was a problem hiding this comment.
SUGGESTION: Add a test case where altimate-code itself is defined as a shell function
Line 65 tests altimate() as a function while altimate-code is an alias, but there is no test case where altimate-code() is defined as a shell function (with only altimate on PATH), which is the primary first-iteration path where unset -f "$ALTIMATE_NAME" is needed to prevent command -v altimate-code from succeeding with the function name.
| expect "$sh" "$STUBS/only-altimate" "$ALIAS_SETUP; altimate() { echo function; }" 0 'ran altimate' | |
| expect "$sh" "$STUBS/only-altimate" "$ALIAS_SETUP; altimate() { echo function; }" 0 'ran altimate' | |
| expect "$sh" "$STUBS/only-altimate" 'altimate-code() { echo function; }' 0 'ran altimate' |
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
There was a problem hiding this comment.
Added in 032fa43: a case with altimate-code() { echo function; } defined and only altimate on PATH, which expects ran altimate. It passes in both bash and zsh.
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (10 files)
Previous Review Summaries (4 snapshots, latest commit 2c0f11f)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 2c0f11f)Status: No Issues Found | Recommendation: Merge Files Reviewed (10 files)
Previous review (commit 032fa43)Status: No Issues Found | Recommendation: Merge Files Reviewed (10 files)
Previous review (commit 648354e)Status: 5 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (10 files)
Fix these issues in Kilo Cloud Previous review (commit 457f3c2)Status: 5 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (10 files)
Reviewed by gemini-4-argon · Input: 53.8K · Output: 1.1K · Cached: 156.6K |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
hkaltai
changed the title
The separate `command -v` step could be satisfied by an alias or shell function that the resolver deliberately ignores, and cost an extra shell call. The skills and slash commands now rely on the resolver's `altimate-code CLI not found` exit instead. Adds a resolver test where `altimate-code` is a shell function. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`altimate` is the CLI's canonical name since v0.7.1 and every install method provides it, so the resolver now tries it first and falls back to `altimate-code` only for npm installs that predate it. With both names on PATH from installs of different versions, the canonical name wins instead of a possibly stale `altimate-code` copy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The review flow ran `gh pr checkout` before resolving the CLI, so a machine without it had its branch switched before "not found" was reported. The PR-scope command now runs after the resolver in the same Bash call. bash's `command -v` returns a non-executable file when no executable match exists, so a broken `altimate` on PATH beat a working `altimate-code`. The resolver now only accepts an executable path. Recovery messages name `altimate-code` for npm installs older than v0.7.1, which the resolver still supports. The resolver test checks its temp dir, runs with only the stub dirs on PATH, and covers legacy-only installs with an alias or function, aliases and functions with nothing installed, and a non-executable `altimate`. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
sahrizvi
left a comment
sahrizvi
left a comment
There was a problem hiding this comment.
Multi-model consensus review (Claude, Grok 4.3, Qwen 3.6 Plus, DeepSeek V4 Pro, Kimi K2.6). Major findings are inline; minor findings and nits are in a separate comment.
| ## [1.1.0] — 2026-10-19 | ||
|
|
||
| ### Fixed | ||
| - The skills and slash commands now resolve the CLI as `altimate`, its canonical name since v0.7.1, and fall back to `altimate-code` for older npm installs. Standalone installs (curl, Homebrew, PowerShell) expose only `altimate`, so the plugin previously reported "not installed" on machines where the CLI was present. |
There was a problem hiding this comment.
[MAJOR] The "only altimate" claim is false for Homebrew today, and for curl and PowerShell once altimate-code#1562 ships
The Homebrew formula has always installed both names: bin.install "altimate" plus bin.install_symlink "altimate" => "altimate-code" (altimate-code packages/opencode/script/publish.ts:329-358; altimate-code CHANGELOG #820 says "Homebrew installs are unchanged"). altimate-code#1562, part of this change set, makes the curl and PowerShell installers create an altimate-code alias. It also rewrites the CLI README to say the standalone install exposes "the same two names the npm install exposes".
The same claim is repeated in README.md:20, commands/altimate.md:10, commands/review.md:22, skills/altimate-code/SKILL.md:24 and skills/review/SKILL.md:32. In the skill files, the model reads it as fact. Behaviour is fine, because the resolver handles both layouts. Only the text is wrong.
Suggested fix: remove Homebrew from the claim and describe the gap as historical, e.g. "curl and PowerShell installs from v0.7.1 until altimate-code vX.Y put only altimate on PATH". For README line 20: # standalone binary; exposes altimate (and altimate-code from vX.Y).
Consensus: Claude, Grok, Qwen, DeepSeek, Kimi
There was a problem hiding this comment.
Agreed, and fixed in 2c8423c. I checked the formula in publish.ts: Homebrew installs altimate and links altimate-code to it. Every place that made the claim (the README, both slash commands, both skills and the CHANGELOG) now says that npm and Homebrew installs expose both names and that only older curl and PowerShell installs lack altimate-code. The README install comment for curl now just says it exposes altimate. I didn't name an installer version because altimate-code#1562 is still open. altimate-codex-plugin#5 has the same fix (54196eb).
| "name": "altimate-code", | ||
| "displayName": "Altimate Code", | ||
| "version": "1.0.0", | ||
| "version": "1.1.0", |
There was a problem hiding this comment.
[MAJOR] Conflicts with #7: both release 1.1.0, and the branches conflict in 5 files
git merge-tree of this branch and #7 reports content conflicts in plugin.json, CHANGELOG.md, README.md, commands/altimate.md and skills/altimate-code/SKILL.md. marketplace.json merges cleanly only because both PRs set it to 1.1.0. Both PRs add ## [1.1.0] — 2026-10-19.
#7 also rewrites the same run blocks this PR edits: --agent builder, < /dev/null, and mktemp "${TMPDIR:-/tmp}/altimate-result.XXXXXX". Whichever PR merges second must carry both sets of changes into every block. If this PR's version of the blocks wins the conflict resolution, the stdin-hang, agent and mktemp fixes are lost silently, and nothing in tests/resolve-cli.sh would catch it.
Suggested fix: agree on a merge order and rebase the second PR onto the first. Either fold both sets of bullets into one [1.1.0] section, or release 1.1.1 if 1.1.0 has already been tagged or submitted to the directory. Re-run tests/resolve-cli.sh afterwards, since its per-file block counts may change.
Consensus: Claude, Grok, Qwen, DeepSeek, Kimi (DeepSeek rated it CRITICAL)
There was a problem hiding this comment.
Resolved: #7 is now merged. 2c8423c merges main into this branch, and GitHub reports it as mergeable. Every run block keeps #7's --agent builder, < /dev/null and mktemp "${TMPDIR:-/tmp}/altimate-result.XXXXXX", and only the binary goes through "$ALTIMATE_BIN". Because 1.1.0 is already on main, this PR now releases 1.1.1 with its own CHANGELOG section, so users who already have 1.1.0 get an update. tests/resolve-cli.sh passes after the merge, with the SKILL.md block count raised to 3 for the new workspace block.
| <user's task, verbatim> | ||
| ALTIMATE_TASK | ||
| )" | ||
| for ALTIMATE_NAME in altimate altimate-code; do |
There was a problem hiding this comment.
[MAJOR] Once #7 is merged in, its new altimate-code workspace|link|auth commands bypass this resolver
#7 has Claude run altimate-code workspace status < /dev/null, altimate-code workspace list, and altimate-code link --workspace … or --create. It also tells users to type ! altimate-code auth login … and ! altimate-code workspace sync, and its "not installed" message says to run altimate-code once. grep -c ALTIMATE_BIN on #7's branch returns 0.
On an install that has only altimate (curl or PowerShell before #1562, or before the installer is re-run), delegated runs would work, but checking the workspace link, linking and signing in would fail with command not found. That is the bug this PR fixes, now inside the same skill.
Suggested fix: in the merged result, put this resolver in front of every command Claude runs ("$ALTIMATE_BIN" workspace status < /dev/null, and so on). For the ! commands users type, write altimate and add "(altimate-code on npm installs older than v0.7.1)", as this PR does elsewhere. Also add a test guard against bare invocations (see the summary comment).
Consensus: Claude, Grok, Qwen, DeepSeek, Kimi
There was a problem hiding this comment.
Fixed in 2c8423c. The Altimate workspaces section now starts with a resolver block, and workspace status, workspace list, link --workspace and link --create all run as "$ALTIMATE_BIN" … < /dev/null. Commands the user types after ! (auth login, workspace sync, workspace status, link) now say altimate, with a note that npm installs older than v0.7.1 use altimate-code. The same goes for the failure-modes rows and the README's workspace setup. tests/resolve-cli.sh now fails if any line starts with altimate or altimate-code followed by run, review, workspace, link, auth or session. I checked that a bare altimate-code workspace status makes it fail.
Consensus review: minor findings and nitsReviewed by 5 models: Claude, Grok 4.3, Qwen 3.6 Plus, DeepSeek V4 Pro and Kimi K2.6. Kimi replaced GPT 5.3 Codex, which stalled. The 3 major findings are posted as inline comments. Verdict: changes requested. The resolver code itself is correct. I verified locally that Minor
Nits
Not tied to a diff line
Done well: the resolver runs in the same Bash call as the CLI, and the docs explain why. Aliases and functions are removed inside a subshell, so the user's shell isn't changed. The 🤖 Generated with Claude Code |
Keeps main's builder agent, stdin redirect and mktemp template in every run block, with the CLI resolved through the resolver. The workspace, link and sign-in commands from main also go through the resolver, and commands the user types name `altimate`. Releases as 1.1.1, since 1.1.0 is already on main. Install notes now say npm and Homebrew expose both names and only older curl and PowerShell installs lack `altimate-code`. The review template no longer ends in a complete command. The resolver test fails on bare CLI command lines, covers a non-executable `altimate` with no fallback, and runs under zsh. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
hkaltai
changed the title
|
Thanks. Replies to the minor findings and nits; the three major findings are answered inline. All fixes are in 2c8423c, and the Codex-side ones are in altimate-codex-plugin#5 (54196eb). Minor
Nits
Not tied to a diff line: this PR now merges after #7, so #7's run-block fixes are kept, as described in the inline reply. The version switch for users with both names is listed under Limits (altimate-code#824). The end-to-end Claude Code check with only |
sahrizvi
left a comment
sahrizvi
left a comment
There was a problem hiding this comment.
Consensus re-review at 2c8423c: minor findings and nits
Reviewed by 5 models: Claude, GPT 5.3 Codex, DeepSeek V4 Pro, Grok 4.3 and Qwen 3.6 Plus. The resolver-order finding (vs codex#5) is inline and non-blocking. bash tests/resolve-cli.sh and zsh tests/resolve-cli.sh both pass locally.
Verdict: approve. The resolver-order item inline is non-blocking: please finish porting dc86f54 here as you planned, ideally before both plugins release. Thanks for the thorough follow-up: Majors 1–3 from the last round are fixed, and so are Minor 1 and Nits 1, 2, 3 and 5. The merge with #7 is clean. --agent builder, mktemp "${TMPDIR:-/tmp}/altimate-result.XXXXXX" and < /dev/null are in every run block, #7's 1.1.0 CHANGELOG section is untouched, and the workspace, link and auth commands go through the resolver.
Minor
- "
altimate-codeon npm installs older than v0.7.1" is wrong. Every publishedaltimate-coderelease on npm from 0.4.7 to 0.7.1 declares both bins (npm view altimate-code@0.6.0 bin). altimate-code's v0.7.1 notes say the rename toaltimatewas "for the curl path only". The installs that have onlyaltimate-codeare standalone (curl/PowerShell) installs from before v0.7.1, so those users are told to type! altimate …and the fallback note points them at npm. It appears inskills/altimate-code/SKILL.md:125,141-144,152,README.md:32,50,77-82,commands/review.md:69andskills/review/SKILL.md:83. Related: CHANGELOG 1.1.1 bullet 2 (CHANGELOG.md:9) saysaltimateis the name "which every install method provides", which is also false for those installs. Suggest using codex#5's wording: "curl and PowerShell installs from v0.7.1 on may expose onlyaltimate, and installs older than v0.7.1 expose onlyaltimate-code". After the reorder, use "(altimateon installs withoutaltimate-code)". (DeepSeek, Claude; verified against the npm registry) - The bare-invocation guard only matches at line start (
tests/resolve-cli.sh:38). It misses chained forms likegh pr checkout 1 && altimate-code review(the shape the review files use, currently correctly through"$ALTIMATE_BIN") andTASK=x; altimate run …. The reply's "fails on any command line … that calls" overstates it. Suggest scanning fenced```bashblocks for(^|[;&|(][[:space:]]*)altimate(-code)?([[:space:]]|$), or at least allowing&&/;prefixes. (Claude, GPT 5.3 Codex) tests/resolve-cli.shhas drifted from codex#5 again. codex#5 added abroken-altimate-codestub and cases plus a foreignaltimateahead of a realaltimate-code, and itsbothcase expectsran altimate-code. The PR body's "matches altimate-codex-plugin#5 apart from per-file block counts" no longer holds. Port it with the reorder. (Qwen, DeepSeek, Claude)
Nits
skills/altimate-code/SKILL.md:130: "Open it in the browser" runs"$ALTIMATE_BIN" workspace statuswithout< /dev/null, unlike the other three workspace bullets. (Claude, Qwen)- Failure-row label order:
README.md:76,commands/review.md:68andskills/review/SKILL.md:82say "neitheraltimate-codenoraltimate", whileskills/altimate-code/SKILL.md:140and codex#5 say "neitheraltimatenoraltimate-code". (DeepSeek) README.md:33-34: double blank line. (Claude)- The end-to-end Claude Code check with only
altimateinstalled is still unchecked in the test plan.
Not tied to a diff line
- Cross-repo, outside this PR: codex#5 still has
mktemp -t altimate-result.XXXXXX.md, no< /dev/nullon its runs, and thefast-edit/analyst/builderpersona selection, all of which #7 fixed here. If the same CLI behaviour applies under Codex, it needs its own #7-equivalent change. (Qwen) - Users with both names from different installs: this goes away with the reorder (inline).
🤖 Generated with Claude Code
| <user's task, verbatim> | ||
| ALTIMATE_TASK | ||
| )" | ||
| for ALTIMATE_NAME in altimate altimate-code; do |
There was a problem hiding this comment.
[Non-blocking] The resolver order now differs from altimate-codex-plugin#5
This loop tries altimate first and fails with (tried altimate, altimate-code). codex#5 dc86f54 ("prefer altimate-code over altimate") now tries altimate-code first and fails with (tried altimate-code, altimate). Its docs say "the lookup tries altimate-code first, because no other tool uses that name", and its recovery text says "altimate-code (altimate on installs without altimate-code)". Its both test expects ran altimate-code. The two plugins ship as one change set, so with an unrelated altimate on PATH, or two installs of different versions, Claude Code and Codex now run different binaries.
The reply on this thread ("both plugins already use the same order") was written 14 seconds before dc86f54 landed. Your codex#5 comment says #8 would get "the same reorder, the same doc wording, the broken-altimate and foreign-altimate test cases, the failure-table label and the CHANGELOG text". That isn't in 2c8423c yet.
Suggested follow-up (not blocking this approval): port dc86f54. Flip all 7 loops and error strings. Update step 1 in both skills and both commands. Update the recovery parentheticals, CHANGELOG 1.1.1, README.md:32 and the tests (both → ran altimate-code, plus the broken-altimate-code and foreign-altimate cases). Update the PR title and the body's Before/After, Limits and Spec. Then diff the resolver blocks and tests/resolve-cli.sh across the two repos.
Consensus: Claude, GPT 5.3 Codex, DeepSeek V4 Pro, Qwen 3.6 Plus, Grok 4.3 (after convergence)
2 participants
What / How
Since v0.7.1 the CLI's canonical binary is
altimate. npm (npm install -g altimate-code) and Homebrew installs expose bothaltimateandaltimate-code, but curl and PowerShell installs made before the installers add analtimate-codealias (AltimateAI/altimate-code#1562, open) expose onlyaltimate. The plugin only ever ranaltimate-code, so on those installs it reported the CLI as missing and every delegated run failed.altimate-code,review) and both slash commands (/altimate-code:altimate,/altimate-code:review) now resolves the binary asaltimate, the canonical name every install method provides, and falls back toaltimate-codefor npm installs older than v0.7.1. The lookup sits in the same shell call as the run, because each Bash tool call starts a fresh shell.!namealtimate, withaltimate-codefor npm installs older than v0.7.1.plugin.jsonandmarketplace.json, with a 1.1.1 CHANGELOG entry. 1.1.0 is fix: delegated runs no longer hang; route workspace questions; real agent and command names (1.1.0) #7's release, already onmain; this branch mergesmainand keeps fix: delegated runs no longer hang; route workspace questions; real agent and command names (1.1.0) #7'sbuilderagent, stdin redirect andmktemptemplate in every run block.Before / After
main, 1.1.0)altimate)altimateand runs italtimate-codealtimate, the same CLI under its canonical namealtimate-code)altimate-codealtimate-code, no changealias altimate-code=altimatealtimate-code, even if it is the older copyaltimate, the canonical name; which copy of it comes first on PATH is still up to the install layout (AltimateAI/altimate-code#824)Test plan
altimate→ runsaltimate; both → runsaltimate; onlyaltimate-code→ runsaltimate-code; neither → reports the CLI as not installed.tests/resolve-cli.shpasses when run with bash and with zsh. It checks that every copy of the resolver is identical, that no command line calls the CLI by name, and that the resolver ignores aliases and shell functions, skips a non-executablealtimate(falling back, or exiting 127 with nothing else installed), resolves relative PATH entries, and exits 127 when neither binary is found. The test file matches altimate-codex-plugin#5 apart from per-file block counts.plugin.jsonandmarketplace.jsonparse as JSON.altimateon PATH: install the plugin, send a warehouse prompt, confirm the skill delegates and the run completes.Limits
altimateis on PATH, the plugin runs it, even whenaltimate-codeis also installed, becausealtimateis tried first. The upstream installer makes the same assumption.altimateon PATH wins, even if older. That is an upstream install-layout issue (ux: warn at startup if multiple altimate binaries are on $PATH altimate-code#824), not handled here.Spec
Criteria:
altimate(noaltimate-code) on PATH, both skills and both slash commands detect the CLI as installed and invokealtimate run/altimate reviewinstead of reporting it as missing.altimateandaltimate-codeon PATH, the plugin invokesaltimate; with onlyaltimate-codeon PATH, it invokesaltimate-code.workspace status,workspace listandlink, goes through the resolver; no command line in them callsaltimateoraltimate-codeby name.plugin.jsonandmarketplace.jsonboth declare version 1.1.1, and the CHANGELOG has a 1.1.1 entry.Catalog: none
🤖 Generated with Claude Code