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.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
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.
compatibility
Requires TRES Finance MCP connector
TRES Finance — Rollup Review
Take a fully-specified rollup rule and compute exactly which sub-transactions it
will claim — with every one of its filters applied — then flag genuine problems. You
do NOT design new rollups and you do NOT execute mutations.
All GraphQL runs through the TRES Finance MCP connector (execute tool). All
variable keys and nested input fields MUST use camelCase, never snake_case.
What this adds over tres-rollup-rules
The tres-rollup-rules discovery step groups sub-txs only at the
(wallet, asset, direction) level — it never applies a single candidate's full filter
combination (fees + method_ids + subtx_type + amount bounds + counterparty +
excludeRollups together). This skill does exactly that, per rule, via the
subTransactionRollupRulePreview query (which runs the engine's real
), giving:
query_sub_transactions
the exact match count → the zero-match gate (a rule that matches nothing must
not be created), and
pre-create overlap awareness, so the user only ever sees viable proposals.
It is also usable standalone to review a rule someone submitted (Mode B) — a case
the discovery skill doesn't cover.
Two modes
Mode A — pre-create gate (invoked by tres-rollup-rules)
When tres-rollup-rules invokes this skill (via the Skill tool), these instructions
load into the same context that already holds the candidate rule objects — they
are not passed as arguments, they are already in the conversation above. Iterate those
candidates one at a time; for each, run the checks below and emit exactly one
verdict:
PASS — clean, ready to propose (include the exact sub-tx + parent-tx count).
DROP — matches 0 sub-txs; must not be created.
FIX — a config problem with the exact change (e.g. "minAmount > maxAmount",
"recipientIdentifier on an INFLOW rule — should be senderIdentifier").
Overlaps are reported as notes, not DROP/FIX (see Check 2). Produce one verdict line
per candidate, then control returns to tres-rollup-rules Step 2.5.
Mode B — standalone review (when asked to review submitted/pending rules)
Fetch pending rules and review each; produce a per-rule findings summary.
query PendingRollupRules {
subTransactionRollupRule(status:"Pending", limit:50){
totalCount
results { id name interval startDate endDate status rule createdBy createdAt }}}
The status filter is title-case ("Pending", "Active", "Disabled"). If
totalCount is 0, say "No pending rollup requests in this org" and stop.
Ground truth — how a rule selects sub-transactions
A rule claims sub-transactions matching ALL of (this mirrors the engine's
query_sub_transactions):
The rule JSON (as stored / returned) uses snake_case. balance_factor = -1 is
OUTFLOW, +1 is INFLOW — get this right or every direction check is backwards.
type / type_In take the lowercase FinancialAction value ("gas", "fee",
"reward", …) — opposite casing from the rule's UPPERCASE subtxType enum. So
subtx_type is countable exactly (type: "<value>") and fees: ONLY ≈
type_In: ["gas", "fee"].
Gotcha: fees: ONLY already selects GAS+FEE, so a gas/fee rollup needs fees: ONLY
alone — adding subtxType: GAS on top is redundant (and narrows to GAS, dropping FEE).
typeId is NOT a rule filter here.type_id is only the rollup rule's id when
paired withtype_In: ["rollup", "rollup_fee"]. On other types it means something
else entirely. To inspect what an existing rollup rule produced, query
type_In: ["rollup","rollup_fee"], typeId: "<rule_id>" — never typeId alone.
Sentinel dates (operational note): if startDate == "0001-01-01" or
endDate == "9999-12-31", omit that bound (don't pass the sentinel — it may not parse).
Unbounded dates are normal and preferred; they are NOT a finding.
Evidence: the on-chain hash is tx.identifier (sub-select tx { identifier }),
never typeId. For examples also pull amount, sender { identifier },
recipient { identifier }, asset { symbol key }.
Scope — DISABLED rules are out of scope
Only Active and Pending rules are live. Never query, compare against, or flag
DISABLED rules (they're superseded versions).
The checks
Check 1 — Exact impact (the core; always run)
Get the ground-truth count straight from the engine via the
subTransactionRollupRulePreview query — it runs the real query_sub_transactions
with all of the rule's filters applied server-side, so you never reconstruct
filters by hand:
Pass the candidate's rule object verbatim as $rule — the same camelCase shape as the
create mutation (internalAccountId, assetId, platform + balanceFactor + fees
as enum NAMES like OUTFLOW/ONLY, plus any
methodIds/subtxType/minAmount/maxAmount/identifiers). Always pass $interval
= the candidate's interval (DAY or MONTH); it governs how the eligibility-window
boundary is normalized, so a MONTH rule and a DAY rule over the same data can return
different counts. startDate/endDate are optional YYYY-MM-DD — omit for the rule's
full unbounded range.
The count is what the rule would actually roll up on its next run, not raw all-time
matches: the engine funnels the window through its own eligibility logic, so the
current incomplete period and the unsynced/buffer tail are excluded.
transactionCount is the distinct parent-tx count. (Already-rolled-up sub-txs are also
excluded — for what an existing rule has already produced, see the existing-rule
section below.)
subTransactionCount == 0 → DROP (Mode A) / blocking flag (Mode B): "matches 0
sub-txs as configured" — name the filters that zero it out (common culprits:
minAmount > maxAmount, an identifier on the wrong direction, or an inverted date
range). The reason is the useful part.
If subTransactionRollupRulePreview is not in this org's MCP schema (confirm with
validate_query or introspect), fall back to a fully-filtered count query: a single
subTransaction(... excludeRollups: true ...) that applies every one of the rule's
filters using the verified filter-name table above, selecting only totalCount. This
is slightly less precise than the engine preview (it does not exclude the incomplete
period / buffer tail) — say so when you report the number, and keep the ~ prefix.
Check 2 — Overlap (informational, NOT a hard limit)
Another Active/Pending rule (or another candidate) on the same internalAccountId +
assetId + platform + balanceFactor with intersecting dates and non-disjoint
filters can claim some of the same sub-txs. This is not blocking: the engine
processes rules one-by-one ordered by id (PK), so a sub-tx matching multiple rules is
always claimed by the same rule consistently. Surface it as a note (other rule name + id,
up to 3 example tx hashes) so the user is aware — never DROP or force a split for overlap
alone.
No separate config-validation check. Date-order, identifier-on-wrong-direction,
mutually-exclusive prefixes, and bad cutoffTime are enforced by the create mutation
(returned as blocking validationIssues) — don't re-validate them here. A start date set
to clear a locked period is a good use, not a flag (leave the end date open).
Existing-rule impact (Mode B — reviewing an Active/Pending rule)
Do NOT call an existing rule useless because Check 1 returns a low count. A running rule
has already rolled up its pool, and those rollups are excluded from Check 1 — so a rule
that has been doing its job shows only the few recent un-rolled sub-txs. Also count what
it produced:
subTransaction(type_In: ["rollup","rollup_fee"], typeId: "<rule_id>") { totalCount }.
Report both — "currently matches N new sub-txs; has already produced M rollups". A rule
is only ineffective if it has produced ~nothing and matches ~nothing now. (If its
filter looks stale — e.g. a methodId that no longer matches new txs — say that, with
the produced-vs-current numbers, rather than "useless".)
Output
Mode A: one line per candidate back to tres-rollup-rules:
<#> <name>: PASS (<subtx>/<tx> sub-txs) / DROP — <reason> / FIX — <change>, plus any
overlap notes.
Mode B: one findings block per rule. Flat bullet list, each bullet with concrete
evidence; omit a check that found nothing. Always include the impact line. If clean:
"Reviewed (id ) — matches ~ sub-txs across ~ txs. No
issues."
Rules
Never query, compare against, or flag DISABLED rules.
Never propose new rollups or optimizations — that's tres-rollup-rules. You only
compute impact and flag problems.
Never execute mutations.
Every flag carries evidence (a count, a date, a config value, or a tx hash).
