claude-code-usage について
claude-code-usageは、Claude Codeでの作業に向けたスキルです。コンテキスト管理や変更計画、曖昧な指示の確認、プロンプト改善に加え、GitとFoundryの手順も扱います。
主な機能
- 01コンテキストの整理とタスク分割
- 02大規模・複数ファイル変更の計画
- 03曖昧な指示を確認する手順
- 04不完全な回答へのメタプロンプト
- 05GitとFoundryの作業手順
活用シーン
- 01編集前に複数ファイルの変更を計画
- 02曖昧な依頼に着手する前の範囲確認
- 03不完全な回答で不足情報を診断
- 04Solidityのテストとレビュー手順の実施
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ 0xlayerghost/ solidity-agent-kit --skill claude-code-usageインストール後、Claude Code で/claude-code-usageを入力して読み込まれたか確認します。
詳細
Claude Code のベストプラクティス
言語ルール
- 常にユーザーが使用している言語で回答してください。 ユーザーが中国語で質問した場合は、中国語で回答します。英語の場合は英語で回答します。
コンテキスト管理ルール
| ルール | 理由 |
|---|---|
| 1つのウィンドウにつき1つのタスク | タスクを混在させるとコンテキストが汚染され、出力の品質が低下します |
/compact より /clear を使う | コンテキストを圧縮するより、クリーンな状態から始めるほうが確実です |
複雑なタスクの後に /clear を実行する | 古いコンテキストが新しい作業に干渉するのを防ぎます |
| 重要な情報を新しいウィンドウにコピーする | コンテキストの保持に頼らず、重要な詳細を貼り付けてください |
タスク実行の戦略
| タスクの種類 | 推奨される方法 |
|---|---|
| 小規模なバグ修正(数行) | 内容を直接説明し、Claude にその場で変更させます |
| 大規模な機能追加/リファクタリング | /plan → 方針を確認 → /clear → 計画を貼り付け → 段階的に実行 |
| 複数ファイルの変更 | /plan ワークフローを必ず使用してください。計画なしに複数のファイルを変更してはいけません |
| コードの分析/学習 | Claude に直接分析を依頼します。計画は不要です |
| デバッグ | エラーメッセージ、ファイルパス、関連コードを提示し、根本原因を尋ねます |
プロンプトのテクニック
こうしましょう
- 具体的なパスを指定する:「
src/MyToken.solの_transfer関数を変更してください」 - 例を示す:「入力:100トークン、期待値:5%の手数料を差し引いた95トークン」
- 範囲を限定する:「この関数だけを変更し、ほかのコードには手を加えないでください」
- テストを参照する:「この修正で
test_transfer_feeDeductionがパスするようにしてください」
こうするのは避けましょう
- 曖昧な指示:「あの転送関数を変更してください」――どの関数ですか?どこにありますか?
- 制約のない自由形式の依頼:「もっと良くしてください」
- 1つのメッセージで無関係なタスクを複数依頼する
曖昧さの解消 — 指示が不明確な場合
ユーザーの指示が曖昧、自由形式、または複数の解釈が可能な場合は、推測して作業を進めてはいけません。指示を積極的に分析し、作業を開始する前に、考えられる解釈をすべて提示してユーザーに確認してください。
発動条件
指示が次のパターンのいずれかに当てはまる場合は、曖昧さの解消を行います。
| パターン | 例 |
|---|---|
| 対象の指定がない | 「优化一下」――何を最適化しますか? |
| 対象範囲が複数考えられる | 「加个检查」――どの関数に、どのようなチェックを追加しますか? |
| 範囲が不明確 | 「改一下权限」――追加しますか?削除しますか?どのロールですか? |
| 文脈が暗黙的 | 「跟上次一样处理」――「前回」とは何を指しますか? |
| 相反する可能性がある | 「处理一下安全问题」――どの脆弱性ですか?どの程度対応しますか? |
分析の観点
曖昧さを検出した場合は、次の観点から分析します。
- 範囲 — 影響を受ける可能性があるファイル/コントラクト/関数はどれですか?
- 操作 — どの操作が意図されていますか?(追加/変更/削除/リファクタリング/修正)
- スキルとの適合性 — どのスキルが関連しますか?各解釈を該当する /skill に対応付けてください
- 影響 — 各解釈によって、どのような副作用が生じる可能性がありますか?
- 制約 — ユーザーが暗黙に想定している範囲はありますか?
出力形式
調査結果を番号付きリストで提示します。
我检测到你的指令存在多种可能的解读,在开始之前需要确认边界:
**可能的解读:**
1. **[解读A]** — [具体描述]
- 涉及:[files / contracts]
- 关联 skill:/skill-name
- 影响范围:[scope]
2. **[解读B]** — [具体描述]
- 涉及:[files / contracts]
- 关联 skill:/skill-name
- 影响范围:[scope]
**请确认:**
- 你想要哪个解读?(可多选)
- 是否有额外的约束条件?
例
User: "处理一下这个合约的安全问题"
AI: 我检测到你的指令存在多种可能的解读:
1. **运行 Slither 静态分析** — 用 slither MCP 扫描,修复高危问题
- 关联 skill:/solidity-security
- 影响范围:仅修复工具检测到的问题
2. **手动安全审计** — 按审计清单逐项检查(重入、权限、输入验证等)
- 关联 skill:/solidity-audit
- 影响范围:完整审查,可能涉及较多修改
3. **修复已知漏洞** — 你已知有特定安全问题,需要定位并修复
- 关联 skill:/solidity-security
- 影响范围:仅限特定问题
4. **DeFi 安全加固** — 添加防鲸鱼、防闪电贷等保护机制
- 关联 skill:/defi-security
- 影响范围:可能改变合约接口
请确认你想要哪个方向?
主なルール
| ルール | 理由 |
|---|---|
| 推測しない | 誤った推測で時間を浪費するより、1回確認するほうがよいです |
| スキルとの関連を示す | 各解釈を関連する /skill に対応付け、ユーザーがどのワークフローが適用されるかを把握できるようにします |
| 確認に従う | ユーザーが「就按第2个来」と言った場合は、追加の質問をせず、すぐに作業を進めます |
| 文脈に応じて省略する | 会話履歴ですでに解釈が明確な場合は、この手順を省略して直接対応します |
メタプロンプティング — うまくいかない場合
Claude の回答が意図と異なる場合、単に言い換えて再試行するのではなく、メタプロンプティング(逆プロンプティング)を使って Claude に不足点を診断させてから、完全なコンテキストを添えて改めて依頼します。
4 種類のプロンプト
| 種類 | 使用するタイミング | テンプレート |
|---|---|---|
| 診断 | 回答が間違っていた、または不完全だったとき | 「先ほどの質問には、あなたが一度で正しい回答を出せなかった原因となる重要な情報が何か不足していましたか?1つずつ挙げてください。」 |
| 書き換え | 質問の改善方法がわからないとき | 「先ほどの質問を書き直し、一度で正しい回答を出せるよう、足りないと思われるコンテキストを補ってください。」 |
| テンプレート | 次回同じ間違いを防ぎたいとき | 「この種の質問を一度で解決するには、どのような情報を伝える必要がありますか?質問用のテンプレートを作成してください。」 |
| 事前確認 | Claude が作業を始める前 | 「コードを書き始める前に、私から提供してもらう必要がある情報をすべて挙げてください。」 |
推奨フロー
Step 1: Ask your question
↓ (answer is wrong or incomplete)
Step 2: Use [Diagnose] — "我的问题中缺少了什么?"
↓ (Claude lists missing info)
Step 3: Use [Rewrite] — "帮我重写这个问题"
↓ (Claude outputs a complete, self-contained prompt)
Step 4: Copy the rewritten prompt, `/clear`, paste and send
↓ (clean context + complete prompt = correct answer)
実践例
# Round 1 — incomplete question
User: "帮我写一个 staking 合约"
Claude: (generates a basic staking contract, but missing reward logic)
# Round 2 — diagnose
User: "我刚才的提问中缺少了哪些信息?"
Claude: "你没有说明:
1. 质押代币和奖励代币是否相同
2. 奖励分发机制(按时间/按区块/固定APR)
3. 是否需要锁仓期
4. 是否需要紧急提取功能
5. 管理员权限范围"
# Round 3 — rewrite
User: "帮我重写这个问题"
Claude: "请帮我写一个 Staking 合约,要求如下:
- 质押代币:ERC20 TOKEN_A,奖励代币:ERC20 TOKEN_B
- 奖励机制:按质押时长线性释放,年化 12%
- 锁仓期:7 天最短锁仓
- 紧急提取:支持,但扣除 10% 罚金
- 管理员:可更新奖励率,不可触碰用户质押资金
- 安全:使用 ReentrancyGuard + SafeERC20
请基于 OpenZeppelin 5.x,Solidity ^0.8.20,Foundry 项目结构。"
# Round 4 — /clear, paste rewritten prompt, get correct result
重要な原則
何を見落としたかを推測するのではなく、Claude に尋ねましょう。 メタプロンプトを 1 回使えば、試行錯誤を何度も繰り返さずに済みます。
修正後のルール
- 間違いを修正した後は、必ず最後に「同じ間違いを繰り返さないよう、
CLAUDE.mdを更新してください。」と付け加えてください。 これにより、学んだ内容がプロジェクトのメモリに保存され、今後のセッションで同じエラーが再発するのを防げます。
Git 操作のルール
- コミット前に必ず
git diffを実行して変更を確認してください - コミットのみを行い、明示的に依頼されない限りプッシュしないでください
- main/master ブランチに直接プッシュしないでください
- 特定のファイルだけをステージしてください。Solidity プロジェクトでは
.envをコミットするリスクがあるため、git add .は絶対に使わないでください
Foundry 固有のワークフロー
| 操作 | コマンド |
|---|---|
| コミット前 | forge fmt && forge test |
| コントラクトの変更後 | コンパイルを確認するために forge build を実行 |
| PR の前 | ガスへの影響を確認するために forge test --gas-report を実行 |
| テスト失敗のデバッグ | 詳細なトレースを確認するために forge test --match-test <name> -vvvv を実行 |
コマンド早見表
| コマンド | 用途 |
|---|---|
/clear | コンテキストをクリアして、最初から開始 |
/plan | 計画モードに入る — 変更前に分析 |
/help | 利用可能なコマンドをすべて表示 |
/compact | コンテキストを圧縮(代わりに /clear を使うことを推奨) |
プロジェクトレベルの設定
プロジェクトのルートに .claude/instructions.md を作成し、プロジェクト固有のルールを記述してください。Claude は会話の開始時に自動的に読み込むため、手動で読み込む必要はありません。
コメント
Markdown 対応