APromptAura

Prompts for GPT

Ranked by votes, with verified run counts from the community.

0
p/codingAauraNovice4 days agohas example⁂auto-checked

Diagnose and rewrite a slow SQL query with execution-plan reasoning

This query is too slow. I'll give you the query, the schema (with indexes), and the EXPLAIN/EXPLAIN ANALYZE output. Do this: 1. Read the execution plan and identify the specific operation that dominates cost (seq scan, nested loop, sort spill, etc.), quoting the relevant line from the plan. 2. Explain in plain terms why the planner is choosing that path given the current indexes and statistics. 3. Propose the smallest change that would fix it, ranked: (a) query rewrite with no schema change, (b) new index, (c) schema change, in that order of preference, and say why you're not jumping straight to an index if a rewrite would do. 4. Show the rewritten query or CREATE INDEX statement. 5. Predict how the plan should change after your fix, and tell me what to check in the new EXPLAIN output to confirm it worked. 6. Flag if the fix could hurt a different query that shares the same table (e.g. a new index that slows down writes on a hot table). Database: {{database, e.g. Postgres 15}} Query: query Schema/indexes: schema EXPLAIN output: explain_output
ClaudeGPT#sql#performance#database
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Write a regex with an explanation and a battery of test cases

Write a regular expression that matches: pattern_description Flavor/engine: {{regex_flavor, e.g. PCRE / Python re / JS RegExp}} Requirements: 1. Show the regex itself first, then a plain-English breakdown of each group/token, no jargon without explanation. 2. Provide a table of at least 8 test strings: half that should match (including tricky edge cases within scope) and half that should NOT match (including near-misses that a naive regex would wrongly accept), with the expected result for each. 3. State explicitly what the regex deliberately does NOT handle, if the description implies edge cases that would make the pattern unreadable to cover (e.g. fully RFC-compliant email addresses). 4. If a non-regex approach (e.g. a proper parser) would be meaningfully more correct for this task, say so, but still provide the best-effort regex if I asked for one. 5. Avoid catastrophic backtracking; note any risk points if the pattern uses nested quantifiers.
ClaudeGPT#regex#pattern-matching#testing
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Plan a legacy framework migration with a reversible, staged rollout

I need to migrate codebase_description from old_framework to new_framework. Produce a migration plan, not code, structured as: 1. Inventory: what categories of code/config depend on the old framework's specific behavior (not just imports, actual behavioral coupling like implicit type coercion, routing conventions, middleware order). 2. Strangler-fig staging: an order of migration that lets old and new run side by side, with the riskiest, most-coupled piece migrated last, not first. 3. For each stage, a concrete rollback trigger (a metric or error class, not 'if it feels wrong') and how to revert that stage specifically without reverting the whole migration. 4. Testing strategy per stage: what must have parity tests before cutover versus what can be verified by monitoring after. 5. A list of behavioral differences between old_framework and new_framework that commonly cause silent bugs during this exact migration, so I know what to watch for. Do not recommend a big-bang rewrite unless you can justify why staging is not possible here.
ClaudeGPT#migration#architecture#rollout-strategy
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Generate property-based tests that find edge cases, not happy-path duplicates

Write property-based tests (using {{framework, e.g. Hypothesis / fast-check / QuickCheck}}) for the function below. Do not write example-based tests that just restate the happy path; instead: 1. Identify the invariants the function should always satisfy (e.g. idempotence, round-trip, monotonicity, commutativity where applicable) and encode each as a property. 2. Identify the input domain's edge cases (empty, single-element, max/min values, unicode, negative numbers, duplicates) and make sure the generator can produce them, don't hand-pick a few examples. 3. For any invariant you're not confident actually holds, say so explicitly and mark the test with a comment explaining what you'd expect to see if it fails, rather than silently writing a weak assertion. 4. Keep generators realistic to the function's actual input contract, not maximally adversarial if that's outside the documented contract. Function: code Language: language Known contract/docstring: contract
ClaudeGPT#testing#property-based-testing#edge-cases
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Turn a god function into composable, testable units

I have a function that has grown too large and does too many things. Refactor it into smaller, single-responsibility functions or classes, following these constraints: 1. Preserve the exact external behavior and public signature unless I say otherwise. 2. Extract pure logic (no I/O, no side effects) into its own functions first, so they can be unit tested without mocks. 3. Name each extracted piece for what it does, not how it does it. 4. Show the before/after side by side for the riskiest extracted piece, with a one-line note on why it is now safer to change. 5. List any behavior that is ambiguous in the original code (e.g. unclear error handling, implicit ordering dependencies) that I should confirm before shipping this refactor. 6. Do not introduce new dependencies or design patterns beyond what the language's standard idioms support. Language/framework: language Function to refactor: code What it's used for / calling context: context
ClaudeGPT#refactoring#clean-code#testing
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Severity-tagged code review with rationale, not just nitpicks

You are reviewing a pull request. I will paste a diff. For each issue you find, output a table with columns: File:Line, Severity (blocker, major, minor, nit), Category (correctness, security, performance, readability, test-coverage), Issue, and Suggested Fix. Rules: - Only flag a blocker if it would cause a production incident, data loss, or a security hole. - Do not repeat the same class of issue more than once; group repeats and note the count. - If you cannot tell whether something is a bug without more context, say what context you need instead of guessing. - After the table, write a 3-sentence summary: is this safe to merge, needs changes, or needs discussion. - Do not comment on formatting that a linter would catch. Here is the diff: diff_or_pr_link Additional context (framework, invariants, prior incidents this touches): context
ClaudeGPT#code-review#pull-request#security
0
Previous