solidity について
スマートコントラクトや Web3 フロントエンドを開発する人向けの Solidity スキルです。セキュリティ、ガス最適化、テスト、コントラクト連携の指針を扱います。
主な機能
- 01スマートコントラクトの安全設計
- 02ガスとストレージの最適化
- 03テストと静的解析の指針
- 04Web3 フロントエンド連携
活用シーン
- 01コントラクト設計の安全性確認
- 02デプロイ時と実行時のガス削減
- 03コントラクトのテスト計画
- 04型付きフロントエンドとの接続
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ mindrally/ skills --skill solidityインストール後、Claude Code で/solidityを入力して読み込まれたか確認します。
詳細
Solidity
このスキルでは、セキュリティパターン、ガス最適化、テスト/ツール、Web3 React フロントエンドとのコントラクト統合など、Solidity スマートコントラクト開発のベストプラクティスを扱います。
Core Principles
- 無駄を省きます。コードまたは詳細な説明のみを提示します
- 正確さと深さを優先しながら、簡潔さを保ちます
- まず回答し、必要に応じて後から説明します
Code Structure & Security
- 可視性修飾子を明示し、NatSpec ドキュメントを記述します
- 関数修飾子を適用して重複を減らします
- 命名規則に従います:
- コントラクトには CamelCase を使用します
- インターフェースには PascalCase を使用し、「I」を接頭辞に付けます
- インターフェース分離の原則を実装します
- アップグレード可能なコントラクトにはプロキシパターンを使用します
- 状態変更を網羅的なイベントとして出力します
- 再入可能性への対策として Checks-Effects-Interactions パターンに従います
Security Best Practices
- 権限管理には OpenZeppelin の AccessControl を使用します
- オーバーフロー/アンダーフロー保護のため、Solidity 0.8.0 以降を必須とします
- サーキットブレーカーには Pausable パターンを使用します
- 追加の保護として ReentrancyGuard を実装します
- トークンとのやり取りには SafeERC20 を使用します
- プッシュ型ではなくプル型の支払いパターンを採用します
- 機密性の高い操作にはタイムロックとマルチシグ制御を実装します
Gas Optimization
- ガス消費量を最適化します(デプロイ時と実行時)
- コンストラクターで設定する値には immutable 変数を使用します
- revert 文字列の代わりにカスタムエラーを使用します
- ストレージ変数を効率的にパッキングします
- 適切なデータ型を使用します
Tools & Analysis
- 静的解析には Slither と Mythril を統合します
- Hardhat のテスト環境と開発環境を活用します
- 堅牢な CI/CD パイプラインを実装します
- コミット前のリントツールを使用します
Advanced Patterns
- 乱数生成には Chainlink VRF を使用します
- アセンブリは慎重に使用し、詳細なドキュメントを添えます
- 複雑なロジックにはステートマシンパターンを使用します
- 特殊なトークンには ERC20Snapshot、ERC20Permit、ERC20Votes を使用します
Testing & Quality
- 単体テスト、統合テスト、エンドツーエンドテストを包括的に実施します
- プロパティベースのテスト手法を採用します
- 高いカバレッジ目標を設定します
- 定期的にセキュリティ監査を実施します
Web3 Frontend Integration
- コントラクトと通信するフロントエンドコードは、型安全かつ明示的に記述します。コントラクト呼び出しのシグネチャを手書きするのではなく、ABI から TypeScript 型を生成します(例:TypeChain または wagmi/viem codegen)
- ウォレット接続、チェーン/ネットワークの状態、トランザクションの状態は、暗黙的なブール値ではなく、明示的で型付けされた状態(接続済み/接続中/ネットワーク不一致/エラー)として扱います
- トランザクションのライフサイクルを UI 上で明確に示します:送信済み、承認待ち、承認済み、取り消し済み。送信したトランザクションが成功したと決めつけてはいけません
- ユーザーに署名を促す前に、トランザクションを検証してシミュレーションします(例:
eth_call/ガス見積もり)。これにより、早い段階で revert を検出できます - 認可の判断に、クライアント側で読み取ったコントラクトの状態を決して信頼してはいけません。必ずコントラクト自体でオンチェーンの状態を再検証します
- プロバイダー/RPC の障害や、署名リクエストに対するユーザーの拒否は、想定内の回復可能なエラー状態として処理します
コメント
Markdown 対応