Debugging AI 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.

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.

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.

Puts the model in an operations mindset for CI/CD, containers, and infrastructure questions, focusing on reliability and rollback safety. Good for reviewing a deployment plan or working out why a pipeline stage keeps failing intermittently.

Makes the model behave like a browser console: you type an expression, it returns only what the console would print. Handy for reasoning about coercion, array methods, and async ordering without opening devtools. Keeps replies free of explanation unless you ask.

Turns the model into a sandboxed Linux shell that replies only with terminal output and no commentary. Useful for rehearsing commands, checking expected output, or teaching shell basics without touching a real machine. Wrap anything you want said in plain English in braces.