AI Prompts Library

Diagnose the performance of my {CODE / SQL QUERY / ENDPOINT}. Symptoms: {WHAT'S SLOW, HOW SLOW, AT WHAT SCALE — "fine with 100 rows, dies at 100k"}. Environment: {LANGUAGE/DB + anything relevant}.
Method — measure before optimizing:
1. INSTRUMENT FIRST: tell me exactly how to measure where time goes (the profiler command, the
EXPLAIN ANALYZE, the timing wrapper) so we're not guessing.
2. HYPOTHESES: the 3 most likely bottlenecks for this pattern and scale, ranked — with the
tell-tale signature each would show in the measurement.
3. Once identified (or for your top hypothesis now), THE FIX: corrected code/query, with expected order-of-improvement ("this turns O(n²) into O(n log n) — at your 100k rows, roughly 1000× fewer operations").
4. THE HIERARCHY check — in order, because each level dwarfs the next: algorithm choice → I/O and round-trips (N+1 queries, network calls in loops) → memory allocation patterns →
micro-optimizations. Refuse to micro-optimize if a higher level is unfixed.
5. GUARD: a simple benchmark/assertion to keep in place so this regression can't sneak back.
CODE/QUERY: {PASTE}

Decode this error for me. Context: {LANGUAGE/FRAMEWORK + what I was doing when it happened + what
I changed recently, if anything}.
Structure your answer:
1. TRANSLATION: what this error message actually says, in one plain-English sentence. (Error
messages describe symptoms — name the symptom.)
2. WHERE TO LOOK: which line/frame in the trace is MINE vs. library noise — point at the frame
that matters.
3. LIKELY CAUSES, ranked by probability for MY context: for each — why it produces exactly this message, and a 30-second check to confirm or eliminate it (a print, a command, an inspection).
4. THE FIX for the confirmed cause — and if we can't confirm yet, the fix for cause #1 with a note on what result means "move to cause #2".
5. UNDERSTAND IT ONCE: the 2-sentence concept behind this error class, so I recognize it instantly next time.
Rule: never say "this usually means" without committing to a ranked list. Vague error help is no help.
ERROR + STACK TRACE: {PASTE}
RELEVANT CODE (if I have it): {PASTE}

Design a database schema for: {DESCRIBE YOUR APP AND WHAT IT STORES, IN PLAIN ENGLISH}. Database: {PostgreSQL / MySQL / SQLite / "you pick"}. Expected scale: {ROUGH USERS/ROWS or "small, might grow"}.
Process:
1. QUERIES FIRST: before any tables, list the 8–10 queries the app will actually run most (schemas should serve queries, not entity diagrams). Confirm with me if unsure.
2. SCHEMA: full CREATE TABLE statements — sensible types, NOT NULL where truthful, foreign keys with explicit ON DELETE behavior (and a note on why CASCADE vs RESTRICT per relation),
created_at/updated_at where useful, unique constraints that encode business rules.
3. RELATIONSHIPS: text diagram of tables and cardinality; call out any many-to-many and its
junction table.
4. INDEXES: one per frequent query pattern from step 1, each justified in one line. No speculative indexes.
5. THE TRAPS I AVOIDED FOR YOU: where I chose against — EAV tables, JSON-blob-for-everything,
premature sharding, storing derived values — and the one place denormalization IS justified here.
6. MIGRATION PATH: which future requirement would force a schema change, and how today's design keeps that change cheap.

Translate my code from {SOURCE LANGUAGE} to {TARGET LANGUAGE} — as a senior {TARGET} developer
would WRITE it, not as a machine would transliterate it.
Rules:
1. IDIOMATIC FIRST: use {TARGET}'s native patterns (its error handling style, its iteration
idioms, its naming conventions) even when the structure diverges from my original. Word-for-word translations are how you spot a tourist.
2. ECOSYSTEM: replace hand-rolled logic with the standard library or de-facto standard package a native would reach for. Name the package and why it's the community default.
3. SEMANTICS WATCHLIST: after the code, list every place where behavior subtly differs — integer division, string encoding, null vs undefined vs None semantics, mutability, concurrency model,number precision. These bite silently.
4. THE UNTRANSLATABLE: anything with no clean equivalent — explain the trade-off of each
workaround option.
5. TESTS: translate/adapt one test that proves both versions behave identically on the same
inputs, including one edge case from the watchlist.
CODE: {PASTE}

Write documentation for my code that a stressed developer at 6pm actually finds useful. Audience:
{FUTURE ME / MY TEAM / OPEN-SOURCE USERS}.
Produce:
1. ONE-PARAGRAPH OVERVIEW: what this does and when you'd reach for it — written before any
installation details, because people first decide IF they care.
2. QUICKSTART: the minimum copy-paste path from zero to seeing it work. Every command runnable, every placeholder obvious. If setup has a prerequisite, say it BEFORE the step that fails without it.
3. USAGE EXAMPLES: 3 realistic scenarios (basic, typical, advanced) with actual code — examples teach better than API tables.
4. THE GOTCHAS SECTION (the part everyone forgets to write): surprising behaviors, common
mistakes, error messages users will see and what they actually mean, performance cliffs.
5. API REFERENCE: only for the public surface — parameters, returns, throws. Skip internals.
Rules: no marketing adjectives ("blazingly fast", "simple"), present tense, second person ("you"), and every claim testable.
CODE / PROJECT:
{PASTE}

I want to build: {ONE-SENTENCE APP IDEA}. Target user: {WHO}. I know: {YOUR SKILLS/STACK or "beginner"}.
Give me a shippable plan, not a lecture:
1. SCOPE CUT: the true MVP — 3 features max. List what I should explicitly NOT build in v1 (this list matters most).
2. STACK: one recommendation with a one-line reason, biased toward boring, well-documented tech I can debug. No exotic choices.
3. DATA MODEL: tables/collections with fields and relations, as a simple schema.
4. FILE STRUCTURE: the actual directory tree.
5. BUILD ORDER: 6–10 steps, each completable in one sitting, each ending with something testable.
6. CODE: write step 1 completely, ready to run, with setup commands.

You are a precision tool for {REGEX / SQL / BASH / GIT} one-liners. Two modes:
MODE A — I describe, you build: Give me the exact expression/command, then a piece-by-piece
breakdown table (fragment fi what it does), then 2 test cases showing it working, then the ONE most likely way it fails (edge case) and the hardened version.
MODE B — I paste, you explain: Break it into fragments with plain-English meaning, state what the whole thing accomplishes in one sentence, flag anything dangerous (catastrophic backtracking, full table scan, rm risks), and suggest a more readable alternative if one exists.
MY REQUEST ({A or B}):
{DESCRIBE OR PASTE}

Act as my debugging partner. I have a bug I can't crack. Use systematic diagnosis — do NOT jump to a guessed fix.
Process:
1. First, ask me up to 5 clarifying questions: exact error/behavior, expected behavior, when it last worked, what changed, environment.
2. Form the 3 most likely hypotheses, ranked by probability, each with a 1-line test to
confirm/eliminate it ("add this log line", "run this command").
3. I'll report results; narrow down and repeat until we find the root cause.
4. Then: the fix, WHY it happened (root cause explanation), and one guard (test/assertion/type) that prevents regression.
THE BUG:
{DESCRIBE + PASTE ERROR/CODE}