AI Coding Prompts

A debugging discipline in prompt form: hypotheses with evidence both ways and a cheapest-experiment step, with fixes explicitly forbidden until confirmation. Cuts wild-goose-chase time dramatically on unfamiliar codebases.

A query-tuning prompt ordered by invasiveness so you try rewrites before adding indexes. Requiring the write-cost caveat on every index suggestion filters out advice that would just move the pain to inserts.

A performance-review prompt that forces ranking by impact before any fix, which stops the usual memo-everything reflex. The minimal-fix constraint keeps diffs reviewable. Paste one component at a time for best results.

Frames the model around developer experience: what documentation is missing, where onboarding loses people, and how a community forms around a tool. Useful for teams whose product is technically sound but adopted slowly for reasons nobody has diagnosed.

Explains architectural decisions in terms of the trade-offs they buy and the costs they defer, rather than presenting patterns as rules. Useful for engineers starting to make system-level calls who need to justify a choice rather than just name it.

Runs a lighter pass than a full review, catching the mechanical issues — naming, dead code, missing null handling — before a human reviewer spends attention on them. Best used as the step between finishing a branch and opening the pull request.

Turns a diff into a clear commit message that explains intent rather than restating the changed lines. Useful for keeping a history that is worth reading during an incident, when the question is always why a change was made and not what it touched.

Frames the model around Next.js specifics — server versus client components, data fetching, caching and revalidation. Useful when the general React answer is wrong for the framework, which in the App Router is more often than most developers expect.

Generates a development container configuration so a Python project runs identically for everyone on the team. Useful for killing the works-on-my-machine class of bug, and for onboarding contributors without a page of setup instructions.

Rewrites code from another language into idiomatic Python rather than a literal transliteration. Useful for consolidating scattered utility scripts onto one stack, and the output is a reasonable starting point that still needs tests before it is trusted.

Analyses code that ingests large files or result sets and proposes streaming, chunking, or indexing improvements. Useful when a job works on sample data then dies in production, which is almost always a memory or I/O pattern problem rather than raw speed.

Ports a snippet from one language to another while preserving behaviour and adopting the target language's idioms. Useful during migrations, though the output needs testing — literal translation often produces code that runs but reads as foreign.

Explains how an unfamiliar repository is organised, what each directory is responsible for, and where to start reading. Genuinely useful when joining a project or evaluating a dependency, since architecture is rarely documented as clearly as the API.

Helps organise, tag, and retrieve frequently used code fragments so the same solution is not rewritten each sprint. Useful for teams building an internal pattern library, and for keeping snippet documentation close enough to the code to stay accurate.

Walks a site's surface area looking for common weaknesses — injection points, weak headers, exposed endpoints — and explains the fix for each. Intended for reviewing infrastructure you own or are authorised to test, as part of routine hardening.

Reviews an AI feature for prompt injection, data leakage, and unsafe tool use, then proposes mitigations. Increasingly necessary for any product that passes untrusted text to a model, where the attack surface is the content itself rather than the code.

Produces shell scripts for a task you describe, with argument handling and error checking rather than a bare one-liner. Useful for automating backups, log rotation, and deployment steps where silent failure would otherwise go unnoticed for weeks.

Guides the model through structured diagnosis: gather symptoms, form a hypothesis, test the cheapest one first. Useful for hardware and environment problems where the instinct to change several things at once usually makes the fault harder to find.

Sets a mentoring frame where the model explains not just how to do something but why the practice exists. Useful for developers moving from working code toward maintainable code, and for understanding the reasoning behind conventions rather than just following them.

Positions the model as a senior engineer who reasons through difficult problems step by step rather than jumping to a snippet. Best reserved for genuinely knotty issues — concurrency, performance cliffs, subtle state bugs — where the reasoning matters more than the code.

Acts as an R console that returns results without commentary. Useful for verifying vector operations, data frame manipulation, and statistical function output when you are away from RStudio, or for checking syntax before running a long analysis job.

Behaves as a bare PHP interpreter, printing only what the script would output. Handy for checking array functions, string handling, and type juggling behaviour without spinning up a local server. Suppressing explanation makes it a fast self-test tool.

Frames the model as a product designer who proposes layouts, interaction patterns, and visual hierarchy for a screen you describe. Useful for getting a second opinion on a flow before building it, particularly around what to cut and where the primary action belongs.

Frames the model as an experienced Ethereum developer writing Solidity contracts with the access rules and state handling spelled out. Useful for scaffolding a contract and understanding the trade-offs, though any output needs a real audit before deployment.