Solana Development Skill

---
name: solana-dev
description: 'Use when user asks to "build a Solana dapp", "write an Anchor program", "create a token", "debug Solana errors", "set up wallet connection", "test my Solana program", "fuzz my Solana program", "deploy to devnet", "send a v1 transaction", "support larger transactions", "fix maxSupportedTransactionVersion", or "explain Solana concepts" (rent, accounts, PDAs, CPIs). Also for program architecture — state layout, reducing compute units, throughput bottlenecks, instruction naming — and quick on-chain lookups via public RPC + curl (balance, transaction, token account). End-to-end playbook: wallet connection, Anchor/Pinocchio programs, Codama clients, Surfpool/LiteSVM/Mollusk testing, security review, and the v1 transaction format (SIMD-0385, 4096-byte transactions). Prefers @solana/kit 8 plugin clients (createClient + .use()) building transaction v1 by default, @solana/kit-plugin-wallet + @solana/react for wallets, web3.js v3 as the legacy migration target, and Surfpool for local networks.'
license: MIT
compatibility: Requires Node.js 20.18+, Rust toolchain, Solana CLI, Anchor CLI
metadata:
  author: Solana Foundation
  version: "2.7.0"
---

# Solana Development Skill

## What this Skill is for
Use this Skill when the user asks for:
- Solana dApp UI work (React / Next.js)
- Wallet connection + signing flows
- Transaction building / sending / confirmation UX
- Transaction v1 / larger transactions (SIMD-0385) — the default format for new code; sending, reading, indexing
- On-chain program development (Anchor or Pinocchio)
- Program architecture — state layout, PDA seed conventions, naming, parallelization, cranks, vault topology
- Client SDK generation (typed program clients)
- Local testing (Surfpool, LiteSVM, Mollusk) and fuzz testing (Trident, cargo-fuzz)
- Security hardening and audit-style reviews
- Confidential transfers (Token-2022 ZK extension)
- **Toolchain setup, version mismatches, GLIBC errors, dependency conflicts**
- **Upgrading Anchor/Solana CLI versions, migration between versions**
- **Migrating web3.js v1 code to web3.js v3 or Kit**

## Default stack decisions (opinionated)

1) **SDK: @solana/kit 8 plugin clients, transaction v1 by default**
- Build clients with `createClient()` from `@solana/kit`, then `.use(...)` plugins. Pass `transactionConfig: { version: 1 }` to the RPC plugin so every transaction the client plans is v1:
  ```ts
  createClient()
    .use(signer(mySigner))
    .use(solanaRpc({ rpcUrl, transactionConfig: { version: 1, priorityFeeLamports: lamports(5_000n) } }));
  // or solanaLocalRpc / solanaDevnetRpc / solanaMainnetRpc from @solana/kit-plugin-rpc
  ```
- **Transaction v1 is the default for new code**. Set `version: 1`; the planner otherwise defaults to v0. Plugin clients estimate compute and loaded-accounts-data limits by simulation. On manual pipelines, use Kit's resource-estimation helpers instead of guessing limits; use fixed values only for measured overrides or deliberate caps. See [transactions-v1.md](references/transactions-v1.md).
- Manual `pipe()` + `createTransactionMessage({ version: 1 })` is the low-level alternative for when you need control over every step (custom lifetimes, offline signing, bespoke planners) — see [kit/advanced.md](references/kit/advanced.md). It is not the default path.