Audit exported function and class names for consistency and grep-ability
Category: Audit · Updated 2026-09-22 · Tools: Codex
Use this on a library or module other code depends on, especially one with multiple contributors, where names have accreted inconsistently over time (some verbs, some nouns, some abbreviated, some not). Best as a report first, since renaming a public export is a breaking change for callers. Small to medium usage.
Full prompt
List every function, class, and type this module or package exports publicly (not internal/private helpers). For each name, flag it if: it's a generic verb with no object (like `process` or `handle` instead of `processPayment`), it could plausibly collide with a same-named export elsewhere in the codebase, it uses different terminology than sibling exports for the same concept (like mixing `userId` and `user_id` or `accountId` in the same module), or a plain-text search for the name alone wouldn't reliably lead someone to its definition. For each flagged name, suggest a more specific, greppable alternative and note every call site that would need updating. Do not rename anything yet — this is a report only, since these are breaking changes for any external caller.
Tips
- This works best as a periodic check on a stable library, not mid-refactor on code that's still actively changing shape
- Ask for the call-site count per suggested rename up front — it tells you which renames are cheap to actually do and which ones need a deprecation path instead
- If the module has an external/public API boundary, tell the agent explicitly where that boundary is, since renaming something truly external is a much bigger decision than renaming an internal-only export
Still waiting on a reset? See what to do when you hit the limit, or check Codex / Claude time since last reset.
Back to the prompt library · Subscribe: all-products feed