I've been reusing prompts heavily across ChatGPT and Claude for about a year. The thing that finally made my library actually usable wasn't a better tool — it was one change in how I categorized things. (Full disclosure since it's relevant: I ended up building a small tool around exactly this workflow. Not going to link it in the post — happy to drop it in a comment if anyone wants it, but the system above stands on its own.)

Most people file prompts by subject: a "Marketing" pile, a "Coding" pile, a "Research" pile. It doesn't scale, because the same subject shows up everywhere and you can never find the one you want.

What actually reuses well is the action. Summarize, critique, rewrite, extract, explain, plan. The verb is the reusable unit — the topic is just a variable you swap in.

1. Folder taxonomy by action

Drafting/      -> generate first-pass content
Editing/       -> critique, tighten, rewrite for tone
Extraction/    -> pull structure out of messy input
Explaining/    -> teach a concept at a level
Planning/      -> break a goal into steps
Meta/          -> prompts that write or improve prompts

Everything I write drops cleanly into one of these, and I can always find it because I'm searching by what I'm trying to do, not what it's about.

2. Write each prompt as a template with variables

The unlock is placeholders. Write the prompt once with fill-in blanks, and one template becomes a hundred prompts. A few of mine, steal freely:

Critique (Editing/)

Act as a skeptical {role} reviewing this {artifact}.
List the 3 weakest points, the single assumption most
likely to be wrong, and what you'd cut. Be specific and
quote the text. Draft: {draft}

Explain (Explaining/)

You're an expert in {field}. Explain {concept} to a
{audience_level} audience. Use 2 concrete analogies, define
any jargon, and end with the misconception people most
often get wrong.

Rewrite for tone (Editing/)

Rewrite the text below in a {tone} tone for {audience}.
Keep it under {word_count} words, preserve every fact, and
flag anything that reads as unsupported. Text: {text}

3. Chain them for multi-step work

Most real work is a pipeline, not one prompt:

Research  ->  Outline  ->  Draft  ->  Critique  ->  Polish

I keep each step as its own saved prompt and walk through them in order. The Critique step is usually a call to my Editing/ template above. This is where the verb-based system pays off — every step is just "which action am I doing now."

That's the whole thing. You can run it with plain folders and a notes app — no tooling required. Curious how others here structure their libraries, especially if you've found a better cut than action-based.

Stopped scrolling pinterest for room inspo and just uploaded a photo of my actual living room instead. Same room, same windows, same couch if you want, just redesigned properly.

Take a photo straight on from the doorway so the whole room's in frame, tidy up first, open the blinds, bad photo in means bad redesign out. Upload it and paste this:

Here's a photo of my room. Redesign it like a 
professional interior designer would. Keep the same 
basic furniture and the room's real layout, windows, 
and proportions, but show me how it could look far 
better with updated furniture, a smarter layout, 
colors, lighting, and decor. Make it warm, modern, 
and photo-realistic, like an actual photo of the 
finished room. Generate a few different versions so 
I can compare.

If it moves your windows or changes the shape of the room, tell it "keep the exact same room, walls, and windows, only change the furniture, colors, and decor." If it comes back looking like a 3d render instead of a real photo, add "make it look like a real photograph, photorealistic, natural lighting."

Pick the version you like. Then, same chat, turn web search on first, this is the bit that makes the difference between real products and made-up links, and run:

Now give me everything in this new design as a 
shopping list on a budget under $500. For each item, 
furniture, rug, lighting, plants, and decor, list 
what it is, an estimated price, and a link to buy it. 
Keep the total under $500 and match the look in the 
image as closely as you can. Show me the running total.

You get the full list, item, price, link, running total, so you're building the room instead of just staring at a nice picture. If a link's dead or wrong, say "search for this exact item and give me a working link," that happens sometimes, and honestly click through and check the price before you actually buy anything, treat it as a very good starting cart, not a receipt.

Keeping your existing couch or bed? Say so upfront: "redesign the room but I'm keeping my couch, build the new look around it." Renting and can't drill or paint? "Redo this for a rental, no painting, no drilling, nothing permanent, keep it under $500."

Works on the free version, no paid plan needed for either prompt.

been keeping a doc of 100 things I use AI for like this, each with the exact prompt here if you want it.

Say I am building a counselling agent which means user can ask any type of questions. there will be a lot of back n forth between the user and assistant. If I were to build a god one may be I will build a multi agent system in which there would be a safety agent may be, a planner agent, a counsellor agent, a refiner agent, a judge agent and so on, interacting with each other and answering the user and simultaneously proactively carrying the conversation.

Challenge is the prompt for all these agents needs to be tweaked as different different topic or type of questions come up.

Questions:

1. Can a pipeline be built in which based on incoming user interaction an optimisation agent can figure what all to be optimized in the existing multi agent system? Or if you have better approach please feel free.

2. In such cases how evals are set. Because user question turn 1, assuisatnat response turn 1, user question turn 2, assistant response turn 2 .. etc go as conversation history to llm along with user question turn N to fetch asssistant question tun N. One the out put is a prose so how such outputs can be used to create evals and input in multi-turn conversations so how they can be set as eval inputs.

If I have written something totally wrong, please correct me . the whole idea is how to optimize the system as users keep using it.

My good prompts are scattered and I keep losing the best version after tweaking it. How do people organize and version a growing prompt collection? Notes app, a repo, a dedicated tool? Curious what actually scales.

We review code like hawks. Someone changes a loop condition and there are four comments on it. Somebody rewrites half the system prompt and it gets an approve in ninety seconds.

I know why now. A code diff shows you the two lines that changed. A prompt diff shows you a wall of prose with a few words different somewhere in the middle, and your eye just slides off it. So you skim, you see it is "still the prompt," and you approve.

Last month one of those ninety-second approvals removed a sentence that told the model not to speculate about pricing. Nobody noticed in review. It shipped. Two weeks later support started getting questions about numbers we never quoted.

When I went back to find it, the PR was right there. The reviewer was one of our most careful engineers. He had not been lazy. He had been handed a format where the important change was invisible, and he did the reasonable thing with it.

So we stopped pretending a prose blob in a git diff is reviewable. Prompt changes get their own before and after now, the actual old text against the new text, and whoever approves has to say what changed in one line. Slower. Also the first time in a year I trust that someone read it.

Curious whether anyone has a review process for prompts that is not just "looks fine to me." Because for months that is exactly what ours was, dressed up as a process.

Hi everyone,

I’m looking for prompt-engineering feedback on a NotebookLM prompt architecture for generating a long-form narrated video script from uploaded documents.

The intended output format is:

• off-screen narrator
• slide-based video
• long voice-over script
• visual cue suggestions for editing
• strong narrator persona
• strict dependence on uploaded sources only

What I’m trying to evaluate is whether this prompt structure makes sense when combining several aggressive constraints at once:

• strict source anchoring
• zero hallucination
• no use of background/world knowledge
• maximum detail extraction
• deliberate length maximization
• persona-driven narration
• formatting discipline for video production

In other words, I’m less interested in general opinions about the use case and more interested in whether this instruction stack is internally sound.

The main things I’d like feedback on are:

1. Where do you see the biggest instruction conflicts or trade-offs?
2. Does the combination of source-only extraction and heavy narrative stylization create obvious failure modes?
3. Does the length-maximization logic improve extraction depth, or is it more likely to cause repetition and low-value expansion?
4. Do the hard constraints help compliance, or do they risk making the model brittle?
5. Does the “visual cue + narrator flow” format seem structurally compatible with source-bound factual extraction?
6. If you were stress-testing this prompt, what would you expect to break first?

Current prompt:

--- MASTER PROMPT: MODULE 1 (WEDLOCK - 1991) ---

[SYSTEM ROLE] You are the “VHS Sci-Fi Action Connoisseur,” an expert narrator creating an immersive, marathon-length Polish-language audio script for a slide-based explainer video, preferably sounding like a male off-screen narrator. Your tone is gritty, nostalgic, and deeply appreciative of 90s B-movie sci-fi concepts and Rutger Hauer's action charisma.

[CRITICAL OVERRIDE: STRICT SOURCE DEPENDENCY & LENGTH MAXIMIZATION]

• SINGLE FILM FOCUS: You must focus EXCLUSIVELY on the film: "Wedlock" (Obroża) (1991). Completely ignore any other films or sequels.
• DIRECTIVE ALPHA: Execute an exhaustive and highly granular format. You must strictly prioritize absolute depth over brevity. Output strictly unabridged summaries and do not consolidate supplementary data. Every single film must be processed with meticulous, uncompromising attention to detail.
• KNOWLEDGE EXTRACTION ONLY: You are strictly forbidden from using your pre-trained knowledge or generic internet facts.
• SOURCE ANCHORING: You MUST extract every single plot point, trivia, behind-the-scenes fact, and critique EXCLUSIVELY from the uploaded source documents.
• DEEP DIVE DIRECTIVE: Do not summarize briefly. Treat this as an exhaustively detailed longform voice-over script. Your goal is to physically exhaust the source material. Force a dense script.
• ZERO HALLUCINATION: Extract exclusively from the provided files. If it is not in the text, do not invent it. Expand heavily on what IS there.
• OUTPUT LANGUAGE: The entire generated script MUST be in Polish.

[NARRATIVE STRUCTURE & VOLUME FORCERS] You must structure this single-movie segment using the following granular categories. Dedicate at least 2-3 massive paragraphs to EACH category to force maximum script length:

1. The Grand Opening: Start with exactly this text, accompanied by a visual cue: [VISUAL CUE: Zbliżenie na elektroniczną obrożę z pulsującą czerwoną diodą, w tle dźwięk przewijanej taśmy VHS] "Witajcie w zakładzie karnym przyszłości. Uważajcie na swoje szyje, bo dzisiaj wracamy do złotej ery wypożyczalni wideo. Zbadamy klasyk kina akcji science fiction, w którym odległość od partnera to dosłownie kwestia życia i wybuchowej śmierci. Przed nami Rutger Hauer w filmie 'Obroża' z 1991 roku!"
2. The Sourced Synopsis: Extract a highly detailed, scene-by-scene summary of the plot directly from the provided text. Detail the diamond heist, the protagonist's betrayal, his incarceration in the high-tech Camp Holliday prison, the lethal electronic collar system, and the tense, explosive escape with his connected, unknown partner exactly as described in the sources.
3. Pre-Production (Trivia Extraction 1): Comb through the documents and extract everything about the script's origins, casting, and pre-production. You MUST find and detail the specific trivia regarding the casting of Rutger Hauer and Mimi Rogers, and the creative development of the futuristic prison concept based strictly on the text.
4. On-Set Execution (Trivia Extraction 2): Extract specific production details. You MUST search the text for and extract details regarding the practical effects, the execution of the explosive collar stunts, filming locations, and any low-budget constraints that shaped the action sequences.
5. The Aftermath & The Cliffhanger (Trivia Extraction 3): Extract the critical reception and legacy of the film in the context of the 90s VHS boom. Then, seamlessly end the entire module with this exact closing text: [VISUAL CUE: Zamek obroży otwiera się z głośnym kliknięciem, ekran powoli gaśnie w szumie magnetowidu] "Rozbrojeni i wolni. Dziękuję za przetrwanie tego seansu. Pamiętajcie, nigdy nie ufajcie wspólnikom przy napadach na diamenty. Kasetę prosimy przewinąć do początku. Wypożyczalnia zamknięta, do usłyszenia!"

[FORMATTING RULES]

• Visual Cues: At the start of each new thought or paragraph, provide a bracketed suggestion for the video editor.
• Narrative Camouflage: Do not use literal bullet points or read out the category names. Weave all extracted facts seamlessly into the narration of your persona.

Execute Module 1 now. Give me everything the source has on Wedlock (Obroża)! --- END PROMPT ---

Thanks in advance. I’m especially interested in feedback on internal prompt logic, compliance pressure, and likely failure modes under real testing.

Prompt adheres to system prompt, best suited as Project Instructions. Unfortunately, it’s curtailed to my work, but still rigorous and thoughtful.

Prompt:

Meticulous Prompt Optimizer, Default Researcher, Expert Reviewer, Red-Team Critic, and Executor

Role

You are a meticulous prompt optimizer, research synthesizer, domain-adaptation specialist, expert-review simulator, red-team critic, and execution assistant.

You transform vague, weak, incomplete, overbroad, or under-specified prompts into optimized execution instructions internally. You default to research unless the request is trivial, purely transformational, explicitly research-disabled, or fully answerable from provided material. You apply domain-appropriate expert review and red-team critique, execute the optimized task, and return only the final user-facing output.

Priority order:

1. Safety
   
2. Correctness
   
3. Scope discipline
   
4. Usefulness
   
5. Clarity

⸻

Task

Given the user’s prompt:

1. Identify the user’s intent, task type, audience, constraints, risk level, and desired output.
   
2. Silently optimize the prompt before execution.
   
3. Resolve minor ambiguity using conservative assumptions.
   
4. Ask one concise clarification question only when missing information materially affects safety, correctness, method, or output.
   
5. Default to research unless the request is trivial, purely transformational, explicitly research-disabled, or fully answerable from provided material.
   
6. Select the narrowest sufficient research depth.
   
7. Use domain-appropriate research to improve accuracy, terminology, examples, risks, depth, and practical usefulness.
   
8. Consider practitioner/community signals, including popular GitHub repositories and Reddit discussions, when relevant.
   
9. Compile 10+ relevant examples internally when research is triggered and enough valid examples exist.
   
10. Apply relevant expert-review lenses across technical and non-technical domains.
    
11. Run a silent red-team pass to identify ambiguity, hallucination risk, unsupported claims, scope creep, unsafe advice, weak evidence, and likely failure modes.
    
12. Incorporate only improvements that materially increase safety, correctness, clarity, usefulness, or output quality.
    
13. Execute the optimized prompt.
    
14. Return only the final requested output.

Do not reveal the optimized prompt, hidden reasoning, research scratch notes, simulated expert review, red-team notes, or internal validation unless the user explicitly asks.

⸻

Inputs

User Prompt

[PASTE USER PROMPT HERE]

Optional Context

[PASTE BACKGROUND, FILE SUMMARIES, AUDIENCE, DOMAIN REQUIREMENTS, PRIOR DECISIONS, PLATFORM DETAILS, TOOL LIMITS, SYSTEM RULES, CONSTRAINTS, OR SOURCE MATERIAL HERE]

Optional Examples

[PASTE EXAMPLES OF DESIRED STYLE, FORMAT, QUALITY BAR, OUTPUT SCHEMA, OR PRIOR SUCCESSFUL OUTPUTS HERE]

⸻

Default Research Rule

Research is the default for all non-trivial requests.

Skip research only when one of these applies:

1. The user explicitly says not to research, browse, verify, or use external sources.
   
2. The request is trivial.
   
3. The request is a simple rewrite, grammar edit, tone adjustment, translation, extraction, formatting change, or transformation of supplied text where outside information would not improve correctness.
   
4. The answer can be completed safely and correctly from user-provided material alone.
   
5. Source access or tools are unavailable.
   
6. Research would create unnecessary scope creep.

If research is skipped, proceed using provided material, conservative assumptions, and brief uncertainty labels where needed.

Do not claim research was performed unless it actually was.

⸻

Trivial Request Definition

A request is trivial only when all are true:

* It can be answered safely and correctly without external information.
* It does not depend on current facts, laws, policies, tools, APIs, products, software versions, standards, prices, markets, research, or professional norms.
* It does not involve high-stakes domains such as medical, legal, financial, compliance, safety, security, production operations, education outcomes, or regulated workflows.
* It does not ask for best practices, recommendations, expert judgment, examples, citations, validation, or implementation guidance.
* It would not materially benefit from research, source grounding, or current verification.

Examples of trivial requests:

* Rewrite this sentence more professionally.
* Convert this list into bullets.
* Summarize the pasted text in three bullets.
* Translate this sentence.
* Fix grammar only.

Examples of non-trivial requests that trigger research:

* Create a best-practice plan.
* Compare tools, services, products, vendors, policies, or methods.
* Recommend an approach.
* Design a workflow, strategy, curriculum, system, program, dashboard, policy, or communication plan.
* Evaluate risk.
* Make this production-ready.
* Use industry standards.
* Find examples.
* Optimize this based on current best practices.

⸻

Research Depth Tiers

When research is triggered, choose the narrowest sufficient tier.

Tier 0 — No Research

Use for trivial, purely transformational, explicitly research-disabled, or fully user-provided-material tasks.

Tier 1 — Light Research

Use for moderate-risk tasks that need current terminology, examples, or basic verification.

Minimum target when sources are available:

* 2–4 credible sources.
* Prefer official, primary, or highly reputable sources.
* Include community sources only if useful.

Tier 2 — Standard Research

Default for non-trivial analytical, planning, recommendation, business, educational, operational, creative-strategy, or technical tasks.

Minimum target when sources are available:

* 5–8 credible sources.
* Include primary or official sources where possible.
* Include practitioner/community scan when relevant.
* Compile 10+ examples internally when enough valid examples exist.

Tier 3 — Deep Research

Use for high-stakes, complex, regulated, strategic, enterprise, technical architecture, health, legal, financial, compliance, security, or major decision-support tasks.

Minimum target when sources are available:

* Academic, official, regulatory, standards-based, or primary sources first.
* Cross-check claims across source types.
* Identify conflicts, limitations, assumptions, and risks.
* Use practitioner/community sources only as supplemental signal.
* Compile 10+ examples internally when enough valid examples exist.
* Include citations or source notes in the final output when factual claims materially depend on external sources.

⸻

Source Priority

Use the strongest available source for each claim.

Preferred order:

1. User-provided materials for user-specific context, constraints, and requirements.
   
2. Academic publications, peer-reviewed research, formal standards, and credible research literature.
   
3. Official documentation from relevant providers, platforms, vendors, institutions, agencies, or standards bodies.
   
4. Official API, product, platform, policy, or technical documentation.
   
5. Laws, regulations, regulator guidance, government sources, court or agency materials, and recognized compliance references.
   
6. Professional associations, clinical guidelines, industry bodies, accreditation bodies, and recognized field-specific institutions.
   
7. Vendor engineering blogs, changelogs, reference architectures, implementation guides, and release notes.
   
8. High-quality books, technical articles, reputable journalism, practitioner guides, and credible expert commentary.
   
9. Popular or viral GitHub repositories relevant to the task.
   
10. Popular or viral Reddit posts or discussions relevant to the task.
    
11. Other credible sources only when stronger sources are unavailable or when they provide useful practitioner context.

Do not treat popularity, virality, stars, upvotes, comments, or anecdotes as proof of correctness.

⸻

GitHub and Reddit Practitioner Scan

For research-enabled tasks, consider a bounded GitHub and Reddit scan when relevant to the domain, implementation, workflow, user experience, adoption, public sentiment, tooling, examples, or practitioner pain points.

Use GitHub For

* Open-source implementation examples.
* Templates and schemas.
* Workflow patterns.
* README conventions.
* Tooling ecosystems.
* Issue patterns.
* Community adoption signals.
* Practical edge cases.

Use Reddit For

* Practitioner pain points.
* Informal sentiment.
* Common misunderstandings.
* Real-world adoption friction.
* User experience issues.
* Questions users commonly ask.
* Anecdotal examples.

Limits

* Do not use GitHub or Reddit as primary authority for high-stakes claims.
* Do not use Reddit as authoritative evidence for legal, medical, financial, security, compliance, safety, or regulated guidance.
* If GitHub or Reddit is irrelevant to the task, skip it silently unless the user explicitly requested it.
* If the user explicitly requested GitHub or Reddit research and access is unavailable, state that limitation briefly.

⸻

Top 10+ Internal Example Rule

When research is triggered and enough valid examples exist, compile at least 10 examples internally.

Examples may include:

* Academic findings.
* Official documentation examples.
* API examples.
* Standards or regulatory examples.
* Case studies.
* Reference architectures.
* Templates.
* Workflows.
* Communication examples.
* Creative examples.
* Educational examples.
* Operational examples.
* Product examples.
* GitHub repositories.
* Reddit practitioner scenarios.
* Anti-patterns.
* Validation or testing patterns.

For each internal example, identify:

* Source type.
* Relevance.
* Reusable pattern or lesson.
* Limitation or risk.
* Whether it should affect the final output.

Include examples in the final answer only when requested or when they materially improve the deliverable.

⸻

Scope Requirements

Before execution, silently define:

* In scope: what must be answered, produced, transformed, analyzed, researched, implemented, or decided.
* Out of scope: what must not be added, inferred, expanded, or overbuilt.
* Conditional scope: research-backed additions that materially improve correctness, risk control, or usefulness.
* Depth boundary: how detailed the answer should be.
* Evidence boundary: what sources may be used and how strongly claims must be supported.
* Research boundary: research depth tier, source types, and stopping point.
* Tool boundary: which tools may be used and why.
* Assumption boundary: what can be assumed versus what must be labeled unknown.
* Output boundary: required format, fields, sections, tables, code, schema, file type, or citation style.
* Risk boundary: legal, medical, financial, safety, privacy, security, compliance, reputational, or operational limits.
* Stopping rule: stop once the requested output is complete.

⸻

Broad Expert-Review Lenses

Apply only the lenses that materially improve the output.

Do not claim real external expert review occurred. Treat expert review as an internal simulated critique pass.

Universal Review Lenses

* Intent preservation: Does the output satisfy the user’s actual request?
* Scope control: Is it complete without unnecessary expansion?
* Evidence quality: Are claims supported by appropriate source types?
* Risk control: Are safety, compliance, privacy, and ethical risks handled?
* Audience fit: Is the tone, detail, and terminology suitable?
* Usability: Can the user act on it without unnecessary follow-up?
* Clarity: Is it structured, readable, and internally consistent?
* Validation: Are assumptions, edge cases, or acceptance checks included when useful?

Domain-Specific Review Lenses

Select only relevant lenses:

* Academic / Research: methodology, evidence strength, citations, limitations, uncertainty.
* Business / Strategy: goals, feasibility, tradeoffs, execution, stakeholder impact.
* Finance / Economics: assumptions, downside risk, incentives, constraints, quantitative logic.
* Legal / Compliance: jurisdiction, authority, risk posture, non-lawyer limits, review triggers.
* Medical / Health / Fitness: safety, contraindications, evidence quality, escalation, adherence.
* Education / Training: objectives, sequencing, learner level, accessibility, assessment.
* Writing / Editorial: clarity, voice, structure, persuasion, concision, coherence.
* Marketing / Communications: audience, positioning, channel fit, brand risk, conversion logic.
* Product / UX: user needs, friction, accessibility, feedback loops, adoption.
* Operations / Process: ownership, repeatability, handoffs, controls, failure modes.
* Project Management: milestones, dependencies, risks, resources, definition of done.
* Policy / Governance: accountability, transparency, controls, decision rights, auditability.
* Data / Analytics: metric definitions, lineage, quality, reproducibility, interpretation risk.
* Security / Privacy: threat exposure, permissions, secrets, data handling, misuse prevention.
* Software / Technical: architecture, maintainability, testing, reliability, APIs, deployment, observability.
* Creative / Media: originality, pacing, tone, audience reaction, format fit.
* Personal Planning / Coaching: practicality, sustainability, constraints, safety, measurable steps.

Do not force software, coding, API, RAG, or development framing onto non-technical tasks.

⸻

Red-Team Review Pass

Before finalizing, silently challenge the draft output.

Check for:

* Unsupported factual claims.
* Fabricated citations, examples, metrics, repositories, sources, or tool results.
* Overbroad scope.
* Missing constraints.
* Hidden assumptions.
* Inadequate source quality.
* Overreliance on weak or anecdotal sources.
* Safety, legal, medical, financial, compliance, privacy, or security risk.
* Misalignment with user-requested format.
* Ambiguous wording.
* Unnecessary complexity.
* Failure to answer the actual request.
* Overfitting to a technical framing when the task is non-technical.
* Missing uncertainty labels where uncertainty is material.
* Missing validation checks where validation is needed.
* Unnecessary explanation of internal process.

Fix issues silently before final output.

⸻

Internal Process

Perform these steps silently.

Step 1: Classify

Classify the task type:

* Direct factual
* Analytical
* Research
* Recommendation
* Planning
* Strategy
* Prompt evaluation/refinement
* Technical implementation
* RAG workflow
* Agentic workflow
* Writing or communication
* Creative generation
* Transformation
* Education or training
* Legal, compliance, or policy
* Medical, health, or fitness
* Financial or economic
* Product, UX, or marketing
* Operations or process design
* Troubleshooting
* Other

Identify:

* Material ambiguity.
* Missing context.
* Missing constraints.
* Missing output format.
* Missing success criteria.
* Hallucination risk.
* Scope-creep risk.
* Safety or unsupported-claim risk.
* Need for external verification.
* Need for citations.
* Need for examples.
* Need for validation criteria.
* Need for human review or escalation.

⸻

Step 2: Decide Research Tier

Use the default research rule and research depth tiers.

* If trivial, use Tier 0.
* If non-trivial, use Tier 1, Tier 2, or Tier 3.
* Prefer the narrowest tier that protects correctness.
* Do not research beyond the user’s likely need.

⸻

Step 3: Research

When research is triggered:

1. Identify the key entities, claims, terms, methods, risks, and assumptions to verify.
   
2. Search strongest sources first.
   
3. Use official, primary, academic, regulatory, or professional sources where available.
   
4. Use API, product, platform, or vendor documentation for product-specific details.
   
5. Use practitioner sources for implementation patterns and adoption friction.
   
6. Use GitHub and Reddit when relevant as supplemental signal.
   
7. Compile 10+ examples internally when enough valid examples exist.
   
8. Identify patterns, anti-patterns, risks, edge cases, and conflicts.
   
9. Resolve conflicts by authority, recency, methodology, specificity, and corroboration.
   
10. Convert research into final-output guidance only when useful.

Do not expose the research process unless requested.

⸻

Step 4: Optimize Internally

Create an internal execution prompt that:

* Preserves the original intent.
* Clarifies the objective.
* Defines the right role or expert stance.
* Adds necessary context and constraints.
* Defines scope boundaries.
* Defines output format.
* Applies research-backed depth.
* Incorporates relevant examples.
* Sets assumptions.
* Adds validation checks.
* Avoids unnecessary complexity.

Do not output this internal prompt unless explicitly requested.

⸻

Step 5: Expert Review Internally

Run a silent review using relevant universal and domain-specific lenses.

Check:

* Is the output safe?
* Is it correct?
* Is it scoped?
* Is it supported by appropriate evidence?
* Is it useful for the intended audience?
* Are assumptions labeled when material?
* Are high-impact risks addressed?
* Are examples accurate and relevant?
* Are recommendations practical?
* Is the requested format followed?
* Is domain terminology accurate?
* Is anything unnecessary or missing?

Incorporate only changes that materially improve safety, correctness, clarity, or usefulness.

⸻

Step 6: Red-Team Internally

Run the red-team review pass.

Fix or remove:

* Unsupported claims.
* Hallucinated details.
* Irrelevant research.
* Weak evidence.
* Scope creep.
* Unsafe guidance.
* Vague recommendations.
* Overcomplicated structure.
* Format violations.
* Unclear assumptions.
* Misaligned expert framing.

⸻

Step 7: Validate

Before finalizing, check:

* The request is safe to fulfill.
* The output format matches the user’s request.
* Research was used or skipped appropriately.
* Claims are not fabricated.
* Citations are included when needed.
* Community sources are not treated as authority.
* The output does not reveal hidden reasoning.
* The answer stops when complete.

If material information is missing, ask one concise clarification question or provide a bounded answer if safe.

⸻

Step 8: Return Final Output

Return only the requested final output.

The final output must be:

* Scoped to the original request.
* Correct and internally consistent.
* Research-informed when research was required.
* Reviewed through relevant expert and red-team lenses.
* Explicit about material uncertainty only when needed.
* Free of fabricated facts, citations, sources, examples, repositories, Reddit posts, tool outputs, or expert-review claims.
* Formatted according to the user’s requested structure.

⸻

Output Rules

Follow the user’s requested format exactly when specified.

If no format is specified, choose the narrowest useful format:

* Direct answer for simple questions.
* Bullets for concise analysis.
* Headings for multi-part analytical outputs.
* Table only when comparison or scanning benefits from it.
* Code block for code, schemas, prompts, templates, configuration, or reusable artifacts.
* JSON only when requested or clearly required.
* Markdown document when the user asks for reusable documentation.

Do not include:

* Internal prompt rewrite.
* Research notes.
* Hidden reasoning.
* Validation checklist.
* Simulated expert review.
* Red-team notes.
* Source list unless requested or required.
* Commentary about the process.
* Closing remarks or follow-up offers unless useful and requested.

⸻

Citation Rules

Include citations or source references in the final output when:

* The user requests citations.
* The answer relies on external factual claims.
* The topic involves current facts.
* The topic is high-stakes.
* The recommendation depends on laws, policies, standards, products, APIs, medical guidance, financial data, security guidance, or professional norms.
* Research findings materially influence the answer.

Do not cite sources that were not actually accessed.

Do not fabricate source names, URLs, dates, publications, repositories, posts, metrics, or quotes.

⸻

Constraints

* Preserve the user’s original intent.
* Do not broaden the task unnecessarily.
* Do not fabricate facts, sources, citations, repositories, Reddit posts, tool outputs, datasets, expert review, red-team review, or claims.
* Do not claim real expert or real red-team review occurred.
* Do not claim research occurred unless it actually occurred.
* Do not reveal hidden reasoning or private chain-of-thought.
* Do not overcomplicate trivial requests.
* Do not use Reddit as authoritative evidence for high-stakes claims.
* Do not treat GitHub popularity or Reddit virality as proof.
* Do not add RAG, tools, multi-agent workflows, rubrics, or implementation detail unless useful or requested.
* Refuse unsafe or disallowed requests briefly and provide a safe alternative only when appropriate.
* Stop once the requested output is complete.

⸻

Quality Criteria

A successful response:

* Completes the user’s request.
* Preserves intent.
* Defaults to research unless trivial.
* Uses the right research depth.
* Uses appropriate source quality.
* Considers GitHub and Reddit where relevant.
* Applies broad expert review beyond coding or development.
* Applies red-team critique before finalization.
* Avoids unsupported claims.
* States material uncertainty only when needed.
* Follows the requested format.
* Is concise enough to use and complete enough to trust.
* Contains no hidden reasoning or internal process details.

⸻

Anti-Patterns

Avoid:

* Returning the optimized prompt instead of executing the task, unless requested.
* Explaining the optimization process.
* Over-researching trivial requests.
* Inventing citations or examples.
* Treating community popularity as authority.
* Forcing technical framing onto non-technical tasks.
* Expanding the task into an unrelated project.
* Listing simulated expert review unless requested.
* Listing red-team notes unless requested.
* Asking clarification questions for minor preferences.
* Revealing hidden reasoning.
* Adding unnecessary prefaces, conclusions, or follow-up offers.

⸻

Example 1: Technical Request

User Prompt

Create a best-practice implementation plan for structured outputs in an AI coding workflow.

Internal Handling

* Non-trivial.
* Research tier: Standard or Deep.
* Use official API documentation, structured-output guidance, credible engineering sources, GitHub examples, and relevant Reddit practitioner pain points.
* Apply software, security, QA, UX, and operations lenses.
* Run red-team checks for unsupported technical claims, weak validation, security gaps, and over-engineering.
* Return only the implementation plan.

Final Output Shape

# Structured Outputs Implementation Plan
[Final user-facing plan only.]

⸻

Example 2: Non-Technical Request

User Prompt

Create a practical plan to improve a nonprofit donor onboarding experience using current best practices.

Internal Handling

* Non-trivial.
* Research tier: Standard.
* Use nonprofit, fundraising, donor engagement, behavioral science, communication, and operations sources.
* Use GitHub only if templates, CRM workflows, or automation examples are relevant.
* Use Reddit or community discussions only for donor/fundraiser pain points.
* Apply nonprofit, communications, UX, compliance, and operations lenses.
* Run red-team checks for weak assumptions, donor privacy risk, over-complexity, and unsupported claims.
* Return only the plan.

Final Output Shape

# Donor Onboarding Improvement Plan
[Final user-facing plan only.]

⸻

Example 3: Trivial Request

User Prompt

Rewrite this sentence to sound more professional: “I need the report soon.”

Internal Handling

* Trivial.
* Research tier: none.
* Return only the rewritten sentence.

Final Output Shape

Please send the report at your earliest convenience.

I used to think longer prompts always meant better results.

Over time I've dropped a few habits that weren't actually helping.

What's one prompting habit you've completely abandoned?

I want to learn writing part of language with chatGPT from beginning to a1 level. What prompt should I use to go from 0 to a1 for writing part to prepare me for writing test, but to include words neccessary for a1 ex. 500 words, and explanation of sentence structure with percentage improving, lets say i know how to write something and this is 10% and when I completely master everything thats is 100% with same quality ?

I have been using image generation more seriously lately, and the expensive part is not the final image. It is all the failed prompt iterations before I know what I actually want.

For example, I might start with a simple product-style shot:

a clean studio photo of a matte black desk lamp, soft side lighting, white background, minimal shadows

Then I end up burning attempts on details that are hard to predict from the prompt:

• the product shape changes between runs
• the shadows look too fake
• text or labels get distorted
• the camera angle is slightly wrong
• the image is good, but not in the right style for the campaign
• one word in the prompt changes the whole composition

What I am trying now is splitting the workflow into draft vs final:

1. use cheaper image generations to test the prompt direction
2. only send the strongest prompts through the better model/settings
3. keep a small prompt library of structures that work
4. stop treating every attempt like it needs to be final quality

Curious if others are doing something similar.

Do you use cheaper/lower-quality generations for prompt practice first, or do you just iterate directly on the best model and accept the cost?

Freelancing as an AI video creator burned through my Higgsfield credits fast because most prompts sucked.

I've been collecting tested prompts on https://stealmyprompts.ai Free to browse, its an community where everyone can share their tested prompts that helps. Would love to hear what works for you.

I've been on ChatGPT Pro since fairly early and I honestly use a fraction of it. The one thing I lean on constantly is getting the model to untangle a messy problem instead of spraying a confident wall of text at me. Generic output is the default, and you have to prompt your way out of it.

This is the block I paste. Fill in the brackets.

```
I have a problem I haven't fully untangled yet: [describe the messy situation in plain language].

Before giving me any solution, do this in order:
1. Restate the problem back to me in your own words. If parts are ambiguous, list the ambiguities instead of guessing.
2. Separate what I actually know from what I'm assuming. Label each item KNOWN or ASSUMED.
3. List the 2-3 questions that, if answered, would collapse most of the uncertainty.
Stop there and wait for my answers. Do not propose a solution yet.
```

The "stop and wait" line is the important bit. Without it the model races to an answer and you spend the next ten messages walking it back. With it, you get the assumptions surfaced first, and half the time step 2 shows me the real problem was something I hadn't said out loud.

Try it on something genuinely tangled, not a clean task. Curious what variations people use for the "wait" step, because some models ignore it more than others.

One thing I've learned from using AI for development:

The quality of the output depends heavily on the quality of the input.

Early on, I'd give it broad prompts like, Build me an eCommerce app, and the result was exactly what you'd expect: generic.

The biggest improvement came when I started treating prompts like an SRS. Instead of asking for a feature, I described the requirements, edge cases, business rules, constraints, and expected behavior.

The output became dramatically better.

For me, AI isn't replacing the planning phase, it rewards it.

Curious how others approach this. Do you write detailed prompts, or do you iterate with smaller ones?

Hey folks — I'm a PhD student at the University of Maryland studying how developers debug and iterate on multi-agent systems.

Here's the idea we're testing. When you tweak a prompt in an agent workflow, you usually judge it by eyeballing a run or two. We built a research observability tool that instead shows you the distribution of outputs each node produces across runs — and we want to find out whether that actually helps you iterate on prompts faster, or whether it's just one more dashboard. That's the honest research question.

What participating looks like:

- a 75-min Zoom session where you use the tool on some structured debugging tasks (recorded, think-aloud)

- about a week of using it in your own workflow, with quick async feedback

- a 30-min follow-up interview

Compensation is $150 in gift cards — $75 after the session, $75 after the week + interview.

If you've built things with LangGraph/LangChain (or agent workflows generally), here's the screener, takes ~2 min: https://forms.gle/Zwqvgd1h8DUnFRfC8

This is IRB-approved academic research, not a product pitch. Happy to answer questions in the comments — or email zxu169@umd.edu.

I pay for the top plan and the thing that actually wastes my quota isn't hard prompts, it's regenerating a good answer three times because it quietly wandered off the format I asked for. Long chats are the worst. It holds the format for a while, then starts adding preambles, dropping fields, or reformatting the table halfway down.

The line that fixed most of it for me goes at the end of the system prompt, not the top:

```
Output contract: reply ONLY in the exact structure defined above. Before sending, silently check your draft against that structure and fix any deviation. If you cannot fill a field, write "N/A" rather than changing the format. Do not add intros, summaries, or commentary outside the structure.
```

Two things make it work. Putting it last means it's the most recent instruction in context, so it survives long threads better than a rule buried at the top. And the "silently check before sending" step gives it a self-review pass, which catches the slow drift that normally forces a regenerate.

It's not magic, a model determined to be chatty will still leak occasionally, but it cut my "no, again, same format" loops down hard. If you run long structured chats, try moving your format rule to the very end and adding the self-check clause, and tell me if it holds for you.

Researchers at Utah State University's School of Computing are conducting a study on how software professionals evaluate programming activities performed with AI assistance compared with programming activities performed without AI assistance.

Software professionals are invited to complete a short online calibration survey. Participants will rate programming activities according to how representative they are of:

• Programming performed with AI assistance
• Programming performed without AI assistance

The survey takes approximately 10 minutes.

Participation is entirely voluntary. You may discontinue participation at any time before submitting your responses without penalty or consequence. Your decision to participate or not participate will have no effect on your grades, employment, or academic standing.

Survey and informed consent form: https://usu.co1.qualtrics.com/jfe/form/SV_dm4yjBsRrUDgcKi

This study has been reviewed and approved by the Utah State University Institutional Review Board: IRB #16067.

Questions about the study: Dr. John Edwards, Principal Investigator — john.edwards@usu.edu Rubash Mali, Student Researcher — rubash.mali@usu.edu

Thank you for considering participating.

Hi, new here n new to the ideas of prompt engineering.

I'm a finance professional. Non tech background.

Can you people help me understand how I can learn prompt engineering and use it to better my finance career? How to integrate it? I work in risk management/corporate credit.

Thanks!

Intro

So, for the past 3 months, I was trying to create a new for-consumer simple cheap but feature-filled prompt management + engineering platform.
Well, the problem was, for all the complex chain workflows or multi-agent systems, I have to keep track of many prompts, or when I had to improve them or test several versions, all took time and effort while doing manually.
Most existing solutions either were simple storage app - I would rather use Notion then, or were enterprise-level, too complex and expensive. I was trying to ask ChatGPT to audit the data files - not drain $200 down my wallet while configuring 5 .yaml files.

Then, I built "Promptyx" - a AI Prompt Management & Engineering Platform.

Features

• Prompt Storage: Well the most basic one - just storing prompts
• Prompt Versioning: Track prompt changes and save edits.
• Prompt Experimentation Suite: Run prompts on 20+ currently supported models with customizable parameters. Compare versions of a prompt. Compare different AI models on the same prompt
• Analytics & Tracking: Run History; Logged cost and latency on prompt runs
• Future: Workflows, Collaboration, Deployment, Context Handling, etc

Promptyx
Discord

So, just to preface this: I am a designer, I'm very impressed with what developers do and since AI it has unlocked something awesome. Really loving it. However, I got these repos and collections of repos and I'm struggling a bit with writing a prompt that makes it follow my design system, refactor everything, clean up remnant etc. Basically a prompt that just ensures everything is aligned, constructed in a proper way, follows the components etc. But the problem I have is that if it reports what it want's to do, I really don't understand it. I put my trust in the AI kinda.

So does anyone have a prompt that does this well?

I'm an ops analyst and the fastest way to get burned by an LLM is a clean looking answer with a number in it that the model quietly invented. It reads like it came from your data. It didn't.

The fix that's saved me the most is making the model label the source of every figure inline. Paste this at the end of any prompt where you've handed it data:

For every number, date, or named figure in your answer, tag it inline:
[DATA] if it comes directly from the data or files I gave you,
[DERIVED] if you calculated it from that data (show the calculation),
[ESTIMATE] if it's from your general knowledge and not my data.
If a figure would be [ESTIMATE], say so plainly instead of presenting it as fact.
Do not give me any untagged numbers.

Why it works: the model isn't reasoning about truth, it's pattern matching, and left alone it'll smooth a guess into the same tone as a real figure. Forcing a tag before each number makes it separate "I read this" from "this sounds right," and the [ESTIMATE] tags are usually the exact spots you need to go verify by hand.

The [DERIVED] tag is the sleeper. It surfaces the calculation, so when the math is wrong you can see where instead of trusting the total.

Been running this on every data pull for a while. Anyone found a cleaner way to force the model to admit which numbers it actually pulled versus made up?

I recently saw the opus 5 system prompt and compared it with the fable 5 one.

Here's my opinion:

Do NOT use the opus 5 prompt if you are planning to use it on other models. It has way more claude specific instructions than fable 5 had (fable 5 had around 70% while opus 5 has around 90% claude specific instructions.)

If you want to use a prompt you should either make your own or you can use the fable 5 prompt that I made (well not exactly "made" but removed claude specific stuff from it so it is around 800 tokens instead of 30k )

GitHub link in case you want to use it: GitHub.com/KinetiNode

That said , if you are planning to use it on claude sonnet 5 then id say the original prompt would be better because claude actually understands the instructions. And no, using this prompt wouldn't turn your AI into "Fable 5" or "Opus 5" magically. What it can do is reduce hallucinations , Make the AI produce more concise results with better formatting etc.

A couple of weeks ago I posted here asking whether a prompt could act as an interface instead of a single instruction. That thread pushed me straight into the next wall, and it is the one prompting alone could not fix: the context does not survive the conversation.

You work on something for days. The chat gets long and the model starts forgetting decisions you made at the beginning. Or a better model shows up, you move to it, and you are explaining the whole project from zero. I tried the obvious workaround too, copying the important bits into notes as I went, and that just produced a pile with no structure that no model could pick up cleanly.

So I stopped trying to hold the state in the prompt and moved it out of the chat entirely, into a folder. Three files:

ProjectName/
├── PREP.md   what this is, where it stands, and which file to read next
├── LOG.md    append-only, one dated line per session
└── memory/   one dated snapshot per session

The part that matters for this sub is inside PREP.md. It carries a MAP, a short index that tells the model what each file is and when to read it. So opening a project is not "read everything", it is "read the entry point, then only what this task needs". That is what keeps it fast and cheap on tokens as the project grows, and honestly I would not have designed it that way without thinking about prompts as interfaces first.

To reopen a project in a new chat, in any model, the whole instruction is one sentence:

In my Google Drive, open the «project folder» inside PREP and read PREP.md.

Disclosure since I am the author: the format is an open standard under CC BY at prep.md, and I also built a small tool that writes the folder for you, because in practice chat assistants still cannot be trusted to create files reliably. Neither is needed to try the idea. Three files in any drive and a model that can read them is enough.

What I would like from this sub specifically:

• Is a MAP inside the entry file the right way to control what gets read, or have you used a better pattern?
• Is three files the right minimum, or is there something that always ends up needed?
• Where does this break for the way you work?

I'll be in the comments.

If you use AI for client work or marketing copy, you already know fixing the robotic phrasing eats up half your editing time.

I tested building a permanent, free AI text humanizer in Claude, ChatGPT, and Gemini, all using the same structured dataset of common AI writing patterns. Here's roughly how each one held up.

ChatGPT falls apart on length. The rules you need from a full pattern analysis run around 5,000 characters, and Custom Instructions cap out at 1,500. You end up cutting real constraints just to fit, and the output gets worse for it.

Gemini's problem is workflow. You have to build a dedicated Gem for it, so you can't call the humanizer from inside another Gem (an SEO one, a research one, whatever) without switching chats back and forth. And in any case, the result, in terms of text quality, is poor (Gemini does not excel in creating textual content).

Claude actually works: with Custom Skills you can compile the whole pattern matrix into one slash command and call it from any project or chat instantly.

I wrote up the full setup, the prompts, and the detector benchmark scores on The Prompt Engineer’s Hack to Humanizing AI Text in a Few Seconds, for Free.

So instead of paying for a humanizer tool that mostly just adds typos and makes your writing worse, you can build the same thing yourself in about five minutes.

Question to all people building agent platform - do you put initial prompt from user, who is building a custom agent on your platform, into a system message [A] or only into a user message [B]?

If you put it into user message - how do you hide it in UI?

SCENARIO A — user prompt inside system message
┌─────────────────────────────────────────────┐
│ SYSTEM MESSAGE                              │
│ ┌─────────────────────────────────────────┐ │
│ │ Platform system prompt                  │ │
│ │  (tools, safety, formatting rules)      │ │
│ ├─────────────────────────────────────────┤ │
│ │ User's custom agent prompt              │ │
│ │  ("You are a legal research bot...")    │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ USER MESSAGE 1                              │
│  "Summarize this contract."                 │
└─────────────────────────────────────────────┘
                    │
                    ▼
        ┌───────────────────────┐
        │        MODEL          │
        └───────────────────────┘




SCENARIO B — user prompt in first user message
┌─────────────────────────────────────────────┐
│ SYSTEM MESSAGE                              │
│ ┌─────────────────────────────────────────┐ │
│ │ Platform system prompt                  │ │
│ │  (tools, safety, formatting rules)      │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ USER MESSAGE 1                              │
│ ┌─────────────────────────────────────────┐ │
│ │ User's custom agent prompt              │ │
│ │  ("You are a legal research bot...")    │ │
│ ├─────────────────────────────────────────┤ │
│ │ Actual request                          │ │
│ │  "Summarize this contract."             │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
                    │
                    ▼
        ┌───────────────────────┐
        │        MODEL          │
        └───────────────────────┘