tres-rollup-rules

Name: tres-rollup-rules
Author: anthropics

github.com/anthropicsデータ・データベース4.8k50 回インストール2 週間前に更新

リポジトリ

tres-rollup-rules について

子取引のパターンを分析し、ERP データ向けのロールアップルールを提案する Tres Finance のエージェントスキルです。ウォレット、アセット、プラットフォーム、方向で候補を探し、取引プレビューで検証します。

主な機能

01子取引の反復パターンを分析
02ウォレット、アセット、プラットフォーム、方向で分類
03既存ルールを確認して対象の重複を回避
04候補ルールを個別にプレビュー・検証
05ロールアップルールの一覧、作成、削除

活用シーン

01頻繁な取引に日次または月次の集約ルールを提案
02一致なしや設定不備のルールを特定して除外
03既存のロールアップルールを確認または削除

MCP 対応

TRES Finance MCP connector を通じて GraphQL のクエリと変更を実行します。クエリに確信がない場合は、先に validate_query で検証する手順です。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/anthropics/claude-plugins-community --skill tres-rollup-rules

インストール後、Claude Code で/tres-rollup-rulesを入力して読み込まれたか確認します。

同梱ファイルreferences/proposal-html-template.html

詳細

TRES Finance — ロールアップルール

組織のサブトランザクションのパターンを分析し、繰り返し発生するトランザクションのグループを特定して、ERP との連携をより明確にするため、一定の間隔ごとに1件のエントリへ統合するロールアップルールを提案します。これはデータ駆動型の検出フローです。データから候補を見つけ、実際のトランザクションに照らしてそれぞれを検証したうえで、提示して作成します。

ロールアップルールは、対象とするサブトランザクションを正確に定義する4つのディメンションをキーとします。 internalAccount（ウォレット）＋ asset KEY ＋ platform ＋ balanceFactor（方向）。任意の識別フィルター（fees、methodIds、subtxType、金額の下限・上限、取引相手）を使って、さらに対象を絞り込めます。検出して提案する内容はすべて、この形式に対応している必要があります。末尾の「ルールフィールドリファレンス」を参照してください。

ロールアップは非破壊的です。元の生のサブトランザクションは常に保持され、ロールアップの内訳レポートで確認できます。

すべての GraphQL はTRES Finance MCP コネクター（execute ツール。確信がない場合は事前に validate_query で検証）を介して実行します。すべての変数キーとネストされた入力フィールドには必ず camelCase を使用してください（例：internalAccountId、balanceFactor）。snake_case は使用しないでください。

ルーティング

「ロールアップルールを提案／作成して」、「トランザクションが多すぎる」、「X をロールアップして」 → 検出パイプライン全体を実行します（以下のステップ 0～6）。これがメインフローです。
「ロールアップルールを表示／一覧表示して」 → セクション A（既存ルールの一覧表示）を実行して終了します。
「ロールアップルールを削除して」 → セクション C（ルールの削除）を実行します。
「この特定のルールを確認して」／「このルールは何に一致する？」 → tres-rollup-review スキルに引き継ぎます。

ステップ 0 — 対象範囲の確認

ユーザーと対象範囲を確認しますが、簡潔に進めてください。対象範囲が限定されるのは分析だけで、ルール自体は通常、広く適用されます。

分析期間（任意）

期間を指定すると、検出クエリの対象が絞られ、最近の代表的なアクティビティを確認できます。必須ではなく、ルールの日付範囲でもありません。

「2025年第1四半期」→ 開始：2025-01-01T00:00:00Z、終了：2025-03-31T23:59:59Z
「過去3か月」→ 今日を基準に計算します

ユーザーが期間を指定しない場合は、全期間を分析します。これは一般的な方法で、問題ありません。

ルールの日付範囲（終了日なしを推奨）

作成するルールには、通常、開始日／終了日を設定しないでください。デフォルトでは「開始時点から無期限」となり、今後も一致するトランザクションを取り込み続けます。ユーザーがルールの期間を明示的に限定したい場合にのみ、startDate／endDate を設定します。

ウォレット（任意、デフォルト：すべて）

ユーザーは特定のウォレットに対象を限定できます。

アセットクラス（任意、デフォルト：スパム以外すべて）

ユーザーは特定のアセットクラスに対象を限定できます（例：「ステーブルコインのみ」「ETH」）。1つのクラス（例：USDC）が多数のアセットキー／チェーンにまたがることがありますが、各ルールが対象とするキーは1つです。ステップ 2 のアセットクラスの対応付けを参照してください。

クラスタリングの指針（任意）

「ガス代に注目して」「10ドル未満のステーキング報酬は無視して」「methodId ごとに ETH の送金をグループ化して」といったヒントを指定できます。

対象範囲を簡潔に確認してから開始します。

「すべてのウォレットとすべてのアセットを対象に、ロールアップ候補を確認します（全期間を分析します）。指定がなければ、提案するルールに期間の制限は設けません。それでは開始します。」

ステップ 1 — インベントリ

以下を実行します（可能な場合は並行して実行します）。

1a. ウォレット

query Wallets { internalAccount { totalCount results { id name identifier parentPlatform platforms balancesCount status } } }

ウォレットの id（整数）を収集します。これはルールの internalAccountId です。platforms（複数形のリスト）と parentPlatform（文字列）を使用してください。ウォレットには単数形の platform フィールドはありません。

1b. 既存のロールアップルール（対象の重複を避けるため）

query ExistingRules { subTransactionRollupRule { totalCount results { id name interval status startDate endDate createdBy lastSuccessfulRunAt rule } } }

rule は JSON 設定です（internal_account_id、asset_id、platform、balance_factor、fees、…）。Active または Pending のルールですでに対象となっている（account、assetKey、direction）の組み合わせを確認し、それらはスキップしてください。Disabled のルールは無視します（無効なルールは後継バージョンであり、現在有効な対象範囲ではありません）。また、組織の命名規則を把握するため、既存ルールの名前も確認してください（後述の「命名」を参照）。

1c. 対象範囲内のサブトランザクション数

query InScope($ts_Gte: DateTime, $ts_Lte: DateTime) {
  subTransaction(timestamp_Gte: $ts_Gte, timestamp_Lte: $ts_Lte) { totalCount }
}

（すべての履歴を分析する場合は、タイムスタンプ引数を完全に省略してください。）

レポート：「ウォレット X 件、既存ルール Y 件（うち有効 Z 件）、対象範囲内のサブトランザクション N 件が見つかりました。」

Step 2 — 検出（中核となる分析）

集計クエリを使用して、（ウォレット、資産、方向）のグループのうち、反復量が最も多いものを特定し、判別に役立つフィルターを詳しく調べます。

フィルター名のリファレンス（検証済み — これらの名前を正確に使用）

ウォレット：belongsTo_In: [ID]（1つの ID でも配列）
キーによる資産指定：asset_In: [ID]（資産キーの配列。例：["ethereum_native"]）
資産クラス：asset_AssetClass_In: [ID]
方向：balanceFactor: Float（-1 = OUTFLOW、1 = INFLOW）
金額：amount_Gte / amount_Lte；法定通貨：fiatValue_Gte / fiatValue_Lte
取引相手：sender_Identifier_In: [String]、recipient_Identifier_In: [String]
メソッド：tx_MethodId: String（単一指定）または tx__method_id でグループ化
サブトランザクションの種類：type: String / type_In: [String]（FinancialAction）— 小文字の値（"gas"、"reward"、…）でフィルターします。mutation の大文字の subtxType 列挙値とは大文字・小文字が逆であることに注意してください。groupBy: ["type"] も使用できます。
日付：timestamp_Gte / timestamp_Lte
ロールアップ済みのサブトランザクションを除外：excludeRollups: true
ガス／手数料のサブトランザクションを除外：excludeGasFees: true；スパムを除外：excludeSpam: true
内部送金のみ：internalTransfer: true

ロールアップ済みのサブトランザクションは常に除外する

すべての検出／件数クエリに excludeRollups: true を追加してください。これにより、ROLLUP / ROLLUP_FEE サブトランザクションが除外され、カウントが新しいルールで実際に取り込まれる件数を反映します。これはロールアップエンジン自体の選択方法と一致します。これを指定しないと、以前のルールですでにロールアップされたグループが二重にカウントされます。（onlyRollup: false では除外されません。これは何もしません。）既存のルールが生成した結果を調べるには、type_In: ["rollup", "rollup_fee"], typeId: "<rule_id>" を指定してクエリを実行します。typeId がロールアップルール ID を意味するのは、ロールアップの type と組み合わせた場合のみです。

2a. ルールの実際のキーでグループ化する（ウォレット ID + 資産キー + プラットフォーム + 方向）

query GroupByKey($ts_Gte: DateTime, $ts_Lte: DateTime) {
  subTransaction(
    timestamp_Gte: $ts_Gte, timestamp_Lte: $ts_Lte,
    excludeRollups: true,
    groupBy: ["belongs_to", "asset", "platform", "balance_factor"],
    aggregations: [
      { field: id, function: COUNT, alias: "count" },
      { field: fiatValue, function: AVG, alias: "avgFiat" }
    ]
  ) {
    groupedAggregations { groupKey results { alias value } }
  }
}

groupKey から、ウォレットの ID（→ internalAccountId）、資産のキー（→ assetId）、プラットフォーム、balanceFactor が得られます。ルールに必要な4つのフィールドが正確に含まれており、名前やシンボルを推測する必要はありません。サブトランザクションが約50件未満のグループは、ルールを作成する価値がほとんどありません。

資産クラスとの対応付け

ユーザーは資産の クラス（「USDC をすべてロールアップする」）で考えますが、ルールが対象にするのは1つの資産キーです。ユーザーがクラスを指定した場合、優先順位を付けるために、まず asset__asset_class__symbol でグループ化してもかまいません。ただし、その後、可能性のある各クラスを具体的な資産キーに展開し（Step 2a ですでにキーが返されます）、（ウォレット、assetKey、プラットフォーム、方向）の組み合わせごとに1つのルールを提案する必要があります。レポートには、同じウォレット内の関連キーも記載し、各ルールが対象とするバリエーションと対象外のバリエーションをユーザーが確認できるようにしてください。

2b. methodId で詳しく調べる（重要なグループごと）

query DrillMethod($ts_Gte: DateTime, $ts_Lte: DateTime, $belongsTo_In: [ID], $asset_In: [ID], $balanceFactor: Float) {
  subTransaction(
    timestamp_Gte: $ts_Gte, timestamp_Lte: $ts_Lte,
    belongsTo_In: $belongsTo_In, asset_In: $asset_In, balanceFactor: $balanceFactor,
    excludeRollups: true,
    groupBy: ["tx__method_id"],
    aggregations: [
      { field: id, function: COUNT, alias: "count" },
      { field: amount, function: AVG, alias: "avgAmount" },
      { field: amount, function: MAX, alias: "maxAmount" }
    ]
  ) {
    groupedAggregations { groupKey results { alias value } }
  }
}

2c. サブトランザクションの種類で詳しく調べる（任意）

同じ形式のクエリを groupBy: ["type"] を指定して繰り返し、特定のサブトランザクションの種類がグループの大部分を占めているか確認します。これは subtxType ルールを使用する場合にのみ役立ちます。

分析方針

最適なルールの組み合わせを判断するには、次の点を考慮します。

カバレッジ — 各ルールがグループの意味のある割合を対象にする必要があります。
識別フィルター（有用な場合。必須ではありません） — 4 つの主要フィールド（wallet + assetKey + platform + direction）と fees で、ほとんどのルールを完全に定義できます。異質なグループをより明確に絞り込める場合に限り、任意の絞り込みフィルター（methodIds、金額の範囲、counterparty、または subtxType）を追加します。優れたルールの多くでは、これらを一切使用しません。特に subtxType は任意です。反射的に追加しないでください。
間隔 — 頻度の高いグループ（サブトランザクションが約 500 件超）では DAY、それ以外では MONTH を指定します。
既存のルール — Active/Pending ルールですでにカバーされている（account、assetKey、direction）の組み合わせはスキップします。既存のルールを現在のマッチ数だけで判断してはいけません。稼働中のルールは、すでに対象のプールをロールアップしているため、残っているライブ（ロールアップされていない）サブトランザクションは、最近処理されていないわずかな件数だけです。よく機能しているルールでも、アイドル状態に見えることがあります。実際に何を処理したか確認するには、そのルールが生成したロールアップを数えます。 subTransaction(type_In: ["rollup","rollup_fee"], typeId: "<rule_id>")。ルールがほとんど何も生成しておらず、かつ現時点でもほとんどマッチしない場合に限り、効果がないと判断してください。
重複（ソフト） — 同じ wallet + assetKey + platform + direction を対象にする 2 つのルールのフィルターが互いに排他的でない場合、同じサブトランザクションが両方の対象になることがあります。これは致命的な問題ではありません。エンジンはルールを ID（PK）の決定論的な順序で処理するため、重複するサブトランザクションは常に同じルールに割り当てられます。重複しないルールを優先しますが、重複は注意事項であり、妨げになるものではありません。

候補ごとに、この組み合わせを選んだ理由を記録してください。

ステップ 2.5 — 候補の検証（必須の品質ゲート）

この時点で、ステップ 2 で作成した N 個の候補ルールオブジェクトがコンテキストにあります。tres-rollup-review スキルを（Skill ツール経由で）1 回呼び出してください。これにより、レビュー項目が自身のコンテキストに読み込まれます（別のエージェントではなく、引数も不要です。候補はすでにここにあり、渡すものはありません）。次に、その指示に従い、候補を1 つずつ確認します。候補ごとに、レビューのチェック 1（subTransactionRollupRulePreview を 1 回呼び出す）、チェック 2、チェック 3 を実行し、サブトランザクション数と親トランザクション数を正確に記載した判定を記録します。つまり、候補 10 個なら、プレビュー呼び出し 10 回、判定 10 件です。

結果に応じて対応します。

DROP — サブトランザクションに1 件もマッチしない候補は削除します（ルールが何も処理しないためです）。
FIX — 設定の問題（開始日と終了日の逆転、最小値が最大値を超えている、識別子と方向の不一致、互いに排他的なプレフィックス、不正な cutoffTime）を修正します。
記録 — レポートに、他の候補または Active/Pending ルールとの重複を記載します。重複は参考情報です（エンジンは ID に基づいて決定論的に解決します）。そのため、ユーザーがより明確な分離を希望する場合にのみ調整し、重複だけを理由に削除してはいけません。

DROP となった候補や、未解決の FIX がある候補はステップ 3 に進めません。このゲートによって提案の品質が保たれるため、スキップしないでください。

命名ロールアップルール

提案するルールにはすべて、明確で一貫性のある name が必要です。次のように決めてください。

まず、組織内の既存の命名規則に合わせます。 Step 1b で取得した Active/Pending ルール名から、組織のパターン（区切り文字、フィールドの順序、大文字・小文字の使い方、方向／手数料／間隔の表記方法）を推測し、新しいルールも同じ形式で命名して、既存のルールに自然に並ぶようにします。
既存のパターンが明確でない場合は、次の形式を使います。 <wallet name> - <asset symbol> - <direction> <fees label> に (<interval>) を付けます。手数料ラベルは次のように対応します。
- fees: ONLY → fees（例：「gas fees」）
- fees: INCLUDE → include fees
- fees: EXCLUDE → exclude fees 例：EVM Exec Wallet 1 - ETH - outflow fees (monthly)。1 つの識別フィルター（既知のメソッドなど）でルールが定義される場合は、そのフィルターを名前に含めます（例：… - LP exits (daily)）。

名前は人が読みやすく、提案内で一意になるようにしてください。HTML レポート、提案テーブル、作成ミューテーションの name フィールドで同じ名前を使用します。

Step 3 — 結果を提示する

3a. HTML 提案レポート

作業ディレクトリに独立した .html ファイル（例：rollup-rules-proposal.html）を書き込み、ユーザーが開けるようにパスを伝えます。references/proposal-html-template.html のテンプレートとパターンをそのまま使用してください。CSS と骨組みはそのままコピーし、`` コメントだけを実際のデータ行に置き換えます。CSS やレイアウトを再生成してはいけません。この参照ファイルには、サマリーカード、提案ルールテーブル、スキップされた候補のテーブル、候補ごとの 「Preview matched txs」 台帳リンク、影響バッジ、ハッシュ／アドレスの表示ルールが記載されています。HTML は簡潔にしてください（本文は 4000 トークン未満を目標にします）。

参照ファイルに記載された重要な内容は次のとおりです。

Volume 列は必ず Volume (sub-tx / tx) とし、値には必ず ~ を付けます（例：~1,240 / ~310）。この値は rollup_review によって検証された sub-tx 数と異なる親 tx の数です。~ は、Preview リンクの台帳フィルターではすべてのルールフィルターを正確に表現できないことを示します。
影響バッジ：取引量が多いのは良い結果であり、決して警告ではありません。HIGH は緑、MEDIUM はインディゴ、LOW はグレーにします。赤は実際の問題（🟢／🟡／🔴 の検証ステータス）にのみ使用し、影響の表示には使用しません。
スキップされた候補のテーブル：rollup_review ゲートによって除外された候補（例：「一致する sub-tx が 0 件」「ルール #38211 と重複」）を含めます。

3b. 提案タスクテーブル

チャット内に番号付きの Markdown テーブルを提示します。ユーザーが番号で承認できるよう、提案ルールごとに 1 行を設けます。列：#、Rule Name、Wallet (id)、Asset / Platform、Direction、Filter、Volume (sub-tx / tx)、Interval、Validated Impact。優先度の目安：sub-tx が 1000 件を超える場合は HIGH、200～1000 件の場合は MEDIUM、200 件未満の場合は LOW。

Step 4 — ユーザーによる確認

ユーザーに次のように尋ねます。

「ロールアップルールを X 件提案しました（すべて実際のトランザクションで検証済みです）。上のレポートとテーブルを確認してください。次のいずれかを選べます。」

すべて承認 — 提案したルールをすべて作成します

特定のルールを承認 — 番号を指定してください

フィードバックを提供 — 調整したい内容を教えてください。再分析します

キャンセル — ルールは作成されません

続行する前にユーザーの応答を待ってください。明示的な確認なしに、ルールを作成してはいけません。

ステップ 5 — ルールの作成

承認されたルールについては、MCP の execute ツールを使って createSubTransactionRollupRules ミューテーションを実行します（一括処理に対応しており、ルールごとの結果と検証上の問題が返されます）。

mutation CreateRollupRules($rules: [RollupRuleCreationRequest]!) {
  createSubTransactionRollupRules(rules: $rules) {
    results {
      rollupRuleId
      validationIssues { blocking type message }
    }
  }
}

$rules の各エントリ（すべて camelCase）：

{
  "name": "ETH outflow gas — wallet-1 (daily)",
  "interval": "DAY",
  "createdBy": "AI",
  "rule": {
    "internalAccountId": 123,
    "assetId": "ethereum_native",
    "platform": "ETHEREUM",
    "balanceFactor": "OUTFLOW",
    "fees": "ONLY",
    "methodIds": ["0x573ade81"]
  }
}

監査証跡でルールの作成者が AI として記録されるよう、必ず createdBy: "AI" を設定します。
ユーザーがルールに期間を指定することを希望しない限り、startDate / endDate は省略します。省略すると、ルールの適用期間は無期限になります。
ユーザーまたは分析で実際に設定したオプションのフィルターフィールドだけを含めます。未使用のオプションフィールドに null を指定せず、rule オブジェクトから省略してください。
新しいルールの作成を優先します。既存の PENDING ルールの編集（トップレベルの ruleId: <id> を指定）はサポートされていますが、保留中のルールは遅延後に自動承認される場合があります。そのため、インプレース編集は有効化と競合する可能性があります。保留中のルールを編集するのは、ユーザーが明示的に依頼した場合に限ってください。

列挙型の値（GraphQL の列挙型。クエリ内では引用符で囲みません）：

interval：DAY または MONTH
platform：大文字 — ETHEREUM、BASE、SOLANA、BITCOIN、…
balanceFactor：INFLOW（流入、+1）または OUTFLOW（流出、-1）
fees：INCLUDE（トランザクションとその手数料）、EXCLUDE（手数料なしのトランザクション）、ONLY（手数料のサブトランザクションのみ — GAS と FEE を選択）。ガス／手数料のロールアップでは、fees: ONLY だけを指定します。subtxType: GAS/FEE も設定しないでください。ONLY ですでに対象になっており、subtxType: GAS を追加すると冗長なうえ、FEE のサブトランザクションが誤って除外されます。
subtxType：FinancialAction の列挙型または null — 例：REWARD、NATIVE_TRANSFER、TOKEN_TRANSFER。ガス／手数料のロールアップでは null のままにします（代わりに fees: ONLY を使用します）。
createdBy：AI

プラットフォームの大文字・小文字表記： クエリのフィルターでは小文字（subTransaction(asset_In: [...])、asset(platform: "ethereum")）、ミューテーションの入力では大文字の列挙型を使います（rule.platform: ETHEREUM）。クエリの戻り値も大文字です。

サーバーが適用する検証ルール（これらに違反するルールは絶対に提案しないでください）：

senderIdentifier は INFLOW ルールでのみ有効です。recipientIdentifier は OUTFLOW ルールでのみ有効です（流出では送信元は常にユーザーのウォレットであり、逆の場合も同様です）。
senderIdentifier と originalSenderPrefix は同時に指定できません。recipientIdentifier と originalRecipientPrefix も同時に指定できません。
startDate は endDate より前である必要があります。
同一のルール（同じ rule JSON）を同じ組織に重複して作成することはできません。

ミューテーションは一致するトランザクションと重複も再確認し、validationIssues として返します。ロールアップレビューのゲートですでに検出されているはずですが、最終的な判断はサーバーが行います。

`assetId` と `internalAccountId` の解決

internalAccountId（整数）：ステップ 1 のウォレット一覧から取得します。
assetId はアセットのキーです = "<platform_lowercase>_<identifier>"。ネイティブトークン：ethereum_native、base_native、solana_native。ERC-20：ethereum_0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48（USDC）。ステップ 2a ではすでに groupKey にキーが返されます。それ以外の場合は、次のように検索してください：

query AssetKeys { asset(key_In: ["ethereum_native"]) { results { key identifier platform symbol name parentPlatform } } }

ステップ 6 — 結果の報告

一括処理のレスポンスに含まれるルールごとの結果について、ステータスがひと目でわかるよう色分けして報告します — 🟢 緑 = 問題なく作成、🟡 黄 = ブロック対象ではない検証上の問題がある状態で作成、🔴 赤 = ブロック／未作成：

rollupRuleId が存在し、validationIssues がない → 🟢 作成済み
rollupRuleId が存在し、ブロック対象ではない validationIssues のみがある → 🟡 作成済み。問題も報告
blocking: true の validationIssues がある（rollupRuleId は存在しない）→ 🔴 失敗。message を引用

作成されたルールは PENDING ステータスで開始し、次回の処理サイクルで有効になります。ステップ 3 の報告で、提案されたルールごとの rollup_review の検証結果を伝える際にも、同じ 🟢／🟡／🔴 の色分けを使用してください。

A. 既存のロールアップルールを一覧表示する

ユーザーが現在のルールを確認したいだけの場合：

query ListRollupRules($limit: Int, $offset: Int, $status_In: [String]) {
  subTransactionRollupRule(limit: $limit, offset: $offset, status_In: $status_In) {
    totalCount
    results { id name interval startDate endDate nextActivationDate status rule }
  }
}

変数：{"limit": 50, "offset": 0}（フィルターするには status_In: ["Active"] などを追加します。 status はタイトルケースです）。番号付きの Markdown テーブルで表示します。列は Name、ID、Status、Interval、 Date range（または「indefinite」）、および主要なルールフィルター（wallet、asset、direction、fees、任意のフィルター）とします。totalCount > 50 の場合はページネーションします。

C. ロールアップルールを削除する

API 経由で削除できるのは PENDING ルールのみです。Active ルールについては TRES サポートが必要です。

まずルールを一覧表示し（セクション A）、ユーザーが削除対象を特定できるようにしてから、削除前にルール ID を確認します。

mutation DeleteRollupRules($ruleIds: [Int]!) {
  deleteSubTransactionRollupRules(ruleIds: $ruleIds) {
    results { deletedIds failures { ruleId reason } }
  }
}

deletedIds（削除成功）と failures（理由付き。通常はルールがすでに Active です）を報告します。

ルールフィールドのリファレンス（RollupRule）

必須： internalAccountId（int）、assetId（asset key）、platform（enum）、 balanceFactor（INFLOW/OUTFLOW）、fees（INCLUDE/EXCLUDE/ONLY）。

任意（安全なデフォルト値があります。必要な場合のみ設定）： senderIdentifier、 recipientIdentifier、originalSenderPrefix、originalRecipientPrefix、methodIds（リスト）、 maxAmount、minAmount、excludeFiat（デフォルトは false）、excludeInternal（デフォルトは false）、subtxType（FinancialAction）、bufferInDays（デフォルトは 0。遅れて到着する txs を待つ日数）、 cutoffTime（"HH:MM"）、rollupInternalTransfersOnly（デフォルトは false。 true の場合、内部振替のみがロールアップされ、ロールアップはその流入とペアになります。システムは mergeWithInflowTx と runInternalTransferClassificationOnRollups も設定します）。

トップレベルのリクエストフィールド： name（必須）、interval（必須）、rule（必須）、 startDate（任意）、endDate（任意）、ruleId（任意。PENDING ルールを編集する場合）、 createdBy（AI を設定）。

FinancialAction の列挙値（subtxType 用）： TRACE_TRANSFER, TOKEN_TRANSFER, NATIVE_TRANSFER, DELEGATION, UNDELEGATION, VEST, UNVEST, VALIDATOR_CREATION, REWARD, COMMISSION, GAS, FEE, EXCHANGE_WITHDRAWAL, EXCHANGE_DEPOSIT, EXCHANGE_TRANSFER, EXCHANGE_BUY, EXCHANGE_SELL, EXCHANGE_LOAN, EXCHANGE_SETTLEMENT, REBATE, FIAT_TRANSFER, BURNED, ROLLUP, ROLLUP_FEE, PLUG, GROUP, FUNDING, INTEREST, TRANSFER_DELEGATION_REWARD, REEVALUATION, PAYMENT, BANK_DEPOSIT, BANK_WITHDRAWAL, MINING_REWARD.

ルール

コンテキストを小さく保つ — 集計を使用し、結果セット全体を取得しないでください。
可能な場合は検出クエリを並列実行します。
提示前に必ず Step 2.5 の rollup_review ゲートを実行します。
分析後は必ず HTML レポートと提案テーブルの両方を作成します。
提案する各ルールについて、理由を説明します。
作成前に必ず確認します — 提案全体を提示し、作成ミューテーションを呼び出す前に明示的な承認を待ちます。
レポートの提示後、簡潔な会話形式の要約を提供します。
ディメンションを選択する際は、ユーザーのクラスタリングに関する指針を取り入れます。

制限事項 — MCP では利用できません

Active ルールの編集 — Active ルールを編集する方法はありません。再作成してください（PENDING ルールは ruleId を使って編集するか、削除して再作成できます）。
ルールの有効化／無効化 — API から直接制御するのではなく、バックエンドの処理パイプラインによって管理されます。
ロールアップの内訳の表示 — 集計された元トランザクションの詳細な内訳は、TRES ダッシュボードの Rollup Breakdown レポートにあります。
Active ルールの削除 — API 経由で削除できるのは PENDING ルールのみです。Active ルールについてはユーザーに TRES サポートへの問い合わせを案内してください。

Markdown 対応

ログインしてコメント

基本情報

作者: anthropics
リポジトリ: anthropics/claude-plugins-community
カテゴリ: データ・データベース
インストール数: 50
GitHub スター: 4,789

問題を報告