I work in DevRel at Arbitrum. The problem I kept running into: developers want to try Stylus (Rust smart contracts that compile to WASM and run on Arbitrum alongside Solidity), but the getting-started path involves too many disconnected pieces. You need the Rust WASM target, cargo-stylus, Docker for the local devnode, knowledge of the sol_storage! macro for storage layouts, ABI export for the frontend, CORS workarounds for the devnode, and so on. Each piece is documented, but the integration path is not.
So I built a Claude Code skill that encodes the full workflow as structured reference documentation. A "skill" is a set of markdown files that Claude loads into context when relevant. The main SKILL.md file contains a compact decision tree (Stylus vs Solidity vs both), the monorepo structure, bootstrap commands, and core workflow. Six deeper reference docs cover Stylus SDK patterns, Solidity/Foundry specifics, frontend integration (viem + wagmi), local devnode setup, deployment, and testing.
The key design choice is on-demand loading. Claude doesn't load all 6 reference docs at once -- it reads the decision tree and pulls in only the ones the current conversation needs. This keeps context usage efficient while still having deep knowledge available.
The skill is opinionated by design. It prescribes viem (not ethers.js), pnpm (not npm/yarn), Foundry (not Hardhat), specific SDK versions. I found that LLMs produce dramatically more consistent output when you eliminate ambiguous tool choices. The tradeoff is obvious -- if you prefer ethers.js, this skill isn't for you.
What the skill doesn't do: it doesn't generate contracts blindly. It knows about Arbitrum-specific gotchas like block.number returning approximate L1 block numbers, the two-component fee model, Stylus contract activation requirements, and the CORS issue with the devnode. These are the things that trip up developers who copy-paste from Ethereum tutorials.
Tradeoffs I'm aware of: the opinionated approach means this won't suit every workflow. The skill doesn't support Hardhat or ethers.js users. The reference docs will need updating as the Stylus SDK evolves. And it's only useful if you're already using Claude Code.
MIT licensed. The whole thing is markdown files -- easy to fork, modify, or use as a template for skills in other domains.
I work in DevRel at Arbitrum. The problem I kept running into: developers want to try Stylus (Rust smart contracts that compile to WASM and run on Arbitrum alongside Solidity), but the getting-started path involves too many disconnected pieces. You need the Rust WASM target, cargo-stylus, Docker for the local devnode, knowledge of the sol_storage! macro for storage layouts, ABI export for the frontend, CORS workarounds for the devnode, and so on. Each piece is documented, but the integration path is not.
So I built a Claude Code skill that encodes the full workflow as structured reference documentation. A "skill" is a set of markdown files that Claude loads into context when relevant. The main SKILL.md file contains a compact decision tree (Stylus vs Solidity vs both), the monorepo structure, bootstrap commands, and core workflow. Six deeper reference docs cover Stylus SDK patterns, Solidity/Foundry specifics, frontend integration (viem + wagmi), local devnode setup, deployment, and testing.
The key design choice is on-demand loading. Claude doesn't load all 6 reference docs at once -- it reads the decision tree and pulls in only the ones the current conversation needs. This keeps context usage efficient while still having deep knowledge available.
The skill is opinionated by design. It prescribes viem (not ethers.js), pnpm (not npm/yarn), Foundry (not Hardhat), specific SDK versions. I found that LLMs produce dramatically more consistent output when you eliminate ambiguous tool choices. The tradeoff is obvious -- if you prefer ethers.js, this skill isn't for you.
What the skill doesn't do: it doesn't generate contracts blindly. It knows about Arbitrum-specific gotchas like block.number returning approximate L1 block numbers, the two-component fee model, Stylus contract activation requirements, and the CORS issue with the devnode. These are the things that trip up developers who copy-paste from Ethereum tutorials.
Tradeoffs I'm aware of: the opinionated approach means this won't suit every workflow. The skill doesn't support Hardhat or ethers.js users. The reference docs will need updating as the Stylus SDK evolves. And it's only useful if you're already using Claude Code.
MIT licensed. The whole thing is markdown files -- easy to fork, modify, or use as a template for skills in other domains.
Demo video: https://youtu.be/vsejiaOTmJA