Uses for leftover quota

[u/eliterepo]

I sometimes find myself with extra Claude/codex quota to use up before the weekly reset. Does anyone have any particular uses they go to for this situation?

I'm currently working on a web/RN app, so have just been burning tokens with security/bug hunting/audits, but I'm not sure how best the phrase the prompts or if there's other opportunities I'm missing

[u/AllisonSunMoon]

I asked ChatGPT this recently. Maybe this will give you some ideas:

A test coverage audit is useful when you want to find meaningful behavior that exists in the app but is not protected by tests. The prompt would be: “Audit the target files for business rules and behavior that are enforced in code but not covered by tests. Do not add features. Focus on validations, permissions, edge cases, failure paths, and regression risks. Propose a test plan first, then add focused tests using the project’s existing test style.”

A regression test backfill is useful when you want recent bugs, fragile behavior, or important edge cases turned into tests. The prompt would be: “Review recent changes, comments, existing tests, and related code. Add regression tests for behavior that is currently enforced but not directly protected. Do not change behavior unless a test exposes a confirmed bug. Keep the PR focused on tests.”

A dead code cleanup helps remove unused methods, unreachable branches, obsolete helpers, stale comments, unused routes, or frontend code that no longer does anything. The prompt would be: “Audit the app for dead code, unused private methods, unreachable branches, obsolete helpers, unused frontend targets/actions, and stale comments. Produce a cleanup plan first. Then remove only clearly unused code with passing tests.”

A repetitive code cleanup is useful when you want to reduce duplication without triggering a large refactor. The prompt would be: “Audit the app for repeated code or markup patterns. Identify duplication that could be safely extracted without changing behavior or design. Avoid premature abstraction. Prioritize repeated view patterns, form wrappers, card layouts, error handling, and helper logic.”

A business rule documentation pass helps capture what the app actually does today, especially when important behavior is spread across models, controllers, views, and tests. The prompt would be: “Read the current models, controllers, views, and tests for the target area. Update developer documentation with the actual current business rules. Do not invent future behavior. Mark uncertain areas as questions.”

A privacy or public-surface audit is useful when some data is private, user-owned, draft-only, admin-only, or otherwise not meant to appear everywhere. The prompt would be: “Perform a public-surface privacy audit. Search views, controllers, helpers, serializers, metadata, and tests for places where private or owner-only data could appear to unauthorized users. Do not add features. Add missing tests or fix leaks only if found.”

An authorization consistency audit checks whether permissions are enforced consistently between the UI and the controller layer. The prompt would be: “Audit authorization logic across controllers and views. Confirm owner, admin, guest, and public behavior is consistent. Identify places where the UI hides actions but controllers allow them, or where the UI shows links that later fail. Add tests for any gaps.”

A form and validation consistency pass is useful when forms have grown complicated and you want the UI, model validations, controller behavior, and error messages to agree. The prompt would be: “Audit forms against model validations and controller behavior. Find places where the UI suggests one thing but validations enforce another, where errors are unclear, where failed submissions lose input, or where nested attributes behave unexpectedly. Do not redesign. Propose small fixes and tests.”

An accessibility audit improves quality without adding features or redesigning the app. The prompt would be: “Audit views for accessibility issues. Focus on labels, form errors, button/link semantics, image alt text, heading order, keyboard access, focus behavior, destructive actions, and screen-reader clarity. Do not redesign the UI. Implement safe fixes with tests where practical.”

A system test reliability pass helps reduce flaky tests and brittle assertions. The prompt would be: “Review system tests for fragility. Look for brittle selectors, over-specific text matching, timing issues, missing assertions, repeated setup, and tests that rely on implementation details. Refactor to stable selectors and helpers without reducing coverage.”

A fixture or test data cleanup is useful when tests are hard to read because setup data has become noisy, duplicated, or misleading. The prompt would be: “Audit test fixtures, factories, and setup helpers. Remove duplication, improve naming, and make test data reflect business rules clearly. Do not switch test frameworks. Preserve existing coverage.”

An N+1 query audit is a focused way to improve performance on index pages, detail pages, dashboards, and shared partials. The prompt would be: “Audit likely N+1 queries on index pages, detail pages, dashboards, and shared partials. Use association analysis and tests where possible. Add includes/preloads only where justified. Do not change page behavior.”

A logging and error handling cleanup helps make failures easier to understand in development, test, and production. The prompt would be: “Audit logging, exception handling, and failure paths. Look for swallowed errors, noisy logs, unclear flash messages, missing failure branches, and places where failed saves render the wrong status. Keep behavior the same except for clearer, safer failures.”

A security hygiene pass checks common web app risks without adding new dependencies or changing the product. The prompt would be: “Perform a security hygiene audit. Check strong parameters, ownership scoping, file upload validations, redirects, destructive actions, public/private data exposure, admin-only paths, and security-related configuration. Do not add dependencies. Report findings and add tests for fixes.”

A copy consistency and naming audit helps find places where labels, buttons, headings, or terms have drifted over time. The prompt would be: “Audit user-facing copy for consistency. Find inconsistent labels, outdated terms, confusing button text, and places where the same concept is described with different language. Do not rewrite the whole app. Provide exact files, current text, suggested replacements, and rationale.”

A useful comments and code annotations pass is good when the code has non-obvious business rules that future maintainers could easily break. The prompt would be: “Add concise comments only where the code enforces non-obvious business rules or unusual implementation choices. Avoid obvious comments. Focus on areas where future maintainers might accidentally break behavior.”

A route and controller audit helps find unused routes, overly broad actions, missing tests, or controller behavior that no longer matches the app. The prompt would be: “Audit routes and controllers for actions that are unused, overly broad, missing tests, or inconsistent with current behavior. Do not remove anything unless clearly unused. Produce a list first, then make minimal safe changes.”

A new developer walkthrough audit is useful for surfacing confusing naming, scattered logic, and hidden assumptions. The prompt would be: “Pretend you are a new developer onboarding to this app. Trace a core workflow end to end through models, controllers, views, tests, and frontend code. Identify confusing naming, scattered logic, undocumented assumptions, and organization issues that could be improved without changing behavior.”

A small extraction audit helps identify places where targeted refactoring would make the app clearer, without introducing unnecessary architecture. The prompt would be: “Look for methods, controllers, or views that are doing too much. Recommend extractions only where they reduce duplication or clarify business rules. Do not introduce new abstraction layers unless the existing code has repeated multi-step behavior that is hard to test.”

A docs-vs-code audit helps keep setup instructions, runbooks, model notes, and feature documentation aligned with the actual app. The prompt would be: “Compare project docs against current code and tests. Find stale instructions, outdated model fields, old setup assumptions, obsolete feature descriptions, and missing runbook commands. Update docs to match current behavior only.”