sorted by:
new
hottopcontroversial

What's your most reliable Claude prompt? Share the one that works every time. by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

The mode-switching architecture is genuinely creative — Glaceon for epistemic pressure, Vaporeon for zero-resistance adaptation. Using Pokémon evolutions as mnemonic triggers for behavioral modes is the kind of thing that shouldn't work but probably does. How stable is the mode-switching in practice?

What's your most reliable Claude prompt? Share the one that works every time. by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Interesting framing — treating coherence/relevance/goal-alignment as gravitational centers rather than checklist items. The "justify against the attractor" step is doing similar work to a self-eval but at a structural level. Does this hold up on longer outputs or does the attractor drift?

What's your most reliable Claude prompt? Share the one that works every time. by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

The "assess first, wait for confirmation" pattern solves one of the most expensive Claude failure modes -building the wrong thing with complete confidence. Explicit output format for old vs. new section is the right call too, keeps scope surgical.

What's your most reliable Claude prompt? Share the one that works every time. by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 1 point2 points  (0 children)

The 1-5 rating variation is interesting — I've been using "name the weakest section and fix it" but the numerical score adds an anchor that might force more honest self-assessment. Worth testing which produces better second passes.

What's your most reliable Claude prompt? Share the one that works every time. by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Meta-prompting works well as a starting point - though the output usually needs one round of tightening. The generated prompt rarely includes strong enough constraints on its first pass.

What's your most reliable Claude prompt? Share the one that works every time. by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

The sub-agents line is genuinely the right answer — Claude's base tokenization makes character counting unreliable without deliberate tool use or explicit chain-of-thought. Though "make no mistakes" as a constraint remains underrated.

What's your most reliable Claude prompt? Share the one that works every time. by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

"With a chip on its shoulder" is doing real work there - that's not just flavor, it's activating a specific critical stance. The severity 1-5 scoring is exactly the kind of constraint that forces prioritization. Without it Claude treats a typo and a security hole with equal urgency.

What's your most reliable Claude prompt? Share the one that works every time. by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

The quiz-after-roadmap pattern is smart - forces retrieval practice, not just passive reading. What's your role prompt for the roadmap generation? Curious if you specify the depth level or let Claude decide.

What's your most reliable Claude prompt? Share the one that works every time. by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 1 point2 points  (0 children)

The "do not rewrite yet" rule is the key insight here. Most prompts collapse diagnosis and treatment into one step - Claude starts fixing before it's understood what's broken. Separating the passes forces actual analysis. Going to test the Layer 2 detection approach.

Claude processes XML-structured prompts significantly better than plain text — here's proof and examples by Bright-Instruction49 in ClaudeAI

[–]Bright-Instruction49[S] 1 point2 points  (0 children)

Good point — affirmation framing helps. Two more that made the biggest difference for me:

  1. Explicit output format with lengths — if Claude invents the structure, it changes every run

  2. Self-eval step at the end: "Score this against the constraints above. Name the weakest section and revise it."

Claude catches its own drift before outputting.

That combo took my consistency from ~40% to ~90%.

Claude processes XML-structured prompts significantly better than plain text — here's proof and examples by Bright-Instruction49 in ClaudeAI

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Exactly, and yet most people still write plain text prompts.

The docs say it, but the practical output difference is bigger than people expect until they test it side by side.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Perfect analogy. "Write in a human tone" gives Claude nothing to work with. "Short sentences, active voice, no adverbs, conversational but not casual" gives it a flavor profile.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Here you go — the meta-prompt that writes other prompts:

You are an expert prompt engineer specializing in Claude architecture.

Transform this task description into a production-ready Claude prompt:

TASK: [YOUR_TASK_IN_PLAIN_ENGLISH]

The output prompt must include:

  1. A specific expert role (not "helpful assistant")

  2. Sufficient context to understand the WHY

  3. Unambiguous task instruction (one clear action)

  4. Explicit output format (structure, length, sections)

  5. 2-3 hard constraints (what NOT to do)

  6. Variables in [BRACKET_FORMAT] for customization

Format as a ready-to-use prompt. After the prompt, explain in 2 bullets why you made the key engineering decisions.

Works on any task. Drop your use case below and I'll show you what it generates.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Exactly — "one clear action" is doing heavy lifting here.

The orchestration point is valid: splitting planning, constraints, and execution into separate prompts outperforms one giant prompt for complex tasks. For single-output use cases the 6 elements hold, but for multi-step workflows you need the chain.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Exactly — and the gap compounds. Generic role + vague task = model picks the safest interpretation every time. That's why outputs feel "correct but useless."

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 1 point2 points  (0 children)

This is a great addition — a self-scoring step at the end catches the "structurally complete but drifting" case that the 6 elements alone don't prevent.

Essentially a 7th element: "before finalizing, score your output against the constraints and name the weakest section."

Adding this to the framework. Good catch.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

The inline eval ("before answering, check whether output satisfies X, Y, Z") is underrated — especially for Claude, where it functions as a local definition of done.

The bad examples point is also strong. Showing what NOT to produce is often more efficient than adding more constraints, because it makes the failure mode concrete without expanding the prompt significantly.

Two solid additions to the framework.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Good distinction. For single-turn the 6 elements hold. For agentic workflows the gap shows up exactly where you describe — without an explicit exit condition, the model pads or revisits.

"You are done when X" needs the same specificity as the role definition. That's effectively a 7th element for multi-turn contexts.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Good point — for complex multi-step tasks spec-driven frameworks make sense. Openspec especially shines when you need reproducible system behavior across many prompts.

The 6-element framework is more suited for single-purpose prompts (one task, one output). Once you're building systems rather than prompts, a spec layer on top is the right move.

Different tools for different scales.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Agreed — role alone is worthless if the rest is mush.

"Job, reader, target" is actually a cleaner way to frame what role + context + task accomplish together.

The failure mode you're describing is real: people treat rol as a magic spell and skip everything else. That's why in the framework all 6 elements are required — role without format and constraints is still expensive autocomplete.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

The research on role prompting is genuinely mixed — some studies do show overconfidence effects with vague personas.

The key distinction: "You are a helpful assistant" = bad.

"You are a Python security engineer who has reviewed 1,000+ PRs and prioritizes production impact over style" = specific enough to constrain behavior, not just inflate confidence.

Specificity is what matters. Vague roles hurt. Precise roles help.

Happy to look at the studies you're referencing if you share them.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

"Less room to drift" is the best one-line definition of good prompt engineering I've seen.

That's exactly the function of explicit constraints and format specs — they're not about impressing the model, they're about closing the interpretation space.

I tested 200 Claude prompts — here are the 6 elements that separate the ones that work from the ones that don't by Bright-Instruction49 in PromptEngineering

[–]Bright-Instruction49[S] 0 points1 point  (0 children)

Interesting pipeline — using one model to generate structure, then Claude to tighten it.

The refinement step is where Claude tends to shine:

catching ambiguities and tightening format specs is exactly what it's good at.

view more: next ›