Solana wallet management and token trading via Jupiter aggregator. Check balances, view transaction history, swap tokens, and manage your Solana portfolio.
49
55%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./public/skills/0xterrybit/solana-trader/SKILL.mdQuality
Discovery
82%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description with strong specificity and excellent trigger terms covering the Solana/crypto trading domain. Its main weakness is the absence of an explicit 'Use when...' clause, which would help Claude know exactly when to select this skill. The domain is niche enough that conflict risk is minimal.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about Solana wallets, token swaps, crypto balances, Jupiter DEX, or SPL tokens.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: check balances, view transaction history, swap tokens, and manage Solana portfolio. Also names specific technologies (Jupiter aggregator, Solana). | 3 / 3 |
Completeness | Clearly answers 'what does this do' with specific actions, but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The when is only implied through the action descriptions. | 2 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Solana', 'wallet', 'token', 'swap', 'balances', 'transaction history', 'Jupiter', 'portfolio', 'trading'. These cover common user language well. | 3 / 3 |
Distinctiveness Conflict Risk | Very distinct niche — Solana blockchain, Jupiter aggregator, and crypto wallet management are highly specific domains unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is comprehensive in scope but suffers from significant verbosity and a monolithic structure that wastes context window tokens. The swap execution workflow (Step 4) contains incorrect commands that would fail in practice, undermining the actionability of the most critical operation. The content would benefit greatly from aggressive trimming of redundant RPC provider examples, splitting reference material into separate files, and fixing the transaction signing/submission flow.
Suggestions
Split reference content (token addresses, RPC providers, private key import methods, fee configuration) into separate bundle files and reference them from SKILL.md to improve progressive disclosure and reduce the main file to ~100 lines.
Fix Step 4 (Sign and Submit Transaction) — the `solana transfer` command cannot sign a Jupiter swap transaction. Provide a working approach, such as a small Node.js/Python script that deserializes the base64 transaction, signs it with the keypair, and submits it.
Consolidate the 5 nearly-identical transaction history options into a single default approach with a brief note about alternative providers, rather than showing full curl commands for each.
Add explicit post-swap verification: check transaction status via `getSignatureStatuses` and verify the output token balance increased, creating a proper feedback loop for this financial operation.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~400+ lines. Includes extensive redundant content: 5 different RPC provider options for transaction history (Options 1-5 are nearly identical curl commands), detailed referral fee breakdowns, multiple import methods for private keys, and explanatory notes Claude doesn't need. The common token addresses table, free RPC endpoints table, and 'Useful Links' section add bulk without proportional value. Much of this could be cut by 60%+. | 1 / 3 |
Actionability | Provides many concrete bash commands and curl examples, which is good. However, Step 4 (Sign and Submit Transaction) is problematic — the `solana transfer` command is incorrectly used for signing a raw Jupiter swap transaction, making the swap execution flow not actually executable as written. The signing/submission of Jupiter swap transactions requires different tooling (e.g., a small script to deserialize, sign, and send the versioned transaction). | 2 / 3 |
Workflow Clarity | The swap workflow has a clear 4-step sequence with an explicit user confirmation checkpoint (Step 2), which is good. However, Step 4's signing approach is incorrect/incomplete, breaking the workflow. The retry logic section mentions getting a fresh quote and re-confirming but lacks explicit validation that the swap succeeded (e.g., checking the transaction status after submission). Missing verification of final balance after swap/transfer. | 2 / 3 |
Progressive Disclosure | Everything is crammed into a single monolithic SKILL.md with no bundle files. The token address table, 5 RPC provider options, private key import methods, and detailed fee configuration could all be split into separate reference files. There are no references to external bundle files for advanced topics. The document is a wall of content that would benefit enormously from splitting into focused sub-files. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 9 / 11 Passed | |
f45fcb5
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.