Code review & debugging21 categories
Critique this API design
Before other people start depending on an interface you're designing.
Critique this API as someone who will have to use it without reading its implementation. - What is confusing or easy to misuse? Where would I reach for the wrong function? - What is missing that I will obviously need? - What is present that nobody needs? - Is anything inconsistent with the rest of the surface — naming, argument order, return shapes, error handling? - Which decisions here will be painful to change later, once callers depend on them? Suggest a revised signature. Be specific about what you'd rename. API:
Making it yours
- Paste your own material where the prompt asks for it. Everything above that line is instruction, not content.
- Delete any rule that does not apply to you. A shorter prompt that fits beats a thorough one that does not.
- If the answer comes back vague, add a line saying what you do not want. Constraints work better than encouragement.
Refactoring and design calls. Cutting code down, naming things properly, and choosing between two workable options.
Related prompts
Delete as much of this as possibleCode that works but feels bigger than the problem.Better names for these thingsWhen you've written `data2`, `handleThing`, or `utils`.Improve these error messagesErrors that say "something went wrong".Should I add this dependency?Before `npm install` on something you could write yourself.Name this functionYou've called it doThing and you know it.Two fixes, pick oneTwo plausible approaches and no strong feeling about either.
Keep this one
Phrasery saves prompts with a right-click and puts them back the same way. Add this to your own library in one click.
Add to your browser — free