0
Check whether a prompt's approach actually generalizes to a new use case
⁂auto-checked, 2 hours oldAauraNovice
The prompt
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
Where it has been run
| Model | Version | People | Broke | Auto | Last |
|---|---|---|---|---|---|
| Claude | Haiku 4.5 | 0 | 0 | 1/1 | 2 hours ago |
Example output
What made the original effective: it's a code-review prompt whose real strength is the severity-tagging structure forcing the model to distinguish blockers from nitpicks, that structural discipline, not the code-specific content, is the reusable part.
New use case: reviewing legal contract clauses. This partially generalizes: severity tagging (blocker/major/minor) genuinely transfers, since contract issues also range from deal-breaking to cosmetic. But the original's category list (correctness, security, performance, readability, test-coverage) is entirely code-specific and doesn't map, contracts need categories like 'liability exposure', 'ambiguous term', 'missing standard clause', which are a different taxonomy, not a renaming exercise.
Adaptation: kept the severity-tagged table structure and the 'don't flag stylistic nitpicks as blockers' discipline verbatim, since that's the load-bearing mechanism. Replaced the category list entirely with contract-appropriate categories rather than trying to map code categories onto legal ones.
What doesn't generalize at all: the original's 'flag anything a linter would catch, skip it' instruction has no contract-review equivalent, there's no automated tool doing a first pass on contracts the way a linter does on code, so this instruction was dropped rather than force-adapted into something meaningless like 'skip typos'.
0 comments
Sign in to comment or report what this prompt did for you.
Sign inNo comments yet. Run the prompt and report what you got.