Repository navigation
Conversation
`altimate` is the CLI's canonical name since v0.7.1. The npm package exposes both `altimate` and `altimate-code`, but the curl, Homebrew and PowerShell installers expose only `altimate`, so the plugin reported the CLI as missing on standalone installs. Every CLI invocation in the skills and slash commands now resolves the binary in the same shell call, trying `altimate` first and falling back to `altimate-code`, ignoring aliases and shell functions. It exits 127 with a clear message before mktemp when neither is installed, which replaces the separate `command -v` pre-check. Install guidance lists both the npm and curl installs. Adds tests/resolve-cli.sh, which checks every resolver copy is identical and resolves correctly in bash and zsh. Bumps the plugin to 1.1.0. 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 shell command. 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. Instructions say "shell command" rather than "Bash call", since Codex runs a generic shell. 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` with and without a legacy fallback. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (10 files)
Previous Review Summaries (2 snapshots, latest commit 54196eb)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 54196eb)Status: No Issues Found | Recommendation: Merge Files Reviewed (10 files)
Previous review (commit c941ad4)Status: No Issues Found | Recommendation: Merge Files Reviewed (10 files)
Reviewed by gemini-4-argon · Input: 74.8K · Output: 1.1K · Cached: 152.9K |
sahrizvi
left a comment
sahrizvi
left a comment
There was a problem hiding this comment.
Consensus review (5 models: Claude, GPT 5.3 Codex, DeepSeek V4 Pro, Grok 4.3, Qwen 3.6 Plus; converged 5/5 after 2 rounds). Two MAJOR findings are inline below. Minor issues, nits and cross-repo notes are in a separate PR comment.
Cross-plugin check: all six resolver blocks here are byte-identical to altimate-claude-plugin#8 (same candidates and order, the same [ -x ] check, exit 127, message, and resolve-before-gh pr checkout), so at runtime the two plugins resolve the CLI identically. Both majors below apply to both plugins.
| <user's task, verbatim> | ||
| ALTIMATE_TASK | ||
| )" | ||
| for ALTIMATE_NAME in altimate altimate-code; do |
There was a problem hiding this comment.
MAJOR (Design/Security): try altimate-code first, then fall back to altimate.
altimate is a generic name, and the PR's own Limits section says an unrelated altimate on PATH gets run even when altimate-code is installed. With altimate-code#1562, every install method exposes altimate-code:
- npm
bin - the Homebrew formula (
bin.install_symlink "altimate" => "altimate-code"inpackages/opencode/script/publish.ts) - the curl
link_aliassymlink - the PowerShell
.cmdand sh shims
So the unambiguous name is always available. Trying altimate first hands the user's task text (with --yolo --output --dir) to whichever altimate comes first on PATH, whether that's a foreign tool or an older standalone build (altimate-code#824).
Reordering doesn't strand standalone installs from v0.7.1 up to the #1562 release, which only have altimate: the loop still falls back to it. The installer probes altimate first only to read --version, so that order doesn't decide which binary should receive task text.
for ALTIMATE_NAME in altimate-code altimate; do
ALTIMATE_BIN="$(unalias "$ALTIMATE_NAME" 2>/dev/null; unset -f "$ALTIMATE_NAME" 2>/dev/null; command -v "$ALTIMATE_NAME")"
[ -x "$ALTIMATE_BIN" ] && break || ALTIMATE_BIN=
done
[ -n "$ALTIMATE_BIN" ] || { echo "altimate-code CLI not found (tried altimate-code, altimate)" >&2; exit 127; }This applies to all 6 blocks (commands/altimate.md:34,55, commands/review.md:24, skills/altimate-code/SKILL.md:58,94, skills/review/SKILL.md:35) and the same blocks in altimate-claude-plugin#8.
In tests/resolve-cli.sh:
- the
bothcase should expectran altimate-code - add a case with a foreign executable
altimateearlier on PATH next to a realaltimate-code
The README/CHANGELOG/PR-body wording needs the same update. Note that the claude-plugin#8 title ("altimate-code or altimate") still describes the order from before 2c0f11f flipped it.
Flagged by: Claude, DeepSeek V4 Pro, GPT 5.3 Codex
There was a problem hiding this comment.
Fixed in dc86f54. All six resolver blocks now try altimate-code first and fall back to altimate, and the not-found message reads (tried altimate-code, altimate). In tests/resolve-cli.sh the both case now expects ran altimate-code. I added a case with a foreign executable altimate ahead of a real altimate-code on PATH (expects altimate-code) and a case with a non-executable altimate-code ahead of altimate (expects altimate). The README, CHANGELOG, PR body and Spec criteria now describe the new order. The test 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.** There is no separate check: the invocation below resolves the CLI first, ignoring aliases and shell functions, and exits 127 with `altimate-code CLI not found` before doing anything else. 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 the invocation exits with `altimate-code CLI not found`, jump to "Failure modes" below and stop. |
There was a problem hiding this comment.
MAJOR (Documentation): "standalone curl/Homebrew/PowerShell installers expose only altimate" is already false for Homebrew, and #1562 makes it false for curl and PowerShell.
- Homebrew: the formula already symlinks
altimate-code. - curl / PowerShell: altimate-code#1562 adds
altimate-code, and rewrites the CLI README to say "plus analtimate-codealias — the same two names the npm install exposes".
These lines are model-facing instructions, and they're also the stated rationale for the change. After the change set ships, the plugins will contradict the CLI's own docs.
"Only altimate" was also never true for pre-v0.7.1 standalone installs, which had ~/.altimate-code/bin/altimate-code. The recovery text "altimate-code on npm installs older than v0.7.1" leaves those installs out.
Suggested wording:
npm, Homebrew and current standalone installers expose both
altimateandaltimate-code. Standalone installs from v0.7.1 up to the #1562 release expose onlyaltimate; re-running the installer addsaltimate-code.
The same claim appears in:
commands/altimate.md:10commands/review.md:21skills/review/SKILL.md:32README.md:72plugins/altimate-code/README.md:25,28CHANGELOG.md:10- the matching files in altimate-claude-plugin#8
Flagged by: Claude, DeepSeek V4 Pro, GPT 5.3 Codex (GPT and Qwen noted MAJOR vs MINOR is debatable, because runtime behaviour is unaffected)
There was a problem hiding this comment.
Fixed in dc86f54. altimate-code#1562 is still open, so I didn't describe current curl/PowerShell installers as exposing both names. The model-facing note in all four skill and command files now reads: "npm and Homebrew installs expose both altimate and altimate-code; curl and PowerShell installs from v0.7.1 on may expose only altimate, and installs older than v0.7.1 expose only altimate-code." That covers pre-v0.7.1 standalone installs too. Recovery text now says "Run altimate-code (altimate on installs without altimate-code)" and no longer singles out npm. The plugin README and CHANGELOG were updated to match.
Consensus review: minor issues, nits and cross-repo notesPanel: Claude, GPT 5.3 Codex, DeepSeek V4 Pro, Grok 4.3, Qwen 3.6 Plus. Converged 5/5 after 2 rounds. The two MAJOR findings (resolver order, and the stale "standalone exposes only Verdict: REQUEST CHANGES. The two majors block. The minors below can land here or as fast follow-ups. Minor
Nits
Missing tests
What's done well
🤖 Generated with Claude Code |
npm and Homebrew installs expose both `altimate` and `altimate-code`; 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 and runs under zsh. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`altimate` is a generic name another tool may own, while `altimate-code` is unambiguous. The resolver now tries `altimate-code` first and falls back to `altimate` for standalone installs that expose only that name. Install-name notes, recovery messages and the README now describe the current installers accurately, and the test covers a foreign `altimate` ahead of a real `altimate-code`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thanks for the consensus review. Both MAJORs are fixed in dc86f54 (replies inline). On the minors and nits:
Missing tests: added the foreign |
|
@kilo-code-bot Thanks, nothing to act on from this summary. Since then, dc86f54 has changed the resolver order to try |
sahrizvi
left a comment
sahrizvi
left a comment
There was a problem hiding this comment.
Consensus re-review at dc86f54 (5 models: Claude, GPT 5.3 Codex, DeepSeek V4 Pro, Grok 4.3, Qwen 3.6 Plus; converged 5/5 in 1 round). Verdict: approve. Both earlier majors are fixed in this repo. The cross-repo order mismatch with altimate-claude-plugin#8 is inline and non-blocking. bash tests/resolve-cli.sh passes in bash and zsh in both plugins.
Status of earlier findings, minors and nits
Earlier findings at dc86f54
| # | Finding | Status |
|---|---|---|
| 1 | altimate tried before altimate-code |
Fixed here; still open in claude-plugin#8 (inline, non-blocking) |
| 2 | "standalone exposes only altimate" |
Fixed. The model-facing wording is accurate and hedged with "may" |
| 3 | Cross-plugin drift | Partly fixed. #8 gained the broken-altimate case and the bare-call grep, but the order, wording and tests now differ (inline) |
| 4 | Test not enforced | Partly fixed (grep added). CI is deferred, which is fine |
| 5 | Empty $ALTIMATE_BIN when split |
Deferred, fine |
| 6 | Root README "One skill" | Fixed |
| 7 | session list order |
Fixed by the reorder |
| 8 | Windows/PowerShell note | Deferred, fine (see Minor 1) |
| Missing test | Foreign altimate first |
Added (tests/resolve-cli.sh:73), plus the broken-altimate-code-first case |
Minor
- Preferring
altimate-codecan now pick a stale or inert binary on Windows-adjacent setups. Git Bash: the pre-#1562 installer removes a pre-v0.7.1altimate-codeonly whenos != windows, so an upgraded install can still have~/.altimate/bin/altimate-code.exenext toaltimate.exe, and MSYScommand -v altimate-codepicks the stale build. WSL: #1562's extensionlessaltimate-codeshim in the Windows install dir is on WSL's PATH by default and passes[ -x ]. Under Linux it prints "this is the Windows build" and exits 127, which matches no failure-table row. Re-running the #1562 installer fixes both. The resolver behaves as designed; this is install layout. Suggest a Limits bullet and a failure-table row saying to re-run the installer. (This is inferred from the installer code and was not reproduced.) (Claude; DeepSeek V4 Pro and Qwen 3.6 Plus agreed) - README curl comments (
README.md:78,plugins/altimate-code/README.md:25: "standalone binary; exposesaltimate") are true today but will undersell #1562 once it ships. Either word them as "andaltimate-codefrom ", or track a follow-up tied to that release. Same in claude-plugin. (GPT 5.3 Codex, Grok 4.3, DeepSeek V4 Pro, Claude)
Nits
commands/review.md:29,skills/review/SKILL.md:40: the<the scope command chosen below, run through "$ALTIMATE_BIN">placeholder sits inside a bash fence. The old"$ALTIMATE_BIN" review # plus any scope/flags from belowwas a runnable default. Consider"$ALTIMATE_BIN" review # replace with the scope command from the table below.- The preferred name is mixed: install messages say "run
altimateonce", while recovery rows lead withaltimate-code. The failure-table label reads "neitheraltimatenoraltimate-code", the reverse of the try order.CHANGELOG.md:12"Recovery messages namealtimatefor installs withoutaltimate-code" undersells that they now lead withaltimate-code. - Add
expect "$sh" "$STUBS/broken-altimate-code" '' 127 'altimate-code CLI not found (tried altimate-code, altimate)'to mirror thebroken-altimatecase. - The PR title still reads "resolve CLI as altimate or altimate-code", the old order. The body's "same version as the Claude plugin release" is stale: #8 is now 1.1.1.
- The bare-call guard (
tests/resolve-cli.sh:38) is anchored at line start and limited to 4 files, so it missesgh pr checkout 1 && altimate-code review,command -v altimate-codeand new files. This fits the CI follow-up.
What's done well
- The reorder is applied uniformly across all 6 blocks, the message, the tests, the docs, the CHANGELOG and the Spec.
- The install-name note is precise (Homebrew, v0.7.1, pre-v0.7.1) and hedged while #1562 is open.
- The new tests cover the exact adversarial case behind the reorder.
🤖 Generated with Claude Code
| <user's task, verbatim> | ||
| ALTIMATE_TASK | ||
| )" | ||
| for ALTIMATE_NAME in altimate-code altimate; do |
There was a problem hiding this comment.
Non-blocking (cross-repo): this order is right, but altimate-claude-plugin#8 still has the old one, so the change set currently resolves the CLI in opposite orders.
At 2c8423c, claude-plugin#8 still has for ALTIMATE_NAME in altimate altimate-code and (tried altimate, altimate-code) in all 7 blocks (commands/altimate.md:27,49, commands/review.md:25, skills/altimate-code/SKILL.md:52,90,117, skills/review/SKILL.md:35). On a machine with both names, or with a foreign altimate earlier on PATH, this plugin runs altimate-code and the Claude plugin runs altimate. The issue this commit fixes is still live there.
Still to port to #8:
- the order and message in all 7 blocks;
- tests:
both→ran altimate-code, plus the foreign-altimate-first and broken-altimate-code-first cases; - the 3-clause install-name sentence ("…installs older than v0.7.1 expose only
altimate-code") and the "triesaltimate-codefirst, because no other tool uses that name" sentence; - recovery and
session listtext (altimate-code(altimateon installs withoutaltimate-code)); - the 1.1.1 CHANGELOG bullet, which still says "resolve the CLI as
altimate, its canonical name"; - the PR title.
After that, the two tests/resolve-cli.sh files should differ only in the SKILL.md:2/:3 block count. Not blocking this approval, but ideally the two land together once #8 matches.
2 participants
What / How
Since v0.7.1 the CLI also ships as
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. This plugin only ever ranaltimate-code, so on those installs it reported the CLI as missing and every delegated run failed.Same fix as AltimateAI/altimate-claude-plugin#8, ported to the Codex plugin.
CLI resolution: every shell command in both skills (
altimate-code,review) and both slash commands (/altimate-code:altimate,/altimate-code:review) resolves the binary asaltimate-code, a name no other tool uses, and falls back toaltimatefor standalone installs that expose only that name. The lookup:alias altimate-code=altimatecan't be captured as the binary path;altimate-code CLI not found (tried altimate-code, altimate)beforemktempwhen neither is installed. This replaces the separatecommand -vpre-check.It sits in the same shell command as the run, because each shell command starts fresh.
PR reviews:
gh pr checkout <n> && "$ALTIMATE_BIN" reviewruns after the resolver in the same shell command, so a missing CLI stops before the user's branch is switched.Install and recovery guidance: not-installed messages, troubleshooting rows and both READMEs list the npm and the curl install. Recovery messages say to run
altimate-code, oraltimateon installs withoutaltimate-code.Test:
tests/resolve-cli.shchecks every resolver copy and its behaviour in bash and zsh (see Test plan).CONTRIBUTING.mdsays to run it when touching the resolver.Version: 1.0.0 → 1.1.0 in
plugin.json, with a 1.1.0 CHANGELOG entry (same version as the Claude plugin release).Before / After
main, 1.0.0)altimate)altimateand runs italtimate-codealtimate-code, no changealtimate-code)altimate-codealtimate-code, no changealtimate-code CLI not foundand shows the npm and curl install commandsgh pr checkout, so the branch is not switchedaltimate-codeoraltimatealtimateis earlier on PATH thanaltimate-codealtimate-codealtimate-code; the unrelatedaltimatenever receives the taskaltimate-codeoraltimateis earlier on PATHaltimate-code, even if it is the older copyTest plan
tests/resolve-cli.shpasses in bash 3.2 and zsh 5.9 on macOS. It runs each shell without startup files and with only stub directories on PATH, and checks:altimate→ runsaltimate; both →altimate-code; an unrelatedaltimateahead ofaltimate-codeon PATH →altimate-code; onlyaltimate-code→altimate-code; neither → exit 127 with the not-found message;altimateoraltimate-codeare ignored, including with only the legacy binary installed and with nothing installed;altimate-codefalls back toaltimate, a non-executablealtimateis skipped, and exits 127 when there is no fallback;plugin.jsonand.agents/plugins/marketplace.jsonparse as JSON.altimateon PATH: install the plugin, send a warehouse prompt, confirm the skill delegates and the run completes.Limits
altimateis on PATH andaltimate-codeis not installed, the plugin runs that tool.altimate-codeis tried first, so this only affects standalone installs that lack thealtimate-codealias.altimate-codeon 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-code, including when an unrelatedaltimatecomes first on PATH; with onlyaltimate-codeon PATH, it invokesaltimate-code.gh pr checkoutfor a PR review.plugin.jsondeclares version 1.1.0 and the CHANGELOG has an entry for it.Catalog: none
🤖 Generated with Claude Code