← Kilter MoneyCONTENT HISTORY
WHAT CHANGED
Update to Kilter Money
Snapshot Oct 24, 2026 · 13:53 UTC · version 1.1.1
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Save Kilter Money and check future changes in Following.
Up to 3 plugins free · no card required.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Use when the user shares a receipt (a photo, or a typed/pasted list of items and prices) from a single purchase and wants it logged to Kilter Money. Covers deciding whether the purchase needs to be split across categories at all, how to allocate tax/tip/discounts across split lines, and what to do when an item has no matching category yet.\n",
"included_files": [],
"name": "split-receipt-by-category",
"skill_md_contents": "---\nname: split-receipt-by-category\ndescription: >\n Use when the user shares a receipt (a photo, or a typed/pasted list of\n items and prices) from a single purchase and wants it logged to Kilter\n Money. Covers deciding whether the purchase needs to be split across\n categories at all, how to allocate tax/tip/discounts across split lines,\n and what to do when an item has no matching category yet.\n---\n\n# Splitting a receipt by category\n\nA receipt is always **one purchase, one `add_expense` call** — never one\ncall per item or per category. The only question this skill answers is\nwhether that one call uses a single `categoryId`/`categoryName` or\n`splits`.\n\n## 1. Decide if it needs splitting at all\n\nMost receipts do **not** need splitting. Only split when the items on the\nreceipt genuinely belong to two or more categories the user already keeps\nseparate.\n\n- **Single-purpose merchant → never split**, regardless of how many food\n items are on the check. A restaurant, cafe, bar, coffee shop, or\n fast-food order is one `Dining`/`Restaurants`-type category even though\n it lists an appetizer, an entree, and a drink as separate line items —\n those aren't different categories to this user, they're one meal.\n Likewise a gas station fill-up, a single-item purchase, or a pharmacy\n errand for one thing: one category.\n- **Multi-purpose merchant → split only if it actually crosses\n categories.** A grocery-store, big-box (Target/Walmart/Costco), or\n pharmacy receipt often mixes groceries, household supplies, pet\n supplies, electronics, or personal care on one ticket. Group the line\n items into however many of the user's *existing* categories they\n actually span (usually 2-3, rarely more) — don't create a split line\n per item, and don't split two items into different categories just\n because they're technically different products (all food/snack/drink\n items on a grocery run are still one `Groceries` line, even if some\n would arguably be \"dining\").\n\nWhen in doubt, prefer the simpler read: a single category is always a\nvalid answer, and splitting when it isn't warranted just adds noise the\nuser has to review.\n\n## 2. Always call `list_categories` first\n\nDo this before reasoning about category names, whether splitting is\nneeded, or whether something is \"missing\" a category — skip archived\ncategories. Match items to the user's actual category names; don't invent\nnew category labels in the split without going through step 4.\n\n## 3. Building the split lines\n\n- One split line per category the receipt spans, not per item.\n- **Tax and tip/discounts are not their own line.** Fold tax\n proportionally into each category's line based on that line's share of\n the pre-tax subtotal (round each line, then put any rounding remainder\n — usually a cent or two — on the largest line so the lines sum exactly\n to `amountCents`; `add_expense` rejects splits that don't reconcile\n exactly). Net a storewide discount into the affected line(s) the same\n way before allocating tax. A tip (restaurant) doesn't apply here since\n restaurant receipts aren't split in the first place.\n- Double check the split lines sum to the receipt total before calling\n `add_expense`. If they don't reconcile, re-check the item grouping\n rather than fudging one line to make the math work.\n\n## 4. An item doesn't fit any existing category\n\nDon't silently force it into the closest existing category, and don't\nsilently invent a new category. Ask the user, once, naming the specific\nitem(s): e.g. \"This receipt has a pet-supplies item but you don't have a\nPet Supplies category yet — want me to create one for it?\"\n\n- **If yes:** call `list_budgets` first.\n - If it returns one or more budgets (budgeting is enabled for this\n account), pick the budget that best matches the new category's theme\n and tell the user which one you'd assign it to before creating it\n (e.g. \"I'll put it under your Household budget\") so they can redirect\n or say \"leave it unassigned\" instead. Only ask them to choose outright\n if no budget is a reasonable fit.\n - If `list_budgets` returns empty, budgeting isn't set up on this\n account — create the category with no `budgetId` and don't bring up\n budgets.\n - Then `create_category` with the resolved `budgetId`/`budgetName` (or\n neither), and use the new category in the split.\n- **If no:** ask which existing category to fold the item into instead\n (don't guess), or drop that item's amount from the logged expense if the\n user says so.\n\n## 5. Confirm back to the user\n\nAfter the single `add_expense` call, summarize what was logged in one\nshort line per split: category and amount (plus merchant/date/total if not\nalready obvious from context). If the user disagrees with how something\nwas split, that's a normal category edit in the app, not a reason to\nre-log the expense.\n"
}SHA-256 of public snapshot: d861cd55f29482feda38aa3f1524f6900af16acc98205232d1aefa5820c18908