`list --global` finds nothing when packages are installed globally with pnpm 11

detectGlobalNodeModules と scanForIntents から始め、INTENT_GLOBAL_NODE_MODULES のオーバーライドと pnpm root -g の結果がどのように利用されているかを確認します。pnpm ls -g --json --depth 0 を使って重複を排除した node_modules のルートを導出し、既存のフォールバックを維持したうえで、pnpm 11 のグローバルパッケージとレガシーレイアウトの両方が検出されることを検証します。

--global / --global-only comes back empty for me even though I have an intent-enabled package
installed globally with pnpm. Local project scanning works perfectly, so this is only the global path.

I have @tanstack/cli 0.70.0 installed globally, and it ships 5 skills:

$ find -L "$(pnpm root -g)" -name SKILL.md | wc -l
5

But intent doesn't see any of them:

$ pnpm dlx @tanstack/intent list --global-only --debug
Debug: intent list
  scope: global
  packages: 0
  skills: 0
  packageJsonReadCount: 0
No intent-enabled packages found.

packageJsonReadCount: 0 was the clue — it isn't finding some packages and skipping others, it
never opens a single file.

It looks like it comes from detectGlobalNodeModules(), which runs pnpm root -g and treats the
output as a directory to scan for packages. That held up to pnpm 10, where you'd get
~/Library/pnpm/global/5/node_modules. pnpm 11 reorganised global installs so each package lives in
its own isolated directory, and pnpm root -g now returns the parent of those:

$ pnpm root -g
/Users/me/Library/pnpm/global/v11

$ ls /Users/me/Library/pnpm/global/v11
d74d-<timestamp>-<hash>   # @tanstack/cli
d74d-<timestamp>-<hash>   # some-other-global-cli
...

Each of those has its own node_modules, so the real location is
<root>/<dir>/node_modules/@tanstack/cli. Scanning <root> itself finds nothing.

Pointing the env override at one of them confirms it:

$ INTENT_GLOBAL_NODE_MODULES=~/Library/pnpm/global/v11/<dir>/node_modules \
    pnpm dlx @tanstack/intent list --global-only
1 intent-enabled package, 5 skills

That's only a workaround for one package at a time, since under pnpm 11 there's no single global
node_modules to point at.

Suggested fix

Two parts, since the root cause is really that the global scope is assumed to be a single directory.

1. Let global detection return several roots. Under pnpm 11 there genuinely are N of them, one
per installed package, so nodeModules.global needs to become a list that scanForIntents iterates
(deduped by real path, since a shared store can alias).

2. Ask pnpm for the paths instead of guessing them. pnpm ls -g --json --depth 0 reports a
resolved path for every global package, so the layout never has to be inferred:

[{ "path": "…/global/v11",
   "dependencies": {
     "@tanstack/cli": {
       "version": "0.70.0",
       "path": "…/global/v11/<dir>/node_modules/@tanstack/cli" } } }]

Taking each dependency's path up to and including the last node_modules segment, then deduping,
gives exactly the set of roots to scan:

function pnpmGlobalRoots() {
  const out = execFileSync("pnpm", ["ls", "-g", "--json", "--depth", "0"], {
    encoding: "utf8",
    stdio: ["ignore", "pipe", "ignore"],
    timeout: GLOBAL_NODE_MODULES_COMMAND_TIMEOUT_MS,
  });
  const marker = `${sep}node_modules`;
  const roots = new Set();
  for (const importer of JSON.parse(out)) {
    for (const info of Object.values(importer.dependencies ?? {})) {
      const i = info?.path?.lastIndexOf(marker) ?? -1;
      if (i !== -1) roots.add(info.path.slice(0, i + marker.length));
    }
  }
  return [...roots];
}

Keep the existing pnpm root -g result as a fallback if that call throws or returns nothing. The
nice property is that it needs no version sniffing — on pnpm 10 and earlier every package resolves
under the one global node_modules, so the set collapses to a single root and behaviour is
unchanged.

I ran that derivation against my own install to check it. It produces 6 roots, and scanning them all
finds what's actually there:

root	found
1	@tanstack/cli — 5 skills
3	@playwright/cli — 1 skill
2, 4, 5, 6	nothing

So 2 packages / 6 skills, versus 0 / 0 today. Worth noting @playwright/cli ships a skill too —
the current behaviour hides more than just the TanStack CLI.

3. Minor, while you're in there: INTENT_GLOBAL_NODE_MODULES could accept a
path.delimiter-separated list. Right now it's a single path, so under pnpm 11 the escape hatch can
only ever reach one global package at a time.

Not a big problem for me in practice, since project dependencies work fine and that's where skills
normally live. The main annoyance is that the empty result is indistinguishable from "these global
packages genuinely ship no skills".

A couple of other projects have hit the same pnpm 11 change, in case it's useful context:
denoland/deno#34451 (a hardcoded global/5 path stopped resolving) and pnpm/pnpm#11762, which
describes the isolated-global-package layout.

Environment: @tanstack/intent 0.3.6, pnpm 11.17.0, node 24.18.0, macOS 26.5.1 (arm64)