From pm-decoders
Decode a car lease offer — the money factor converted to APR, the cap-cost math, mileage and disposition traps, and what to negotiate. Use when asked to decode my car lease, is this lease deal good, what's a money factor, or review this lease before I sign. Produces the real-numbers decode (money factor → APR, total lease cost), the trap list with dollar exposure, and the negotiation points dealers expect to concede.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pm-decoders:car-lease-decoderThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Leases are quoted in a dialect designed to prevent comparison: money factors instead of interest rates, cap costs instead of prices, payments instead of totals. This skill translates everything into the two numbers that matter — the *effective APR* and the *total cost of the lease* — then walks the traps that live in the back pages.
Leases are quoted in a dialect designed to prevent comparison: money factors instead of interest rates, cap costs instead of prices, payments instead of totals. This skill translates everything into the two numbers that matter — the effective APR and the total cost of the lease — then walks the traps that live in the back pages.
Ask for these only if not provided:
car-tco)The two numbers: effective APR [n.n]% · total lease cost $[n] ([payments] + [drive-off] + [fees] + [projected end charges])
The equation, reconciled [depreciation + rent charge + fees vs their payment math — matches / gap of $n asks why]
Trap table | Trap | The line | Your exposure | The ask |
Negotiation points — cap cost, MF markup, mileage tier, disposition — each with wording
Lease vs buy pointer: [one honest paragraph; full math via car-tco]
End verbatim: "This is a plain-language reading, not financial advice — lease structures and taxes vary by jurisdiction; confirm anything load-bearing before signing."
npx claudepluginhub mohitagw15856/pm-claude-skills --plugin pm-decodersGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.