solana-dev

Solana Development Skill (Kit-first)

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) — 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 (v7+) first

• Build clients with createClient() from @solana/kit, then .use(...) plugins:

  createClient()
    .use(signer(mySigner))
    .use(solanaRpc({ rpcUrl }));
  // or solanaLocalRpc / solanaDevnetRpc / solanaMainnetRpc from @solana/kit-plugin-rpc
  

• Default to signer() / signerFromFile() / generatedSigner() from @solana/kit-plugin-signer — they set both payer and identity to the same keypair (the common case). For fresh local/devnet signers, install the RPC/LiteSVM plugin after generatedSigner(), then fund with airdropSigner(...). Reach for the role-specific variants (payer() + identity()) only when fees and authority must come from different keypairs.
• Use @solana-program/* program plugins (e.g., tokenProgram()) for fluent instruction APIs.
• Prefer Kit types (Address, Signer, transaction message APIs, codecs).
• Transaction v1 (4096-byte transactions, SIMD-0385) is the one exception to the plugin-client default: rpcTransactionPlanner throws on version: 1 today, so v1 needs @solana/kit 8 and the manual pipe() path. See transactions-v1.md.