APromptAura

#prompt-engineering

Top prompts tagged prompt-engineering.

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

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

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⁂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

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

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

Calibrate an agent persona and tone to a specific brand voice, testably

Define a persona and tone for an agent representing brand_context, in a way that's specific enough to be consistently reproducible, not just adjectives. Requirements: 1. Give 3 real example utterances the brand has actually used (in marketing copy, past support replies, etc.) and derive the tone rules from those specific examples, don't start from generic adjectives like 'friendly and professional'. 2. Define the boundaries explicitly: what this persona would never say (a specific phrase pattern or topic stance), not just what it would say, since 'never say' rules are what actually keep an agent consistent across edge cases. 3. Give a calibration test: 3 sample user messages (one routine, one frustrated, one testing the agent's limits/trying to get it to break character) and the correct in-persona response to each, so the persona is testable against real inputs. 4. Address a common failure mode directly: what happens when staying in persona would conflict with giving accurate or safety-relevant information (e.g. a playful brand voice shouldn't stay playful when discussing a safety recall) - persona always yields to accuracy/safety, state that as a hard rule. Brand context and example past copy: brand_context
ClaudeGPT#persona#brand-voice#prompt-engineering
0
0
p/agentsAauraNovice4 days agohas example⁂auto-checked

Write a tool description that stops an LLM from misusing the function

I have a function I want to expose to an LLM agent as a tool. Write the tool description (name, parameter docs, and usage notes) that would actually be passed to the model for function-calling. Given the function signature and behavior below, the description must: 1. State precisely what the function does and does NOT do, especially if its name could be misread (e.g. a function called `search` that only searches titles, not full text, must say so). 2. For each parameter, state its exact expected format/type and what happens on invalid input (error vs silent default), so the model doesn't guess. 3. Include one example call with realistic arguments and the shape of the return value, so the model can parse the result correctly without a separate lookup. 4. Add explicit 'do not call this when...' guidance for the situations this tool is commonly misapplied to, based on how a model might plausibly misread its purpose from the name alone. 5. Keep it concise, this goes into every request's context, don't pad it with obvious statements. Function signature and behavior: function_details Common misuse you've observed or anticipate: misuse_notes
ClaudeGPT#tool-use#function-calling#prompt-engineering
0