[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M718FFX3KV2JRFVS2RCM719D":3,"skill-same:01M718FFX3KV2JRFVS2RCM719D":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M718FFX3KV2JRFVS2RCM719D","tres-rollup-review",null,"Compute the EXACT sub-transaction impact of a rollup rule in TRES Finance — every filter applied — and flag genuine problems (zero matches, overlap, config mistakes) before the rule is created. Two modes. Mode A: a pre-create quality gate invoked by the tres-rollup-rules skill to vet proposed candidate rules. Mode B: standalone review of a rule someone submitted or of existing PENDING rules. Trigger this skill when the user says \"review this rollup rule\", \"what would this rollup rule actually match\", \"preview the rollup impact\", \"how many transactions would this rule catch\", \"is this rollup rule valid\", \"validate my rollup rule\", \"check my pending rollup rules\", or \"review the rollup requests\". Do NOT use this to design or propose new rollups — that is tres-rollup-rules. This skill only measures impact and flags issues; it never executes mutations.","anthropics\u002Fclaude-plugins-community","anthropics","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F76263028?v=4","01M697XGDPXJAVQ8391V2BCYTE","Anthropic","01M718C1RS4JJFM9KNJMTCAYJG",4856,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-rollup-review\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"tres rollup review","rollup","review","catch","create","valid","filter","Connector","candidate","preview","when","impact","MCP","new","only","design","issues","mode","never","standalone","2026-11-10 10:12:30",false,"---\nname: tres-rollup-review\ndescription: >\n  Compute the EXACT sub-transaction impact of a rollup rule in TRES Finance — every\n  filter applied — and flag genuine problems (zero matches, overlap, config mistakes)\n  before the rule is created. Two modes. Mode A: a pre-create quality gate invoked by\n  the tres-rollup-rules skill to vet proposed candidate rules. Mode B: standalone review\n  of a rule someone submitted or of existing PENDING rules. Trigger this skill when the\n  user says \"review this rollup rule\", \"what would this rollup rule actually match\",\n  \"preview the rollup impact\", \"how many transactions would this rule catch\", \"is this\n  rollup rule valid\", \"validate my rollup rule\", \"check my pending rollup rules\", or\n  \"review the rollup requests\". Do NOT use this to design or propose new rollups — that\n  is tres-rollup-rules. This skill only measures impact and flags issues; it never\n  executes mutations.\ncompatibility: \"Requires TRES Finance MCP connector\"\n---\n\n# TRES Finance — Rollup Review\n\nTake a fully-specified rollup rule and compute **exactly** which sub-transactions it\nwill claim — with every one of its filters applied — then flag genuine problems. You\ndo NOT design new rollups and you do NOT execute mutations.\n\nAll GraphQL runs through the **TRES Finance MCP connector** (`execute` tool). All\nvariable keys and nested input fields MUST use **camelCase**, never snake_case.\n\n---\n\n## What this adds over tres-rollup-rules\n\nThe `tres-rollup-rules` discovery step groups sub-txs only at the\n(wallet, asset, direction) level — it never applies a single candidate's *full* filter\ncombination (fees + method_ids + subtx_type + amount bounds + counterparty +\nexcludeRollups together). This skill does exactly that, per rule, via the\n`subTransactionRollupRulePreview` query (which runs the engine's real\n`query_sub_transactions`), giving:\n\n- the **exact** match count → the **zero-match gate** (a rule that matches nothing must\n  not be created), and\n- pre-create **overlap awareness**, so the user only ever sees viable proposals.\n\nIt is also usable **standalone** to review a rule someone submitted (Mode B) — a case\nthe discovery skill doesn't cover.\n\n---\n\n## Two modes\n\n### Mode A — pre-create gate (invoked by `tres-rollup-rules`)\n\nWhen `tres-rollup-rules` invokes this skill (via the Skill tool), these instructions\nload into the **same** context that already holds the candidate rule objects — they\nare not passed as arguments, they are already in the conversation above. Iterate those\ncandidates **one at a time**; for each, run the checks below and emit exactly one\nverdict:\n\n- **PASS** — clean, ready to propose (include the exact sub-tx + parent-tx count).\n- **DROP** — matches 0 sub-txs; must not be created.\n- **FIX** — a config problem with the exact change (e.g. \"minAmount > maxAmount\",\n  \"recipientIdentifier on an INFLOW rule — should be senderIdentifier\").\n\nOverlaps are reported as **notes**, not DROP\u002FFIX (see Check 2). Produce one verdict line\nper candidate, then control returns to `tres-rollup-rules` Step 2.5.\n\n### Mode B — standalone review (when asked to review submitted\u002Fpending rules)\n\nFetch pending rules and review each; produce a per-rule findings summary.\n\n```graphql\nquery PendingRollupRules {\n  subTransactionRollupRule(status: \"Pending\", limit: 50) {\n    totalCount\n    results { id name interval startDate endDate status rule createdBy createdAt }\n  }\n}\n```\n\nThe status filter is title-case (`\"Pending\"`, `\"Active\"`, `\"Disabled\"`). If\n`totalCount` is 0, say \"No pending rollup requests in this org\" and stop.\n\n---\n\n## Ground truth — how a rule selects sub-transactions\n\nA rule claims sub-transactions matching ALL of (this mirrors the engine's\n`query_sub_transactions`):\n\n- `belongsTo_In: [internal_account_id]`, `asset_In: [asset_id]` (the asset KEY),\n  `platform` matches, `balanceFactor` matches `balance_factor`\n- already-rolled-up (`excludeRollups`) and derived\u002Flocked\u002Fsynced sub-txs excluded\n- `fees`: `EXCLUDE` drops GAS\u002FFEE, `ONLY` keeps only GAS\u002FFEE, `INCLUDE` keeps all\n- optional narrowing: `method_ids`, `min_amount`\u002F`max_amount`, `subtx_type`,\n  `sender_identifier`\u002F`recipient_identifier`,\n  `original_sender_prefix`\u002F`original_recipient_prefix`\n\nThe rule JSON (as stored \u002F returned) uses snake_case. `balance_factor = -1` is\n**OUTFLOW**, `+1` is **INFLOW** — get this right or every direction check is backwards.\n\n### Verified subTransaction filter names\n\n| Intent | Filter |\n|---|---|\n| Wallet | `belongsTo_In: [ID]` |\n| Asset by key | `asset_In: [ID]` |\n| Direction | `balanceFactor: Float` (-1 \u002F 1) |\n| Min \u002F max amount | `amount_Gte` \u002F `amount_Lte` |\n| Sender \u002F recipient | `sender_Identifier_In: [String]` \u002F `recipient_Identifier_In: [String]` |\n| Method id | `tx_MethodId: String` (single) \u002F `tx_Classification_MethodId_In: [String]` |\n| Sub-tx type | `type: String` \u002F `type_In: [String]` (lowercase FinancialAction value) |\n| Exclude already-rolled-up | `excludeRollups: true` |\n| Exclude gas\u002Ffee | `excludeGasFees: true` |\n| Dates | `timestamp_Gte` \u002F `timestamp_Lte` (DateTime) |\n\n`type` \u002F `type_In` take the **lowercase** FinancialAction value (`\"gas\"`, `\"fee\"`,\n`\"reward\"`, …) — opposite casing from the rule's UPPERCASE `subtxType` enum. So\n`subtx_type` is countable exactly (`type: \"\u003Cvalue>\"`) and `fees: ONLY` ≈\n`type_In: [\"gas\", \"fee\"]`.\n\n> Gotcha: `fees: ONLY` already selects GAS+FEE, so a gas\u002Ffee rollup needs `fees: ONLY`\n> alone — adding `subtxType: GAS` on top is redundant (and narrows to GAS, dropping FEE).\n\n**`typeId` is NOT a rule filter here.** `type_id` is only the rollup rule's id **when\npaired with** `type_In: [\"rollup\", \"rollup_fee\"]`. On other types it means something\nelse entirely. To inspect what an existing rollup rule produced, query\n`type_In: [\"rollup\",\"rollup_fee\"], typeId: \"\u003Crule_id>\"` — never `typeId` alone.\n\n**Sentinel dates (operational note):** if `startDate == \"0001-01-01\"` or\n`endDate == \"9999-12-31\"`, omit that bound (don't pass the sentinel — it may not parse).\nUnbounded dates are normal and preferred; they are NOT a finding.\n\n**Evidence:** the on-chain hash is `tx.identifier` (sub-select `tx { identifier }`),\nnever `typeId`. For examples also pull `amount`, `sender { identifier }`,\n`recipient { identifier }`, `asset { symbol key }`.\n\n---\n\n## Scope — DISABLED rules are out of scope\n\nOnly **Active** and **Pending** rules are live. Never query, compare against, or flag\nDISABLED rules (they're superseded versions).\n\n---\n\n## The checks\n\n### Check 1 — Exact impact (the core; always run)\n\nGet the ground-truth count straight from the engine via the\n`subTransactionRollupRulePreview` query — it runs the real `query_sub_transactions`\nwith **all** of the rule's filters applied server-side, so you never reconstruct\nfilters by hand:\n\n```graphql\nquery RollupPreview($rule: RollupRuleInputType!, $startDate: Date, $endDate: Date, $interval: Interval) {\n  subTransactionRollupRulePreview(rule: $rule, startDate: $startDate, endDate: $endDate, interval: $interval) {\n    subTransactionCount\n    transactionCount\n  }\n}\n```\n\nPass the candidate's rule object verbatim as `$rule` — the **same camelCase shape as the\ncreate mutation** (`internalAccountId`, `assetId`, `platform` + `balanceFactor` + `fees`\nas enum NAMES like `OUTFLOW`\u002F`ONLY`, plus any\n`methodIds`\u002F`subtxType`\u002F`minAmount`\u002F`maxAmount`\u002Fidentifiers). **Always pass `$interval`**\n= the candidate's interval (`DAY` or `MONTH`); it governs how the eligibility-window\nboundary is normalized, so a MONTH rule and a DAY rule over the same data can return\ndifferent counts. `startDate`\u002F`endDate` are optional `YYYY-MM-DD` — omit for the rule's\nfull unbounded range.\n\nThe count is **what the rule would actually roll up on its next run**, not raw all-time\nmatches: the engine funnels the window through its own eligibility logic, so the\n**current incomplete period and the unsynced\u002Fbuffer tail are excluded**.\n`transactionCount` is the distinct parent-tx count. (Already-rolled-up sub-txs are also\nexcluded — for what an *existing* rule has already produced, see the existing-rule\nsection below.)\n\n- **subTransactionCount == 0 → DROP (Mode A) \u002F blocking flag (Mode B):** \"matches 0\n  sub-txs as configured\" — name the filters that zero it out (common culprits:\n  `minAmount > maxAmount`, an identifier on the wrong direction, or an inverted date\n  range). The reason is the useful part.\n\n> **If `subTransactionRollupRulePreview` is not in this org's MCP schema** (confirm with\n> `validate_query` or `introspect`), fall back to a fully-filtered count query: a single\n> `subTransaction(... excludeRollups: true ...)` that applies every one of the rule's\n> filters using the verified filter-name table above, selecting only `totalCount`. This\n> is slightly less precise than the engine preview (it does not exclude the incomplete\n> period \u002F buffer tail) — say so when you report the number, and keep the `~` prefix.\n\n### Check 2 — Overlap (informational, NOT a hard limit)\n\nAnother **Active\u002FPending** rule (or another candidate) on the same `internalAccountId` +\n`assetId` + `platform` + `balanceFactor` with intersecting dates and non-disjoint\nfilters can claim some of the same sub-txs. This is **not** blocking: the engine\nprocesses rules one-by-one ordered by id (PK), so a sub-tx matching multiple rules is\nalways claimed by the same rule consistently. Surface it as a note (other rule name + id,\nup to 3 example tx hashes) so the user is aware — never DROP or force a split for overlap\nalone.\n\n**No separate config-validation check.** Date-order, identifier-on-wrong-direction,\nmutually-exclusive prefixes, and bad `cutoffTime` are enforced by the create mutation\n(returned as blocking `validationIssues`) — don't re-validate them here. A start date set\nto clear a locked period is a **good** use, not a flag (leave the end date open).\n\n### Existing-rule impact (Mode B — reviewing an Active\u002FPending rule)\n\nDo NOT call an existing rule useless because Check 1 returns a low count. A running rule\nhas already rolled up its pool, and those rollups are excluded from Check 1 — so a rule\nthat has been doing its job shows only the few recent un-rolled sub-txs. Also count what\nit **produced**:\n`subTransaction(type_In: [\"rollup\",\"rollup_fee\"], typeId: \"\u003Crule_id>\") { totalCount }`.\nReport both — \"currently matches N new sub-txs; has already produced M rollups\". A rule\nis only ineffective if it has produced ~nothing **and** matches ~nothing now. (If its\nfilter looks stale — e.g. a `methodId` that no longer matches new txs — say *that*, with\nthe produced-vs-current numbers, rather than \"useless\".)\n\n---\n\n## Output\n\n**Mode A:** one line per candidate back to `tres-rollup-rules`:\n`\u003C#> \u003Cname>: PASS (\u003Csubtx>\u002F\u003Ctx> sub-txs)` \u002F `DROP — \u003Creason>` \u002F `FIX — \u003Cchange>`, plus any\noverlap notes.\n\n**Mode B:** one findings block per rule. Flat bullet list, each bullet with concrete\nevidence; omit a check that found nothing. Always include the impact line. If clean:\n\"Reviewed *\u003Cname>* (id \u003Cid>) — matches ~\u003Ccount> sub-txs across ~\u003Ctx count> txs. No\nissues.\"\n\n---\n\n## Rules\n\n- Never query, compare against, or flag DISABLED rules.\n- Never propose new rollups or optimizations — that's `tres-rollup-rules`. You only\n  compute impact and flag problems.\n- Never execute mutations.\n- Every flag carries evidence (a count, a date, a config value, or a tx hash).\n","# TRES Finance — Rollup Review\n\nTake a fully-specified rollup rule and compute **exactly** which sub-transactions it\nwill claim — with every one of its filters applied — then flag genuine problems. You\ndo NOT design new rollups and you do NOT execute mutations.\n\nAll GraphQL runs through the **TRES Finance MCP connector** (`execute` tool). All\nvariable keys and nested input fields MUST use **camelCase**, never snake_case.\n\n---\n\n## What this adds over tres-rollup-rules\n\nThe `tres-rollup-rules` discovery step groups sub-txs only at the\n(wallet, asset, direction) level — it never applies a single candidate's *full* filter\ncombination (fees + method_ids + subtx_type + amount bounds + counterparty +\nexcludeRollups together). This skill does exactly that, per rule, via the\n`subTransactionRollupRulePreview` query (which runs the engine's real\n`query_sub_transactions`), giving:\n\n- the **exact** match count → the **zero-match gate** (a rule that matches nothing must\n  not be created), and\n- pre-create **overlap awareness**, so the user only ever sees viable proposals.\n\nIt is also usable **standalone** to review a rule someone submitted (Mode B) — a case\nthe discovery skill doesn't cover.\n\n---\n\n## Two modes\n\n### Mode A — pre-create gate (invoked by `tres-rollup-rules`)\n\nWhen `tres-rollup-rules` invokes this skill (via the Skill tool), these instructions\nload into the **same** context that already holds the candidate rule objects — they\nare not passed as arguments, they are already in the conversation above. Iterate those\ncandidates **one at a time**; for each, run the checks below and emit exactly one\nverdict:\n\n- **PASS** — clean, ready to propose (include the exact sub-tx + parent-tx count).\n- **DROP** — matches 0 sub-txs; must not be created.\n- **FIX** — a config problem with the exact change (e.g. \"minAmount > maxAmount\",\n  \"recipientIdentifier on an INFLOW rule — should be senderIdentifier\").\n\nOverlaps are reported as **notes**, not DROP\u002FFIX (see Check 2). Produce one verdict line\nper candidate, then control returns to `tres-rollup-rules` Step 2.5.\n\n### Mode B — standalone review (when asked to review submitted\u002Fpending rules)\n\nFetch pending rules and review each; produce a per-rule findings summary.\n\n```graphql\nquery PendingRollupRules {\n  subTransactionRollupRule(status: \"Pending\", limit: 50) {\n    totalCount\n    results { id name interval startDate endDate status rule createdBy createdAt }\n  }\n}\n```\n\nThe status filter is title-case (`\"Pending\"`, `\"Active\"`, `\"Disabled\"`). If\n`totalCount` is 0, say \"No pending rollup requests in this org\" and stop.\n\n---\n\n## Ground truth — how a rule selects sub-transactions\n\nA rule claims sub-transactions matching ALL of (this mirrors the engine's\n`query_sub_transactions`):\n\n- `belongsTo_In: [internal_account_id]`, `asset_In: [asset_id]` (the asset KEY),\n  `platform` matches, `balanceFactor` matches `balance_factor`\n- already-rolled-up (`excludeRollups`) and derived\u002Flocked\u002Fsynced sub-txs excluded\n- `fees`: `EXCLUDE` drops GAS\u002FFEE, `ONLY` keeps only GAS\u002FFEE, `INCLUDE` keeps all\n- optional narrowing: `method_ids`, `min_amount`\u002F`max_amount`, `subtx_type`,\n  `sender_identifier`\u002F`recipient_identifier`,\n  `original_sender_prefix`\u002F`original_recipient_prefix`\n\nThe rule JSON (as stored \u002F returned) uses snake_case. `balance_factor = -1` is\n**OUTFLOW**, `+1` is **INFLOW** — get this right or every direction check is backwards.\n\n### Verified subTransaction filter names\n\n| Intent | Filter |\n|---|---|\n| Wallet | `belongsTo_In: [ID]` |\n| Asset by key | `asset_In: [ID]` |\n| Direction | `balanceFactor: Float` (-1 \u002F 1) |\n| Min \u002F max amount | `amount_Gte` \u002F `amount_Lte` |\n| Sender \u002F recipient | `sender_Identifier_In: [String]` \u002F `recipient_Identifier_In: [String]` |\n| Method id | `tx_MethodId: String` (single) \u002F `tx_Classification_MethodId_In: [String]` |\n| Sub-tx type | `type: String` \u002F `type_In: [String]` (lowercase FinancialAction value) |\n| Exclude already-rolled-up | `excludeRollups: true` |\n| Exclude gas\u002Ffee | `excludeGasFees: true` |\n| Dates | `timestamp_Gte` \u002F `timestamp_Lte` (DateTime) |\n\n`type` \u002F `type_In` take the **lowercase** FinancialAction value (`\"gas\"`, `\"fee\"`,\n`\"reward\"`, …) — opposite casing from the rule's UPPERCASE `subtxType` enum. So\n`subtx_type` is countable exactly (`type: \"\u003Cvalue>\"`) and `fees: ONLY` ≈\n`type_In: [\"gas\", \"fee\"]`.\n\n> Gotcha: `fees: ONLY` already selects GAS+FEE, so a gas\u002Ffee rollup needs `fees: ONLY`\n> alone — adding `subtxType: GAS` on top is redundant (and narrows to GAS, dropping FEE).\n\n**`typeId` is NOT a rule filter here.** `type_id` is only the rollup rule's id **when\npaired with** `type_In: [\"rollup\", \"rollup_fee\"]`. On other types it means something\nelse entirely. To inspect what an existing rollup rule produced, query\n`type_In: [\"rollup\",\"rollup_fee\"], typeId: \"\u003Crule_id>\"` — never `typeId` alone.\n\n**Sentinel dates (operational note):** if `startDate == \"0001-01-01\"` or\n`endDate == \"9999-12-31\"`, omit that bound (don't pass the sentinel — it may not parse).\nUnbounded dates are normal and preferred; they are NOT a finding.\n\n**Evidence:** the on-chain hash is `tx.identifier` (sub-select `tx { identifier }`),\nnever `typeId`. For examples also pull `amount`, `sender { identifier }`,\n`recipient { identifier }`, `asset { symbol key }`.\n\n---\n\n## Scope — DISABLED rules are out of scope\n\nOnly **Active** and **Pending** rules are live. Never query, compare against, or flag\nDISABLED rules (they're superseded versions).\n\n---\n\n## The checks\n\n### Check 1 — Exact impact (the core; always run)\n\nGet the ground-truth count straight from the engine via the\n`subTransactionRollupRulePreview` query — it runs the real `query_sub_transactions`\nwith **all** of the rule's filters applied server-side, so you never reconstruct\nfilters by hand:\n\n```graphql\nquery RollupPreview($rule: RollupRuleInputType!, $startDate: Date, $endDate: Date, $interval: Interval) {\n  subTransactionRollupRulePreview(rule: $rule, startDate: $startDate, endDate: $endDate, interval: $interval) {\n    subTransactionCount\n    transactionCount\n  }\n}\n```\n\nPass the candidate's rule object verbatim as `$rule` — the **same camelCase shape as the\ncreate mutation** (`internalAccountId`, `assetId`, `platform` + `balanceFactor` + `fees`\nas enum NAMES like `OUTFLOW`\u002F`ONLY`, plus any\n`methodIds`\u002F`subtxType`\u002F`minAmount`\u002F`maxAmount`\u002Fidentifiers). **Always pass `$interval`**\n= the candidate's interval (`DAY` or `MONTH`); it governs how the eligibility-window\nboundary is normalized, so a MONTH rule and a DAY rule over the same data can return\ndifferent counts. `startDate`\u002F`endDate` are optional `YYYY-MM-DD` — omit for the rule's\nfull unbounded range.\n\nThe count is **what the rule would actually roll up on its next run**, not raw all-time\nmatches: the engine funnels the window through its own eligibility logic, so the\n**current incomplete period and the unsynced\u002Fbuffer tail are excluded**.\n`transactionCount` is the distinct parent-tx count. (Already-rolled-up sub-txs are also\nexcluded — for what an *existing* rule has already produced, see the existing-rule\nsection below.)\n\n- **subTransactionCount == 0 → DROP (Mode A) \u002F blocking flag (Mode B):** \"matches 0\n  sub-txs as configured\" — name the filters that zero it out (common culprits:\n  `minAmount > maxAmount`, an identifier on the wrong direction, or an inverted date\n  range). The reason is the useful part.\n\n> **If `subTransactionRollupRulePreview` is not in this org's MCP schema** (confirm with\n> `validate_query` or `introspect`), fall back to a fully-filtered count query: a single\n> `subTransaction(... excludeRollups: true ...)` that applies every one of the rule's\n> filters using the verified filter-name table above, selecting only `totalCount`. This\n> is slightly less precise than the engine preview (it does not exclude the incomplete\n> period \u002F buffer tail) — say so when you report the number, and keep the `~` prefix.\n\n### Check 2 — Overlap (informational, NOT a hard limit)\n\nAnother **Active\u002FPending** rule (or another candidate) on the same `internalAccountId` +\n`assetId` + `platform` + `balanceFactor` with intersecting dates and non-disjoint\nfilters can claim some of the same sub-txs. This is **not** blocking: the engine\nprocesses rules one-by-one ordered by id (PK), so a sub-tx matching multiple rules is\nalways claimed by the same rule consistently. Surface it as a note (other rule name + id,\nup to 3 example tx hashes) so the user is aware — never DROP or force a split for overlap\nalone.\n\n**No separate config-validation check.** Date-order, identifier-on-wrong-direction,\nmutually-exclusive prefixes, and bad `cutoffTime` are enforced by the create mutation\n(returned as blocking `validationIssues`) — don't re-validate them here. A start date set\nto clear a locked period is a **good** use, not a flag (leave the end date open).\n\n### Existing-rule impact (Mode B — reviewing an Active\u002FPending rule)\n\nDo NOT call an existing rule useless because Check 1 returns a low count. A running rule\nhas already rolled up its pool, and those rollups are excluded from Check 1 — so a rule\nthat has been doing its job shows only the few recent un-rolled sub-txs. Also count what\nit **produced**:\n`subTransaction(type_In: [\"rollup\",\"rollup_fee\"], typeId: \"\u003Crule_id>\") { totalCount }`.\nReport both — \"currently matches N new sub-txs; has already produced M rollups\". A rule\nis only ineffective if it has produced ~nothing **and** matches ~nothing now. (If its\nfilter looks stale — e.g. a `methodId` that no longer matches new txs — say *that*, with\nthe produced-vs-current numbers, rather than \"useless\".)\n\n---\n\n## Output\n\n**Mode A:** one line per candidate back to `tres-rollup-rules`:\n`\u003C#> \u003Cname>: PASS (\u003Csubtx>\u002F\u003Ctx> sub-txs)` \u002F `DROP — \u003Creason>` \u002F `FIX — \u003Cchange>`, plus any\noverlap notes.\n\n**Mode B:** one findings block per rule. Flat bullet list, each bullet with concrete\nevidence; omit a check that found nothing. Always include the impact line. If clean:\n\"Reviewed *\u003Cname>* (id \u003Cid>) — matches ~\u003Ccount> sub-txs across ~\u003Ctx count> txs. No\nissues.\"\n\n---\n\n## Rules\n\n- Never query, compare against, or flag DISABLED rules.\n- Never propose new rollups or optimizations — that's `tres-rollup-rules`. You only\n  compute impact and flag problems.\n- Never execute mutations.\n- Every flag carries evidence (a count, a date, a config value, or a tx hash).\n",{"name":5,"description":54,"compatibility":55},"Compute the EXACT sub-transaction impact of a rollup rule in TRES Finance — every filter applied — and flag genuine problems (zero matches, overlap, config mistakes) before the rule is created. Two modes. Mode A: a pre-create quality gate invoked by the tres-rollup-rules skill to vet proposed candidate rules. Mode B: standalone review of a rule someone submitted or of existing PENDING rules. Trigger this skill when the user says \"review this rollup rule\", \"what would this rollup rule actually match\", \"preview the rollup impact\", \"how many transactions would this rule catch\", \"is this rollup rule valid\", \"validate my rollup rule\", \"check my pending rollup rules\", or \"review the rollup requests\". Do NOT use this to design or propose new rollups — that is tres-rollup-rules. This skill only measures impact and flags issues; it never executes mutations.\n","Requires TRES Finance MCP connector","main","163301d1904c0a994539f5226ce0fcd65b8652bf","tres-finance-plugin\u002Fskills\u002Ftres-rollup-review",357,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community","https:\u002F\u002Fgithub.com\u002Fanthropics","https:\u002F\u002Fanthropic.com","2026-11-10 15:47:08",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add anthropics\u002Fclaude-plugins-community --skill tres-rollup-review",{"tool":70,"command":71},"bunx","bunx skills add anthropics\u002Fclaude-plugins-community --skill tres-rollup-review",{"tool":73,"command":74},"pnpm","pnpm dlx skills add anthropics\u002Fclaude-plugins-community --skill tres-rollup-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-rollup-review\u002FSKILL.md",true,[],[79,109,133,157,181,200],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":90,"publishedAt":49},"01M718G9QZ4B2DJVEB3MAW5ZB1","tres-wallets-upload","Upload and onboard multiple on-chain wallets or exchange accounts into Tres Finance. Use this skill whenever the user wants to add wallets, onboard wallets, import wallets, upload wallet addresses, ingest wallets, or connect exchanges into Tres — whether from a file (CSV\u002FExcel) or by typing them manually. This skill guides Claude through the full flow: wallet type selection → input collection → validation → preview with editable HTML table → exchange credential collection (if exchange) → user confirmation → batch creation via the TRES MCP API. Always trigger this skill for wallet onboarding, wallet data ingestion, or any request to \"add wallets to Tres\".","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-wallets-upload\u002FSKILL.md",[85,88,89],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000004","电子表格",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[91,92,93,94,95,96,97,98,99,100,41,101,102,103,38,104,105,106,107,108],"wallets","tres wallets upload","upload","typing","ingestion","Wallet","chain","creation","xlsx","selection","confirmation","connect","collection","api","batch","guides","on-chain","request",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":49},"01M718G5RD9064Z574RQ4SEY38","tres-upload-tx-header-validation","The exact column header names required by the TRES Finance bulk transaction CSV upload. Use whenever building, fixing, or validating the header row of a TRES manual transaction or sub-transaction upload CSV — especially after an upload fails with \"Missing required column(s): ...\". Trigger phrases include: 'fix my CSV headers', 'bulk transaction upload failed', 'missing required columns', 'validate TRES upload CSV', 'transaction CSV template headers'. This skill is ONLY about the header naming convention; it does not cover row values or upload workflow. Do NOT trigger for contacts import CSV (use tres-import-contacts), wallet upload CSV (use tres-wallets-upload), or general CSV parsing unrelated to bulk TX upload headers.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-upload-tx-header-validation\u002FSKILL.md",[],[116,93,117,118,119,120,96,121,122,123,124,125,126,127,43,128,129,130,131,132],"tres upload tx header validation","validation","bulk","do","import","parsing","for","manual","trigger","fix","missing","general","use","workflow","csv","contacts","with",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":49},"01M718G1F3DBWTX5H9RWPHHB4F","tres-tx-story","Analyze a blockchain transaction by its hash using TRES Finance MCP and generate a visual flow diagram showing all asset movements, followed by a plain-language explanation of what happened. Use this skill whenever the user provides a transaction hash and asks to \"analyze\", \"explain\", \"visualize\", \"diagram\", \"show me what happened in\", or \"tell the story of\" a transaction. Also trigger when the user pastes a tx hash (long hex string starting with 0x) and asks anything about it. Always use this skill for transaction hash analysis — do not attempt to answer from memory alone.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-tx-story\u002FSKILL.md",[139],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[141,142,143,144,145,41,39,146,147,148,149,150,151,152,153,154,155,119,156,122],"tres tx story","Story","show","memory","hex","show me","analysis","analyze","me","diagram","generate","flow","asset","blockchain","STRING","visualize",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":164,"publishedAt":49},"01M718FW5ST9J56WY4TJ5G5A7X","tres-settings-management","Manage Organization Settings and Platform Settings via the TRES MCP GraphQL API. Use when users ask about org settings, platform settings, configuration, feature flags, enable\u002Fdisable platforms, balance diff, commit strategy, cost basis, ERP, pricing, sync boundaries, or any setting read\u002Fwrite operation. Trigger phrases include \"get settings\", \"show settings\", \"update settings\", \"change settings\", \"enable platform\", \"disable platform\", \"balance diff\", \"commit strategy\", \"cost basis strategy\", \"set min sync date\", \"configure\", \"turn on\", \"turn off\".","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-settings-management\u002FSKILL.md",[163],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[165,166,167,168,143,169,41,39,170,171,172,104,173,174,175,176,177,178,179,180],"tres settings management","settings","management","SET","get","configure","ask","commit","change","organization","update","read","write","sync","mcp graphql","flags",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":189,"publishedAt":49},"01M718FND35X9DPTNR7JTX2YX8","tres-rollup-rules","Analyze an organization's sub-transaction patterns in TRES Finance, identify groups of repetitive transactions, and propose data-driven rollup rules that consolidate them into one aggregated entry per interval (daily or monthly) for cleaner ERP integration. Also lists and deletes rollup rules. Trigger this skill whenever the user asks about rollup rules, transaction aggregation, consolidating transactions, reducing transaction noise, rolling up gas fees, rolling up staking rewards, rolling up micro-transactions, or collapsing many small ledger entries into fewer summary entries. Also trigger on \"create a rollup rule\", \"suggest rollup rules\", \"what should I roll up\", \"show my rollup rules\", \"delete a rollup rule\", \"aggregate transactions\", \"too many transactions\", \"reduce transaction count\", \"roll up fees\", \"daily rollup\", \"monthly rollup\". If a wallet has too many transactions, high-frequency activity, or noisy ledger entries, proactively suggest rollup rules. For computing the EXACT impact of a single already-specified rule or reviewing submitted\u002Fpending rules, use the tres-rollup-review skill instead.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-rollup-rules\u002FSKILL.md",[187,188],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[190,191,30,143,192,96,193,41,40,194,36,31,195,148,33,196,197,198,174,199],"tres rollup rules","Rules","gas","up","reduce","consolidate","transactions","delete","data-driven","activity",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":207,"publishedAt":49},"01M718F9C31MH0XFSZ29Z4X7WD","tres-request-skill-update","Submit feedback about the TRES Claude plugin — bug reports, feature requests, skill improvements, new skill ideas, MCP issues, workflow friction, or positive feedback about what's working well. Use this skill whenever the user wants to share any kind of feedback about the plugin, its skills, or the TRES MCP. Trigger phrases include: \"submit feedback\", \"report a bug\", \"request a feature\", \"suggest an improvement\", \"I have an idea\", \"something is broken\", \"the skill isn't working\", \"I love this skill\", \"this worked great\", \"the MCP is returning wrong data\", \"the flow is confusing\", \"can you fix the skill\", \"file a skill request\", \"give feedback\", \"this could be better\". Also trigger proactively when the conversation appears to be wrapping up — e.g. the user says \"thanks\", \"that's all\", \"looks good\", \"we're done\", \"nothing else\", or any other signal that the task is complete. In that case, offer a brief feedback prompt instead of launching the full guided flow. Do NOT trigger for general questions about how a skill works — only when the user wants to submit feedback or the conversation is ending.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-request-skill-update\u002FSKILL.md",[206],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[208,108,175,209,210,211,212,213,214,193,125,45,215,43,42,216,41,39,129,217],"skill update","tres request skill update","conversation","brief","broken","submit","re","good","give feedback","you"]