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
Default stack decisions (opinionated)
1)
UI: framework-kit first
- - Use
@solana/client + @solana/react-hooks. - Prefer Wallet Standard discovery/connect via the framework-kit client.
2) SDK: @solana/kit first
- - Prefer Kit types (
Address, Signer, transaction message APIs, codecs). - Prefer
@solana-program/* instruction builders over hand-rolled instruction data.
3) 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.
4) 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.
5) 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)
Solana 开发技能（框架工具包优先）
本技能的用途
当用户提出以下需求时使用本技能：
- - Solana dApp UI 开发（React / Next.js）
- 钱包连接 + 签名流程
- 交易构建 / 发送 / 确认用户体验
- 链上程序开发（Anchor 或 Pinocchio）
- 客户端 SDK 生成（类型化程序客户端）
- 本地测试（LiteSVM、Mollusk、Surfpool）
- 安全加固与审计式审查
默认技术栈决策（有倾向性）
1)
UI：框架工具包优先
- - 使用 @solana/client + @solana/react-hooks。
- 优先通过框架工具包客户端进行钱包标准发现/连接。
2) SDK：@solana/kit 优先
- - 优先使用 Kit 类型（Address、Signer、交易消息 API、编解码器）。
- 优先使用 @solana-program/* 指令构建器，而非手动构建指令数据。
3) 旧版兼容：仅在边界使用 web3.js
- - 如果必须集成期望 web3.js 对象（PublicKey、Transaction、Connection）的库，
使用 @solana/web3-compat 作为边界适配器。
- - 不要让 web3.js 类型泄漏到整个应用中；将其限制在适配器模块内。
4) 程序
- - 默认：Anchor（快速迭代、IDL 生成、成熟工具链）。
- 性能/体积：当需要 CU 优化、最小二进制体积、零依赖或对解析/分配进行精细控制时，使用 Pinocchio。
5) 测试
- - 默认：LiteSVM 或 Mollusk 用于单元测试（快速反馈，进程内运行）。
- 使用 Surfpool 在本地对真实集群状态（主网/开发网）进行集成测试。
- 仅当需要 LiteSVM 无法模拟的特定 RPC 行为时，使用 solana-test-validator。
操作流程（如何执行任务）
解决 Solana 任务时：
1. 分类任务层级
- - UI/钱包/钩子层
- 客户端 SDK/脚本层
- 程序层（+ IDL）
- 测试/CI 层
- 基础设施（RPC/索引/监控）
2. 选择正确的构建模块
- - UI：框架工具包模式。
- 脚本/后端：直接使用 @solana/kit。
- 存在旧版库：引入 web3-compat 适配器边界。
- 高性能程序：优先使用 Pinocchio 而非 Anchor。
3. 以 Solana 特定的正确性实现
始终明确说明：
- - 集群 + RPC 端点 + WebSocket 端点
- 费用支付者 + 最新区块哈希
- 计算预算 + 优先级（相关时）
- 预期的账户所有者 + 签名者 + 可写性
- 代币程序变体（SPL Token vs Token-2022）及任何扩展
4. 添加测试
- - 单元测试：LiteSVM 或 Mollusk。
- 集成测试：Surfpool。
- 对于钱包用户体验，在适当位置添加模拟的钩子/提供者测试。
5. 交付物预期
实施变更时，提供：
- - 确切更改的文件 + 差异（或补丁风格输出）
- 安装/构建/测试命令
- 针对涉及签名/费用/CPI/代币转账的任何内容的简短风险说明部分
渐进式文档（需要时阅读）
