Port the blocktank-api LSP skill from Android, and restore the journey commands that need it

[jvsena42]

Problem or use case

The journeys ported in #691 inherited their backend setup commands from Android, where they call a ./lsp helper at the repo root:

./lsp POST /regtest/chain/deposit '{"address":"<addr>","amountSat":100000}'
./lsp POST /regtest/chain/mine '{"count":3}'
./lsp POST /regtest/lightning/pay '{"invoice":"<bolt11>"}'

None of that exists here. On Android, ./lsp is a one-line shim that execs .claude/plugins/blocktank-api/skills/lsp/scripts/lsp.sh — a Claude Code plugin containing an lsp skill, installed via .claude/install-plugins.sh from a repo-local marketplace. bitkit-ios has no .claude/plugins, no marketplace, and no shim.

The commands were removed from the journeys before merge so they would not tell an agent to run something that does not exist, but the underlying need did not go away: every amount-limits journey needs a funded wallet to be meaningful (with a zero balance the caps fall back to the global maximum and the journeys pass for the wrong reason), and the cjit journeys need to pay an invoice and mine blocks.

This is not iOS-specific work in any real sense — both apps talk to the same Blocktank instance. Env.swift points regtest at api.stag0.blocktank.to, which is exactly what the skill defaults to.

Proposed solution

Port the blocktank-api plugin from bitkit-android, keeping the same shape so the two repos stay comparable:

• .claude/plugins/.claude-plugin/marketplace.json — same structure, owner Synonym, one plugin entry.
• .claude/plugins/blocktank-api/ — SKILL.md, references/api-reference.md, scripts/lsp.sh, scripts/pay-invoices.sh.
• .claude/install-plugins.sh — the installer, adapted from the Android one.
• ./lsp — the shim at the repo root.

Then restore the real commands in the journeys, which is the "adapt if necessary" part:

• journeys/amount-limits/README.md — the funding steps currently say the helper is not available here and to fund "however you normally do". Replace with the real ./lsp deposit and mine calls.
• journeys/cjit-notifications/*.xml — three journeys currently say to pay the invoice "however your setup allows". Restore ./lsp POST /regtest/lightning/pay.
• journeys/amount-limits/external-amount-over-max.xml — restore ./lsp GET /info for the peer id, host and port.
• journeys/README.md — the Backend preconditions section explains the gap; replace it with the working commands.

Worth checking while porting: the skill documents its base URL as https://api.stag0.blocktank.to/blocktank/api/v2, and iOS Env.swift uses https://api.stag0.blocktank.to with its own path. Confirm the shim's default resolves to the same endpoints this app actually talks to before relying on it.

Alternatives considered

Documenting curl or docker compose equivalents in each suite README. That works but duplicates knowledge that already exists as a maintained skill on the Android side, and drifts as soon as the API changes.

Leaving it as-is. Acceptable while the journeys are developer assistance rather than a gate, but it means every backend-dependent journey has a manual step the agent cannot perform, which is most of the corpus outside the widgets suite.

Additional context

• Android plugin: https://github.com/synonymdev/bitkit-android/tree/main/.claude/plugins/blocktank-api
• Android shim: https://github.com/synonymdev/bitkit-android/blob/main/lsp
• iOS journeys that need it: amount-limits (all four), cjit-notifications (all three).
• Related: test: port Android journeys to iOS #691 (the port), Add agent instructions for journeys, including cross-platform runs bitkit-android#1188 (the mirror-side agent instructions).

[ovitrif]

Hey @jvsena42 , I had a reply to Ben but as I shared with you via DMs, I removed a duplicate of it without knowing it will also remove the reply. It was saying that as an intermediate solution, agents could use the ../bitkit-android/lsp path, as usually most of us do have a clone of the sibling app at that path.

This setup is a bit better though, although not perfect. A better solution would ensure there can't be drift if one platform needs an updated version of the skill.

Meanwhile I think it's ok to port it to iOS, no worries there, the issue is on point 🙏🏻

[jvsena42]

Hey @jvsena42 , I had a reply to Ben but as I shared with you via DMs, I removed a duplicate of it without knowing it will also remove the reply. It was saying that as an intermediate solution, agents could use the ../bitkit-android/lsp path, as usually most of us do have a clone of the sibling app at that path.

This setup is a bit better though, although not perfect. A better solution would ensure there can't be drift if one platform needs an updated version of the skill.

Meanwhile I think it's ok to port it to iOS, no worries there, the issue is on point 🙏🏻

good idea!