Claude Prompts

A launch skeleton with a fixed narrative arc — agitate, reveal, prove, close — and hygiene rules that keep the copy out of the promotions-tab voice. Fill the brackets and you have a shippable draft to edit, not a blank page.

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.

An SEO outline prompt that starts from intent classification instead of jumping to headings, so the page answers the query before decorating it. Ships with a compliant title tag and meta description ready to paste.

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.

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.

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.

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.

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.

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.

Combines prospecting and technical site review, identifying where a B2B site loses qualified traffic and how to capture more of it. Useful for a pre-quarter audit where pipeline and organic performance need looking at as one problem rather than two.

Puts the model in a senior marketing seat to build a promotion plan across channels for a launch you describe. Useful when you need sequencing — what runs first, what the budget favours, and which metric decides whether the launch worked.

Frames the model as an instructional writer building teaching material on a topic and level you set. Useful for turning expertise into a structured lesson, and for content marketing where the goal is to rank by genuinely answering the question.

Puts the model in a brand strategy role, working through positioning, personality, and messaging pillars for a business you describe. Useful early, when you need the words that everything else — site copy, ads, packaging — will later be built from.

Casts the model as a PM who turns a rough feature idea into a structured requirements document with goals, scope, and success measures. Useful for forcing clarity on what a feature is actually for before any design or engineering time is spent.