[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M718E4DDSK72C6M7K1MH9PMC":3,"skill-same:01M718E4DDSK72C6M7K1MH9PMC":76},{"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":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M718E4DDSK72C6M7K1MH9PMC","tres-invoice-bill-matching",null,"Match TRES ledger transactions to ERP invoices\u002Fbills (AP\u002FAR) and optionally sync them to the connected ERP (Xero, QuickBooks Online, NetSuite). Trigger this skill whenever the user wants to match, link, close, reconcile, or sync an invoice or bill against a blockchain transaction — even if they don't say \"skill\" or use those exact words. Trigger phrases include: \"match this invoice to a transaction\", \"match a bill to tx\", \"close invoice INV-123\", \"close bill 9988\", \"link this tx to a bill\", \"pay this invoice from this transaction\", \"set up this tx as AP\", \"set up this tx as AR\", \"sync this transaction as AP\u002FAR\", \"match AP\u002FAR\", \"find the invoice\u002Fbill for this hash\", \"what bill does this tx pay\". Trigger ONLY for explicit AP\u002FAR matching\u002Fclosing intent — do NOT trigger for general transaction explanations (use tres-tx-story), for ingesting an explorer link into the ledger (use tres-explorer-tx-to-ledger), or for ERP connection setup itself (use tres-settings-management).","anthropics\u002Fclaude-plugins-community","anthropics","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F76263028?v=4","01M697XGDPXJAVQ8391V2BCYTE","Anthropic","01M718C1RS4JJFM9KNJMTCAYJG",4869,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-invoice-bill-matching\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],"invoice","matching","tres invoice bill matching","as","erp","blockchain","quickbooks","reconcile","sync","close","intent","closing","xero","transactions","ar","pay","only","up","netsuite","SET","2026-11-10 10:12:30",false,"---\nname: tres-invoice-bill-matching\ndescription: >\n  Match TRES ledger transactions to ERP invoices\u002Fbills (AP\u002FAR) and optionally sync them to the connected ERP\n  (Xero, QuickBooks Online, NetSuite). Trigger this skill whenever the user wants to match, link, close,\n  reconcile, or sync an invoice or bill against a blockchain transaction — even if they don't say \"skill\" or\n  use those exact words. Trigger phrases include: \"match this invoice to a transaction\", \"match a bill to tx\",\n  \"close invoice INV-123\", \"close bill 9988\", \"link this tx to a bill\", \"pay this invoice from this transaction\",\n  \"set up this tx as AP\", \"set up this tx as AR\", \"sync this transaction as AP\u002FAR\", \"match AP\u002FAR\", \"find the\n  invoice\u002Fbill for this hash\", \"what bill does this tx pay\". Trigger ONLY for explicit AP\u002FAR matching\u002Fclosing\n  intent — do NOT trigger for general transaction explanations (use tres-tx-story), for ingesting an explorer\n  link into the ledger (use tres-explorer-tx-to-ledger), or for ERP connection setup itself (use tres-settings-management).\n---\n\n# TRES — Invoice\u002FBill Matching & ERP Sync\n\nEnd-to-end workflow that lets the user close an open ERP invoice or bill against a blockchain transaction in\nthe TRES ledger, then optionally push the matched entry to the connected ERP.\n\nThe flow is the same regardless of which side the user starts from (a transaction hash or an invoice\u002Fbill ID).\nThe skill walks through seven conversational steps (verify ERP → identify input → fetch & suggest → user picks\n→ configure payment account & fiat → confirm & apply → loop). Stay terse — show numbered options, capture the\nuser's pick, move on. Never run a mutation without explicit \"yes\" from the user.\n\n---\n\n## Ground rules\n\n1. **Identify the org first.** Begin with `get_viewer` and tell the user \"You're connected to **{orgName}**.\"\n   This makes mistakes recoverable when someone has the wrong token.\n2. **Read before write.** Always fetch the current state of the transaction, invoice\u002Fbill, and payment account\n   before showing a change summary. Surprises are worse than slow.\n3. **Mutations require explicit approval.** Show a summary table (Transaction · Invoice\u002FBill · Payment Account ·\n   Fiat alignment · Sync) and ask \"Apply these changes?\" before any mutation. Only proceed on a clear yes.\n4. **Use schema introspection when in doubt.** Field names, enum values, and argument shapes can drift. If a\n   query\u002Fmutation errors with \"unknown field\" or \"invalid enum\", call `introspect(\u003CTypeName>)` or\n   `build_query(\u003CoperationName>)` and adjust — don't guess. Operations specifically called out as \"verify at\n   runtime\" below are the ones most likely to need this.\n5. **The skill is a loop.** After a successful match, ask \"Match another?\" and restart from Step 2. Don't\n   re-check the ERP — that only happens once per session.\n\n---\n\n## Step 1 — Verify ERP is connected\n\nRun:\n```graphql\nquery { integration(first: 50) { results { id integratedApp isErp connectionStatus companyName } } }\n```\n\nFilter the results where `isErp == true` and `connectionStatus == \"ACTIVE\"`. The supported ERPs you should\nrecognize are **Xero**, **QuickBooks Online (QBO)**, and **NetSuite** — `integratedApp` values are `XERO`,\n`QUICKBOOKS`, and `NETSUITE`. (If you encounter unknown values, `introspect(\"IntegrationsQueryNode\")` will\nconfirm the enum.) Ignore rows where `integratedApp` is empty — the API occasionally returns a null row.\n\n- **No connected ERP:** Tell the user they need to connect one before matching can happen, point them at\n  `https:\u002F\u002Fapp.tres.finance\u002Fsettings\u002Fintegrations`, and stop.\n- **One connected ERP:** Use it implicitly and just mention \"Matching against **{companyName}** ({integratedApp}).\"\n- **Multiple connected ERPs:** Ask which one to use — different ERPs have separate invoice\u002Fbill stores.\n\nCache the chosen ERP's `id`, `integratedApp`, and `companyName` for later steps and the loop.\n\n---\n\n## Step 2 — Identify what the user has\n\nAsk whether they have:\n- a **transaction hash** (e.g. `0x…`) — best case, pins the match immediately,\n- an **invoice\u002Fbill ID or number** (numeric internal ID, or the human-facing `invoiceNumber`\u002F`billNumber`),\n- or **both**.\n\nIf they have neither, require at least one. If they're not sure whether their identifier is an invoice or a\nbill, accept it and try both lookups in Step 3.\n\nAlso accept loose forms — \"INV-123\", \"Bill 9988\", \"the bill for Acme last week\". The `freeText` filter on\n`erpInvoices` \u002F `erpBills` handles these.\n\n**Before moving on, always ask for the transaction date (or an approximate date range) if they haven't given\na tx hash.** Ledger volume is high — date is the single most useful filter for narrowing candidates. Also\noffer: *\"If you happen to have the tx hash, paste it now — it pins the match exactly.\"* Date matters both\ndirections (tx→bill and bill→tx).\n\n---\n\n## Step 3 — Fetch the known object and produce ranked match suggestions\n\nThere are two branches. Pick by what the user provided. If they provided both a tx hash *and* an invoice\u002Fbill\nID, skip ahead to Step 5 (match is already determined).\n\n### Branch A — User has a transaction hash\n\n1. Fetch the transaction with its sub-transactions:\n   ```graphql\n   query GetTx($hash: String!) {\n     transaction(identifier: $hash, currency: \"usd\", limit: 1) {\n       results {\n         id identifier timestamp platform\n         children {\n           id amount balanceFactor isInternalTransfer\n           fiatValue\n           sender    { identifier displayName isInternal }\n           recipient { identifier displayName isInternal }\n           asset { symbol identifier }\n         }\n       }\n     }\n   }\n   ```\n2. Pick the **relevant sub-transaction**. Skip gas, skip internal transfers, prefer the one with the user's\n   wallet on one side and an external counterparty on the other. Determine direction:\n   - `balanceFactor` negative → outflow → look for a **bill** to close.\n   - `balanceFactor` positive → inflow → look for an **invoice** to close.\n   If multiple sub-txs qualify (e.g., a swap with multiple legs), present them and let the user pick one.\n3. **For invoices (inflow), try backend match suggestions first** — they are pre-computed and ranked:\n   ```graphql\n   query Suggest($subTxIds: [String]!) {\n     subTransactionToInvoiceMatchSuggestions(\n       subTransactionId_In: $subTxIds, minScore: 0.3, ordering: \"-score\", first: 10\n     ) {\n       results {\n         id score confidenceTier\n         scoreBreakdown { txHashMatch primaryMatchFactors }\n         invoice {\n           id invoiceId invoiceNumber customerName origAmount balance dueDate billingStatus\n           integration { integratedApp companyName }\n         }\n       }\n     }\n   }\n   ```\n   Important: this endpoint is **invoice-only**. For **bills (outflow), skip straight to the fallback below**\n   — there is no backend bill-suggestion query exposed in the schema.\n4. **Fallback (zero invoice suggestions, or always for bills):** query `erpInvoices` (inflow) or `erpBills`\n   (outflow), filtered by:\n   - amount window: `±20%` of the sub-tx fiat value,\n   - date window: `dateCreated_Range = [tx.timestamp − 60d, tx.timestamp]` — bills\u002Finvoices are issued at or\n     *before* the payment, never after. Don't bother with future-dated invoices\u002Fbills.\n   - contact: if the user has named a vendor\u002Fcustomer, pass that as `freeText`. Do NOT try to match the\n     on-chain recipient address to an ERP contact — ERP contact identifiers (from QBO\u002FXero\u002FNetSuite) are\n     internal IDs, never wallet addresses. Some contact labels *happen to resemble* the vendor name in text,\n     but the schema has no \"resembles\" filter, so rely on `freeText` over `vendor`\u002F`customer` fields.\n   Rank the fallback set client-side by: amount proximity → date proximity (prefer the most recent\n   bill\u002Finvoice before the tx) → name hits in `freeText` output.\n5. Present the top ≤5 as a numbered list (never more — too many choices is worse than too few). For each row\n   show: confidence tier, $ amount, customer\u002Fvendor name, `invoiceNumber`\u002F`billNumber`, due date, and the\n   `primaryMatchFactors` (e.g. `amount_exact`, `contact_match`). Best-fit first.\n\n### Branch B — User has an invoice\u002Fbill ID or number\n\n1. Resolve the entity. Try `erpInvoices` first, then `erpBills` if it's not an invoice (or vice versa if the\n   user said \"bill\"). For **invoices**, include the embedded suggestions:\n   ```graphql\n   query GetInvoice($id: Float, $text: String) {\n     erpInvoices(id: $id, freeText: $text, first: 1) {\n       results {\n         id invoiceNumber customerName origAmount balance dateCreated dueDate billingStatus\n         integration { integratedApp companyName }\n         suggestedSubTransactionMatches {\n           id score confidenceTier\n           subTransaction {\n             id amount fiatValue\n             asset { symbol identifier }\n             tx { identifier timestamp platform }\n           }\n         }\n       }\n     }\n   }\n   ```\n   For **bills**, query `erpBills` — note that bills do **not** expose `suggestedSubTransactionMatches`, so\n   just fetch the bill metadata (`id billNumber vendorName vendorId origAmount balance dateCreated dueDate\n   billingStatus integration { integratedApp companyName }`) and go straight to the fallback step. If `id`\n   lookup returns nothing, retry with `freeText: $userInput`.\n2. For invoices, use the embedded `suggestedSubTransactionMatches` as the ranked list.\n3. **Fallback (zero invoice suggestions, or always for bills):**\n   - First, **ask the user for an approximate date of payment** (and remind them: \"if you have the tx hash,\n     that's fastest\"). Payments happen on or after the bill\u002Finvoice date, usually within days — not before.\n     Default to a window of `[dateCreated, dateCreated + 60 days]` if they can't be specific.\n   - Query `transaction` with **server-side filters** so we don't pull the entire ledger. Use:\n     - `platform: \u003CconfiguredNetwork or user's network>` (e.g. `\"ethereum\"`),\n     - `timestamp_Gte` \u002F `timestamp_Lte` → the user-supplied date window,\n     - `children_Asset_Identifier_In: [\u003CassetIdentifier>]` → the bill's `configuredAsset.identifier` (e.g. the\n       USDC contract), or the invoice's expected asset,\n     - `children_FiatValue_Between: \"\u003Clow>,\u003Chigh>\"` → fiat window around `origAmount` (e.g. `±20%`). This is\n       a **string** of two comma-separated numbers. Example: `\"0.4,0.6\"` for a $0.50 bill.\n     - Optionally `children_BalanceFactor: -1` (outflow, for bills) or `1` (inflow, for invoices).\n     - Use `children_Amount_Between` as an additional filter only when the fiat price can't be trusted\n       (pre-priced historical assets, etc.).\n   - If the resulting set is still large, ask the user for a tighter date or an amount refinement before\n     presenting.\n4. Present **up to 5** candidate transactions as a numbered list — show for each:\n   **tx hash (truncated `0xabcd…1234`), sender → recipient addresses (same shortened form), token amount +\n   symbol, fiat value, and timestamp.** The tx hash is the user-facing identifier they recognize; the raw\n   addresses and token amounts disambiguate when fiat alone is too ambiguous (many txs cluster near the same\n   amount). **Never show internal IDs like `subTxId` to the user — they're meaningless to them.** Hold the\n   `subTxId` internally for the mutation; reference the tx by its hash in all user-visible output.\n   If no good matches, say so and ask for a tx hash — don't guess-dump a big list.\n\n---\n\n## Step 4 — User picks a match (or asks for more)\n\nPrompt: *\"Pick a number, or type `more` to widen the search (give me a contact name, date, or amount to focus\non).\"*\n\n- On a number: capture the chosen `(subTxId, invoiceOrBillId, entityType)` and continue to Step 5.\n- On `more`: re-query with looser windows or with the user's added hints (contact filter, expanded date range,\n  amount range), present a fresh list, repeat.\n- On \"none of these\" or similar: stop gracefully — *\"OK, no match made. Tell me when you have more info.\"*\n\n---\n\n## Step 5 — Configure payment account and (optional) fiat alignment\n\nOnce a match pair is chosen:\n\n1. **Deposit account (for `matchApAr.depositAccountId`).** This is an **ERP integration account**\n   (the GL account in Xero\u002FQBO\u002FNetSuite that the bill will post against — e.g. \"Crypto Wallet – ETH\",\n   \"Cash and cash equivalents\"). It is NOT a tres internal\u002Fwallet account. The schema FK is against\n   `schema_integrationaccount`; the value lives on `ErpBill.depositAccount` \u002F `ErpInvoice.depositAccount`\n   as `IntegrationAccountQuery { id name type value }`.\n\n   Resolution order:\n   1. **Use the pre-set one on the bill\u002Finvoice.** When the entity was created in the ERP, the user\n      typically already picked a deposit account. Read `erpBills.results[].depositAccount.id` (or\n      `erpInvoices.results[].depositAccount.id`). If it's non-null, use that id as `depositAccountId`\n      and just mention it in the summary — no prompt.\n   2. **Otherwise ask.** Query `integrationAccount(integration: \u003CerpId>, first: 100)` and show the\n      user the ASSET-type accounts (cash\u002Fwallet\u002Fcrypto GL accounts) as a numbered list; capture the\n      chosen `integrationAccount.id`.\n   3. `paymentToInternalAccounts` maps *wallet → asset* on the tres side and is useful for payout\n      workflows — it is **not** the source of `depositAccountId` for `matchApAr`. Don't reach for it\n      here.\n\n2. **Fiat alignment.** Compare the sub-tx `fiatValue` to the invoice\u002Fbill `origAmount`. Three cases:\n   - `fiatValue` is **null or 0**: ask *\"This transaction has no fiat value set. Align it to ${origAmount}\n     so the {bill\u002Finvoice} closes fully? (y\u002Fn)\"* — **no default**, require an explicit yes.\n   - `fiatValue` differs from `origAmount`: ask *\"Align tx fiat value from $X to $Y so the AP\u002FAR\n     closes fully? (y\u002Fn)\"* — **no default**, require an explicit yes.\n   - Values match: skip.\n   **Never run `setManualFiatValue` without a clear yes** — even if the user's original request implied\n   \"close the invoice\", the fiat alignment is a separate write and needs its own consent. If they say no,\n   the match still proceeds but the entity may stay partially paid.\n\n---\n\n## Step 6 — Confirm and apply\n\nShow this summary table — use **human-readable values only**: tx hash (truncated), deposit account **name**\n(never its id), invoice\u002Fbill number or customer\u002Fvendor name. Internal IDs (`subTxId`, `depositAccountId`,\nDB `entityId`) are for the mutation payload, never for the user.\n\n| | |\n|---|---|\n| Transaction | `0xabcd…1234` · {asset.symbol} {amount} · ${fiatValue} |\n| Invoice\u002FBill | `{invoiceNumber or billNumber}` · {customer\u002Fvendor} · ${origAmount} {currency} |\n| Payment account | {depositAccount.name} |\n| Align fiat | yes → ${origAmount} \u002F no |\n| Sync to ERP after match | yes \u002F no |\n\nAsk: *\"Apply these changes to **{orgName}**? (yes\u002Fno)\"* — only proceed on yes. Treat this as approval for\nthe **match only**. Fiat alignment and ERP sync each need their own explicit yes captured earlier (Step 5\nfor fiat, the prompt below for sync) — even if the user's opening request said \"sync to QBO\", still confirm\nhere, because the request was issued before they saw the actual match details.\n\nThen run mutations in this order, reporting the result of each:\n\n1. **Match (always):**\n   ```graphql\n   mutation Match($entityType: String!, $matches: [SubTxMatchInput]!) {\n     matchApAr(entityType: $entityType, matches: $matches) {\n       results { subTxId entityId depositAccountId }\n     }\n   }\n   ```\n   Variables:\n   - `entityType`: **lowercase** — `\"invoice\"` or `\"bill\"`. Uppercase values are rejected with\n     `Invalid entity_type`.\n   - `matches[].subTxId`: string (e.g. `\"4548595830\"`).\n   - `matches[].entityId`: **integer** — the DB `id` of the invoice\u002Fbill (from `erpInvoices.results[].id`\n     \u002F `erpBills.results[].id`), NOT the human-facing `invoiceNumber`\u002F`billNumber`. Passing a string\n     errors with *\"Int cannot represent non-integer value\"*; passing a bill number looks up nothing\n     and errors with *\"One or more Bill IDs not found\"*.\n   - `matches[].depositAccountId`: **integer** — the integration account id (see Step 5).\n\n2. **Fiat alignment (only if user opted in):**\n   ```graphql\n   mutation AlignFiat($id: String!, $newFiatValue: String!, $currency: String) {\n     setManualFiatValue(id: $id, newFiatValue: $newFiatValue, currency: $currency) { success }\n   }\n   ```\n   Pass the sub-transaction ID as `id`, the target value as a string in `newFiatValue` (e.g. `\"123.45\"`, the\n   invoice\u002Fbill `origAmount`), and `currency: \"usd\"`. If the response returns an error about a \"locked\n   period\", the accounting period containing the tx is closed — surface that to the user; don't try to force.\n\n3. **ERP sync (ask first, every time):** *\"Sync this transaction to {erpName} now? (y\u002Fn)\"* — **never sync\n   without an explicit yes at this point**, even if the user's original ask included \"and sync to QBO\". The\n   sync call is visible in the ERP and harder to undo than the match itself, so it gets its own gate. If yes:\n   ```graphql\n   mutation Sync($txIds: [String]!, $entityType: String!) {\n     syncSpecificTransactions(transactionIds: $txIds, entitySourceType: $entityType) { status }\n   }\n   ```\n   `entitySourceType` mirrors `entityType` from the match call.\n\nWhen reporting results back to the user, refer to the transaction by its **tx hash** (truncated) and the\ndeposit account by **name** — never by `subTxId` or `depositAccountId`. Those internal IDs are for debugging,\nnot user output.\n\nIf any mutation errors, surface the error message verbatim and offer to retry. The match is the one that\nactually links the records — if it fails, the rest is moot.\n\n---\n\n## Step 7 — Loop\n\nAsk: *\"Match another transaction or invoice\u002Fbill? (y\u002Fn)\"*\n\n- yes → restart from Step 2 (skip Step 1 — keep the cached ERP from this session).\n- no → wrap up: *\"Done. Closed {n} item(s) this session.\"*\n\n---\n\n## Verified TRES MCP operations used\n\n| Purpose | Operation | Type |\n|---|---|---|\n| Org identity | `get_viewer` | MCP tool |\n| Schema discovery | `introspect`, `build_query` | MCP tool |\n| Check ERP connections | `integration` (filter `isErp=true`) | query |\n| Fetch tx by hash | `transaction(identifier:)` | query |\n| Fetch invoices (with embedded suggestions) | `erpInvoices` | query |\n| Fetch bills (with embedded suggestions) | `erpBills` | query |\n| Pre-computed sub-tx → invoice match suggestions | `subTransactionToInvoiceMatchSuggestions` | query |\n| COA-mapped payment accounts | `paymentToInternalAccounts` | query |\n| Match sub-tx ↔ invoice\u002Fbill | `matchApAr` | mutation |\n| Align fiat value | `setManualFiatValue` (verify args at runtime) | mutation |\n| Sync transactions to the ERP | `syncSpecificTransactions` | mutation |\n| Undo a match (on user request) | `manualUnmatchSubtransactions` | mutation |\n\n---\n\n## Out of scope (politely redirect if asked)\n\n- Bulk matching (many ↔ many) — not yet supported by this skill.\n- Sending payments (`sendBillPayment`, `sendInvoicePayment`) — separate workflow.\n- Connecting or revoking the ERP itself — use the `tres-settings-management` skill.\n- Explaining a transaction in narrative form — use `tres-tx-story`.\n- Importing an explorer link into the ledger — use `tres-explorer-tx-to-ledger`.\n","# TRES — Invoice\u002FBill Matching & ERP Sync\n\nEnd-to-end workflow that lets the user close an open ERP invoice or bill against a blockchain transaction in\nthe TRES ledger, then optionally push the matched entry to the connected ERP.\n\nThe flow is the same regardless of which side the user starts from (a transaction hash or an invoice\u002Fbill ID).\nThe skill walks through seven conversational steps (verify ERP → identify input → fetch & suggest → user picks\n→ configure payment account & fiat → confirm & apply → loop). Stay terse — show numbered options, capture the\nuser's pick, move on. Never run a mutation without explicit \"yes\" from the user.\n\n---\n\n## Ground rules\n\n1. **Identify the org first.** Begin with `get_viewer` and tell the user \"You're connected to **{orgName}**.\"\n   This makes mistakes recoverable when someone has the wrong token.\n2. **Read before write.** Always fetch the current state of the transaction, invoice\u002Fbill, and payment account\n   before showing a change summary. Surprises are worse than slow.\n3. **Mutations require explicit approval.** Show a summary table (Transaction · Invoice\u002FBill · Payment Account ·\n   Fiat alignment · Sync) and ask \"Apply these changes?\" before any mutation. Only proceed on a clear yes.\n4. **Use schema introspection when in doubt.** Field names, enum values, and argument shapes can drift. If a\n   query\u002Fmutation errors with \"unknown field\" or \"invalid enum\", call `introspect(\u003CTypeName>)` or\n   `build_query(\u003CoperationName>)` and adjust — don't guess. Operations specifically called out as \"verify at\n   runtime\" below are the ones most likely to need this.\n5. **The skill is a loop.** After a successful match, ask \"Match another?\" and restart from Step 2. Don't\n   re-check the ERP — that only happens once per session.\n\n---\n\n## Step 1 — Verify ERP is connected\n\nRun:\n```graphql\nquery { integration(first: 50) { results { id integratedApp isErp connectionStatus companyName } } }\n```\n\nFilter the results where `isErp == true` and `connectionStatus == \"ACTIVE\"`. The supported ERPs you should\nrecognize are **Xero**, **QuickBooks Online (QBO)**, and **NetSuite** — `integratedApp` values are `XERO`,\n`QUICKBOOKS`, and `NETSUITE`. (If you encounter unknown values, `introspect(\"IntegrationsQueryNode\")` will\nconfirm the enum.) Ignore rows where `integratedApp` is empty — the API occasionally returns a null row.\n\n- **No connected ERP:** Tell the user they need to connect one before matching can happen, point them at\n  `https:\u002F\u002Fapp.tres.finance\u002Fsettings\u002Fintegrations`, and stop.\n- **One connected ERP:** Use it implicitly and just mention \"Matching against **{companyName}** ({integratedApp}).\"\n- **Multiple connected ERPs:** Ask which one to use — different ERPs have separate invoice\u002Fbill stores.\n\nCache the chosen ERP's `id`, `integratedApp`, and `companyName` for later steps and the loop.\n\n---\n\n## Step 2 — Identify what the user has\n\nAsk whether they have:\n- a **transaction hash** (e.g. `0x…`) — best case, pins the match immediately,\n- an **invoice\u002Fbill ID or number** (numeric internal ID, or the human-facing `invoiceNumber`\u002F`billNumber`),\n- or **both**.\n\nIf they have neither, require at least one. If they're not sure whether their identifier is an invoice or a\nbill, accept it and try both lookups in Step 3.\n\nAlso accept loose forms — \"INV-123\", \"Bill 9988\", \"the bill for Acme last week\". The `freeText` filter on\n`erpInvoices` \u002F `erpBills` handles these.\n\n**Before moving on, always ask for the transaction date (or an approximate date range) if they haven't given\na tx hash.** Ledger volume is high — date is the single most useful filter for narrowing candidates. Also\noffer: *\"If you happen to have the tx hash, paste it now — it pins the match exactly.\"* Date matters both\ndirections (tx→bill and bill→tx).\n\n---\n\n## Step 3 — Fetch the known object and produce ranked match suggestions\n\nThere are two branches. Pick by what the user provided. If they provided both a tx hash *and* an invoice\u002Fbill\nID, skip ahead to Step 5 (match is already determined).\n\n### Branch A — User has a transaction hash\n\n1. Fetch the transaction with its sub-transactions:\n   ```graphql\n   query GetTx($hash: String!) {\n     transaction(identifier: $hash, currency: \"usd\", limit: 1) {\n       results {\n         id identifier timestamp platform\n         children {\n           id amount balanceFactor isInternalTransfer\n           fiatValue\n           sender    { identifier displayName isInternal }\n           recipient { identifier displayName isInternal }\n           asset { symbol identifier }\n         }\n       }\n     }\n   }\n   ```\n2. Pick the **relevant sub-transaction**. Skip gas, skip internal transfers, prefer the one with the user's\n   wallet on one side and an external counterparty on the other. Determine direction:\n   - `balanceFactor` negative → outflow → look for a **bill** to close.\n   - `balanceFactor` positive → inflow → look for an **invoice** to close.\n   If multiple sub-txs qualify (e.g., a swap with multiple legs), present them and let the user pick one.\n3. **For invoices (inflow), try backend match suggestions first** — they are pre-computed and ranked:\n   ```graphql\n   query Suggest($subTxIds: [String]!) {\n     subTransactionToInvoiceMatchSuggestions(\n       subTransactionId_In: $subTxIds, minScore: 0.3, ordering: \"-score\", first: 10\n     ) {\n       results {\n         id score confidenceTier\n         scoreBreakdown { txHashMatch primaryMatchFactors }\n         invoice {\n           id invoiceId invoiceNumber customerName origAmount balance dueDate billingStatus\n           integration { integratedApp companyName }\n         }\n       }\n     }\n   }\n   ```\n   Important: this endpoint is **invoice-only**. For **bills (outflow), skip straight to the fallback below**\n   — there is no backend bill-suggestion query exposed in the schema.\n4. **Fallback (zero invoice suggestions, or always for bills):** query `erpInvoices` (inflow) or `erpBills`\n   (outflow), filtered by:\n   - amount window: `±20%` of the sub-tx fiat value,\n   - date window: `dateCreated_Range = [tx.timestamp − 60d, tx.timestamp]` — bills\u002Finvoices are issued at or\n     *before* the payment, never after. Don't bother with future-dated invoices\u002Fbills.\n   - contact: if the user has named a vendor\u002Fcustomer, pass that as `freeText`. Do NOT try to match the\n     on-chain recipient address to an ERP contact — ERP contact identifiers (from QBO\u002FXero\u002FNetSuite) are\n     internal IDs, never wallet addresses. Some contact labels *happen to resemble* the vendor name in text,\n     but the schema has no \"resembles\" filter, so rely on `freeText` over `vendor`\u002F`customer` fields.\n   Rank the fallback set client-side by: amount proximity → date proximity (prefer the most recent\n   bill\u002Finvoice before the tx) → name hits in `freeText` output.\n5. Present the top ≤5 as a numbered list (never more — too many choices is worse than too few). For each row\n   show: confidence tier, $ amount, customer\u002Fvendor name, `invoiceNumber`\u002F`billNumber`, due date, and the\n   `primaryMatchFactors` (e.g. `amount_exact`, `contact_match`). Best-fit first.\n\n### Branch B — User has an invoice\u002Fbill ID or number\n\n1. Resolve the entity. Try `erpInvoices` first, then `erpBills` if it's not an invoice (or vice versa if the\n   user said \"bill\"). For **invoices**, include the embedded suggestions:\n   ```graphql\n   query GetInvoice($id: Float, $text: String) {\n     erpInvoices(id: $id, freeText: $text, first: 1) {\n       results {\n         id invoiceNumber customerName origAmount balance dateCreated dueDate billingStatus\n         integration { integratedApp companyName }\n         suggestedSubTransactionMatches {\n           id score confidenceTier\n           subTransaction {\n             id amount fiatValue\n             asset { symbol identifier }\n             tx { identifier timestamp platform }\n           }\n         }\n       }\n     }\n   }\n   ```\n   For **bills**, query `erpBills` — note that bills do **not** expose `suggestedSubTransactionMatches`, so\n   just fetch the bill metadata (`id billNumber vendorName vendorId origAmount balance dateCreated dueDate\n   billingStatus integration { integratedApp companyName }`) and go straight to the fallback step. If `id`\n   lookup returns nothing, retry with `freeText: $userInput`.\n2. For invoices, use the embedded `suggestedSubTransactionMatches` as the ranked list.\n3. **Fallback (zero invoice suggestions, or always for bills):**\n   - First, **ask the user for an approximate date of payment** (and remind them: \"if you have the tx hash,\n     that's fastest\"). Payments happen on or after the bill\u002Finvoice date, usually within days — not before.\n     Default to a window of `[dateCreated, dateCreated + 60 days]` if they can't be specific.\n   - Query `transaction` with **server-side filters** so we don't pull the entire ledger. Use:\n     - `platform: \u003CconfiguredNetwork or user's network>` (e.g. `\"ethereum\"`),\n     - `timestamp_Gte` \u002F `timestamp_Lte` → the user-supplied date window,\n     - `children_Asset_Identifier_In: [\u003CassetIdentifier>]` → the bill's `configuredAsset.identifier` (e.g. the\n       USDC contract), or the invoice's expected asset,\n     - `children_FiatValue_Between: \"\u003Clow>,\u003Chigh>\"` → fiat window around `origAmount` (e.g. `±20%`). This is\n       a **string** of two comma-separated numbers. Example: `\"0.4,0.6\"` for a $0.50 bill.\n     - Optionally `children_BalanceFactor: -1` (outflow, for bills) or `1` (inflow, for invoices).\n     - Use `children_Amount_Between` as an additional filter only when the fiat price can't be trusted\n       (pre-priced historical assets, etc.).\n   - If the resulting set is still large, ask the user for a tighter date or an amount refinement before\n     presenting.\n4. Present **up to 5** candidate transactions as a numbered list — show for each:\n   **tx hash (truncated `0xabcd…1234`), sender → recipient addresses (same shortened form), token amount +\n   symbol, fiat value, and timestamp.** The tx hash is the user-facing identifier they recognize; the raw\n   addresses and token amounts disambiguate when fiat alone is too ambiguous (many txs cluster near the same\n   amount). **Never show internal IDs like `subTxId` to the user — they're meaningless to them.** Hold the\n   `subTxId` internally for the mutation; reference the tx by its hash in all user-visible output.\n   If no good matches, say so and ask for a tx hash — don't guess-dump a big list.\n\n---\n\n## Step 4 — User picks a match (or asks for more)\n\nPrompt: *\"Pick a number, or type `more` to widen the search (give me a contact name, date, or amount to focus\non).\"*\n\n- On a number: capture the chosen `(subTxId, invoiceOrBillId, entityType)` and continue to Step 5.\n- On `more`: re-query with looser windows or with the user's added hints (contact filter, expanded date range,\n  amount range), present a fresh list, repeat.\n- On \"none of these\" or similar: stop gracefully — *\"OK, no match made. Tell me when you have more info.\"*\n\n---\n\n## Step 5 — Configure payment account and (optional) fiat alignment\n\nOnce a match pair is chosen:\n\n1. **Deposit account (for `matchApAr.depositAccountId`).** This is an **ERP integration account**\n   (the GL account in Xero\u002FQBO\u002FNetSuite that the bill will post against — e.g. \"Crypto Wallet – ETH\",\n   \"Cash and cash equivalents\"). It is NOT a tres internal\u002Fwallet account. The schema FK is against\n   `schema_integrationaccount`; the value lives on `ErpBill.depositAccount` \u002F `ErpInvoice.depositAccount`\n   as `IntegrationAccountQuery { id name type value }`.\n\n   Resolution order:\n   1. **Use the pre-set one on the bill\u002Finvoice.** When the entity was created in the ERP, the user\n      typically already picked a deposit account. Read `erpBills.results[].depositAccount.id` (or\n      `erpInvoices.results[].depositAccount.id`). If it's non-null, use that id as `depositAccountId`\n      and just mention it in the summary — no prompt.\n   2. **Otherwise ask.** Query `integrationAccount(integration: \u003CerpId>, first: 100)` and show the\n      user the ASSET-type accounts (cash\u002Fwallet\u002Fcrypto GL accounts) as a numbered list; capture the\n      chosen `integrationAccount.id`.\n   3. `paymentToInternalAccounts` maps *wallet → asset* on the tres side and is useful for payout\n      workflows — it is **not** the source of `depositAccountId` for `matchApAr`. Don't reach for it\n      here.\n\n2. **Fiat alignment.** Compare the sub-tx `fiatValue` to the invoice\u002Fbill `origAmount`. Three cases:\n   - `fiatValue` is **null or 0**: ask *\"This transaction has no fiat value set. Align it to ${origAmount}\n     so the {bill\u002Finvoice} closes fully? (y\u002Fn)\"* — **no default**, require an explicit yes.\n   - `fiatValue` differs from `origAmount`: ask *\"Align tx fiat value from $X to $Y so the AP\u002FAR\n     closes fully? (y\u002Fn)\"* — **no default**, require an explicit yes.\n   - Values match: skip.\n   **Never run `setManualFiatValue` without a clear yes** — even if the user's original request implied\n   \"close the invoice\", the fiat alignment is a separate write and needs its own consent. If they say no,\n   the match still proceeds but the entity may stay partially paid.\n\n---\n\n## Step 6 — Confirm and apply\n\nShow this summary table — use **human-readable values only**: tx hash (truncated), deposit account **name**\n(never its id), invoice\u002Fbill number or customer\u002Fvendor name. Internal IDs (`subTxId`, `depositAccountId`,\nDB `entityId`) are for the mutation payload, never for the user.\n\n| | |\n|---|---|\n| Transaction | `0xabcd…1234` · {asset.symbol} {amount} · ${fiatValue} |\n| Invoice\u002FBill | `{invoiceNumber or billNumber}` · {customer\u002Fvendor} · ${origAmount} {currency} |\n| Payment account | {depositAccount.name} |\n| Align fiat | yes → ${origAmount} \u002F no |\n| Sync to ERP after match | yes \u002F no |\n\nAsk: *\"Apply these changes to **{orgName}**? (yes\u002Fno)\"* — only proceed on yes. Treat this as approval for\nthe **match only**. Fiat alignment and ERP sync each need their own explicit yes captured earlier (Step 5\nfor fiat, the prompt below for sync) — even if the user's opening request said \"sync to QBO\", still confirm\nhere, because the request was issued before they saw the actual match details.\n\nThen run mutations in this order, reporting the result of each:\n\n1. **Match (always):**\n   ```graphql\n   mutation Match($entityType: String!, $matches: [SubTxMatchInput]!) {\n     matchApAr(entityType: $entityType, matches: $matches) {\n       results { subTxId entityId depositAccountId }\n     }\n   }\n   ```\n   Variables:\n   - `entityType`: **lowercase** — `\"invoice\"` or `\"bill\"`. Uppercase values are rejected with\n     `Invalid entity_type`.\n   - `matches[].subTxId`: string (e.g. `\"4548595830\"`).\n   - `matches[].entityId`: **integer** — the DB `id` of the invoice\u002Fbill (from `erpInvoices.results[].id`\n     \u002F `erpBills.results[].id`), NOT the human-facing `invoiceNumber`\u002F`billNumber`. Passing a string\n     errors with *\"Int cannot represent non-integer value\"*; passing a bill number looks up nothing\n     and errors with *\"One or more Bill IDs not found\"*.\n   - `matches[].depositAccountId`: **integer** — the integration account id (see Step 5).\n\n2. **Fiat alignment (only if user opted in):**\n   ```graphql\n   mutation AlignFiat($id: String!, $newFiatValue: String!, $currency: String) {\n     setManualFiatValue(id: $id, newFiatValue: $newFiatValue, currency: $currency) { success }\n   }\n   ```\n   Pass the sub-transaction ID as `id`, the target value as a string in `newFiatValue` (e.g. `\"123.45\"`, the\n   invoice\u002Fbill `origAmount`), and `currency: \"usd\"`. If the response returns an error about a \"locked\n   period\", the accounting period containing the tx is closed — surface that to the user; don't try to force.\n\n3. **ERP sync (ask first, every time):** *\"Sync this transaction to {erpName} now? (y\u002Fn)\"* — **never sync\n   without an explicit yes at this point**, even if the user's original ask included \"and sync to QBO\". The\n   sync call is visible in the ERP and harder to undo than the match itself, so it gets its own gate. If yes:\n   ```graphql\n   mutation Sync($txIds: [String]!, $entityType: String!) {\n     syncSpecificTransactions(transactionIds: $txIds, entitySourceType: $entityType) { status }\n   }\n   ```\n   `entitySourceType` mirrors `entityType` from the match call.\n\nWhen reporting results back to the user, refer to the transaction by its **tx hash** (truncated) and the\ndeposit account by **name** — never by `subTxId` or `depositAccountId`. Those internal IDs are for debugging,\nnot user output.\n\nIf any mutation errors, surface the error message verbatim and offer to retry. The match is the one that\nactually links the records — if it fails, the rest is moot.\n\n---\n\n## Step 7 — Loop\n\nAsk: *\"Match another transaction or invoice\u002Fbill? (y\u002Fn)\"*\n\n- yes → restart from Step 2 (skip Step 1 — keep the cached ERP from this session).\n- no → wrap up: *\"Done. Closed {n} item(s) this session.\"*\n\n---\n\n## Verified TRES MCP operations used\n\n| Purpose | Operation | Type |\n|---|---|---|\n| Org identity | `get_viewer` | MCP tool |\n| Schema discovery | `introspect`, `build_query` | MCP tool |\n| Check ERP connections | `integration` (filter `isErp=true`) | query |\n| Fetch tx by hash | `transaction(identifier:)` | query |\n| Fetch invoices (with embedded suggestions) | `erpInvoices` | query |\n| Fetch bills (with embedded suggestions) | `erpBills` | query |\n| Pre-computed sub-tx → invoice match suggestions | `subTransactionToInvoiceMatchSuggestions` | query |\n| COA-mapped payment accounts | `paymentToInternalAccounts` | query |\n| Match sub-tx ↔ invoice\u002Fbill | `matchApAr` | mutation |\n| Align fiat value | `setManualFiatValue` (verify args at runtime) | mutation |\n| Sync transactions to the ERP | `syncSpecificTransactions` | mutation |\n| Undo a match (on user request) | `manualUnmatchSubtransactions` | mutation |\n\n---\n\n## Out of scope (politely redirect if asked)\n\n- Bulk matching (many ↔ many) — not yet supported by this skill.\n- Sending payments (`sendBillPayment`, `sendInvoicePayment`) — separate workflow.\n- Connecting or revoking the ERP itself — use the `tres-settings-management` skill.\n- Explaining a transaction in narrative form — use `tres-tx-story`.\n- Importing an explorer link into the ledger — use `tres-explorer-tx-to-ledger`.\n",{"name":5,"description":7},"main","163301d1904c0a994539f5226ce0fcd65b8652bf","tres-finance-plugin\u002Fskills\u002Ftres-invoice-bill-matching",357,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community","https:\u002F\u002Fgithub.com\u002Fanthropics","https:\u002F\u002Fanthropic.com","2026-11-11 15:47:52",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add anthropics\u002Fclaude-plugins-community --skill tres-invoice-bill-matching",{"tool":68,"command":69},"bunx","bunx skills add anthropics\u002Fclaude-plugins-community --skill tres-invoice-bill-matching",{"tool":71,"command":72},"pnpm","pnpm dlx skills add anthropics\u002Fclaude-plugins-community --skill tres-invoice-bill-matching","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-invoice-bill-matching\u002FSKILL.md",true,[],[77,109,133,157,179,201],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":88,"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",[83,86,87],{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000004","电子表格",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108],"wallets","tres wallets upload","upload","typing","ingestion","Wallet","chain","creation","xlsx","selection","MCP","confirmation","connect","collection","preview","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,91,117,118,119,120,94,121,122,123,124,125,126,127,45,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,99,146,147,148,149,150,151,152,153,154,34,155,119,156,122],"tres tx story","Story","show","memory","hex","when","show me","analysis","analyze","me","diagram","generate","flow","asset","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,48,143,168,99,146,169,170,171,104,172,173,174,175,176,37,177,178],"tres settings management","settings","management","get","configure","ask","commit","change","organization","update","read","write","mcp graphql","flags",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":187,"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",[185,186],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[188,189,190,143,191,94,46,99,192,193,194,195,196,149,197,42,198,199,173,200],"tres rollup rules","Rules","rollup","gas","impact","reduce","Connector","review","consolidate","create","delete","data-driven","activity",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":209,"publishedAt":49},"01M718FFX3KV2JRFVS2RCM719D","tres-rollup-review","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.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-community\u002Fblob\u002Fmain\u002Ftres-finance-plugin\u002Fskills\u002Ftres-rollup-review\u002FSKILL.md",[207,208],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[195,210,190,211,212,213,214,215,45,216,99,192,146,103,217,194,218,219,197,220],"tres rollup review","standalone","never","mode","issues","design","new","candidate","filter","valid","catch"]