fix: install Pinecone CLI as a Homebrew cask (formula disabled 2026-03-30)

[mcdgavin]

Problem

The "Install the Pinecone CLI (Optional)" instructions no longer work. The pinecone-io/tap/pinecone formula was disabled on 2026-03-30 when the CLI migrated to a cask, so following the README today produces:

==> Tapping pinecone-io/tap
Tapped 1 cask and 1 formula (22 files, 112.5KB).
Warning: Treating pinecone-io/tap/pinecone as a formula. For the cask, use
pinecone-io/tap/pinecone or specify the `--cask` flag.
Error: pinecone-io/tap/pinecone has been disabled because it has migrated to a
cask. Reinstall with: brew uninstall pinecone-io/tap/pinecone && brew install
--cask pinecone-io/tap/pinecone! It was disabled on 2026-03-30.

Verified against the tap: Formula/pinecone.rb carries disable! date: "2026-03-30" pointing at the cask, and Casks/pinecone.rb is the live GoReleaser-generated cask (currently 1.0.1). pinecone-io/cli's README already documents the cask form.

Fix

Switch every install instruction in the plugin to a single fully qualified command:

brew install --cask pinecone-io/tap/pinecone

File	Change
README.md	single --cask command + upgrade note
hooks/pinecone-api-key-check.sh	session-start CLI guidance now emits the --cask command

skills/cli/SKILL.md and skills/help/SKILL.md carry the same stale command but are rendered from pinecone-io/skills, where the maintainers are carrying the fix (pinecone-io/skills#33). Left for the sync.

The upgrade note tells anyone who installed before the migration to run brew uninstall pinecone-io/tap/pinecone first, since Homebrew refuses to install the cask over the disabled formula.

The hook matters most: when pc is not installed it injects the install command into Claude's context at every session start, so the agent was confidently repeating a command that errors out.

Why drop the separate brew tap step

• brew install taps automatically for a fully qualified user/repo/name (cmd/install.rb calls tap.ensure_installed! on each named argument).
• Since Homebrew 6.0.0, non-official taps require explicit trust. Installing a fully qualified cask trusts only that cask; the tap-then-short-name form now additionally needs brew trust. Homebrew's Tap Trust docs give brew install --cask user/repository/cask as the canonical form.
• This matches what peer vendor taps document (e.g. HashiCorp brew install hashicorp/tap/terraform, Supabase brew install supabase/tap/supabase).

Related

• fix: install Pinecone CLI as a Homebrew cask (formula disabled 2026-03-30) skills#33 is the same fix at the source of the sync-managed skill files. The maintainers have said they will incorporate it.
• fix: install Pinecone CLI as a Homebrew cask (formula disabled 2026-03-30) pinecone-cursor-plugin#24 fixes that plugin's README.

Follow-up, not in this PR

The hook detects the CLI with command -v pc, so a user who installed the old formula before 2026-03-30 still reads as "installed" and never sees the migration note; their next brew upgrade fails on the disabled formula with no warning from the plugin. A one-line readlink check for a Cellar/pinecone target would catch it. Left out here to keep this PR to the install string; it is #47, independent of this one.

Verification

• Clean-state run on Homebrew 6.0.22, starting with the tap untapped, no trust entries, and no cask installed. brew install --cask pinecone-io/tap/pinecone alone tapped pinecone-io/tap, printed Trusted cask pinecone-io/tap/pinecone (item-level trust, not whole-tap), installed cask 1.0.1, and pc version prints 1.0.1. Exit 0. Note the tap still ships the disabled formula alongside the cask (Tapped 1 cask and 1 formula), which is why the old command produced the confusing "Treating ... as a formula" warning before failing.
• bash -n hooks/pinecone-api-key-check.sh passes, and running the hook with no PINECONE_API_KEY emits the new --cask command.
• grep -rn "brew tap" README.md hooks returns nothing; grep -rn "brew install" README.md hooks shows only the --cask form (plus the unrelated brew install uv).
• CHANGELOG.md is left alone since release.yml generates the entry from this PR's commit headline at merge time.