# Two directories cover eight agents, and transaction v1 is the bet > An agent skill that encodes July 2026 Solana practices for eight different coding agents. Its install story reduces to two convention directories, and its content is opinionated enough to name a default transaction format. **solana-foundation/solana-dev-skill** — Skills for agentic development on Solana - Repository: https://github.com/solana-foundation/solana-dev-skill - Website: https://skills.sh/solana-foundation - Stars: 566 · Forks: 137 - Language: TypeScript - License: MIT - Published: 2026-09-18 · Updated: 2026-09-18 · Language: en - Canonical page: https://hysenlabs.com/projects/solana-foundation-solana-dev-skill ## Two convention directories cover eight agents The manual install table lists a project directory and a personal directory for each of eight agents, and the difference between them is smaller than the table suggests. Four of the eight accept a shared cross-agent location for project scope, and most accept it for personal scope too. Two accept a second location as an alternative, and one of those is the notable case: a particular editor needs a nested personal path under a differently named home directory. The claim at the end of the table is the design insight: the shared directory plus one editor-specific directory together cover all eight agents. So the maintenance burden of supporting eight tools is two directories, not eight, and the table exists to show you which two for your tool rather than to enumerate a matrix you have to satisfy. Copying into a per-agent directory is a valid choice that costs you a copy per tool. ## Copy and symlink decide who applies your updates There are three install script modes and the difference between two of them is who updates the skill later. The default installs at user scope into the two convention directories. A project flag installs the same pair inside the repository instead. A link flag creates a symlink rather than a copy, and the stated consequence is that it auto-updates with a git pull. So the default is a snapshot: after you pull new commits into the clone, the installed skill is still the old one until you re-run the script. The symlink mode inverts that, making the clone the single source of truth at the cost of the installed path pointing into a directory that might move or be deleted. All three come from the same three lines: ```bash git clone https://github.com/solana-foundation/solana-dev-skill cd solana-dev-skill ./install.sh # user-level: ~/.agents/skills + ~/.claude/skills ./install.sh --project # project-level: .agents/skills + .claude/skills ./install.sh --link # symlink instead of copy (auto-updates with git pull) ``` There is also a shorter path through a separate skills command, which detects which agents you have installed and installs or symlinks for each of them automatically: ```bash npx skills add solana-foundation/solana-dev-skill ``` ## Transaction v1 is the default, not an option The most consequential thing the skill encodes is a format default. The SDK entry describes the client as a set of eight plugin clients constructed with a client factory and extended by a plugin method, and states that it builds transaction v1 by default. The usage section repeats it as a trigger: transaction v1 and larger transactions, under a named proposal number, are the default format for new code, for sending, for reading and for indexing. That last clause matters, because reading and indexing are usually where a legacy format gets assumed. So an agent reading this skill will not ask which transaction format you want on a new codebase; it will use the current one. The stack decisions table confirms the framing by listing the alternative in the same row and describing it as a legacy migration target rather than as a peer option. This is a dated bet, and the skill says so by naming the month its practices reflect. ## The legacy client is a destination, not a starting point How the skill treats the older client library is the clearest signal of its intent. The classic library is listed under legacy interoperability as a release candidate, described as the classic API rebuilt on the internals of the new kit rather than as an independent implementation. Its role is stated as the migration target for codebases still on the earlier version. One reference file is dedicated to routing legacy calls, and the automatic trigger list includes migrating a script from the earlier version to this one. Most migration material treats the old API as where you are now, and this inverts it: the old API is somewhere you are going, and there is a documented path for code that still has to live there. The alternative column in the stack table points at the new kit as the default for the same reason. ## Two program frameworks with compute units as the dividing line On-chain development gets two frameworks and one criterion. The default is a specific point release of the more common framework. The alternative is a different framework from a different organisation, positioned for high-performance needs, and the example prompts make the criterion explicit: one asks for converting a program from the default framework to the alternative for better compute-unit efficiency. So the choice is not aesthetic. It is framed around a measurable budget, and the skill will pick up a conversion task on its own when it sees one. That is a meaningful difference from a reference that only says both exist. It also means the skill has opinions you can be wrong about: a program that does not need the budget is being asked to justify an extra framework, and the example prompt shows the conversion being requested rather than the skill proposing it. ## Integration tests can fork mainnet, unit tests cannot Testing is split by what you are testing, and the split determines how much machinery you get. Unit tests run against a lightweight in-process virtual machine or a similar harness. Integration tests run against a local network implementation that offers three things the validator does not: forking from mainnet state, cheatcodes, and an embedded form of its own client. The stack table lists the built-in validator as the alternative for integration testing, which is the honest comparison since the validator gives you a node without mainnet state or cheats. The automatic trigger list includes local network setup and cheats, and one example prompt asks the agent to start that network and create an account funded with a specific token balance. So the local test environment can reproduce account state rather than starting empty, which is what makes fee and balance assertions testable. ## Progressive disclosure plus a self-test for whether the skill fires The skill follows the agent skills progressive disclosure pattern, and the structure shows how much sits behind the main file. The main definition carries the core guidance, and everything else lives in a references directory: one subdirectory for the client kit split into nine files, plus single files for user interface patterns, legacy routing, testing, code generation and payments. Agents read those only when a task needs them, which keeps the always-loaded context small while making the corpus deep. Two of the trigger categories are worth noting because they are not about writing code: toolchain issues covering version mismatches, GLIBC errors and dependency conflicts, and migrations between framework and tool versions. The example prompts include a missing GLIBC symbol error and a version upgrade. There is also a small benchmark suite in the test directory that checks skill trigger matching and automatic install behaviour, which means the repository tests whether the skill activates on the right prompts. ## Conclusion Use this skill if you are building on Solana with an agent that reads skill files, and take it as a dated opinion rather than a reference, because it states a specific month and encodes defaults that will age. Install with the symlink mode so a pull updates the skill, and use the two convention directories rather than a per-agent one to avoid maintaining eight copies. Read the stack decisions table before accepting its defaults, since the legacy path is presented as a migration destination rather than an option to start from. ## FAQ ### How do I install the Solana dev skill? Use the one-line skills command, which detects your installed agents and installs or symlinks for each, or run the install script. The script has three modes: user-level, project-level, and a link mode that symlinks instead of copying so a git pull updates the skill. ### Which Solana SDK does the skill recommend? The client kit at version 8, using eight plugin clients built with a client factory and extended by a plugin method, building transaction v1 by default. The classic library at version 3 is listed as the legacy migration target for codebases still on version 1. ### What is transaction v1 in the Solana dev skill? The current transaction format, which the skill sets as the default for new code when sending, reading and indexing. It is not offered as an option to choose between, which is why the skill encodes it as a practice rather than a comparison. ### Which program framework does the skill recommend? Anchor at 1.1.x as the default, with a different zero-dependency framework at 0.11 or newer for high-performance needs. The dividing line the skill uses is compute-unit efficiency, and one of its example prompts is a conversion between the two. ### How does the skill handle web3.js migration? It treats the version 3 release candidate as the classic API rebuilt on the new kit internals and as the migration target, with a dedicated reference file for routing legacy calls and an automatic trigger for migrating a version 1 script to version 3. ### What testing tools does the skill cover? A local network implementation for integration tests, offering mainnet forking, cheatcodes and an embedded client, and a lightweight in-process virtual machine or a similar harness for unit tests. The built-in validator is listed as the alternative for integration testing. ## Sources - [Issues](https://github.com/solana-foundation/solana-dev-skill/issues) - [License: MIT](https://github.com/solana-foundation/solana-dev-skill/blob/main/LICENSE) - [Project website](https://skills.sh/solana-foundation) - [README](https://github.com/solana-foundation/solana-dev-skill/blob/main/README.md) - [solana-foundation/solana-dev-skill on GitHub](https://github.com/solana-foundation/solana-dev-skill) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/solana-foundation-solana-dev-skill