token-integration-analyzer
作成者 trailofbitstoken-integration-analyzer は、トークン実装とトークン統合を対象にしたセキュリティレビュー用スキルです。ERC20/ERC721 の適合性、特殊なトークンパターン、オーナー権限、希少性、非標準のトークン処理をチェックし、Security Audit のワークフローを支援します。token-integration-analyzer ガイドを使えば、判断の手間を減らし、互換性リスクを見極めやすくなります。
このスキルは 83/100 の評価で、ディレクトリ候補として十分に有力です。エージェントが使うべき場面を明確に示し、トークン分析の実務フローと再利用しやすいレポート形式を備えているため、汎用的なプロンプトよりも判断の迷いを減らせます。ディレクトリ利用者にとっては、ERC20/ERC721 の統合レビューや特殊トークンのリスク分析を構造化して進めたい場合に導入候補として有力です。一方で、実際のワークフローの細部は自動化というよりドキュメントからエージェントが読み取る形になるため、その点は織り込んでおく必要があります。
- 運用範囲が明確で、トークン実装、トークン統合、オンチェーンの希少性分析、20以上の特殊トークンパターンを正面から扱っています。
- トリガーの判断がしやすく、frontmatter の説明と複数段階のワークフローにより、エージェントが使いどころを認識しやすい構成です。
- 成果物が実用的で、評価カテゴリとレポートテンプレートによってレビュー結果の出力形式を具体化できます。
- インストールコマンドや補助スクリプトは含まれていないため、実行は引き続きエージェントが記載手順を追う前提になります。
- リポジトリはドキュメント中心で、手作業の分析ステップに依存しているように見えるため、複雑な案件では速度や一貫性に制約が出る可能性があります。
token-integration-analyzer skill の概要
token-integration-analyzer でできること
token-integration-analyzer は、トークンコードとトークン向けプロトコルに特化したセキュリティレビュー skill です。トークンが本当に ERC20 や ERC721 として振る舞うか、プロトコルが変則的または非標準のトークンを安全に扱えるか、所有者権限・希少性・アップグレード経路が見えないリスクを生んでいないかを確認するのに役立ちます。
どんな人に向いているか
トークンのローンチ、DeFi 連携、vault、bridge、マーケットプレイス、あるいは第三者トークンを受け付けるあらゆるシステムをレビューしているなら、token-integration-analyzer skill を使うべきです。特に、token-integration-analyzer for Security Audit のように、アプリケーションロジックだけでなくトークンの振る舞い自体を脅威モデルに含めるチームに向いています。
何が違うのか
この skill は、よくある「この Solidity リポジトリを解析して」という汎用プロンプトではありません。トークン統合のチェックリスト、変則トークンのパターン網羅、コンテキストの掘り起こしを軸に設計されています。つまり、token-integration-analyzer の導入価値が高いのは、表面的な標準準拠チェックではなく、互換性や境界条件について意思決定に使えるレベルの出力が必要なときです。
token-integration-analyzer skill の使い方
インストールして、まず読むべきファイルを見つける
token-integration-analyzer install では、trailofbits/skills のリポジトリにある skill パスを使い、最初に SKILL.md を開きます。次に、チェックカテゴリを確認するために resources/ASSESSMENT_CATEGORIES.md、想定される出力形式を確認するために resources/REPORT_TEMPLATES.md を読みます。この 2 つのファイルが、skill がどんな証拠を求めるかを最速で把握する手がかりです。
漠然とした目的を使えるプロンプトに落とし込む
良い token-integration-analyzer usage は、まず対象を明確にするところから始まります。
- 「この ERC20 の非標準な transfer 挙動と owner control を確認してほしい」
- 「fee-on-transfer と rebasing token を、この lending protocol が安全に扱えるか評価してほしい」
- 「この NFT コントラクトの ERC721 準拠、approval 処理、mint/burn の境界ケースを確認してほしい」
chain、contract type、deployment stage、既知の特殊挙動も入れてください。トークンが upgradeable、rebasing、fee-on-transfer、pausable、proxy-based だと分かっているなら、最初に明記してください。そうした事実は、広いセキュリティ文脈よりも分析の進め方を大きく左右します。
うまく結果を出すための推奨ワークフロー
- トークン implementation を分析するのか、トークン integration を分析するのかを明示する。
- 関連するソースファイル、デプロイ済みアドレス、または repo path を渡す。
- チェックリスト形式のレビューと、簡潔なリスク要約の両方を依頼する。
- 税率、rebase、blacklist、flash minting、カスタム approval などの変則挙動に注目するよう求める。
この skill は、「問題を見つけて」ではなく、振る舞いを具体的なリスクに結びつけるよう依頼したときに最もよく機能します。
最初に読むべきもの
まず SKILL.md を開き、その後で上記 2 つの resource ファイルを使ってカテゴリとレポート形式を把握します。repo に Solidity があるなら、フルレビューの前に token contract、integration points、inheritance tree、proxy や admin module も確認してください。token-integration-analyzer guide 系のワークフローでは、この順番にすると過信を減らせて、出力の検証もしやすくなります。
token-integration-analyzer skill の FAQ
これは token contract 専用ですか?
いいえ。token-integration-analyzer skill は、token implementation と、トークンを統合する protocol の両方を対象にしています。この区別は重要です。標準的には正しい token でも、vault、AMM、bridge が ERC の標準挙動を前提にしていると危険になり得ます。
Solidity の専門家である必要がありますか?
いいえ。ただし、入力の質が高いほど結果は良くなります。初心者でも、contract 名、token type、想定挙動を言えれば使えます。トークンの特殊な仕組みを 1 文で説明できないなら、自分が本当に気にしている主要リスクを見逃すかもしれません。
なぜ通常のプロンプトではだめなのですか?
通常のプロンプトでは、変則トークンの境界条件、owner 権限の含意、標準準拠と安全な統合の違いが抜け落ちがちです。この skill は、一回きりの回答よりも、構造化された分析と再現性のあるレビュー手順が欲しいときに役立ちます。
どんなときに使わないほうがいいですか?
トークン挙動と無関係な作業や、高レベルの製品要約だけが欲しい場合は見送ってください。source context や deployment detail が不足していて、標準 ERC 挙動とカスタムロジックを見分けられないときも、相性はよくありません。
token-integration-analyzer skill を改善するには
具体的な token behavior をそのまま伝える
品質が最も大きく上がるのは、非標準メカニズムを明示することです。fee、rebases、blacklist ルール、mint control、pausability、hooks、wrapper logic、proxy upgrades の有無を伝えてください。token-integration-analyzer では、そうした詳細のほうが、単に「この token を audit して」という言い方よりずっと実用的です。
欲しい出力をはっきり指定する
security review が必要なら、チェックリストと優先度付きリスクを求めてください。integration guidance が必要なら、想定される failure mode と未対応の token class を聞いてください。launch readiness を知りたいなら、最重要の blocker を含む yes/no の判断を依頼してください。
よくある失敗パターンに注意する
最も多い失敗は、環境の指定が足りないことです。token standard、chain、proxy pattern、integration surface が曖昧だと精度が落ちます。もう一つは、本当は compatibility の問題なのに「bugs」だけを求めてしまうことです。トークンは基本的な ERC チェックに通っても、下流システムの accounting、withdrawals、pricing logic を壊すことがあります。
具体的な追加情報で反復する
最初の結果が不十分なら、怪しい function、file、address を正確に追加してから、その証拠を付けて token-integration-analyzer usage のプロンプトを再実行してください。良い追加入力の例は次のようなものです。「Token.sol の transfer、fee exemption、admin mint path に注目してほしい。protocol 側は transferFrom が true を返し、revert しない前提になっている。」
