@artblocks/abx-cli 0.7.0 → 0.7.2

package/skill/reference/ecosystem/multichain.md

@@ -0,0 +1,73 @@
+# Multichain integrations
+
+Read only the provider relevant to the idea. Coverage below is the intersection reviewed for ABX:
+Ethereum (`1`), Base (`8453`), Arbitrum One (`42161`), not each provider's full network list.
+Official documentation reviewed 2026-10-30; recheck the chosen tool and network before use.
+This starter catalog is not exhaustive; research other protocols when they fit the project's concept.
+Apply [durability guidance](durability.md): official discovery/build tooling does not need to become
+a dependency of the finished NFT. Prefer same-chain EVM reads with self-contained fallback output.
+
+## OpenSea — discovery and marketplace context
+
+- **Ideas:** research related collections, plan collector-facing metadata and traits, or link to
+  the marketplace from a companion site. Keep the NFT usable without OpenSea; do not recommend live
+  floor-price/indexed-trait API calls in its artwork or core eligibility logic.
+- **Official route:** [agent tools](https://docs.opensea.io/docs/build-with-ai-agents) link its skill,
+  CLI, SDK, and [MCP](https://docs.opensea.io/reference/mcp). Use an existing connection when suitable;
+  adding all surfaces supplies no extra capability by itself.
+- **Data:** **off-chain** discovery, indexed traits, and marketplace API/MCP results. NFT ownership
+  and settlement are **on-chain**, but consuming an indexed response does not give a Solidity hook
+  a contract read. For that route use the NFT/protocol's official contract interfaces directly.
+- **Footprint:** MCP data tools and REST need an API key; MCP handshake/tool discovery does not.
+  [Instant keys](https://docs.opensea.io/reference/api-keys) need no signup but expire; a full key
+  involves the developer account flow. The same key serves MCP and REST. Wallet-scoped tools need
+  additional wallet authentication. Check current limits and renewal rather than creating keys to
+  evade quotas.
+- **Before integrating:** verify the [current chains](https://docs.opensea.io/reference/get_chains)
+  and exact feature. Keep keys server-side. Use ABX metadata commands for canonical state; use
+  OpenSea tools for its projection/orders. Its SeaDrop deployment tools are not an ABX deploy lane.
+
+## Uniswap — swaps, liquidity, and pool-informed art
+
+- **Ideas:** use a selected pool's same-chain state as a visual input computed in the EVM, with
+  bounded reads and fallback art. Offer swap links in a companion sales app; the NFT's essential
+  rendering should not require a trading API, embedded swap app, or active liquidity position.
+- **Official route:** start with the relevant [Uniswap skill](https://developers.uniswap.org/docs/uniswap-ai/skills)
+  and [integration choices](https://developers.uniswap.org/docs/get-started/quickstart). Reuse its
+  routing, SDKs, and interfaces rather than implementing a swap router.
+- **Data:** **on-chain** pool state can live-augment an ABX renderer or inform hook logic on the
+  same chain. Use the version's official read interfaces (including
+  [v4 StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) where appropriate).
+  **Off-chain** quotes and indexed volume/history suit discovery or a companion app. Do not use
+  them as default live-view inputs; consider an actual bounded on-chain snapshot if relevant.
+  A pool's instantaneous price is not a manipulation-resistant price oracle.
+- **Footprint:** [interface links](https://developers.uniswap.org/docs/trading/custom-interface-links)
+  avoid provisioning a developer API key; execution still needs the collector's wallet. The Trading
+  API needs a developer key. Browser/build-time contract/SDK reads need RPC access; EVM-to-EVM
+  reads do not add an application RPC service. The [iframe embed](https://developers.uniswap.org/docs/trading/embed-app)
+  requires origin allowlisting; reserve it for companion apps, with their own availability expectations.
+- **Before integrating:** select protocol version, chain, pool, and token addresses from the
+  [deployment sources](https://developers.uniswap.org/deployments). Check the exact tool's chain
+  support separately. Read-only pool data, swap execution, liquidity positions, and Uniswap v4 hooks
+  are distinct integrations; a Uniswap hook is not an ABX parameter hook.
+
+## Art Blocks — existing projects and collector communities
+
+- **Ideas:** discover related artists/projects or design a same-chain collector interaction using
+  verified contract state. Link to another work from a companion gallery; do not recommend a hosted
+  generator/media iframe as part of a permanent NFT's essential output. Discovery grants no reuse rights.
+- **Official route:** use the [Art Blocks skills](https://docs.artblocks.io/developer/mcp-server/skills/)
+  and [MCP](https://docs.artblocks.io/developer/mcp-server/quick-start/) for project/token discovery
+  and query workflows. [Token, generator, and media APIs](https://docs.artblocks.io/developer/token-and-generator-apis/)
+  provide published read paths for research or optional companion displays.
+- **Data:** **mixed**. Ownership and some token/script state are **on-chain**, varying by core;
+  inspect the [official core interfaces](https://docs.artblocks.io/developer/core-contract/).
+  API/MCP discovery, generated media, and computed traits are **off-chain** access paths. A published
+  live-view URL is an external service dependency, not preserved artwork or an EVM-readable input.
+- **Footprint:** MCP uses OAuth/browser sign-in; do not assume an ABX Services login authorizes it.
+  Published token/view URLs can suit a companion display without adding an MCP connection. Verify
+  authentication and rate policy for the exact query/API route; do not promise unlimited access.
+- **Before integrating:** carry chain, core address, project, and token identity. On a shared Art
+  Blocks core, collection-wide `balanceOf` is not a project-specific ownership check. Use the
+  official Art Blocks tooling for its contracts; ABX parameter/minter commands target ABX projects.
+  A holder gate on a different chain needs a separate proof design.

package/skill/reference/ecosystem/tokens.md

@@ -0,0 +1,63 @@
+# ERC-20s and token creation
+
+Use for token-informed ABX ideas, an existing token community, or a companion fungible token.
+Official sources reviewed 2026-10-30. Recheck the selected chain, token identity, and tool/version.
+These are discovery routes, not executed ABX integrations. Read only the relevant section.
+
+## Existing tokens as creative inputs
+
+The [ERC-20 standard](https://eips.ethereum.org/EIPS/eip-20) exposes **on-chain** balances, supply,
+and allowances. Prefer a same-chain ABX augment hook or renderer turning a chosen wallet's balance
+into visual variation, with bounded reads and self-contained fallback art. Use external-state
+configure/transfer gates only for an intentional mechanic with lifecycle tests and failure semantics.
+Specify whose balance matters: current NFT owner, configuring wallet, or a fixed community treasury.
+For extension choices use [capabilities.md](../capabilities.md) and [code.md](../code.md).
+
+| Token / chain scope | Official identity and tooling | Example on-chain input / boundary |
+|---|---|---|
+| USDC — Ethereum, Base, Arbitrum One; check each testnet separately | [Circle's contract directory](https://developers.circle.com/stablecoins/usdc-contract-addresses), then the token's verified ERC-20 interface | Treasury balance informs an artwork's density. Distinguish native USDC from bridged variants; reserve reports and redemption access are separate issuer/off-chain concerns. |
+| ARB — Arbitrum One; verify other deployments separately | [Arbitrum Foundation deployment directory](https://docs.arbitrum.foundation/deployment-addresses), then the verified token interface | A holder's balance selects a palette. ERC-20 balance alone does not establish delegated voting power or governance participation. |
+| AERO — Base | [Aerodrome's official contracts and ABIs](https://github.com/aerodrome-finance/contracts) | Treasury or owner balance drives visual variation. AERO and veAERO positions are different assets/interfaces; do not infer locked voting power from an ERC-20 balance. |
+
+Use official deployment directories and interfaces rather than symbols, token search rankings, or
+copied addresses. Direct reads need RPC for a browser/build tool; same-chain contract-to-contract
+reads need no API account. An **off-chain** token search, price feed, portfolio API, or holder index
+is a different route, even when its source is contract state. Keep it in discovery or a companion
+app by default. Do not fetch a token's hosted logo/price/portfolio API from a permanent NFT's live
+view; prefer verified numeric contract reads or actual captured on-chain bytes. An essential service
+requires the explicit lifetime commitment and recovery design in [durability.md](durability.md).
+
+`name`, `symbol`, and `decimals` are optional in ERC-20. Normalize units from the actual token and
+avoid unbounded holder enumeration. A current balance is temporary, not proof of sustained ownership;
+pool prices, valuations, and eligibility rules need their own trust/manipulation assessment.
+Inspect token upgrade/admin/pause powers; an on-chain token is not necessarily immutable. Rendering
+fallbacks should keep the NFT usable if reads fail. A gate's fallback must preserve its intended rule.
+
+## Companion token creation — Clanker as one starting reference
+
+ABX creates its NFT collections; fungible token launch and management belong to a separate protocol.
+[Clanker's official SDK](https://github.com/clanker-devco/clanker-sdk) and
+[official agent skill](https://github.com/clanker-devco/clanker-sdk/blob/main/.cursor/skills/use-clanker-sdk/SKILL.md)
+provide one reusable route for creation, liquidity, and post-launch operations. Prefer these over
+building a token launcher, pool deployer, or reward client. This is a starting option, not a required
+provider: a creator/agent may choose another protocol using the same verification criteria.
+
+- **Coverage:** the official skill lists Ethereum, Base, Arbitrum One, and Base Sepolia among its
+  networks. Verify the installed SDK version and actual protocol deployments for the chosen chain;
+  this does not establish availability on every ABX chain or paired testnet.
+- **Data and ideas:** the resulting ERC-20 and pool state are **on-chain** inputs for same-chain
+  ABX art or intentional eligibility. Hosted discovery/media are **off-chain**; keep the NFT's
+  output independent of the launch website, SDK, and token image host. A companion token balance can
+  affect art without giving the NFT permission to trade or claim rewards.
+- **Setup:** the direct SDK flow uses RPC and a wallet client, with gas/funding and transaction
+  authority. It does not document a separate Clanker account/API key for that route. Hosted APIs,
+  social login, and optional services have separate requirements; consult the
+  [current official docs](https://docs.clanker.world). Reuse existing suitable connections and signer;
+  never export an ABX-managed key to satisfy a third-party example.
+- **Before launch:** verify admin/recipient roles, allocations, liquidity/fees, costs, and required
+  metadata or distribution hosting. Use the chosen official tool's simulation/preview and explicit
+  transaction review. No companion-token deployment, approval, or funding is implied by ideation.
+
+For a proposal, record the token's chain and official identity, input field and provenance, ABX seam,
+live versus captured behavior, resilience, new accounts/credentials, and runtime dependencies. Keep
+token launch and ABX NFT deployment as separately reviewed operations, using each protocol's official tools.

package/skill/reference/ecosystem.md

@@ -0,0 +1,98 @@
+# Ecosystem discovery and integration planning
+
+Use this reference when a creator wants ideas involving existing protocols, communities, or tools.
+For public context, see [Ecosystem integrations](https://docs.abx.io/docs/using-abx/guides/ecosystem-integrations).
+These are discovery routes, not tested ABX adapters or a promise of third-party compatibility.
+
+## Load by chain set and intent
+
+Read the selected chain's context, then only the topic/provider relevant to the idea. Shared
+providers are described once; chain notes add local context rather than copying their instructions.
+
+| Requested network | References |
+|---|---|
+| Ethereum (`1`) | [Ethereum context](ecosystem/chains/ethereum.md) |
+| Sepolia (`11155111`) | [Sepolia context](ecosystem/chains/sepolia.md) |
+| Base (`8453`) | [Base context](ecosystem/chains/base.md) |
+| Base Sepolia (`84532`) | [Base Sepolia context](ecosystem/chains/base-sepolia.md) |
+| Arbitrum One (`42161`) | [Arbitrum context](ecosystem/chains/arbitrum.md) |
+| Arbitrum Sepolia (`421614`) | [Arbitrum Sepolia context](ecosystem/chains/arbitrum-sepolia.md) |
+| Robinhood Chain (`4663`) | [Robinhood context](ecosystem/chains/robinhood.md) |
+| Robinhood Chain Testnet (`46630`) | [Robinhood testnet context](ecosystem/chains/robinhood-testnet.md) |
+
+Topic routes: [multichain integrations](ecosystem/multichain.md) cover marketplaces, liquidity, and
+existing generative art; [ERC-20s and token creation](ecosystem/tokens.md) cover specific tokens and
+an external launch protocol. These examples are non-exhaustive starting points, not an allowlist or
+provider ranking. Explore protocols beyond this catalog that fit the creator's theme, community, or
+distinctive mechanics. Evaluate their actual on-chain data, semantics, reliability, official tools,
+and setup/runtime costs; explain why each input belongs in this particular project. An unlisted
+provider is unresearched here, not unsupported. Verify new candidates against official sources and
+the same durability criteria. Read `abx capabilities --json` for current ABX network eligibility;
+third-party coverage does not enable an ABX network or sponsorship lane.
+
+## Turn an idea into a bounded plan
+
+1. Apply the [durability guidance](ecosystem/durability.md) to the object's intended behavior and
+   lifespan. Keep discovery/build tools separate from the finished NFT's dependencies.
+   Start from the project's theme, audience, and distinctive mechanic. Explain how each proposed
+   input supports that concept; do not force a familiar token, provider, or financial theme into an
+   unrelated work. Keep ideation separate from account creation or transaction execution.
+2. Check available connections and project dependencies through their supported discovery/status
+   surfaces. Reuse suitable existing tooling and accounts. Do not inspect credential files to make
+   this inventory.
+3. Prefer the provider's official skill, MCP, CLI, SDK, API, or contract interfaces for its part of the
+   workflow. Link to current installation/authentication instructions instead of copying them here.
+   Add only the project-specific glue; do not rebuild an existing client, router, indexer, or signer.
+4. Before implementation, check the ABX part using [capabilities.md](capabilities.md). An external
+   API read or marketplace order is not an ABX command. Keep ABX operations in its CLI and provider
+   operations in official tools; do not let a third-party deploy flow replace the chosen ABX collection.
+5. Before implementation, verify the specific chain, contract/version, token or project identity,
+   current tool support, and the read/write authority. Testnet availability, liquidity, and datasets
+   need separate evidence. A documentation review is not an executed integration test.
+
+## Input provenance and ABX execution
+
+Label each proposed input **on-chain**, **off-chain**, or **mixed**, including the actual access path.
+
+| Input route | Where it can drive ABX behavior |
+|---|---|
+| On-chain, same-chain contract read | Can inform contract actions, state rules, eligibility, or renderer/augment output. Configure/transfer hooks need deliberate failure semantics and lifecycle tests; a display input should not block transfers |
+| Off-chain API/indexer, even if sourced from contracts | Discovery/build tooling or an optional companion app. Prefer capturing the actual bounded input on-chain over putting HTTP calls in the NFT's live view |
+| Mixed: on-chain state plus hosted metadata/media | Separate the durable NFT output from hosted enrichment. Any essential service is a lifetime dependency requiring explicit creator choice and the recovery design below |
+
+Specify the contract and field, or API and timestamp, plus whether the input is live or captured.
+For contract integrations use official interfaces, bounded reads, and purpose-appropriate failure handling.
+Do not assume a renderer's `msg.sender` is the NFT owner. A mutable external read can affect hook
+liveness as well as output; inspect upgrade/pause powers. A browser's hardcoded RPC fetch is still a
+network dependency; prefer computing the input in the EVM. A pool spot value alone is not a
+manipulation-resistant price oracle.
+
+## Account and dependency footprint
+
+For each proposed route, include a short row in the creator's plan:
+
+| Route | Setup delta | Authority and cost | Runtime dependency / exit |
+|---|---|---|---|
+| Provider + official tool + exact chain | Reuse existing connection, no signup, new account, API key, OAuth, RPC, or unknown | Reads versus signatures/approvals; fees, limits, expiry, and renewal to verify | Build-time, optional companion, or lifetime NFT dependency; responsible owner, replacement controls, and behavior if it disappears |
+
+Count accounts, credentials, and hosted dependencies separately. A signup-free key still needs
+storage and renewal; an account-free HTTP endpoint is still an availability dependency. Distinguish
+creator setup from what every collector must do. Prefer the least setup that meets the actual goal,
+not an account-free route that recreates the provider's service or hides extra maintenance.
+
+Use public docs, interfaces, or a local fixture for early comparison. Introduce a new connection,
+credential, paid plan, or wallet permission only when the chosen workflow needs it and the creator's
+authorization covers it. Record credential references and expiry, never secret values, in handoffs.
+
+## Integration boundaries to resolve
+
+- **Live or captured:** do not recommend HTTP-dependent NFT live views by default. Prefer EVM reads
+  or actual input bytes captured on-chain; a URL/hash alone does not preserve them. Required external
+  APIs need explicit lifetime-dependency disclosure and owner-controlled replacement plus a tested
+  fallback, as described in [durability.md](ecosystem/durability.md). Read [code.md](code.md) for lanes.
+- **Source chain:** a contract cannot directly read another chain's NFT ownership. Multichain
+  APIs can assist discovery but do not supply a trustless cross-chain proof or shared state.
+- **Compatibility:** marketplace indexing, royalties, signed listings, transfer validators, and
+  lending eligibility are separate checks. Read [creator-token.md](creator-token.md) when relevant.
+- **Writes:** a quote, unsigned transaction, or tool connection is not approval to trade, approve a
+  spender, lend, bridge, or deploy. Keep the existing ABX confirmation and reconciliation rules.

package/skill/reference/ideation.md

@@ -0,0 +1,29 @@
+# Project ideation
+
+Start with what the object means and does, who participates, and why they would care. Explore its
+data, changing state, participant roles, rules, and relationships with other systems before choosing
+its appearance or deployment family. Artwork is one possibility; follow the creator's intent.
+
+For example, consider a shared resource with contribution rules, a record of provenance or claims,
+a liquidity position with community-defined interactions, or a charter connected to an externally
+launched ERC-20. An object can represent rights or a financial instrument, but real-world rights,
+custody, and enforcement need their own design. These are starting points, not a checklist or
+promises of ready-made ABX features. Explore beyond them and beyond the documented protocols.
+
+Think in actions as well as data: a governed parameter edit or token transfer can trigger custom
+on-chain logic to swap through an AMM, create another asset, or settle an obligation. Configure and
+transfer hooks can make contract calls using explicitly arranged funding and authority; augment
+hooks only derive data during reads. These actions need not serve a visual outcome.
+
+Discuss the core interaction and value in plain language. Consider what changes, who may change it,
+and what happens when a participant or dependency disappears. On-chain, off-chain, and hybrid
+designs are all possible; choose deliberately for the intended lifespan, trust, and behavior.
+Durability need not mean frozen state. Use [ecosystem.md](ecosystem.md) for relevant integrations,
+favoring official third-party tools rather than rebuilding them.
+
+Keep exploration separate from implementation. Research and compare concepts until the creator
+chooses a direction and asks to implement it; do not start code, create repositories or cloud
+resources, or deploy during ideation. Future launch intent or available accounts and wallets do
+not select an idea. An explicit request to implement a chosen concept already establishes that
+direction; do not ask for it again. Resolve technical feasibility through
+[capabilities.md](capabilities.md) before making implementation promises.

package/skill/reference/setup.md

@@ -34,7 +34,9 @@ The shipped skill is named `abx`. `abx skill install` installs it to `.claude/sk
 the rename transition the installer moves a recognized `abx-self-host` folder to
 `.abx-skill-backups/` before installing the new name. It preserves custom bytes rather than deleting
 them. For a custom skills parent, run `abx skill install --target <that-parent>`; do not move or merge
-the old folder manually. Restart the agent after installation.
+the old folder manually. Restart the agent after installation. If this is a one-shot session that
+cannot restart, run `abx skill path`, open the printed `SKILL.md` directly, and follow it for the
+current run; the installed copy becomes automatic in the next session.
 
 ABX requires Node 22.13 or newer. Prefer a project-local npm dependency for reproducible automation;
 use a global install for interactive machine-wide use. Avoid repeated `npx` execution when version