# Botchain Skill Engine

> Operate on the BOT Chain EVM network, including native and token balances, contract reads and deployments, tBOT transfers, gas estimates, paymaster checks, and transaction status. Use when a request mentions BOT Chain, tBOT, botchain.ai, bohr.life, mainnet chain ID 677, or Bohr testnet chain ID 968. Do not use for unrelated robotics, proof-of-work, or trading-bot projects called BotChain.

- Skill: `manueldezman/botchain-skill-engine` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add manueldezman/botchain-skill-engine`
- Raw SKILL.md: https://api.skillmd.com/api/skills/manueldezman/botchain-skill-engine/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT-0
- Author: manueldezman (https://skillmd.com/u/manueldezman)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/manueldezman/botchain-skill-engine

---


# BOT Chain Skill Engine

Use the local `botchain-mcp-server` to inspect and operate on BOT Chain while
keeping signing keys in the user's local environment. Treat `tBOT` as the
native asset of Bohr testnet, chain ID 968.

## Requirements

This skill requires network access and the `botchain-mcp-server` running
locally. Write actions require `BOTCHAIN_PRIVATE_KEY`; contract workflows may
also require Foundry or Hardhat.

## Choose the relevant guidance

Load only the material needed for the request:

- For network identifiers, RPC endpoints, or explorer URLs, read
  [references/rpc-endpoints.md](references/rpc-endpoints.md).
- Before contract creation or deployment, read
  [references/boundary-rules.md](references/boundary-rules.md). Start from
  [assets/contract-template.sol](assets/contract-template.sol) when a generic
  contract template is appropriate.
- Before estimating gas or sending to multiple recipients, read
  [references/gas-estimation.md](references/gas-estimation.md).
- Before changing an existing project's network configuration, read
  [references/migration.md](references/migration.md).

## Operate on BOT Chain

1. Call `check_environment_health` before a chain operation. For requests about
   “my” wallet, use the configured signer's public address returned by health.
2. Use the narrowest MCP tool that performs the requested action. Do not create
   an ad hoc RPC script unless the user explicitly requests a standalone script.
3. If required compiler tooling is missing, explain what is missing and obtain
   approval before installing it.
4. For a migration, inspect the existing configuration and deployment flow,
   propose a minimal change, and obtain approval before editing it.
5. After a write, use `check_transaction_status` or `fetch_explorer_state` to
   verify the result before reporting it.

Use these MCP tools without guessing their parameters:

| Tool | Use |
|---|---|
| `check_environment_health` | Check RPC, chain, tooling, and signer readiness. |
| `check_balance` | Read a native-token or ERC-20 balance. |
| `read_contract` | Call a read-only contract method. |
| `estimate_gas` | Simulate a transaction and estimate its gas. |
| `check_transaction_status` | Read and verify a transaction receipt. |
| `check_gasless_eligibility` | Check paymaster sponsorship with `pm_isSponsorable`. |
| `execute_terminal_cmd` | Run an allow-listed development command. |
| `deploy_contract` | Compile and deploy a contract with local signing. |
| `send_transaction` | Send a native or ERC-20 transfer with local signing. |
| `batch_transfer` | Send the same asset to several recipients in sequence. |
| `fetch_explorer_state` | Query supported explorer data. |

## Authorization and safety

- A complete imperative request authorizes that exact write. For example,
  “Send 1 tBOT to 0x…” authorizes that testnet transfer; do not ask the user to
  repeat approval.
- Ask a follow-up before a write when a required value is missing, malformed,
  conflicting, or ambiguous, or when selecting a network would materially
  change the risk.
- Default to Bohr testnet. Use BOT Chain mainnet, chain ID 677, only when the
  user explicitly selects mainnet.
- Never expose the private key in output, command arguments, logs, or errors.
- Never invent a balance, transaction hash, contract address, or confirmation.
  Report a tool or connection failure directly.
- Do not overwrite an existing project configuration. Preserve its toolchain
  and deployment flow unless the user requests a replacement.
- Describe the agent-identity pattern in
  [references/boundary-rules.md](references/boundary-rules.md) as a toolkit
  proposal, not a native BOT Chain feature.

## Examples

**Balance request**

- Input: `What is my tBOT balance?`
- Behavior: Resolve “my” from `check_environment_health`, call `check_balance`
  on chain 968, and return the verified balance without requesting the address.

**Authorized transfer**

- Input: `Send 1 tBOT to 0x1f90F279C1E2E5481385aC0086b9AC49ff712234`
- Behavior: Treat the prompt as authorization for that exact testnet transfer,
  send it with `send_transaction`, verify it, and return the real transaction
  status and hash.

**Ambiguous write**

- Input: `Send BOT to 0x1f90F279C1E2E5481385aC0086b9AC49ff712234`
- Behavior: Ask for the amount and whether the user means BOT Chain mainnet or
  tBOT on Bohr testnet before sending anything.

## Failure handling

- If the MCP server is unavailable, explain that local BOT Chain tooling is not
  connected; do not silently substitute another network or execution path.
- If the signer is missing, explain that read actions remain available but a
  local `BOTCHAIN_PRIVATE_KEY` is required for writes.
- If a transaction is submitted but not yet confirmed, report it as pending and
  provide its real hash rather than claiming success.