solana-dev

Name: solana-dev
Author: solana-foundation

48kinstalls124forks

How to install solana-dev?

solana-foundation/solana-dev-skill/solana-dev

$npx -y skills add solana-foundation/solana-dev-skill --skill solana-dev

Installs into the current project.

Summary

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", "deploy to devnet", or "explain Solana concepts" (rent, accounts, PDAs, CPIs, etc.). Also use for quick on-chain

Files · 1

View on GitHub

SKILL.md

1	# Solana Development Skill (Kit-first)
2
3	## What this Skill is for
4	Use this Skill when the user asks for:
5	- Solana dApp UI work (React / Next.js)
6	- Wallet connection + signing flows
7	- Transaction building / sending / confirmation UX
8	- On-chain program development (Anchor or Pinocchio)
9	- Client SDK generation (typed program clients)
10	- Local testing (Surfpool, LiteSVM, Mollusk)
11	- Security hardening and audit-style reviews
12	- Confidential transfers (Token-2022 ZK extension)
13	- Toolchain setup, version mismatches, GLIBC errors, dependency conflicts
14	- Upgrading Anchor/Solana CLI versions, migration between versions
15	- Migrating web3.js v1 code to web3.js v3 or Kit
16
17	## Default stack decisions (opinionated)
18
19	1) SDK: @solana/kit (v7+) first
20	- Build clients with `createClient()` from `@solana/kit`, then `.use(...)` plugins:
21	```ts
22	createClient()
23	.use(signer(mySigner))
24	.use(solanaRpc({ rpcUrl }));
25	// or solanaLocalRpc / solanaDevnetRpc / solanaMainnetRpc from @solana/kit-plugin-rpc
26	```
27	- Default to `signer()` / `signerFromFile()` / `generatedSigner()` from
28	`@solana/kit-plugin-signer` — they set both `payer` and `identity` to the same keypair (the
29	common case). For fresh local/devnet signers, install the RPC/LiteSVM plugin after
30	`generatedSigner()`, then fund with `airdropSigner(...)`. Reach for the role-specific variants
31	(`payer()` + `identity()`) only when fees and authority must come from different keypairs.
32	- Use `@solana-program/*` program plugins (e.g., `tokenProgram()`) for fluent instruction APIs.
33	- Prefer Kit types (`Address`, `Signer`, transaction message APIs, codecs).
34
35	2) UI: Kit plugin client + @solana/react
36	- Wallet connection via `walletSigner()` from `@solana/kit-plugin-wallet` (Wallet Standard discovery; the connected wallet fills the payer/identity roles), with React hooks from `@solana/kit-plugin-wallet/react`.
37	- Client bindings via `@solana/react` v7 (`ClientProvider`, typed `useClient<AppClient>`, data hooks, SWR/TanStack adapters). Its legacy Wallet Standard hooks are being deprecated — don't use them.
38	- Do not use `@solana/client` / `@solana/react-hooks` (framework-kit) or `@solana/wallet-adapter-*` for new work.
39
40	3) Legacy compatibility: web3.js v3 (RC)
41	- web3.js v3 (`@solana/web3.js@rc`) is the classic class-based API rebuilt on Kit internals. It is still a release candidate — treat it as the migration target for v1 codebases, not a default recommendation for new work.
42	- Migrating a v1 codebase: use the official migration skill from the solana-web3.js repo rather than hand-migrating — see [kit-web3-interop.md](references/kit-web3-interop.md) for routing.
43	- Do not introduce `@solana/web3-compat` in new work — it is superseded.
44	- Do not let legacy class types leak across the entire app; contain them to adapter modules.
45
46	4) Programs
47	- Default: Anchor 1.1.x (fast iteration, IDL generation, mature tooling).
48	- Performance/footprint: Pinocchio (0.11+) when you need CU optimization, minimal binary size,
49	zero dependencies, or fine-grained control over parsing/allocations.
50
51	5) Testing (Surfpool-centered)
52	- Unit tests: LiteSVM (in-process, Rust/TS) or Mollusk (Rust instruction harness).
53	- Integration tests: Surfpool — mainnet forking with lazy account cloning, 26 `surfnet_*` cheatcodes (time travel, account/token state, oracle scenarios, CU profiling), embeddable in-process via the `@solana/surfpool` SDK, and the default `anchor test` runner in Anchor 1.0+.
54	- Use solana-test-validator only when you need full validator runtime fidelity not emulated by Surfpool.
55
56	## Agent safety guardrails
57
58	### Transaction review (W009)
59	- Never sign or send transactions without explicit user approval. Always display the transaction summary (recipient, amount, token, fee payer, cluster) and wait for confirmation before proceeding.
60	- **Never ask for or store pr

People who liked this also viewed

6 picks

Type

solana-dev

48kinstalls124forks

View on GitHub

How to install solana-dev?

solana-foundation/solana-dev-skill/solana-dev

$npx -y skills add solana-foundation/solana-dev-skill --skill solana-dev

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Solana Development Skill (Kit-first)
2
3	## What this Skill is for
4	Use this Skill when the user asks for:
5	- Solana dApp UI work (React / Next.js)
6	- Wallet connection + signing flows
7	- Transaction building / sending / confirmation UX
8	- On-chain program development (Anchor or Pinocchio)
9	- Client SDK generation (typed program clients)
10	- Local testing (Surfpool, LiteSVM, Mollusk)
11	- Security hardening and audit-style reviews
12	- Confidential transfers (Token-2022 ZK extension)
13	- Toolchain setup, version mismatches, GLIBC errors, dependency conflicts
14	- Upgrading Anchor/Solana CLI versions, migration between versions
15	- Migrating web3.js v1 code to web3.js v3 or Kit
16
17	## Default stack decisions (opinionated)
18
19	1) SDK: @solana/kit (v7+) first
20	- Build clients with `createClient()` from `@solana/kit`, then `.use(...)` plugins:
21	```ts
22	createClient()
23	.use(signer(mySigner))
24	.use(solanaRpc({ rpcUrl }));
25	// or solanaLocalRpc / solanaDevnetRpc / solanaMainnetRpc from @solana/kit-plugin-rpc
26	```
27	- Default to `signer()` / `signerFromFile()` / `generatedSigner()` from
28	`@solana/kit-plugin-signer` — they set both `payer` and `identity` to the same keypair (the
29	common case). For fresh local/devnet signers, install the RPC/LiteSVM plugin after
30	`generatedSigner()`, then fund with `airdropSigner(...)`. Reach for the role-specific variants
31	(`payer()` + `identity()`) only when fees and authority must come from different keypairs.
32	- Use `@solana-program/*` program plugins (e.g., `tokenProgram()`) for fluent instruction APIs.
33	- Prefer Kit types (`Address`, `Signer`, transaction message APIs, codecs).
34
35	2) UI: Kit plugin client + @solana/react
36	- Wallet connection via `walletSigner()` from `@solana/kit-plugin-wallet` (Wallet Standard discovery; the connected wallet fills the payer/identity roles), with React hooks from `@solana/kit-plugin-wallet/react`.
37	- Client bindings via `@solana/react` v7 (`ClientProvider`, typed `useClient<AppClient>`, data hooks, SWR/TanStack adapters). Its legacy Wallet Standard hooks are being deprecated — don't use them.
38	- Do not use `@solana/client` / `@solana/react-hooks` (framework-kit) or `@solana/wallet-adapter-*` for new work.
39
40	3) Legacy compatibility: web3.js v3 (RC)
41	- web3.js v3 (`@solana/web3.js@rc`) is the classic class-based API rebuilt on Kit internals. It is still a release candidate — treat it as the migration target for v1 codebases, not a default recommendation for new work.
42	- Migrating a v1 codebase: use the official migration skill from the solana-web3.js repo rather than hand-migrating — see [kit-web3-interop.md](references/kit-web3-interop.md) for routing.
43	- Do not introduce `@solana/web3-compat` in new work — it is superseded.
44	- Do not let legacy class types leak across the entire app; contain them to adapter modules.
45
46	4) Programs
47	- Default: Anchor 1.1.x (fast iteration, IDL generation, mature tooling).
48	- Performance/footprint: Pinocchio (0.11+) when you need CU optimization, minimal binary size,
49	zero dependencies, or fine-grained control over parsing/allocations.
50
51	5) Testing (Surfpool-centered)
52	- Unit tests: LiteSVM (in-process, Rust/TS) or Mollusk (Rust instruction harness).
53	- Integration tests: Surfpool — mainnet forking with lazy account cloning, 26 `surfnet_*` cheatcodes (time travel, account/token state, oracle scenarios, CU profiling), embeddable in-process via the `@solana/surfpool` SDK, and the default `anchor test` runner in Anchor 1.0+.
54	- Use solana-test-validator only when you need full validator runtime fidelity not emulated by Surfpool.
55
56	## Agent safety guardrails
57
58	### Transaction review (W009)
59	- Never sign or send transactions without explicit user approval. Always display the transaction summary (recipient, amount, token, fee payer, cluster) and wait for confirmation before proceeding.
60	- **Never ask for or store pr

People who liked this also viewed

6 picks

Type