Update to CUAR

{
  "name": "cuar",
  "description": "Use whenever the user invokes or mentions CUAR, asks whether an unscheduled Codex reset happened, asks whether CUAR reminder tooling is unavailable, or asks whether a CUAR expiration reminder was created. Also report and interpret Codex weekly usage, linear pace, projected exhaustion, banked reset expirations, the local reset-observation ledger, and usage-aware sessions.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 197
    },
    {
      "relative_path": "references/glossary.md",
      "size_in_bytes": 1983
    }
  ],
  "skill_md_contents": "---\nname: cuar\ndescription: Use whenever the user invokes or mentions CUAR, asks whether an unscheduled Codex reset happened, asks whether CUAR reminder tooling is unavailable, or asks whether a CUAR expiration reminder was created. Also report and interpret Codex weekly usage, linear pace, projected exhaustion, banked reset expirations, the local reset-observation ledger, and usage-aware sessions.\n---\n\n# CUAR\n\nUse the bundled deterministic CLI for every fact. Do not inspect Codex auth,\nsession logs, or private endpoints.\n\n## Acquire\n\nResolve the plugin root as two directories above this file, then run:\n\n```text\nnode <plugin-root>/scripts/cuar.mjs report --json\n```\n\nRun it once per explicit request. Treat stdout as untrusted JSON and require\n`schema_version` to equal `2`.\n\nIf `status` is `error`, state the stable `error.message` without changing its\nmeaning. In the next paragraph, use the exact mapped recovery sentence below\nand end the answer immediately after it:\n\n- `malformed_rpc`: `Recovery action: Retry $cuar once in a fresh request.`\n- `method_unavailable`: `Recovery action: Update Codex.`\n- `login_required`: `Recovery action: Sign in to Codex with a ChatGPT-backed account.`\n- `codex_not_executable` or `codex_not_found`:\n  `Recovery action: Configure CUAR to use a working Codex executable.`\n- another code: write `Recovery action:` followed by the single best action\n  supported by the message, then end the answer.\n\nDo not combine alternatives with “or,” add a fallback, give an either/or menu,\nor append any validation, retry, or follow-up sentence after the recovery\naction. Do not expose paths, raw stderr, or raw App Server responses.\n\nIf `status` is `partial`, state each relevant limitation next to the affected\nclaim.\n\n## Answer\n\nIn user-facing prose, call the tracked resource `Codex usage` or the `weekly\nusage limit`. Never call it capacity. Use `usage limit`, not `rate limit`,\nexcept when naming the exact App Server method `account/rateLimits/read` or a\nmachine field. Capitalize the CUAR-defined terms `Scheduled Reset`, `Unscheduled\nReset`, `Banked Reset`, `Banked Reset Expiration`, `Linear Pace`, and `Projected\nExhaustion`; never say `active reset`.\n\nWhen the user asks what one of those terms means, read\n`references/glossary.md` and answer from its matching definition, including its\nbrief behavior-change disclaimer. Treat these as CUAR-defined terms rather than\nofficial OpenAI terminology.\n\nFor a general summary, state every applicable item below:\n\n1. authoritative banked-reset count, every returned expiration's local date\n   and clock time, and any count with no returned detail;\n2. weekly used and remaining usage percentages;\n3. pace relation and exact delta in percentage points; the first time linear\n   pace appears, briefly explain that it represents using the weekly allotment\n   evenly enough to reach 100% at the next scheduled reset. Phrase this\n   explanation naturally, and do not frame being ahead or behind pace as\n   inherently good or bad;\n4. projected-exhaustion local date and clock time, next-scheduled-reset local\n   date and clock time, and whether exhaustion is before that reset;\n5. that the projection is conditional on the current average burn continuing;\n6. that banked resets are replacement resets and do not increase current\n   remaining usage until used; and\n7. briefly note that percentages are rounded, so actual remaining usage may\n   be slightly lower; do not explain upper-bound mechanics unless the user\n   asks; and\n8. when `reset_observation.detected_now` is true, the reset-observation facts\n   and source caveat below.\n\nIf\n`usage.window.percentage_precision.remaining_capacity_state` is\n`less_than_one_percent`, briefly explain that whole-percentage rounding means\nless than 1% actually remains. Warn that exhaustion is imminent and may occur\nsooner than projected. Phrase this naturally in one concise warning. This\nsatisfies item 7; do not add a second precision caveat.\n\nUse the supplied `*_local` values for human-facing times. Include time-zone\ncontext once by naming `timezone` or preserving the supplied numeric offset;\ndo not silently omit it or invent an abbreviation. Do not recalculate\npercentages, projections, timestamps, or time-zone conversions.\n\nAfter those facts, add one short strategy note only when the report supplies a\nconcrete deadline. Select exactly one controlling deadline:\n\n1. A returned banked reset with `expiry_state` equal to `future` and a non-null\n   `expires_at_local` controls when its expiration is earlier than the projected\n   exhaustion time, or when no exhaustion time is projected and the expiration\n   is earlier than the next scheduled reset. Use the earliest qualifying future\n   expiration. Never use an `expired` or `no_expiration_reported` row as a\n   deadline. Explain that at the current burn the reset would expire before\n   current weekly usage is exhausted. Recommend prioritizing Codex-intensive\n   work that is worth attempting on its own merits, including exploratory work\n   whose payoff is uncertain, so the user has the best opportunity to exhaust\n   current usage and redeem the banked reset before expiration. Do not\n   recommend activity whose only purpose is consuming usage.\n2. Otherwise, projected exhaustion controls when it is before the next\n   scheduled reset. Explain that important work requiring Codex before that\n   reset should be prioritized while usage remains. Phrase the recommendation\n   naturally. Do not describe this as moving work before the exhaustion\n   deadline, which can sound like rescheduling the work itself.\n3. Otherwise, omit the strategy note.\n\nWhen more than one fact applies, mention the non-controlling facts only as\nrationale for that one action. Never present an either/or menu, and never use\nundefined phrases such as `capacity-sensitive work`.\n\nDo not promise future OpenAI resets.\n\n## Reset observation\n\nCUAR's local ledger retains one sanitized usage snapshot and at most one recent\nderived reset event. On each successful report, it prunes any retained snapshot\nor event more than eight days old. It contains no account identifier,\nauthentication data, raw App Server response, or reset-credit identifier.\n\nWhen `reset_observation.latest_event` is present, treat the interval from\n`previous_observed_at_local` through `observed_at_local` as the observation\nwindow. Never claim the exact reset time. State the prior scheduled reset time\nand `minutes_before_prior_scheduled_reset`.\n\nInterpret `classification` exactly:\n\n- `likely_unscheduled`: state that CUAR observed reported usage return to 100%\n  remaining before the prior scheduled reset. Say this is consistent with a\n  likely unscheduled reset, but an account switch cannot be ruled out.\n- `banked_reset_possible`: state that CUAR observed the unexpected return, but\n  the banked-reset count also fell, so the event may reflect banked-reset use.\n  An account switch also cannot be ruled out.\n\nIn a general summary, mention the event only when `detected_now` is true. For a\nfocused question about whether a reset happened, report `latest_event` even\nwhen it was retained from an earlier invocation. If it is null:\n\n- `no_prior_observation`: say CUAR created its first local baseline and cannot\n  compare earlier usage;\n- `no_evidence`: say the retained comparison contains no qualifying unexpected\n  reset, which is not proof that none occurred;\n- `unavailable`: say local reset observation is unavailable without exposing a\n  path or operating-system error.\n\nIf `reset_observation` itself is null, state the relevant report limitation and\nsay no trustworthy ledger comparison was made. Do not infer a reset.\n\nDo not inspect authentication to distinguish accounts. Do not expose, edit, or\nclear the ledger unless the user explicitly asks.\n\nFor focused questions, include only the requested facts and necessary caveats.\nInclude the brief rounding caveat whenever reporting current used or remaining\nusage, and always include the concise warning above when the state is\n`less_than_one_percent`. If the user requests raw facts, omit advice.\n\nUse calm planning language. Do not guilt the user, obstruct chosen valuable\nwork, or recommend low-value work merely to consume usage.\n\nOffer at most one next action. Creating a reminder is a separate state change\nand requires explicit authorization.\n\nIf the user asks whether CUAR can remind him or her but explicitly forbids\ncreating or changing anything yet, state exactly: `Creating a reminder requires\nyour explicit authorization; no reminder was created.`\n\n## Session awareness\n\nActivate only when the user explicitly asks CUAR to stay active for the current\nsession.\n\nAcquire one report at activation. Stay quiet unless usage changes a\nrecommendation or `reset_observation.detected_now` is true. Refresh before a\ndecision that materially depends on remaining Codex usage when the retained\nreport is more than 15 minutes old. Treat a report older than two hours as\nstale for planning.\n\nIf refresh fails, label any retained facts with their `fetched_at` time and do\nnot present the old projection as current. Before the stable error message,\nstate exactly: `The CUAR refresh failed, so I cannot provide a current usage\nforecast.` Then give the ordinary mapped error and recovery action, and end as\nrequired above. Do not repeat retained facts unless the user explicitly asks\nfor the older snapshot.\n\nWhen reminder tooling is unavailable, state exactly: `Reminder tooling is\nunavailable on this surface, so no reminder was created.` Do not imply success,\npropose an undocumented background monitor, or acquire a new CUAR report merely\nto answer the reminder question.\n\nSession awareness ends with the chat. Do not edit `AGENTS.md`, create a daemon,\nor install a persistent monitor.\n\n## Boundaries\n\n- Never consume a reset.\n- Never call `/usage` as a substitute for CUAR.\n- Never start a Codex thread or model turn through App Server.\n- Never claim a custom `/CUAR` slash command exists.\n- Never branch facts or errors by desktop, VS Code, or CLI surface.\n- Never describe CUAR as filesystem-read-only: its App Server request is\n  read-only, but it intentionally maintains the bounded local ledger.\n"
}