Beeminder audit
Procedural guidance on safely auditing, modifying, and cleaning up Beeminder goal data (including odometer resets, @TARE mechanics, and timezone protections) without risking accidental derailment. Triggers on keywords like beeminder audit, beeminder cleanup, delete datapoints, tare.From its SKILL.md
npx -y skills add kingdonb/mecris --skill beeminder-auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.4 KB, as published. Nobody here has run it
Beeminder Audit Skill
Auditing, correcting, and backdating goal data on Beeminder carries a significant risk of accidental goal derailment. This skill provides a set of strict rules and procedures to safely audit and modify Beeminder goal data.
Risk Profile & Safety Rules
- Do Less / Ceiling Goals (Hard Cap):
- For goals like API spend limits, adding a high value in the past can trigger historical ceiling violations, immediately derailing the goal.
- Always inspect the current road parameters and historical cap levels before adding high historical values.
- Do More / Floor Goals:
- Deleting or moving a datapoint's date forward can create a temporary gap on that day, violating the minimum floor and triggering an immediate derailment.
- Never shift a datapoint's date forward if it was the only data point satisfying the goal on its original date.
- Authentication & User-Awareness:
- Always verify you are querying and writing to the correct user's Beeminder goals.
- Do not overwrite or delete values unilaterally without showing the current history and requesting explicit confirmation.
The @TARE Reset Mechanic
For cumulative/odometer goals that reset every month (like groqspend or claudespend):
- Start-of-Month Tare:
- A tare datapoint of value
0.0with the exact comment@TAREmust be submitted on the 1st day of the month (or prior to the month's first real reading). - Beeminder uses this tare to offset the visual graph, resetting the cumulative cost back to zero for the new period.
- A tare datapoint of value
- Audit Check:
- Verify that each month boundary has a
0.0value with@TAREcomment. If missing, a reset will not be registered visually, causing the graph to display cumulative lifetime costs rather than monthly costs.
- Verify that each month boundary has a
Timezone Protection (The Daystamp Bug)
Beeminder API accepts a daystamp string in YYYYMMDD format.
- Never rely on naive datetime conversions:
- Converting a naive UTC datetime (like
2026-06-01 00:00:00) to local US/Eastern timezone shifts the timestamp back by 4-5 hours (to2026-05-31 20:00:00-04:00), changing the daystamp and corrupting the month boundary.
- Converting a naive UTC datetime (like
- Ensure explicit timezone metadata:
- Always construct timezone-aware UTC datetimes at 12:00 noon UTC (e.g.
datetime(2026, 6, 30, 12, 0, tzinfo=timezone.utc)) for historical entries. When converted to Eastern, the daystamp will remain on the correct day (e.g.,20260630).
- Always construct timezone-aware UTC datetimes at 12:00 noon UTC (e.g.
Audit Workflow
- Fetch History: Retrieve the last 30-40 datapoints for the goal using the
get_goal_datapointsAPI tool. - Map Boundaries: Organize readings by month and check for:
- Presence of
@TAREon Day 1 of each month. - Consistency of final odometer readings on the last day of each month.
- Timezone shifting or duplicate datapoints.
- Presence of
- Confirm Edits with User: Show a table of proposed changes (Deletions, Modifications, Additions) and request explicit approval.
- Execute & Verify: Perform deletions/insertions in sequence, then re-fetch the history to display the finalized audit report.