Feature Request: Split into separate skills

[Taylor123]

A monolithic skill is a waste of tokens and is not a best practice when it comes to context engineering. Instead, it would be better to split the current solana-dev-skill into separate skills to reduce context drift and improve output. Separating into dedicated skills also allows for a more thoughtful procedure outline in the SKILL.md.

I would suggest splitting some of the following:

• Program Security Analysis - reviews and identifies issues. This could generate a TODO list md file or annotate code directly where issues are found.
• Anchor Program Development - writes solana program's using anchor framework
• Pinocchio Program Development - writes solana programs using Pinocchio
• Client Development - writes TS code for clients interacting with Solana and smart contracts
• IDL Generation - context for generating IDLs
• Testing - writes testing code
  • This could be split by testing framework as well
• Payments - context for payments

[ArvinFarrelP]

Hi, I'd like to work on this.

My plan is to split the monolithic solana-dev skill into separate skills:

• Anchor Program Development
• Pinocchio Program Development
• Client Development
• Testing
• Security Analysis
• Payments

Each skill will have its own SKILL.md and references.

Does this structure look good?

[Taylor123]

Does this structure look good?

I like this structure. @dev-jodee @jacobcreech are you in favor of such updates?

The Readme and any external documentation would need to change for the skill installation.

[dev-jodee]

Yep, think it makes sense to me to break it appart

[lgalabru]

Hey @Taylor123! this skill was recently re-vamped, using Claude recommended best practices (progressive disclosure among others).
Splitting that skill into sub-skills would introduce some trade-offs, and would definitely degrade the devex (devs forced to go back to discovery mode on skills.sh to install the missing skills).

Are you seeing pieces of guidance in our skill being ignored?

The-Complete-Guide-to-Building-Skill-for-Claude.pdf

[ArvinFarrelP]

Hi! I saw the discussion in the issue and went ahead with an implementation of the proposed modular skill structure so it can be reviewed more concretely.

If there are any concerns about the approach or structure, I'm happy to adjust based on maintainer feedback.

[Taylor123]

Are you seeing pieces of guidance in our skill being ignored?

Nothing specifically breaks the guidance, but anecdotally I've had better results from agents when skills are compartmentalized. Especially when they're very different procedures (writing code vs analyzing code)

[lgalabru]

I've had better results from agents when skills are compartmentalized

@Taylor123 could you be more specific and provide concrete examples we could reproduce, understand, and explore?

Breaking down the skill would be a significant regression in terms of developer experience. For a developer exploring Solana without knowing what they don't know, we'd end up with a broken flow:

1. Installing a 101-skill (?)
2. Opening a Claude/Codex session and describing what they're building using 101-skill
3. Either terminating their session to install missing skills, or pointing their agent to a remote skill (suboptimal in terms of token consumption and loss of local reproducibility)
4. Starting to vibe-code a program (Pinocchio, Anchor, etc.)
5. Back to 3) to install a skill for testing, profiling, or security auditing
6. Back to 3) to install a skill for frontend integration, etc.

Installing the skill once feels like a better experience, and it performs significantly better in terms of token consumption — it lets you reuse the same session context rather than going through a warm-up phase multiple times.

If progressive disclosure is correctly designed (and I'm not convinced it is today), then the "monolithic" skill feels like the right approach: developers do download some extra markdown files, but those files lie dormant and consume no tokens until they're actually needed.

I don't think migrating to the flow described above is justified by saving a few KB on disk.