solana-anchor-claude-skill adoption decision

README excerpt

README.md

Solana Anchor Claude Skill

A Claude Code skill for creating and editing Solana projects, including Rust/Anchor and TypeScript, with a focus on:

• Maintainability
• Readability
• Minimal code
• 2026 best practices

[!TIP]

This skill has the most stars of any Solana Claude skill not produced by the Solana Foundation (which inherently get more distribution) and is made by someone working in the software industry for more than 25 years. If you find it useful, please add a GitHub star above! 🙏

Sponsor shout out

Shout out to Quicknode for sponsoring development of this Claude skill!

What are Claude Skills?

Claude Code supports "skills" - reusable instruction sets that Claude automatically applies when working on your code. Skills are stored in .claude/skills/ directories and can be invoked manually or triggered automatically based on context.

Installation

npx skills add https://github.com/quiknode-labs/solana-anchor-claude-skill

This automatically installs the skill to your Claude Code skills directory (~/.claude/skills/).

Usage

Once installed, the skill automatically applies when Claude Code works on Solana/Anchor projects. You can also manually invoke it with:

/solana-anchor-claude-skill

SKILL.md excerpt

SKILL.md

Variable Naming

Ensure good variable naming. Rather than add comments to explain what things are, give them useful names.

Don't do this:

// Foo
const shlerg = getFoo();

Do this instead:

const foo = getFoo();

Naming conventions:

• Arrays should be plurals (shoes), items within arrays should be the singular (shoes.forEach((shoe) => {...}))
• Functions should be verby, like calculateFoo or getBar
• Avoid abbreviations, use full words (e.g., use context rather than ctx). Never use e for something thrown, use thrownObject, never use v when you mean value. There is almost no case where a single character variable is a good idea outside maths (eg p and q for cryptography).
• Name a transaction some variant of transaction. Name instructions some variant of instruction. Name signatures some variant of signature. Do not confuse them - eg if the type looks like an instruction, you should not call it a 'transaction' because that is deceptive.

You can still add comments for additional context, just be careful to avoid comments that are explaining things that would be better conveyed by good variable naming.

Solana-Specific TypeScript

• Don't make new @solana/web3.js version 1 code. Do not make new code using @coral-xyz/anchor package. Don't replace Solana Kit with web3.js version 1 code. web3.js version 1 is legacy and should be eventually removed. Solana Kit used to be called web3.js version 2. Use Solana Kit, preferably via Solana Kite.
• Use Kite's connection.getPDAAndBump() to turn seeds into PDAs and bumps
• There is no need to use offsets that you set to decode Solana account data - either download an npm package for the program like @solana-program/token for the token program or make one using Codama.
• In Solana Kit, you make instructions by making TS clients from IDLs using Codama. You can easily make Codama clients for installed IDLs using:

npx create-codama-clients

• Do not use the bs58 npm package.

Don't do this:

import bs58 from "bs58";
const signature = bs58.encode(signatureBytes);

Do this instead:

import { getBase58Decoder } from "@solana/codecs";
const signature = getBase58Decoder().decode(signatureBytes);

Yes, bs58 and @solana/codecs packages have different concepts of 'encode' and 'decode'.

Anchor has silly defaults

Every project will need an IDL.

[features]
idl-build = ["anchor-lang/idl-build", "anchor-spl/idl-build"]

and if it uses SPL Tokens (like almost every Anchor project) it will need this dependency (insert whatever version is applicable):

[dependencies]
anchor-spl = "0.32.1"

Account Constraints

• Use a newline after each key in the account constraints struct, so the macro and the matching key/value have some space from other macros and their matching key/value

Space Calculation (CRITICAL - NO MAGIC NUMBERS)

• Do not use magic numbers anywhere. I don't want to see 8 + 32 or whatever.
• Do not make constants for the sizes of various data structures
• For space, use syntax like: space = SomeStruct::DISCRIMINATOR.len() + SomeStruct::INIT_SPACE,
• All structs should have #[derive(InitSpace)] added to them, to get the INIT_SPACE trait
• DO NOT use magic numbers

Example:

#[derive(InitSpace)]
#[account]
pub struct UserProfile {
    pub authority: Pubkey,

    #[max_len(50)]
    pub username: String,

    pub bump: u8,
}

#[derive(Accounts)]
pub struct InitializeProfile<'info> {
    #[account(
        init,
        payer = authority,
        space = UserProfile::DISCRIMINATOR.len() + UserProfile::INIT_SPACE,
        seeds = [b"profile", authority.key().as_ref()],
        bump
    )]
    pub profile: Account<'info, UserProfile>,

    #[account(mut)]
    pub authority: Signer<'info>,