Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Build with LLMs

Use LLM workflows to integrate with Radius
View as Markdown

Use this page to run faster, safer Radius development with LLM-assisted workflows. The goal is simple: keep the model grounded in Radius-specific context, generate focused changes, and verify outputs before shipping.

Why this works for Radius

Radius docs are available in Markdown-friendly formats, which makes them easy for LLM tools to parse and reason about.

  • Append .md to docs URLs when you need plain text context
  • Use /llms.txt for a compact index of key docs
  • Use /llms-full.txt for broader corpus-style ingestion

These formats reduce UI noise and preserve heading structure for better model responses.

Recommended workflow

1) Prime the model with project constraints

Start every session with the rules your integration must follow.

Include at minimum:

  • Chain ID: 72344
  • RPC URL: https://rpc.testnet.radiustech.xyz
  • Native fee token: USD
  • Library/tooling standards: viem, Foundry, pnpm

Also include links or excerpts from:

  • /developer-resources/network-configuration
  • /developer-resources/fees
  • /developer-resources/json-rpc-api
  • /developer-resources/ethereum-compatibility
  • /developer-resources/tooling-configuration

2) Ask for one scoped task at a time

Avoid broad prompts like “build my app.” Use narrow prompts with explicit output shape.

Good prompt pattern:

  • Task objective
  • Input context
  • Expected output format
  • Non-negotiable constraints

Example scope:

  • “Create a defineChain config using Radius testnet values (chain ID 72344, RPC endpoint https://rpc.testnet.radiustech.xyz).”

3) Require deterministic outputs

Ask the model to return:

  • Exact file edits
  • Minimal diffs
  • Copy-paste-ready commands
  • Short rationale tied to Radius behavior differences

This reduces rework and makes review faster.

4) Validate every generated change

Before merging:

  1. Run your type checks and tests.
  2. Verify fee handling uses Radius-compatible behavior.
  3. Confirm no Ethereum assumptions leak into block behavior logic.
  4. Confirm no forbidden tooling appears (for example, avoid ethers.js and Hardhat in Radius examples).

How to Use Radius Dev Skill

Use the Radius Dev Skill to standardize setup and reduce repeat prompting across projects, teams, and sessions.

Claude Code

/plugin marketplace add https://github.com/radiustechsystems/skills.git
 
/plugin install radius-dev@skills

npx skills

npx skills add radiustechsystems/skills

Fund wallets with the dripping-faucet skill

Use the dripping-faucet skill to fund testnet wallets inside an agentic workflow. The skill handles unsigned drips, the signed fallback (for when signatures are re-enabled), rate-limit retries, and on-chain balance verification.

Install it alongside any other Radius skill:

# Claude Code prompt
claude "Read docs.radiustech.xyz/skills/dripping-faucet.md and fund a local wallet"
 
# Claude Code
/plugin install dripping-faucet@skills
 
# npx skills
npx skills add radiustechsystems/skills

The skill triggers on prompts like "fund my wallet", "get testnet tokens", "drip SBC", or "use the faucet".

:::note Testnet only The dripping-faucet skill targets the testnet faucet API. There is no agentic faucet workflow for mainnet. For mainnet, use the Dashboard to claim SBC, or bridge stablecoins from Ethereum or Base. :::

For the full API reference and programmatic examples, see Fund a wallet.

Public flat file

This skill is also hosted as a flat file:

  • https://docs.radiustech.xyz/SKILLS.md

As your workflows evolve, you can add more skills alongside Radius Dev Skill (for example, auditing, deployment, or observability skills) and keep discovery current by checking the Skills Documentation index.

Prompt templates you can reuse

Generate integration code

“Using viem, generate a Radius testnet chain config with id: 72344 and RPC https://rpc.testnet.radiustech.xyz. No fee overrides are needed — viem's built-in estimation works with Radius. Return only the final TypeScript file content.”

Audit an implementation

“Review this transaction flow for Radius compatibility. Check fee configuration, JSON-RPC method assumptions, and block-related logic. Return: (1) critical issues, (2) exact code changes, (3) a short validation checklist.”

Create a migration plan

“Migrate this ethers.js snippet to viem for Radius. Keep behavior identical. Return: (1) migration diff, (2) risks, (3) test plan.”

Common mistakes to avoid

  • Treating Radius like Ethereum for block semantics
  • Relying on external automatic fee defaults
  • Mixing toolchains (for example, ethers.js + viem)
  • Asking for large multi-feature output in one prompt
  • Accepting generated code without runtime validation

Practical tips

  • Keep a reusable “Radius context block” in your editor snippets.
  • Ask the model to cite the exact page section used for each decision.
  • Prefer iterative prompt loops: plan → patch → verify.
  • Store approved prompts with your project docs so the team reuses proven patterns.
  • Convert repeatable prompts into composable skills as they stabilize.
  • Revisit your installed skills periodically so your agent setup stays current as new skills become available.

Related pages