grepai-trace-graph
GrepAIのトレース機能を使って完全なコールグラフを構築します。再帰的な依存関係の分析が必要な場面で活用してください。
description の原文を見る
Build complete call graphs with GrepAI trace. Use this skill for recursive dependency analysis.
SKILL.md 本文
GrepAI Trace Graph
このスキルは grepai trace graph を使用して、すべての依存関係を再帰的に表示する完全なコールグラフを構築することをカバーしています。
このスキルを使うべき場合
- 関数の完全な依存関係をマッピング
- 複雑なコードフローを理解
- 大規模なリファクタリングのための影響分析
- アプリケーションアーキテクチャを可視化
Trace Graph とは
grepai trace graph は再帰的な依存関係ツリーを構築します:
main
├── initialize
│ ├── loadConfig
│ │ └── parseYAML
│ └── connectDB
│ ├── createPool
│ └── ping
├── startServer
│ ├── registerRoutes
│ │ ├── authMiddleware
│ │ └── loggingMiddleware
│ └── listen
└── gracefulShutdown
└── closeDB
基本的な使い方
grepai trace graph "FunctionName"
例
grepai trace graph "main"
出力:
🔍 Call Graph for "main"
main
├── initialize
│ ├── loadConfig
│ └── connectDB
├── startServer
│ ├── registerRoutes
│ └── listen
└── gracefulShutdown
└── closeDB
Nodes: 9
Max depth: 3
深さの制御
--depth で再帰の深さを制限します:
# デフォルトの深さ (2レベル)
grepai trace graph "main"
# より深い分析 (3レベル)
grepai trace graph "main" --depth 3
# 浅い (1レベル、callees と同じ)
grepai trace graph "main" --depth 1
# 非常に深い (5レベル)
grepai trace graph "main" --depth 5
深さの例
--depth 1 (callees と同じ):
main
├── initialize
├── startServer
└── gracefulShutdown
--depth 2 (デフォルト):
main
├── initialize
│ ├── loadConfig
│ └── connectDB
├── startServer
│ ├── registerRoutes
│ └── listen
└── gracefulShutdown
└── closeDB
--depth 3:
main
├── initialize
│ ├── loadConfig
│ │ └── parseYAML
│ └── connectDB
│ ├── createPool
│ └── ping
├── startServer
│ ├── registerRoutes
│ │ ├── authMiddleware
│ │ └── loggingMiddleware
│ └── listen
└── gracefulShutdown
└── closeDB
JSON 出力
grepai trace graph "main" --depth 2 --json
出力:
{
"query": "main",
"mode": "graph",
"depth": 2,
"root": {
"name": "main",
"file": "cmd/main.go",
"line": 10,
"children": [
{
"name": "initialize",
"file": "cmd/main.go",
"line": 15,
"children": [
{
"name": "loadConfig",
"file": "config/config.go",
"line": 20,
"children": []
},
{
"name": "connectDB",
"file": "db/db.go",
"line": 30,
"children": []
}
]
},
{
"name": "startServer",
"file": "server/server.go",
"line": 25,
"children": [
{
"name": "registerRoutes",
"file": "server/routes.go",
"line": 10,
"children": []
}
]
}
]
},
"stats": {
"nodes": 6,
"max_depth": 2
}
}
コンパクト JSON
grepai trace graph "main" --depth 2 --json --compact
出力:
{
"q": "main",
"d": 2,
"r": {
"n": "main",
"c": [
{"n": "initialize", "c": [{"n": "loadConfig"}, {"n": "connectDB"}]},
{"n": "startServer", "c": [{"n": "registerRoutes"}]}
]
},
"s": {"nodes": 6, "depth": 2}
}
TOON 出力 (v0.26.0+)
TOON フォーマットは JSON より約 50% トークン数が少なくなります:
grepai trace graph "main" --depth 2 --toon
注:
--jsonと--toonは相互排他的です。
抽出モード
# 高速モード (正規表現ベース)
grepai trace graph "main" --mode fast
# 精密モード (tree-sitter AST)
grepai trace graph "main" --mode precise
ユースケース
アプリケーションフローを理解する
# アプリケーション起動全体をマップ
grepai trace graph "main" --depth 4
影響分析
# このユーティリティ関数に何が依存しているか?
grepai trace graph "validateInput" --depth 3
# データベースレイヤー変更の完全な影響
grepai trace graph "executeQuery" --depth 2
コードレビュー
# この関数は複雑すぎないか?
grepai trace graph "processOrder" --depth 5
# ノード数が多い = 高い複雑さ
ドキュメント
# アーキテクチャ図のデータを生成
grepai trace graph "main" --depth 3 --json > architecture.json
リファクタリング計画
# この変更で何が壊れるか?
grepai trace graph "legacyAuth" --depth 3
サイクルの処理
GrepAI は循環依存を検出してマークします:
main
├── processA
│ └── processB
│ └── processA [CYCLE]
JSON の場合:
{
"name": "processA",
"cycle": true
}
大規模なグラフ
非常に大規模なコードベースでは、グラフが圧倒的になる可能性があります:
深さを制限
# 浅く開始
grepai trace graph "main" --depth 2
特定の領域に焦点を絞る
# main の代わりに特定のサブシステムをトレース
grepai trace graph "authMiddleware" --depth 3
後処理でフィルタリング
# JSON を取得してフィルタリング
grepai trace graph "main" --depth 3 --json | jq '...'
グラフを可視化
DOT フォーマット (Graphviz) へエクスポート
# JSON を DOT に変換
grepai trace graph "main" --depth 3 --json | python3 << 'EOF'
import json
import sys
data = json.load(sys.stdin)
print("digraph G {")
print(" rankdir=TB;")
def traverse(node, parent=None):
name = node.get('name') or node.get('n')
if parent:
print(f' "{parent}" -> "{name}";')
children = node.get('children') or node.get('c') or []
for child in children:
traverse(child, name)
traverse(data.get('root') or data.get('r'))
print("}")
EOF
その後、レンダリング:
dot -Tpng graph.dot -o graph.png
Mermaid 図
grepai trace graph "main" --depth 2 --json | python3 << 'EOF'
import json
import sys
data = json.load(sys.stdin)
print("```mermaid")
print("graph TD")
def traverse(node, parent=None):
name = node.get('name') or node.get('n')
if parent:
print(f" {parent} --> {name}")
children = node.get('children') or node.get('c') or []
for child in children:
traverse(child, name)
traverse(data.get('root') or data.get('r'))
print("```")
EOF
グラフサイズの比較
時系列で複雑さを追跡:
# ノード数を取得
grepai trace graph "main" --depth 3 --json | jq '.stats.nodes'
# リファクタリング前後を比較
echo "Before: $(grepai trace graph 'main' --depth 3 --json | jq '.stats.nodes') nodes"
# ... リファクタリング ...
echo "After: $(grepai trace graph 'main' --depth 3 --json | jq '.stats.nodes') nodes"
よくある問題
❌ 問題: グラフが大きすぎる / タイムアウト ✅ 解決策:
- 深さを減らす:
--depth 2 mainではなく特定の関数をトレース--mode fastを使用
❌ 問題: 多くのサイクルが検出される ✅ 解決策: コードに循環依存があることを示しています。リファクタリングを検討してください。
❌ 問題: ブランチが欠落している ✅ 解決策:
--mode preciseを試す- ファイルがインデックスされているか確認
- 言語が有効化されているか確認
ベストプラクティス
- 浅く開始:
--depth 2から始めて、必要に応じて増やす - 分析を焦点化: 常に
mainではなく特定の関数をトレース - ドキュメント用にエクスポート: 図を生成するために JSON を使用
- 時系列で追跡: 複雑さメトリックとしてノード数を監視
- サイクルを調査: 循環依存はコードの悪い兆候です
出力フォーマット
Trace graph の結果:
🔍 Call Graph for "main"
Depth: 3
Mode: fast
main
├── initialize
│ ├── loadConfig
│ │ └── parseYAML
│ └── connectDB
│ ├── createPool
│ └── ping
├── startServer
│ ├── registerRoutes
│ │ ├── authMiddleware
│ │ └── loggingMiddleware
│ └── listen
└── gracefulShutdown
└── closeDB
Statistics:
- Total nodes: 12
- Maximum depth reached: 3
- Cycles detected: 0
Tip: Use --json for machine-readable output
Use --depth N to control recursion depth
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- yoanbernabeu
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/yoanbernabeu/grepai-skills / ライセンス: MIT
関連スキル
superfluid
Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード:Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool(member/distributor)、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper
civ-finish-quotes
実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。
nookplot
Base(Ethereum L2)上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。
web3-polymarket
Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。
ethskills
Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格(ERC-20、ERC-721、ERC-4626など)、Layer 2ネットワーク(Base、Arbitrum、Optimism、zkSync、Polygon)、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化(EIPライフサイクル、フォーク追跡、今後の変更予定)といったトピックを含みます。
xxyy-trade
このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。