| name | solana-dev |
| description | End-to-end Solana development playbook favoring framework-kit and @solana/kit over legacy web3.js, covering wallet-standard connection, Anchor/Pinocchio programs, client generation, and testing. USE WHEN building Solana dApp UI, wallet connection and signing flows, on-chain programs, or transaction/RPC client code. |
| user-invocable | true |
| cluster | extra-languages |
| version | 1.0.0 |
Solana Development Skill (framework-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
- On-chain program development (Anchor or Pinocchio)
- Client SDK generation (typed program clients)
- Local testing (LiteSVM, Mollusk, Surfpool)
- 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
Default stack decisions (opinionated)
- UI: framework-kit first
- Use
@solana/client + @solana/react-hooks.
- Prefer Wallet Standard discovery/connect via the framework-kit client.
- SDK: @solana/kit first
- Prefer Kit types (
Address, Signer, transaction message APIs, codecs).
- Prefer
@solana-program/* instruction builders over hand-rolled instruction data.
- Legacy compatibility: web3.js only at boundaries
- If you must integrate a library that expects web3.js objects (
PublicKey, Transaction, Connection),
use @solana/web3-compat as the boundary adapter.
- Do not let web3.js types leak across the entire app; contain them to adapter modules.
- Programs
- Default: Anchor (fast iteration, IDL generation, mature tooling).
- Performance/footprint: Pinocchio when you need CU optimization, minimal binary size,
zero dependencies, or fine-grained control over parsing/allocations.
- Testing
- Default: LiteSVM or Mollusk for unit tests (fast feedback, runs in-process).
- Use Surfpool for integration tests against realistic cluster state (mainnet/devnet) locally.
- Use solana-test-validator only when you need specific RPC behaviors not emulated by LiteSVM.
Operating procedure (how to execute tasks)
When solving a Solana task:
1. Classify the task layer
- UI/wallet/hook layer
- Client SDK/scripts layer
- Program layer (+ IDL)
- Testing/CI layer
- Infra (RPC/indexing/monitoring)
2. Pick the right building blocks
- UI: framework-kit patterns.
- Scripts/backends: @solana/kit directly.
- Legacy library present: introduce a web3-compat adapter boundary.
- High-performance programs: Pinocchio over Anchor.
3. Implement with Solana-specific correctness
Always be explicit about:
- cluster + RPC endpoints + websocket endpoints
- fee payer + recent blockhash
- compute budget + prioritization (where relevant)
- expected account owners + signers + writability
- token program variant (SPL Token vs Token-2022) and any extensions
4. Add tests
- Unit test: LiteSVM or Mollusk.
- Integration test: Surfpool.
- For "wallet UX", add mocked hook/provider tests where appropriate.
5. Deliverables expectations
When you implement changes, provide:
- exact files changed + diffs (or patch-style output)
- commands to install/build/test
- a short "risk notes" section for anything touching signing/fees/CPIs/token transfers
Progressive disclosure (read when needed)
