Platform integration: shipping Houston with Link, four upstream asks (per-arch binaries, manifest URL, viem isolation, SKILL versioning)

[ja-818]

Context

Hi! We're Houston, a desktop platform for non-technical founders to run AI agents (a bit like Shopify-for-AI). We want to ship Link as a first-class payments surface in Houston so any agent a user creates can transact on their behalf the moment they connect their wallet.

We're already building toward a launch-week integration on our side (system prompt guidance, sidebar entry, bundled SKILL.md). While going through the integration we surfaced a few small upstream changes that would meaningfully reduce the maintenance burden for Houston (and any other agent platform that wants to bundle link-cli).

This issue tracks four asks. We've sent code for the first one; happy to send code for the others if directions are agreeable.

1. Ship per-arch standalone binaries with each release

Why it matters: Houston ships a signed/notarized macOS .app bundle. Our existing CLI integrations (codex, composio, claude-code) are all single-file binaries we download, sha256-verify, and stage into Resources/bin/ at build time. link-cli ships only on npm today, which means any platform that wants to bundle it has to maintain its own bun build --compile (or pkg) pipeline against your npm package, hoping each release continues to compile cleanly under whichever runtime they picked. Shipping binaries upstream solves that for everyone in one place.

What we built: [#73]. Adds a release-binaries.yml workflow that triggers on release.published and attaches single-file binaries for darwin-arm64, darwin-x64, linux-x64, windows-x64 plus a manifest.json (version, sha256s, download URLs) to the same GitHub release that changesets/action already publishes. ~200 LOC including comments.

Verified locally: all four targets cross-compile from a single macOS arm64 host via oven-sh/setup-bun@v2, the resulting binaries pass --help, --version, and exercise the viem-backed mpp decode path successfully.

2. Pull viem out of the hot path (or make it optional)

Why it matters: #5 (ERR_MODULE_NOT_FOUND: missing viem dependency) shows viem is already a packaging trip-hazard. For platforms doing standalone bundling, viem's WASM + dynamic import pattern is the single dep most likely to break a future bun build --compile (or any tree-shake/bundle path). Most users of link-cli won't ever hit the SPT/MPP path — virtual cards work everywhere — so paying for viem at install time is heavyweight.

Proposal: Either (a) lazy-import viem only inside mpp decode / mpp pay so the static bundle doesn't pull it in unless the SPT path executes, or (b) split a separate @stripe/link-cli-mpp peer/optional dep so the core CLI ships without it.

Status: Not opening a PR speculatively because the right shape depends on what your SDK roadmap is. Happy to send one if you indicate which direction you'd accept.

3. Stable manifest URL with pinned checksums per release

Why it matters: Same shape as claude-code's https://storage.googleapis.com/.../manifest.json and codex's release manifest. Lets downstream consumers pin a single URL, fetch one JSON, get the per-target download URL + sha256, verify, and install. Today that's possible via gh release view --json assets, but a stable shaped JSON is friendlier than scraping releases.

What we built: Bundled into the same PR as #1 above. Each release will ship a manifest.json asset alongside the binaries:

{
  "version": "0.4.2",
  "generated_at": "...",
  "binaries": {
    "darwin-arm64": { "file": "...", "sha256": "...", "url": "..." },
    "darwin-x64":   { ... },
    "linux-x64":    { ... },
    "windows-x64":  { ... }
  }
}

4. Optional version metadata in SKILL.md

Why it matters: Your own CLAUDE.md calls out that "README, SKILL.md, schema.ts can easily drift apart." For platforms that bundle the SKILL into agent skill folders independently from the CLI binary (Houston does this so agents can discover the skill via progressive discovery before anyone has run link-cli), a version-mismatch between bundled SKILL and runtime CLI fails at the worst possible moment, mid-spend-request.

Proposal: Add optional min_cli_version / max_cli_version fields to skills/create-payment-credential/SKILL.md frontmatter. Consumers that bundle the skill validate compatibility at bundle time; consumers that don't can ignore the fields. No CLI-side enforcement required.

Status: Tiny PR (~10 LOC frontmatter + a paragraph in CLAUDE.md). Holding off until you confirm interest, since this is the least universal of the four asks.

---

Happy to iterate on any of these. We'd love to be a launch-week reference integration for Link — a polished "click here to connect your wallet, agent can now buy things on your behalf" flow surfaced on the sidebar of every Houston user's desktop. Anything we can do to make that smoother on your end too, let us know.

Authored on behalf of Houston. cc @stevekaliski-stripe @danhill-stripe @jlaustripe @yanlamko

[sandrasnapk-max]

#72