Strict code review that ignores style
codingReviews a diff for correctness, edge cases, and regressions — and refuses to comment on formatting.
24 prompts that do one job each. Every one states its constraints, says what to change for your project, and explains why it works. No role-play preamble, no "you are a world-class expert".
Reviews a diff for correctness, edge cases, and regressions — and refuses to comment on formatting.
Extracts or restructures code while proving the public behavior stays identical.
Writes the failing test first, then the fix, and refuses to skip the reproduction.
Produces a map of responsibilities, data flow, and the parts that look dangerous to change.
Turns a business question into a query plus the schema assumptions it made.
Pressure-tests an endpoint spec for naming, pagination, errors, and the version you will regret in a year.
Plans a brownfield migration in steps small enough to revert, and names the point of no return.
Builds the test matrix from requirements and failure modes, so it catches what the implementation forgot.
Looks for injection, authorization gaps, and secret leakage — and refuses to comment on anything else.
Groups a messy log into failure signatures and ranks hypotheses before anyone touches code.
Checks markup against the failures screen readers actually hit, not a checklist of rules.
Builds a pattern from positive examples and then states what it will wrongly match.
Checks function, table, and endpoint names against what they actually do.
Decides in one minute using blast radius, confidence, and time-to-restore.
Groups commits into user-facing changes, without inventing anything that is not in the log.
Turns what the product does into what it removes from the reader's day.
Turns logs and a chat transcript into a blameless postmortem with contributing factors, not a culprit.
Extracts what was decided, what was merely discussed, and who owes what by when.
Rewrites button labels, errors, and empty states so they say what happened and what to do.
Declines a request clearly, names the constraint, and offers a smaller yes.
Separates what is known, what is inferred, and what is unknown — with citations on the first two.
Defines the metric, the population, and the comparison before anyone queries the warehouse.
Separates what the paper shows, what it suggests, and what everyone will misquote.
Turns a transcript into problems and constraints, and separates them from proposed solutions.
Each prompt is structured around constraints rather than encouragement. Telling a model it is an expert changes tone; telling it what not to output changes results. If a prompt here works, it is because of the rules, not the framing.
If you improve one, send it over — prompts that survive real use are worth publishing.