Track recurring liabilities such as subscriptions, insurance, and loans. Use when the user wants to add, update, remove, summarize, or review upcoming recurring payments
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Track recurring liabilities such as subscriptions, insurance, and loans. Use when the user wants to add, update, remove, summarize, or review upcoming recurring payments
Liability Tracker
Use this skill when the user wants to:
add, update, remove recurring liabilities
review subscriptions, insurance, loans, or other recurring obligations
calculate total recurring liability burden
see upcoming payments due
Load the local finance context
Resolve the data directory first: use PLUTUS_DATA_DIR if set, otherwise ~/.config/plutus/data/.
If the data directory does not exist, direct the user to onboard using the plutus-onboard skill.
Read profile.json from the data directory first.
Read liabilities.json from the data directory before making calculations or recommendations.
When the user reports a change, confirm the intended edit if it would overwrite or remove an existing item, then update liabilities.json in the data directory immediately.
Use python for date math when needed.
Rules:
Track recurring deductions only: subscriptions, insurance, loans, and similar repeating obligations.
Do not store fixed next_due dates.
Store due_day for monthly recurring, due_day and due_month for yearly recurring, and so on.
If a quarterly liability needs exact upcoming-date alerts, store an additional anchor field such as anchor_month so the quarter cadence is unambiguous.
Use ISO 8601 dates for any additional date fields you introduce.
Keep only the minimum detail required for tracking and calculations.
Due Dates And Alerts
Compute next_due dynamically from today's date instead of persisting it.
Monthly liabilities use the next calendar month/day combination on or after today.
Quarterly liabilities use the stored quarter anchor. If no anchor exists yet, ask for it before calculating an exact upcoming date.
Yearly liabilities use due_month plus due_day.
If a stored due_day is larger than the number of days in the target month, clamp it to the month's last day.
When the user asks for upcoming payments without a specific window, default to the next 30 days.
Output
Lead with the total liability burden by each frequency: month, year and so on, whichever relevant.
Use a markdown table for liability summaries with fields such as name, category, frequency, amount, and next due.
Call out upcoming payments separately when relevant.