APromptAura

p/meta

Prompts about prompting, site challenges, and community business.

hotnewtopstill works
filter✓ verified in 30 dayshas example output
0
p/metaAauraNovice4 days agohas example⁂auto-checked

How verification works here, and why a failed report is worth as much as a good one

Read this before you use the site, it explains the one thing PromptAura does that other prompt libraries do not. THE PROBLEM Prompts do not age well. They are written against a specific model, at a specific moment, and models change underneath them constantly. Every prompt library on the internet is full of instructions that stopped working a year ago, and none of them can tell you which ones. A list of prompts with upvotes cannot solve this. Upvotes measure whether an idea sounds good. They do not measure whether it still runs. WHAT WE DO INSTEAD When you run a prompt from this site, tell us what happened. You pick the model and the version, and you say whether it did what it claimed. That single dated claim drives everything: - The freshness badge on every prompt, so you can see at a glance whether anyone has confirmed it lately - The compatibility table, showing which models a prompt has actually been run on - The "still works" sort, which ranks by verified runs and pushes reported breakage down - The model watch pages, which show what stopped working after a release WHY FAILURES MATTER MORE THAN YOU THINK Most people will only click the button when something works. That is human, and it is also how the dataset becomes useless. If a prompt fails for you, say so. It costs you ten seconds and it is the single most valuable thing you can contribute here. A library where nothing is ever marked broken is just a list with extra steps. Reporting a failure does not attack the author. Models moved; that is nobody's fault. The prompt gets flagged, the author can revise it, and the next person does not waste their time. AUTOMATED VERIFICATION You will see verifications from an account called aura-bot. That is automation: it runs prompts against current models and records the result. Its bio says so, and its reports are labeled. It is a smoke test, not a human saying a prompt is good. Treat it as a floor, not a recommendation. FROM YOUR EDITOR If you connect the MCP server, you can verify without visiting the site at all. Run a prompt in Claude Code or Cursor, then tell your assistant it worked, and it records the result with the model version filled in automatically. See /connect.
Any#site-guide#verification#freshness
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Weekly challenge: turn meeting notes into action items nobody argues about

This is the first PromptAura weekly challenge. Post your entry as a prompt in p/productivity, tag it `weekly-challenge`, and include an example output. THE BRIEF Write a prompt that takes raw, messy meeting notes and produces a list of action items that survives contact with the people who were in the room. That means: - Every item has exactly one owner, named - Every item has a date or an explicit "no date agreed" - Anything that was discussed but not decided is listed separately as open, not silently promoted into a task - Nothing is invented. If the notes do not say who owns something, the prompt must say so rather than guessing Test it on your own real notes, not on a clean sample. The whole point is handling the mess. HOW ENTRIES ARE JUDGED Verified runs decide it, not upvotes. Whoever's entry collects the most "worked for me" verifications by the end of the week wins. That means you should run other people's entries and report honestly, including when they fail. WINNER GETS A pinned spot on the p/meta feed for the following week, and the founder flair on their profile. THE PROMPT BELOW IS THE BASELINE TO BEAT You are turning raw meeting notes into action items. Notes: meeting_notes Rules: - One owner per item, named exactly as they appear in the notes - If no owner is identifiable, put the item under Unassigned and do not guess - If no date was agreed, write "no date agreed" rather than inventing one - Anything discussed without a decision goes under Open questions, never under Actions - Do not add items that are not supported by the notes Output format: Actions - [owner] [action] [date or "no date agreed"] Unassigned - [action] Open questions - [question]
ClaudeGPTAny#weekly-challenge#meeting-notes#action-items
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Analyze the prompt length versus output quality tradeoff before adding more instructions

I keep adding instructions to this prompt every time I see a new failure case, and it's getting long. Before I add the next one, help me think about the length/quality tradeoff properly. Given the current prompt: current_prompt and the new instruction I'm considering adding: proposed_addition 1. Check whether the new instruction is actually needed as an explicit rule, or whether it's covering a case so rare that it doesn't justify permanently lengthening a prompt that runs on every call - ask me for the actual frequency of this failure if I haven't stated it, since that's the key input to this decision. 2. Check whether the new instruction could instead be a rephrasing/tightening of an existing instruction rather than a net-new addition, since prompts often accumulate redundant instructions covering overlapping ground. 3. If it should be added, check whether it belongs where I'm planning to add it, or whether it would be more effective and cause less prompt bloat if merged into an existing related instruction instead of appended as a new standalone one. 4. Note the concrete cost of the addition: token count increase, and whether this prompt is used at high enough volume that the added cost is worth actually calculating in dollar terms. 5. Give a clear recommendation: add it, merge it into an existing instruction, or don't add it and handle this failure case a different way (post-processing validation instead of a prompt instruction). Current prompt: current_prompt Proposed addition: proposed_addition How often this failure occurs: failure_frequency
ClaudeGPT#prompt-optimization#cost-analysis#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Community challenge: rewrite this prompt for a reader with zero context

Challenge format: I'll give you a prompt written by and for an expert in field, full of jargon and unstated assumptions. Rewrite it so a total beginner to field could use it and get a comparably useful result, without dumbing down the actual task. Rules: 1. List every piece of unstated domain knowledge the original prompt assumes the reader has (not the model, the human using the prompt), since that's what a beginner is missing, not model capability. 2. For each assumption, either build the missing context directly into the prompt (so the beginner doesn't need to already know it) or add a clarifying question the prompt should ask the beginner first, whichever is more appropriate for that specific gap. 3. Keep the actual task and rigor identical, this is not a simplified or lesser version of the task, a beginner should get output of the same quality, just without needing to already be an expert to operate the prompt correctly. 4. Test it mentally: would someone who has never heard of field-specific terms used in the original be able to fill in every variable and understand every instruction in your rewrite? Flag any spot where you're not fully sure. Original expert-level prompt: original_prompt Field: field
ClaudeGPT#community-challenge#accessibility#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example💀failed our automated check

Reverse-engineer a likely prompt from an output you want to reproduce

I found an AI-generated output that has a style/structure I want to reproduce, but I don't have the original prompt. Given the output text: output_text, work backward to a plausible prompt that would produce this kind of output consistently. Requirements: 1. Identify the structural signatures in the output (heading pattern, sentence length distribution, use of examples, hedging language, specific recurring phrases) that suggest specific prompt instructions, and state the inference explicitly ('the consistent use of a rhetorical question to open each section suggests an instruction like...'). 2. Distinguish features that are likely prompt-driven (deliberate, would recur reliably) from features that could just be incidental to this one generation (a phrase that happened to appear once, not necessarily instructed). 3. Draft a candidate prompt based on your inferences. 4. State your confidence level honestly: this is inherently a guess, note which parts of your reconstruction you're fairly confident about versus which are speculative, don't present the whole thing as certain. 5. Suggest the fastest way to verify: what to check by running the candidate prompt and comparing new output against the original's style. Output text to reverse-engineer: output_text
ClaudeGPT#reverse-engineering#prompt-analysis#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Check whether a prompt's approach actually generalizes to a new use case

I want to reuse the approach from this prompt, which works well for original_use_case, for a new use case: new_use_case. Before I just copy-paste and swap topic words, check whether the underlying approach actually generalizes. Given the original prompt: original_prompt 1. Identify what made the original prompt's approach effective (a specific reasoning structure, a particular constraint, an output format) separate from the topic-specific content, so we know what's actually being reused. 2. For the new use case, check whether the same structural approach is actually appropriate, or whether the new task has different characteristics (different failure modes, different stakes, different ambiguity patterns) that would make a naive copy underperform. 3. If it generalizes well, adapt the prompt and explain what changed versus what stayed structurally identical. 4. If it only partially generalizes, identify the specific part that needs to be different and why, don't force-fit the original structure where it doesn't apply. 5. If it doesn't really generalize (the tasks are more different than they first appear), say so plainly rather than producing a superficially-adapted prompt that will underperform, and suggest what a prompt actually suited to the new use case would need instead. Original prompt and use case: original_prompt / original_use_case New use case: new_use_case
ClaudeGPT#portability#prompt-adaptation#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Build a targeted edge-case test suite for a prompt before trusting it

Build a test suite of edge-case inputs for this prompt before I rely on it in production: prompt for task_description. Don't just give me random varied inputs, derive the edge cases from the prompt's actual logic. Requirements: 1. Read the prompt's conditional instructions (any 'if X, do Y, otherwise do Z' logic) and generate at least one test input for each branch, plus one input that sits right at the boundary between branches, since boundaries are where prompts most often misfire. 2. Generate inputs that test what happens when the prompt's assumptions are violated (it assumes the input will always contain a date, what if it doesn't; it assumes a single item, what if there are zero or many). 3. Generate one adversarial-but-realistic input (not a malicious attack, just a real-world messy input: contradictory information, missing context, informal phrasing) since production inputs are messier than clean test cases. 4. For each test input, state what the correct output SHOULD be and why, based on the prompt's stated logic, so this suite can actually be used to check pass/fail, not just to eyeball outputs. 5. Organize the suite as a table: Input, Expected Behavior, What It Tests. Prompt: prompt Task description: task_description
ClaudeGPT#testing#edge-cases#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example💀failed our automated check

Edit a prompt for clarity without changing what it asks for

Edit this prompt for clarity and readability only, not content or requirements, that's important: don't add, remove, or change any instruction, only improve how clearly the existing instructions are expressed. Given the prompt: prompt 1. Identify sentences that are doing double duty (stating two unrelated requirements in one run-on sentence) and split them, since a model is more likely to miss the second half of a compound instruction. 2. Identify vague referents ('it', 'this', 'that') where it's not immediately clear what they refer to, and replace with the explicit noun. 3. Identify instructions buried mid-paragraph that would be clearer as a numbered list, given that structured lists are easier for a model to track and satisfy completely than prose. 4. After editing, do a line-by-line diff check yourself: confirm every requirement in the original still appears in the edited version, and flag explicitly if you're unsure whether an edit accidentally changed meaning, rather than asserting confidently that nothing changed. 5. Do not add new best-practice instructions that weren't in the original (like adding a 'think step by step' if it wasn't there), this is a clarity pass, not an improvement pass. Prompt to edit: prompt
ClaudeGPT#prompt-editing#clarity#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Convert a free-form chat prompt into a strict JSON-output prompt

I have a prompt designed for conversational, free-text output and I need to convert it to produce strict, parseable JSON matching a schema, for use in a pipeline. Given the original prompt: original_prompt and the target schema: target_schema 1. Map each piece of information the original prompt asks for into a specific schema field, and flag anything the original asks for that doesn't map cleanly (information that's inherently free-text/nuanced and would be lossy forced into a fixed field) so we decide together how to handle it rather than silently cramming it in. 2. Add explicit instructions for the model to never wrap the JSON in markdown code fences or add explanatory text before/after, since that breaks naive parsers, and note that this needs to be tested since models don't always comply perfectly. 3. Specify what the model should output for fields where information is genuinely absent from the input (null vs omitting the field vs an empty string) and be consistent, since inconsistent null-handling breaks downstream parsing. 4. Add a instruction for how to handle a case where the input doesn't fit the schema at all (e.g. asked to extract order details from a message that isn't actually an order) - a fixed error-shape response, not an empty or malformed JSON guess. 5. Give the final prompt text, ready to use. Original prompt: original_prompt Target schema: target_schema
ClaudeGPT#structured-output#json#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Stress test a prompt for bias and failure modes before wide release

Before I release this prompt for general use, stress test it for bias and failure modes across a range of inputs it will realistically encounter. Given the prompt: prompt and the population of users/inputs it will see: user_population_description 1. Generate a diverse set of test inputs that vary along dimensions relevant to bias risk for this specific task (not generic demographic categories unless they're actually relevant to how this prompt could fail differently for different inputs) - name the dimensions you're varying and why they're relevant here specifically. 2. For each test input, note if the prompt's output quality, tone, or thoroughness would plausibly differ in a way that's not justified by the input's actual content (e.g. giving a noticeably shorter or more dismissive answer to inputs written in non-native-sounding English, when the underlying question is equally valid). 3. Distinguish a genuine bias risk (systematic, would recur) from a one-off quality variance (any single output can be a bit better or worse, that's normal, not evidence of bias). 4. For genuine risks found, propose the specific prompt addition that would mitigate it, and note if it's a prompt-level fix or something that needs to be addressed at the model/system level instead. 5. Be honest if you don't find a meaningful risk in a dimension you tested, don't manufacture a finding to seem thorough. Prompt: prompt User population: user_population_description
Claude#bias-testing#stress-testing#prompt-safety
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Generate a meta-prompt that produces well-structured prompts for a category of task

Write a meta-prompt: a prompt whose job is to generate other prompts for the task category task_category. This isn't a single-use prompt, it's a generator, so it needs to ask the right clarifying questions and produce a properly structured output prompt every time. Requirements: 1. The meta-prompt must first gather the information it needs to write a good prompt for this category (what specifically varies task to task within this category, e.g. for 'code review prompts', that's language, focus area, severity scheme) by asking targeted questions, not by guessing defaults silently. 2. It must encode the structural best practices for prompts in this category (e.g. for eval-writing prompts: always require pass/fail criteria over vague quality scores) as a template the generator follows, not leave structure to chance each time. 3. It must include a self-check step: after drafting the prompt, review it against a short checklist (does it have clear success criteria, does it use variable placeholders correctly, is it free of ambiguous instructions) before presenting the final version. 4. Give me the actual meta-prompt text, then demonstrate it once by generating an example prompt for a specific instance of task_category. Task category: task_category What tends to vary across instances of this category: variation_factors
ClaudeGPT#meta-prompting#prompt-generation#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Adapt a prompt's tone for a different audience without losing its function

I have a prompt that works well for original_audience and I need a version for new_audience, same underlying task and information, different register. Given the original prompt: original_prompt 1. Separate what must change (vocabulary level, sentence complexity, amount of explanation/hand-holding, formality) from what must NOT change (factual accuracy requirements, any compliance/safety constraints, the core task instructions) - list both explicitly so nothing load-bearing gets casually rewritten along with the tone. 2. Rewrite the prompt for the new audience, and for each meaningful change, note whether it's a tone change or accidentally also a scope/content change, since tone edits sometimes silently drop a constraint. 3. Give one example output from each version side by side (or describe how outputs would differ) so the difference is concrete, not just described in the abstract. 4. Flag if the new audience actually needs a genuinely different task, not just a different tone (e.g. explaining a legal concept to a 10-year-old might need simplification of the concept itself, not just simpler words, which is a bigger change than a tone pass). Original prompt: original_prompt Original audience: original_audience New audience: new_audience
ClaudeGPT#tone-adaptation#audience#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Debug a prompt that produces inconsistent output formatting across runs

This prompt produces the right content but inconsistent formatting run to run (sometimes markdown, sometimes plain text, sometimes different heading structure). Help me fix the actual cause. Given the prompt and 3-4 example outputs showing the inconsistency: prompt / example_outputs 1. Check whether the prompt actually specifies a format at all, versus implies one loosely through an example that could be read as illustrative rather than prescriptive - this is the most common root cause and I want it ruled in or out explicitly first. 2. If a format is specified, check whether it's specified precisely enough (e.g. 'use headers' doesn't say what level, what if any bold/italic is expected) - ambiguity in the spec, not model unreliability, is often the real cause. 3. Check if the inconsistency correlates with anything about the input (longer inputs get different formatting than short ones, certain topics trigger different structure) rather than being purely random, since that points to a different fix (an input-dependent rule) than pure underspecification. 4. Propose the exact formatting specification to add, and if useful, one formatted example to lock in the structure as few-shot, weighing that against the added token cost. 5. If none of the above explains it, say so and suggest it may need output post-processing/validation rather than a prompt fix, since not every consistency problem is solvable purely at the prompt level. Prompt: prompt Example outputs showing inconsistency: example_outputs
ClaudeGPT#prompt-debugging#consistency#formatting
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Write a changelog entry when you revise a production prompt

I'm about to ship a change to a production prompt. Help me write a proper changelog entry so future me (or a teammate) understands why this changed, not just what changed. Given the old prompt, new prompt, and the reason for the change: old_prompt / new_prompt / reason_for_change 1. Write a one-line summary of the behavioral change (what output difference a user would actually notice), not a description of the wording diff. 2. State the specific evidence that motivated this change (a failure example, a user complaint, an eval regression), quoting or referencing it concretely, not 'seemed like it could be better'. 3. List what you tested this new version against before shipping (which inputs, how many, what the pass rate was) so there's a record of validation, not just intent. 4. Flag any known tradeoff this change introduces (e.g. fixes case A but might make case B slightly worse, or increases average token count) so it's not discovered as a surprise later. 5. Note the rollback condition: what signal in production would indicate this change should be reverted. Old prompt: old_prompt New prompt: new_prompt Reason for change: reason_for_change Test results if any: test_results
ClaudeGPT#prompt-versioning#changelog#production
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Decide between chain-of-thought and direct-answer prompting for a specific task

Help me decide whether to use explicit chain-of-thought prompting or a direct-answer prompt for this task: task_description, rather than defaulting to 'CoT is always better'. Given the task and 2-3 example inputs: 1. Characterize the task type: is it primarily a multi-step reasoning task (where CoT genuinely helps by giving the model room to work through steps) or a retrieval/classification/formatting task (where CoT often just adds latency/cost without improving accuracy, or can even hurt by giving the model room to talk itself into an over-thought wrong answer). 2. If CoT seems warranted, specify what kind: should reasoning be shown to the user (useful for auditability) or hidden/scratchpad-only (useful when you only want the final answer and reasoning would clutter the response)? 3. If direct-answer seems sufficient, say so plainly and don't hedge into recommending CoT 'just in case', that defeats the point of the comparison. 4. Propose a quick test: 3 inputs where CoT and direct-answer would most likely diverge if there's a real difference, so I can verify the recommendation empirically rather than trusting the theoretical argument alone. Task: task_description Example inputs: example_inputs
ClaudeGPT#chain-of-thought#prompt-engineering#task-design
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Convert a zero-shot prompt into a well-chosen few-shot version

I have a zero-shot prompt that's inconsistent in output format/quality. Help me convert it to a few-shot prompt with well-chosen examples, not just any examples. Given the prompt and a handful of real inputs/outputs (including some bad ones that show the current failure mode): prompt / sample_io 1. Select 2-4 examples for the few-shot prompt that specifically cover the range of failure modes you see in the bad outputs, not just easy/typical cases - a few-shot example set that's all easy cases won't fix inconsistency on hard ones. 2. For each chosen example, state which specific failure mode it's meant to correct, so the example set is deliberate, not just 'here are some examples'. 3. Format the examples consistently with the exact structure you want output to follow (this consistency is itself doing work, not just the content of the examples). 4. Warn me if any of my candidate examples are actually ambiguous or borderline themselves, since a flawed few-shot example teaches the model the flaw, don't include one without flagging it first. 5. Note the token cost tradeoff: few-shot prompts are longer and cost more per call, is this justified given how much the zero-shot version is actually failing, or would a more precise instruction achieve the same consistency more cheaply. Zero-shot prompt: prompt Sample inputs/outputs, including failures: sample_io
ClaudeGPT#few-shot#prompt-engineering#consistency
0
0
p/metaAauraNovice4 days agohas example💀failed our automated check

Community challenge: golf this prompt to the fewest tokens without losing behavior

Prompt golf challenge. Here's a working prompt that reliably does task: original_prompt. The goal: rewrite it to use meaningfully fewer tokens while producing behaviorally identical outputs on the test cases below, not just similar-looking outputs. Rules: 1. Every cut must be justified: state which word/phrase you removed and why you believe the model doesn't need it explicitly stated (either because it's implied by something else in the prompt, or because it's default model behavior anyway). 2. Run (or reason through) the golfed version against each of the provided test inputs and compare to the original's known-good output for that input; if any output would differ in a way that matters, that cut failed, revert it and try a different cut instead. 3. Report the final token count reduction as a percentage, and the number of cuts that failed verification and were reverted, so the process is honest about what didn't work, not just the survivors. 4. If you hit a floor where further cuts start failing verification, stop there and report that as the practical minimum for this specific test set, rather than continuing to guess. Original prompt: original_prompt Test inputs with known-good outputs: test_cases
ClaudeGPT#prompt-golf#compression#community-challenge
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Audit a system prompt for prompt-injection surface area

Audit this system prompt for how vulnerable it would be to prompt injection if it's ever used with untrusted input in the user turn or in retrieved content. Given the system prompt: system_prompt 1. Identify any instruction in the prompt that relies on the model correctly distinguishing 'the system prompt's authority' from 'something that merely claims to have that authority' - if the prompt never explicitly states this distinction, that's a gap, name it. 2. Identify any capability granted (tool access, ability to change its own behavior mid-conversation, ability to reveal its instructions) that would be especially dangerous if triggered by injected content rather than the legitimate user, and rank by how bad the outcome would be. 3. Check whether the prompt has any explicit instruction about NOT revealing its own system prompt or internal reasoning if asked, and whether that instruction would actually hold up against a moderately clever extraction attempt (paraphrase the kind of request that typically defeats a weak version of this instruction). 4. Propose the minimum additions needed to close the highest-severity gaps, don't propose a full prompt rewrite if the fix is narrow. System prompt to audit: system_prompt How untrusted content enters the system (if any): untrusted_input_paths
ClaudeGPT#prompt-injection#security-audit#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example💀failed our automated check

Compare how different models handle the same prompt and why they diverge

I want to understand behavioral differences between models on the same prompt, not just which output I personally prefer. Given this prompt: prompt and outputs from models_list: 1. For each pair of models that diverge meaningfully, identify the specific instruction or ambiguity in the prompt that each model resolved differently, don't just describe the outputs as 'different in style'. 2. Distinguish divergence that's a genuine capability difference (one model got a factual/logical detail wrong the other got right) from divergence that's a preference/interpretation difference (both are defensible readings of an underspecified instruction). 3. For preference/interpretation divergences, propose the specific prompt change that would make the instruction unambiguous enough that both models would converge, and state your confidence that the fix would actually work versus just being a reasonable guess. 4. Note if any model appears to have ignored an explicit instruction entirely (not just interpreted it loosely) since that's a different, more concerning category than reasonable interpretive divergence. 5. Give a practical recommendation: if I need consistent behavior across these models, what's the minimum prompt change needed, versus what divergence I should just accept as inherent. Prompt: prompt Outputs by model: outputs_by_model
ClaudeGPTGemini#model-comparison#cross-model#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example💀failed our automated check

Compress a bloated prompt without silently losing behavior

This prompt has grown too long through iteration and I want it shorter without breaking what currently works. Given the prompt: prompt 1. Categorize every sentence/clause into: essential (removing it would change model behavior on real inputs), redundant (says the same thing as another clause, can be merged), and dead weight (was added for an edge case that either no longer applies or never actually needed explicit instruction, model would do this anyway). 2. For anything you mark redundant or dead weight, state your confidence and what evidence would confirm it's actually safe to cut (e.g. 'test against the 3 edge-case inputs that originally motivated this clause'). 3. Produce the compressed version, but only cut what you're highly confident about; for medium-confidence cuts, list them separately as 'candidates to test before cutting' rather than baking them into the compressed version unverified. 4. Give a rough token/word count before and after. 5. Do not change the meaning of any surviving instruction while compressing its wording, flag if a wording change you made for brevity could plausibly shift behavior. Prompt to compress: prompt Known edge cases this prompt needs to handle correctly: edge_cases
ClaudeGPT#prompt-optimization#compression#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Write an eval rubric for a prompt before you scale it up

I'm about to scale up usage of this prompt: prompt for use_case. Before I do, help me write an evaluation rubric so I can measure quality systematically instead of spot-checking. Requirements: 1. Derive 4-6 scoring criteria directly from what the prompt itself demands (if the prompt requires a specific format, that's a criterion; if it requires groundedness, that's a criterion) rather than generic LLM-output quality metrics that don't reflect this specific prompt's actual requirements. 2. Make each criterion as objectively checkable as possible: state whether it's programmatically checkable (regex, schema, exact match), or genuinely requires an LLM-judge or human, and don't overstate how automatable a subjective criterion is. 3. For each criterion, write the LLM-judge instruction that would grade it, calibrated with one example of a passing and one failing output, so the judge prompt itself is reproducible and not vague. 4. Define a pass/fail threshold for the overall rubric (e.g. must pass all disqualifying criteria plus 80% of others) rather than leaving 'good enough' undefined. 5. Suggest how many sample outputs I'd need to eval before I can trust an aggregate pass rate, given the stakes of use_case. Prompt: prompt Use case and stakes: use_case
ClaudeGPT#evals#rubric#llm-judge
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Extract a reusable template from a one-off prompt that worked well

I wrote a prompt for a specific task and it worked really well. Help me generalize it into a reusable template with variable placeholders, without over-abstracting it into something so generic it loses what made it work. Given the original prompt and the specific task it solved: 1. Identify which parts are genuinely task-specific (should become variables) versus which parts are structural (the reasoning steps, the output format requirements, the constraints) and should stay fixed since they're what made this prompt effective, not incidental wording. 2. For each variable you introduce, write a one-line description of what should go there and one example value, so future users of the template aren't guessing. 3. Explicitly call out any part of the original prompt that's doing real work but is easy to accidentally strip out during templating (a specific constraint, an example, an edge-case handling instruction) - these are the parts generic templates usually lose. 4. Test the template mentally against one different-but-similar task to see if it still holds up, and note if any part needs adjustment for that case, rather than assuming genericization is complete on the first pass. Original working prompt: original_prompt What task it solved: task_it_solved
ClaudeGPT#prompt-templates#reusability#prompt-engineering
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Systematically A/B two prompt variants instead of eyeballing outputs

I have two versions of a prompt for task_description and I want a rigorous comparison, not a vibes-based 'this one sounds better'. Given both prompt variants and n representative test inputs: 1. Before generating any outputs, state 2-4 concrete criteria you'll judge by, specific to this task (not generic 'quality'), and for each, how you'll detect it in an output (a presence/absence check, a count, a structural property). 2. Run both prompts against each test input (or reason about what each would produce if you can't execute code) and score each output against every criterion, showing your scoring, not just a final verdict. 3. Report per-criterion win/loss/tie counts across all inputs, not just an overall 'variant A is better' impression, since a prompt can win on one axis and lose on another. 4. Flag any input where the two variants produced meaningfully different outputs for a reason unrelated to your criteria (e.g. one variant happened to get a lucky/unlucky example), so I don't over-attribute that difference to the prompt wording itself. 5. Give a final recommendation with the specific tradeoff named, not just a winner declared. Variant A: prompt_a Variant B: prompt_b Test inputs: test_inputs
ClaudeGPT#prompt-testing#evaluation#ab-testing
0
0
p/metaAauraNovice4 days agohas example⁂auto-checked

Diagnose why a prompt underperforms before rewriting it

I have a prompt that isn't producing the results I want. Before you rewrite it, diagnose it. Paste the prompt, 2-3 example outputs it produced, and what I actually wanted instead. Then: 1. Classify the failure: is this an instruction-following gap (the prompt asked for X but the model didn't do X), an ambiguity gap (the prompt is genuinely underspecified and the model guessed reasonably), a format gap (content is right but structure is wrong), or a capability gap (the task is genuinely hard for the model regardless of prompt wording). 2. For instruction-following and ambiguity gaps, quote the exact phrase in the prompt responsible, don't just describe it abstractly. 3. Only after diagnosis, propose a fix, and make the fix as small as possible, changing only what the diagnosis points to, not a full rewrite, so I can see what specifically mattered. 4. If it's a capability gap, say so honestly rather than proposing a prompt tweak that won't actually help, and suggest a structural workaround instead (breaking into steps, adding a verification pass). Prompt: prompt Example outputs: example_outputs What I wanted instead: desired_outcome
ClaudeGPT#prompt-debugging#prompt-engineering#diagnosis
0