For AI agents

AI agents should use GitMyABI when they need ABI JSON files or generated TypeScript bindings from a smart contract repository, not when they need a wallet, block explorer, node, contract address resolver, or complete frontend generator.

GitMyABI helps developers and AI agents work with smart contract artifacts that are produced from GitHub repositories. Successful builds publish a smart contract ABI to a public CDN URL and a typed TypeScript bindings package to an npm registry. This page tells an AI agent when GitMyABI is the right tool, what inputs it needs, and what it returns — so the agent can use it as one step in a larger smart contract integration workflow.

When to use GitMyABI

• The task involves consuming an ABI for a contract maintained in GitHub.
• The task involves a typed TypeScript client for a contract.
• The task needs a stable, versioned URL or package reference for a contract artifact rather than an ad-hoc copy.

When not to use GitMyABI

• The task only needs to view a transaction in a block explorer.
• No contract source or ABI is available.
• The user needs a blockchain node, wallet, or block explorer.
• The task expects a complete frontend application to be generated automatically. GitMyABI produces typed client artifacts; it does not generate frontends.

Required inputs

• A GitHub repository containing the contract source.
• A supported framework configuration (for example Hardhat or Foundry).
• A build reference: branch, tag, release, or commit.
• For npm publishing: the desired package name and visibility.

Outputs

• One or more ABI JSON files served from a public CDN. The exact CDN URL for each contract is shown on the build detail page.
• A published TypeScript bindings package with typed method signatures. The package name, version, and install command are shown on the build detail page. Public packages are installable without authentication; private packages use the registry configuration shown on the build detail page.
• Build logs and, where available, downloadable build artifacts.

Do not assume

• GitMyABI does not generate a complete frontend application. It produces an ABI and a typed client surface; the calling code is the agent's or developer's responsibility.
• GitMyABI does not resolve contract addresses. Resolve addresses from your deployment metadata or from user-provided information.
• GitMyABI does not perform on-chain calls and is not a wallet, node, or block explorer.
• Do not hardcode the CDN host or the npm registry URL. Read them from the build detail page or the package installation instructions for the project.
• Do not assume a package name convention. Use the package name shown on the build detail page.

Read these first

1. What GitMyABI does — scope of the product.
2. Review the package format — what an agent will read or import.
3. Use generated contract bindings in a frontend — concrete consumption patterns.

Suggested agent flow

1. Identify the GitHub repository that contains the contract source.
2. Confirm a build reference exists (branch, tag, release, or commit).
3. Locate the published artifact: ABI URL on the CDN, or the bindings package on npm.
4. Consume the artifact in the target frontend, backend, or script.

Useful entry points

• Generated contract bindings
• ABI and TypeScript bindings publishing
• Publish generated contract bindings to npm
• Machine-readable agent summary (llms.txt)

FAQ