cost-review

Cost Review

When this skill is activated, assess the true cost a change introduces — not just whether the code works, but what it adds to the system that has to be carried forever: more complexity, an extra database, another dependency, more to deploy, more to monitor, more to maintain. The output ends with a blunt bottom-line summary of what the change costs.

This is not a code-quality review. It does not judge whether the code is good — it makes the ongoing cost of the change explicit so it can be weighed against the benefit before merging.

Clarifying Questions

Before starting, determine what is being assessed. Ask this first and wait for the answer unless it is already obvious from the conversation:

1. What should I assess the cost of?
   • A pull request — provide the PR number or link (this is the most common case).
   • The current branch / uncommitted diff — assess what has changed locally.
   • A described feature or idea — not yet implemented; assess the cost of the proposal as described.

Then, if not already clear:

2. What is the benefit or goal this change is meant to deliver? (so cost can be weighed against it)
3. Are there constraints that make any cost dimension especially important (e.g. a small team, tight infra budget, strict latency or compliance requirements)?

Steps

1. Gather the change based on the case:
   • Pull request: read the PR title, description, and full diff. Use the GitHub tools if available, otherwise the local branch.
   • Branch / diff: run git status, git log <base>..HEAD --oneline, and git diff <base>...HEAD (three-dot range).
   • Feature idea: work from the description; ask for missing detail rather than guessing.
2. Read the actual change (or proposal) and identify every new moving part it introduces.
3. Walk through each cost dimension below and capture concrete, evidence-backed costs — cite file paths, new dependencies, or specific design choices. Skip dimensions that genuinely don't apply.
4. Distinguish one-time cost (paid once, e.g. a migration) from recurring cost (paid forever, e.g. another service to run). Recurring cost is what usually dominates.
5. Note cheaper alternatives where a cost looks avoidable (e.g. "this adds a queue — a cron job may suffice").
6. Produce the output below, ending with the bottom-line summary.

Cost Dimensions

Dimension	What to look for
Complexity	New abstractions, indirection, branching logic, concepts a reader must hold in their head
Infrastructure	A new database, cache, queue, bucket, cron, external service — anything new to provision and run
Dependencies	New libraries or third-party/SaaS services, and the upgrade/security burden they bring
Operations	More to deploy, configure, monitor, alert on, scale, and back up; new failure modes and on-call surface
Maintenance	Ongoing upkeep, who owns it, code that will rot or need patching
Cognitive / onboarding	How much harder the system is to understand for the next person
Performance / resources	CPU, memory, storage, network, added latency, N+1s, extra round-trips
Security / compliance	New attack surface, secrets, PII, data-residency or audit obligations
Testing	New test surface, harder-to-test paths, fixtures or environments needed
Migration / rollback	Data migrations, backfills, how hard it is to undo if it goes wrong
Recurring $	Hosting, license, or per-call costs that show up every month

Output

Summary

One or two sentences: what the change does and the headline cost.

Cost Breakdown

For each relevant dimension, an entry:

{Dimension} — one-time | recurring

• Cost: what it adds.
• Evidence: file path, dependency, or design choice it comes from.
• Cheaper alternative: if one exists, otherwise omit.

What this change costs you

A blunt, scannable bottom line — the part the reader remembers:

- +1 database (Postgres) — recurring infra + backups + monitoring
- +2 runtime dependencies — ongoing upgrade/security burden
- More complexity — a new async job layer to reason about
- +1 deploy target — another service to ship and watch
- One-time: a data migration with a non-trivial rollback

End with a one-line verdict: is the cost proportionate to the stated benefit, or does it look heavy for what it delivers?

Rules

• Be concrete. "Adds complexity" is useless; "adds a queue and a worker process you must now run and monitor" is a cost.
• Separate one-time from recurring cost — recurring cost is usually what matters, and it's the part people underestimate.
• Don't moralize. The goal is to make cost visible so the human can decide, not to block the change.
• Tie every claimed cost to evidence in the diff, the proposal, or the dependencies. No vague assertions.
• Flag costs that look avoidable and name the cheaper path — but don't redesign the feature; that's not this skill's job.
• This skill is read-only: it does not modify source files, push, or comment on a PR unless explicitly asked to.
• If asked to post the result on a PR, output it as a comment-ready block and post only after explicit confirmation.