APromptAura

Updated August 2026

Best coding prompts

Ranked by community votes over the last 30 days. Every prompt below shows how many people ran it and confirmed it did what it claims. Copy any of them without an account.

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
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Explain a suspected memory leak from heap snapshots and propose a fix

I suspect a memory leak in service_name (language/runtime). I'll describe symptoms and, if available, heap snapshot diffs or growth-over-time data. Help me: 1. Distinguish a true leak (unbounded growth, objects that should be freed but aren't) from expected memory behavior (cache warming, GC not having run yet, connection pool at steady-state size). Ask what would confirm this if the data I gave isn't enough. 2. From the object types/counts that are growing, infer the likely retention path (what's holding a reference and preventing collection): common culprits are event listeners never removed, closures capturing large scope, unbounded caches/maps, or a connection pool not releasing. 3. Propose the smallest code change to fix the retention, and explain specifically why it breaks the reference chain. 4. Suggest one verification step (a metric to watch, a snapshot to retake) that would confirm the fix worked in production, not just in a local repro. 5. If the leak is architectural (e.g. a fundamentally unbounded cache with no eviction), say so plainly rather than proposing a band-aid. Symptoms/data: symptoms Relevant code: code
ClaudeGPT#debugging#performance#memory-leak
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

Root-cause a flaky test using a structured hypothesis funnel

This test fails intermittently, not on every run. Help me find the actual root cause instead of just adding a retry or a sleep. Work through this funnel and show your reasoning at each step: 1. List every source of non-determinism visible in the test and the code it exercises (ordering, timing, shared state, randomness, network, concurrency, uninitialized globals). 2. Rank them by how likely each is to explain the specific failure signature I give you. 3. For your top hypothesis, propose the smallest possible experiment (a log line, an assertion, a seed) that would confirm or rule it out, without changing behavior. 4. Only after that, propose a fix. Explicitly say why a sleep/retry would mask this rather than fix it, if that's what's tempting. 5. If the fix requires changing production code (not just the test), flag that clearly since it has broader blast radius. Test code: test_code Code under test: code_under_test Failure signature (error, stack trace, how often it fails): failure_signature
Claude#debugging#testing#flaky-tests
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

REST/GraphQL API design review against real client use cases

Review this API design (not the implementation, the shape of the contract) against the client use cases I'll describe. For each use case, trace exactly how a client would call this API to accomplish it, and flag friction: 1. Over-fetching or under-fetching: does a common use case require multiple round trips that could be one, or return way more data than needed. 2. Inconsistent conventions: naming, pagination style, error shape, versioning, compared across the endpoints I've shown, not against some external standard unless I ask. 3. Idempotency and retry safety: which mutating endpoints are safe to retry blindly, and which aren't but should be (missing idempotency keys). 4. Backward compatibility: if this evolves the way I describe in 'planned future changes', will today's design force a breaking change, or does it leave room to grow. 5. Rank findings by how much client-side pain they'd cause, not by aesthetic preference. Do not suggest switching REST to GraphQL or vice versa unless the use cases genuinely can't be served well by the current style. API design/schema: api_spec Client use cases: use_cases Planned future changes: future_changes
ClaudeGPT#api-design#rest#graphql#code-review
0
0
p/codingAauraNovice4 days agohas example💀failed our automated check

Security-focused code review against a specific threat model

Review this code for security issues, but scope it to the threat model I give you, don't produce a generic OWASP checklist dump. Threat model: {{threat_model, e.g. 'attacker controls request body and headers but has no valid auth token'}}. For each finding: 1. State the exact attacker action that would trigger it, concretely, as if writing a proof-of-concept step. 2. State what the code currently assumes that isn't actually guaranteed (e.g. 'assumes Content-Type header matches actual body format'). 3. Severity based on real exploitability given the threat model, not textbook severity (a SQL injection with no path for attacker-controlled input to the query isn't a blocker here). 4. Fix, minimal and specific to the code, not a rewrite. 5. Explicitly list what you checked and found NOT to be an issue given the threat model (e.g. 'CSRF not applicable, this is a server-to-server API with mTLS'), so I know the review was thorough rather than just silent on those. Code: code Auth/deployment context: context
ClaudeGPT#security#code-review#vulnerability
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

Interpret a flamegraph and turn it into a prioritized optimization list

I'm pasting a description or text export of a CPU flamegraph / profiler output for service_name. Help me turn it into action, not just commentary: 1. Identify the widest frames (highest self-time, not just total time) and name the actual function/operation, not just 'this looks slow'. 2. For each of the top 3 hotspots, give a hypothesis for WHY it's expensive (algorithmic complexity, unnecessary allocation, serialization overhead, lock contention, N+1 pattern) based on the function names and call context I give you. 3. Rank the 3 by expected impact-to-effort ratio, not just raw self-time, factoring in whether the fix is a one-line change or a redesign. 4. For the top-ranked one, propose a concrete fix and estimate (rough order of magnitude, not precise) how much it should reduce that frame's cost. 5. Note any hotspot that's actually expected/acceptable (e.g. a crypto operation that's inherently expensive) so I don't waste time optimizing something that's already near-optimal. Profiler output / description: profile_data Language/runtime: language Context (request volume, latency budget): context
ClaudeGPT#performance#profiling#optimization
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Zero-downtime database schema migration plan

I need to make this schema change: change_description on table table_name in database (production, actively serving traffic, row_count rows). Produce a plan that avoids locking the table for writes and avoids breaking currently-deployed application code during the rollout. Structure: 1. Break the change into safe, backward-compatible steps (e.g. add-nullable-column before backfill before add-constraint before drop-old-column), each deployable independently. 2. For each step, specify: the exact DDL, whether it takes a lock and for how long is acceptable, and what application code version must already be deployed before this step runs. 3. Backfill strategy: batched, with a way to pause/resume, and an estimate of how long it will take given the row count. 4. The order in which application code changes and migration steps must be deployed relative to each other (expand/contract pattern), stated explicitly as a sequence. 5. A rollback plan for each step that doesn't require restoring from backup. 6. What to monitor during the backfill (replication lag, lock wait time, error rate) to know if it's safe to keep going.
ClaudeGPT#sql#migration#database#production
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

SQL migration scripts with a tested rollback path

Write a database migration for: change_description in database. I need both the forward migration and a working rollback, not just a comment saying 'reverse the above'. Format: 1. Forward migration SQL, in the smallest safe steps (see note on locking below). 2. Rollback SQL that actually restores the prior state, including data if the forward migration transforms or deletes anything (not just structural revert). If perfect rollback is impossible (e.g. a dropped column's data is gone), say so explicitly and propose a mitigation (e.g. rename instead of drop, keep for one release cycle). 3. State which statements take a table lock and roughly how that scales with table size, using database's actual locking behavior, not a generic claim. 4. Idempotency: write the migration so re-running it after a partial failure doesn't error out (use IF NOT EXISTS / IF EXISTS guards where the dialect supports them). 5. A one-line comment above each statement explaining its purpose, for the next engineer reading the migration file. Current schema: schema Change needed: change_description
ClaudeGPT#sql#migration#database#rollback
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Architecture Decision Record generator that surfaces the real tradeoffs

Write an Architecture Decision Record (ADR) for the decision: decision_summary. Use this structure and hold yourself to it strictly: 1. Context: what problem forced this decision, including constraints (team size, timeline, existing stack) that ruled out otherwise-reasonable options. Be concrete, not generic. 2. Options considered: at least 2 real alternatives besides the chosen one, each with the honest case FOR it, not a strawman. If an option was rejected mainly for a non-technical reason (team familiarity, timeline), say that plainly instead of inventing a technical excuse. 3. Decision: what was chosen, one paragraph. 4. Consequences: both the benefits AND the costs/risks this decision introduces, explicitly labeled, don't bury the downsides in a single soft sentence. 5. Revisit trigger: a concrete condition under which this decision should be reconsidered (e.g. 'if write volume exceeds X/sec' or 'if team grows past Y engineers'), not 'if it stops working'. Decision details, options I actually considered, and constraints: details
ClaudeGPT#architecture#documentation#decision-making
0
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

Debug a confusing stack trace by working backward from the error

I have a stack trace and error message that doesn't obviously point to the real bug. Help me find it methodically: 1. Start from the exception type and message: state precisely what condition triggers this exception in the language/library it comes from (don't guess generically, look at what that specific error actually means). 2. Walk the stack trace top to bottom, and for each frame, state what would have to be true at that point for the next frame's call to have happened. Stop at the first frame where something looks inconsistent with the code I've shown you. 3. Give your best hypothesis for the root cause, and separately, one alternative hypothesis in case the first is wrong, with a way to distinguish between them (a log statement, a debugger breakpoint, a value to print). 4. Do not propose a fix until the root cause is confirmed or I tell you to proceed with best guess. If I say proceed with best guess, clearly label the fix as unconfirmed. Stack trace: stack_trace Relevant code: code What I was doing when it happened: context
ClaudeGPT#debugging#stack-trace#javascript
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Generate high-value unit tests for existing untested code, not filler

Write unit tests for the function/class below in framework. I don't want boilerplate happy-path-only tests. For each test you write, briefly state (as a comment) what specific risk it guards against. Cover, in priority order: 1. Boundary conditions implied by the code (off-by-one ranges, empty collections, first/last element behavior). 2. Error paths: every raised exception or returned error should have at least one test that triggers it deliberately. 3. State mutation correctness if the function has side effects: assert the state after, not just the return value. 4. Any branch in the code that isn't exercised by the boundary/error tests above, so coverage isn't accidental. 5. Skip tests that would just restate the implementation (e.g. mocking every internal call so the test can't fail even if logic changes) - flag anywhere the code's structure makes it hard to test meaningfully without a refactor, instead of writing a fake test. Code: code Existing test file (if any, so I don't get duplicates): existing_tests
ClaudeGPT#testing#unit-tests#coverage
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Write a production-ready Dockerfile and CI pipeline with reasoning for each choice

Write a Dockerfile and a CI pipeline config ({{ci_system, e.g. GitHub Actions}}) for {{project_type, e.g. a Node/TypeScript API}}. For every non-obvious choice, add a comment explaining why, not just what. Requirements: 1. Multi-stage build: separate build and runtime stages, runtime image should not contain build tools or dev dependencies. 2. Layer caching: order instructions so dependency installation is cached separately from source code copies. 3. Run as a non-root user in the final image. 4. Pin base image versions (no `latest`), and explain the tradeoff if I should consider a distroless or alpine variant given this project's dependencies. 5. CI pipeline: lint, type-check, test, build image, in that order with fail-fast, and cache dependencies between runs. 6. Include a health check appropriate to the project type. 7. Flag anything project-specific I need to fill in (native dependencies that need extra system packages, etc.) rather than silently guessing. Project details: project_details
ClaudeGPT#devops#docker#ci-cd
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Dependency upgrade risk assessment before a major version bump

I'm considering upgrading package_name from current_version to target_version in project_context. Before I do it, help me assess the risk: 1. Based on the changelog/release notes I paste, categorize changes into: breaking (will require code changes), behavioral (same API, different runtime behavior, could cause silent bugs), and safe (additive, no action needed). 2. For each breaking or behavioral change, scan the usage patterns I describe and tell me concretely whether my codebase is likely affected, not just 'check if you use this feature'. 3. Estimate blast radius: how many places in a typical codebase this size would need changes, based on how core this package is to what I describe. 4. Recommend an upgrade strategy: direct jump, or step through intermediate major versions, based on how many breaking changes are involved. 5. Give me a smoke-test checklist specific to what changed, not a generic 'run your test suite' answer. Changelog/release notes: changelog How we use this package: usage_description Current test coverage of affected areas: coverage_notes
ClaudeGPT#dependencies#upgrade#risk-assessment
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Convert imperative loop-heavy code to functional style without losing clarity

Rewrite this code from an imperative, loop-and-mutation style into a functional style using language's idiomatic map/filter/reduce (or equivalent) constructs. Constraints: 1. Only do this where it genuinely improves readability; if a loop is already the clearest way to express the logic (e.g. it has early exits, multiple accumulators, or complex control flow), say so and leave it as a loop rather than forcing a functional rewrite that would be harder to read. 2. Preserve exact behavior including edge cases (empty input, short-circuit behavior). 3. Avoid deeply chained one-liners that sacrifice readability for cleverness; prefer named intermediate variables over a 5-deep chain. 4. Note any performance implications (e.g. multiple passes over the array instead of one) and whether that matters given the expected data size. 5. Show before and after, and a one-line justification for each change. Code: code Expected data size / performance sensitivity: data_size_context
ClaudeGPT#refactoring#functional-programming#clean-code
0
0
p/codingAauraNovice4 days agohas example⁂auto-checked

Simplify deeply nested conditionals without changing behavior

Simplify the deeply nested if/else or switch logic below. Rules: 1. Preserve behavior exactly, including any subtle order-dependent checks (list any you find, so I can confirm you preserved them correctly). 2. Prefer guard clauses / early returns over nested if-else pyramids. 3. Where multiple conditions test the same variable, consider whether a lookup table, strategy map, or polymorphism would be clearer than a long conditional chain, but only propose it if it's genuinely simpler here, not as a default pattern. 4. Compute cyclomatic complexity (rough count of independent paths) before and after, so I can see the actual improvement. 5. If any branch is unreachable or looks like dead code given the earlier conditions, flag it separately, don't silently delete it, since dead-looking code is sometimes defending against a case I haven't told you about. Code: code Language: language
ClaudeGPT#refactoring#clean-code#complexity
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

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
Best writing promptsBest imagegen promptsBest agents promptsBest productivity promptsBest education promptsBest business promptsBest fun prompts