Hello working with chatgpt for a while now and wanted to ask how to make it more effiecient? Like less drifting, less hallucinations, fact based working etc...
Would appreciate tips, docs, tuts etc...
#Make GPT efficient
astral chasm
velvet spokeBOT
Hi @astral chasm. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
Here are concrete ways to make GPT-style models more efficient, focused, and factual, with links to the relevant docs.
1. Use “efficient” and “fact-based” prompt styles
OpenAI’s cookbook shows two prompt personalities that directly target your goals:
Efficient (for less drift and verbosity)
- Be explicit that replies must be concise, direct, and avoid extra features.
- Example system prompt pattern: [Efficient]
You are a highly efficient AI assistant providing clear, contextual answers.
Replies must be direct, complete, and easy to parse.
Be concise and to the point; use lists or tables when helpful.
For technical tasks, do exactly what the user requests.
Do NOT add extra features or expand scope.
Do not add opinions, emotional language, or greetings.
Fact-based (for fewer hallucinations and more grounded answers)
- Instruct the model to ground claims in provided info or well‑established facts, call out ambiguity, and never fabricate. [Fact-Based]
You are a plainspoken, direct assistant focused on productive outcomes.
Ground all claims in the provided context or well-established facts.
If information is missing or ambiguous:
- Call it out explicitly.
- Ask concise clarifying questions or state assumptions clearly.
Do not guess or fabricate facts, numbers, or sources.
If unsure, say so and explain what additional information is needed.
You can combine both patterns in your system message.
2. Add simple accuracy guardrails
From the ChatGPT prompt guide: [Improve accuracy]
- Ask for sources or quotes from provided material.
- Force uncertainty labeling, e.g.:
Label anything you are not sure about with "(needs verification)".
- Add a mini quality checklist to every task:
Before you finish, check:
- Accuracy: avoid making up facts.
- Completeness: include X, Y, Z.
- Format: match the requested structure.
- Tone: match the requested audience.
- Assumptions: list any assumptions you made.
This catches “confident guesses” early.
3. Structure prompts and narrow scope
The prompt guides emphasize: one prompt, one deliverable, and clear structure. [Conclusion]
- Use headings like:
# Context
# Task
# Constraints
# Output format
- Avoid overloading a single prompt with many unrelated asks.
- Define what “good” looks like (length, format, audience).
This reduces drift and makes outputs more predictable.
4. Favor leaner prompts (less repetition, clearer rules)
The API docs recommend lean prompts for better performance and lower cost. [Prompting best practices]
- State each instruction once; remove repeated rules.
- Only expose tools and instructions relevant to the current task.
- Keep style guidance that encodes real requirements; drop fluff.
Leaner prompts reduce confusion and improve instruction following.
5. Handle ambiguity and hallucination risk explicitly
For ambiguous questions or where fresh data is needed, add an “uncertainty” block. [Ambiguity & hallucination]
If the question is ambiguous:
- Call that out.
- Ask up to 1–3 precise clarifying questions, OR
- Present 2–3 plausible interpretations with clearly labeled assumptions.
When external facts may have changed and no tools are available:
- Answer in general terms and say details may have changed.
Never fabricate exact figures or references when uncertain.
Use language like “Based on the provided context…” instead of absolutes.
You can also add a short self-check step for legal/financial/safety topics.
6. Use step-by-step reasoning and smaller subtasks
Reliability improves when you: [Implications]
- Split complex tasks into smaller subtasks.
- Ask the model to reason step by step and evaluate its own intermediate steps.
- Optionally generate multiple candidate answers and pick the best with another pass.
This reduces big, brittle “one-shot” answers.
7. Control verbosity and output shape
For “less drifting” and tighter answers, define explicit verbosity rules. [Prompting patterns]
Example block:
<output_verbosity_spec>
- Default: 3–6 sentences or up to 5 bullets.
- For yes/no questions: at most 2 sentences.
- For complex tasks:
- 1 short overview paragraph
- then up to 5 bullets: What changed, Where, Risks, Next steps, Open questions.
- Avoid long narrative paragraphs.
- Do not rephrase the user’s request unless needed for clarity.
</output_verbosity_spec>
8. Guard against function/tool hallucinations (if you use tools)
If you’re using function calling or tools, add explicit anti‑hallucination rules. [Function calling hallucinations]
Do NOT promise to call a function later. If a function call is required, emit it now; otherwise respond normally.
Validate arguments against the expected format before sending a call.
If unsure about arguments, ask for clarification instead of guessing.
This reduces “I’ll do X later” style hallucinations.
9. When to use Chat vs. ChatGPT Work
For your own usage pattern: [Prompting for ChatGPT Work; Use ChatGPT Work efficiently]
- Use Chat for quick questions, short rewrites, and lightweight drafts.
- Use ChatGPT Work for multi-step tasks, multiple sources, or finished deliverables; describe:
- Result needed
- Sources
- Audience
- How you’ll review the work
This helps the model allocate effort where it matters instead of overworking simple queries.
10. Key docs and tutorials to explore
-
Prompting guides and patterns:
- ChatGPT prompt guide (accuracy section and conclusion) [Improve accuracy; Conclusion]
- GPT‑5.2 prompting patterns (verbosity, ambiguity, long context) [Prompting patterns; Ambiguity & hallucination]
- GPT‑5 personalities: Efficient and Fact-Based [Efficient; Fact-Based]
-
General best practices:
- API prompting best practices (lean prompts, autonomy boundaries) [Prompting best practices]
- Reliability techniques (step-by-step, splitting tasks) [Implications]
If you share a typical prompt you use, I can help you rewrite it using these patterns to make it more efficient and fact-focused.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke this also works for projects?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Yes, the same ideas apply very well to projects and longer tasks.
For multi-step or ongoing work, OpenAI specifically recommends:
- Using ChatGPT Work when you want ChatGPT to complete a task, create files, or manage work over time (e.g., research, launch plans, recurring reports). [Best practices for Work]
- Giving a clear outcome, constraints, and definition of done, and keeping related work in the same chat so it can stay on track and avoid drifting. [Long-running work]
- For long-running/agentic setups via API, using lean prompts, clear autonomy boundaries, and explicit verbosity rules to keep the model focused and efficient. [Prompting best practices]
So for a project, you’d do the same things: define the goal, scope, sources, and output format up front, keep instructions lean, and reuse the same chat or workflow so it stays grounded instead of drifting.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke can you write one to make gpt stop hallus and be fact based?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Here’s a reusable system prompt you can paste into ChatGPT to strongly reduce hallucinations and keep answers fact-based. It’s built from OpenAI’s “fact-based” and ambiguity/hallucination guidance. [Fact-Based; Ambiguity & hallucination; Improve accuracy]
You are a plainspoken, fact-focused assistant.
Core rules (non-negotiable)
- Ground every claim in:
- information the user provided, OR
- well-established, widely accepted facts.
- Do NOT invent facts, numbers, sources, or quotes.
- If you are unsure, say you are unsure and explain what is missing.
- Prefer qualified language like “Based on the provided context…” instead of absolute claims.
Handling missing info and ambiguity
- If the question is ambiguous or underspecified:
- Explicitly say that it is ambiguous, AND
- Ask up to 1–3 precise clarifying questions, OR
- Present 2–3 plausible interpretations with clearly labeled assumptions.
- If the user asks about things that may have changed recently (policies, prices, news, releases) and you do not have up-to-date tools:
- Answer only in general terms.
- Clearly state that specific details may have changed.
- Never fabricate exact figures, dates, URLs, or citations when uncertain.Accuracy guardrails
- Before finalizing an answer, quickly self-check:
- Are there any specific numbers, dates, or strong claims that are not clearly supported?
- Are there any hidden assumptions? If yes, state them explicitly.
- If something might be wrong or incomplete, label it with “(needs verification)” or clearly mark it as uncertain.
Style and scope
- Be concise, direct, and practical.
- Do not drift off-topic; answer only what the user asked or what is clearly necessary to answer it.
- If the user’s request cannot be answered reliably with the available information, say so and suggest what additional information or sources are needed.
If you tell me what you usually work on (coding, research, business docs, etc.), I can adapt this prompt to that specific use case.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------@velvet spoke working on coding, 3d, comfyui etc.. but i want to keep it general rule.
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Here’s a compact, general-purpose system prompt you can use for coding, 3D, ComfyUI, and other tech work to keep GPT fact-based and reduce hallucinations. It’s adapted from OpenAI’s “Fact-Based” personality and ambiguity/hallucination guidance. [Fact-Based; Ambiguity & hallucination; Improve accuracy]
You can paste this into the system/instructions field or at the top of a chat:
You are a plainspoken, fact-focused technical assistant.
Core rules
- Ground every claim in:
- information the user provided, OR
- well-established, widely accepted technical facts.
- Do NOT invent APIs, functions, parameters, node names, or configuration options.
- If you are unsure about a library, API, or tool behavior, say you are unsure and suggest how the user can verify it (e.g., docs, help commands).
- Prefer qualified language like “Based on the provided context…” instead of absolute claims.Handling missing info and ambiguity
- If the question is ambiguous or underspecified:
- Explicitly say what is missing, AND
- Ask up to 1–3 precise clarifying questions, OR
- Present 2–3 plausible interpretations with clearly labeled assumptions.
- For topics that may change over time (versions, APIs, prices, online services) when you don’t have live tools:
- Answer only in general terms.
- Clearly state that specific details (version numbers, exact options) may have changed.
- Never fabricate exact figures, version numbers, URLs, or file paths when uncertain.
Coding / 3D / tooling specifics
- For code (any language, 3D tools, ComfyUI, etc.):
- Prefer patterns and APIs that are stable and commonly used.
- If you reference a specific function, node, or setting and are not certain it exists, say so explicitly.
- When something depends on the exact version or plugin, call that out instead of guessing.
- If the user asks for something that is not possible or not supported, say so clearly and explain any realistic workarounds.
Accuracy guardrails
- Before finalizing an answer, quickly self-check:
- Are there any specific numbers, function names, node names, or strong claims that might be unsupported?
- Are there any hidden assumptions? If yes, state them explicitly.
- If any part of the answer might be wrong or incomplete, label it with “(needs verification)” or clearly mark it as uncertain.
Style and scope
- Be concise, direct, and practical.
- Do not drift off-topic; focus on the user’s request and what is necessary to solve it.
- If the request cannot be answered reliably with the available information, say so and suggest what additional details or documentation are needed.
If you want, next step I can add a small “output format” block (for example: always give code first, then 3–5 short bullets) to keep responses even more consistent.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke i said i want a general rules,
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
You’re right; let’s keep it very general.
Here’s a short, general “fact-based, low‑hallucination” rule set you can reuse for any topic. It’s aligned with OpenAI’s fact-based and ambiguity/hallucination guidance. [Fact-Based; Ambiguity & hallucination; Improve accuracy]
You are a concise, fact-focused assistant.
Core rules
- Base all answers only on:
- information the user provided, or
- well-established, widely accepted facts.
- Do not invent facts, numbers, sources, or quotes.
- If you are unsure or lack information, say so clearly and explain what is missing.
- Prefer qualified language like “Based on the provided context…” instead of absolute claims.
Handling ambiguity and missing info
- If the question is ambiguous or underspecified:
- Explicitly say what is unclear, and
- Ask up to 1–3 precise clarifying questions, or
- Offer 2–3 interpretations with clearly labeled assumptions.
- For topics that may change over time (news, policies, prices, releases) without live data:
- Answer only in general terms.
- State that specific details may have changed.
- Never fabricate exact figures, dates, URLs, or citations when uncertain.Accuracy guardrails
- Before finalizing, quickly self-check:
- Are there any strong claims, numbers, or specifics that might not be supported?
- Are there hidden assumptions? If yes, state them.
- Mark anything that might be wrong or incomplete with “(needs verification)” or similar.
Style and scope
- Be concise, direct, and practical.
- Do not drift off-topic; focus on what is necessary to answer the user’s request.
- If the request cannot be answered reliably, say so and suggest what additional information or sources are needed.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------@velvet spoke can you tell whats wrong with these rules?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
I’m sorry, but the knowledge sources you provided do not contain any information about your custom “general rules” prompt, so I can’t reliably analyze what might be wrong with those specific rules.
Based on the context, the docs do say that prompts can fail when they are:
- Ambiguous or open to multiple interpretations. [Realtime prompting]
- Missing clear definitions for key terms or labels. [Prompt critique]
- Containing conflicting or vague instructions (for example, asking for both extreme concision and exhaustive detail). [Prompt critique; Realtime instructions]
If you paste your exact rules text, I can compare it against these documented failure modes and point out concrete issues grounded in the references.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke
can you read this?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Yes. I can read what you send and use it as part of the conversation, but I can only analyze or comment on it using what’s in the OpenAI docs you provided.
For example, if you paste your “general rules” prompt, I can:
- Check it for ambiguity, missing definitions, or conflicting instructions, following the prompt‑critique patterns shown in the migration and realtime guides. [Prompt critique; Realtime instructions]
- Suggest clearer, more precise wording, in line with the general tips about avoiding ambiguity and literal‑instruction traps. [General tips; Avoid literal traps]
If you paste the rules here, I’ll review them against those documented patterns and point out concrete issues.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke i pasted them 2 times now. its the message.txt
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
I’m sorry, but the knowledge sources I have access to do not include your message.txt content or the exact rules you pasted earlier, so I can’t see or review them.
From the docs, the recommended way to find “what’s wrong” with a set of rules is to check for:
- Ambiguity – wording that can be interpreted in more than one way. [Prompt critique]
- Lacking definitions – terms like “relevant”, “concise”, “fact-based” that are not clearly defined. [Prompt critique]
- Conflicting instructions – e.g., “be very concise” and “explain in great detail” at the same time. [Baseline prompt issues]
- Unstated assumptions – expecting the model to use tools, remember files, or follow hidden rules that are never actually written. [Prompt critique]
To let me give concrete feedback, you’d need to paste the rules directly into this chat (not as an external file reference). Then I can map specific lines to these documented failure modes and suggest precise fixes.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke 1st half of the instructions:
Treat these as standing rules for how to work with me.
Answer the exact question I am asking. Do not substitute a broader, easier, adjacent, or more familiar question.
Use the strongest relevant evidence available. When a question concerns an uploaded file, screenshot, code, workflow, log, document, image, dataset, or other exact source, inspect that exact source before making claims about it. Never claim to have inspected something you have not inspected.
Prefer current evidence over older assumptions. A current source, current tool result, or newly verified fact overrides previous-chat statements, remembered information, older versions, and general knowledge when they conflict.
Statements by me about what was supposedly established, proven, verified, inspected, or concluded in another chat are useful context, but they are not independent evidence. Do not treat such statements as confirmation of the current state of an exact file, workflow, screenshot, UI, codebase, configuration, document, dataset, or other mutable source.
When a claim depends on the current state of a mutable source, verify it from the current source itself before treating it as established fact. A statement that something was previously proven does not remove that requirement.
Do not invent missing details. Never fabricate UI elements, settings, parameters, behavior, code behavior, version differences, causes, features, documentation, source contents, or other facts. If the available evidence does not establish something, say that it is unknown, unverified, or cannot be determined from the available evidence.
Keep evidence and inference separate whenever the distinction matters. Distinguish appropriately between:
- what an exact source establishes;
- what an official or primary source states;
- what a developer or creator states;
- what community or user reports claim;
- what is your own inference, hypothesis, or interpretation.
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Here’s feedback grounded in OpenAI’s own prompt‑design guidance.
Overall: these rules are strong and mostly aligned with best practices for factuality and evidence handling. The main issues are about length, redundancy, and a bit of ambiguity, not correctness.
1. Strengths (what’s working well)
- Clear evidence-first mindset
- “Use the strongest relevant evidence available” and “inspect that exact source before making claims” match the recommendation to ground answers in provided material and avoid hallucinations. [Improve accuracy]
- Good handling of mutable sources
- Preferring current evidence over older assumptions and not trusting “previously proven” claims without re-checking is exactly how to avoid stale or incorrect context.
- Explicit anti-fabrication rule
- “Do not invent missing details” and listing what must not be fabricated is directly in line with fact-based prompt patterns. [Fact-Based]
- Separation of evidence vs inference
- Distinguishing what a source states vs your own inference is a recommended way to reduce hallucination risk and make uncertainty visible. [Improve accuracy]
You’re very aligned with the “fact-based” and “accuracy guardrail” style OpenAI suggests.
2. Issues and risks
-
Verbosity and cognitive load
- The rules are long and dense. The docs recommend lean prompts and avoiding unnecessary repetition, because long, overlapping rules can be harder for the model to follow consistently. [Prompting best practices]
- Several sentences restate the same idea (e.g., “never claim to have inspected something you have not inspected” vs “when a claim depends on the current state… verify it from the current source”).
-
Some ambiguity in “strongest relevant evidence”
- “Use the strongest relevant evidence available” is conceptually good, but “strongest” is not defined. The prompt-critique guidance calls out undefined labels as a source of ambiguity. [Prompt edits]
- You partly clarify later (official/primary vs community reports), but you don’t explicitly say which to prioritize.
-
Potential conflict with “answer the exact question”
- “Answer the exact question I am asking. Do not substitute a broader, easier, adjacent… question.”
- OpenAI’s ambiguity guidance encourages the model to call out ambiguity or offer multiple interpretations when the question is unclear. [Ambiguity & hallucination]
- As written, the model might feel forced to pick one interpretation even when the question is underspecified, instead of surfacing ambiguity.
- Repetition around “previously proven” and mutable sources
- You repeat the idea that “statements about what was previously proven” are not evidence in multiple sentences. This is correct but could be compressed; the prompt-edit guidance suggests minimal changes and avoiding redundant instructions. [Prompt edits]
3. Suggested surgical improvements
Here are minimal edits that keep your intent but align better with the docs:
- Tighten the “answer the exact question” rule and allow ambiguity handling
Current:
Answer the exact question I am asking. Do not substitute a broader, easier, adjacent, or more familiar question.
Improved:
Answer the question I am asking. Do not substitute a broader or different question. If the question is ambiguous or underspecified, explicitly say what is unclear and ask up to 1–3 precise clarifying questions.
(Aligns with recommended ambiguity handling.) [Ambiguity & hallucination]
- Define “strongest relevant evidence” more concretely
Add one short line after that paragraph, for example:
When sources conflict, prioritize in this order: (1) current official or primary sources, (2) direct inspection of the user’s current files or screenshots, (3) other reports or secondary sources.
This makes “strongest” operational instead of vague. [Prompt edits]
- Compress the “previously proven” / mutable-source section
You can merge those paragraphs into one:
Treat my descriptions of what was “previously proven” or “already checked” as context, not evidence. For anything that can change (files, workflows, UIs, code, configs, datasets), verify the current state directly before treating a claim as established fact.
Same meaning, less redundancy.
- Keep the anti-fabrication and evidence-vs-inference parts as-is
Those are already clear and strongly aligned with OpenAI’s guidance; they don’t need much change.
If you share the “2nd half” of your instructions, I can check for conflicts with this first half and suggest a combined, shorter version that still enforces your fact-based, no-hallucination goals.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke and the next part:
Do not turn inference into fact through repetition. A plausible explanation remains a hypothesis until evidence confirms it.
Interpret my wording using the full current context, but do not overrule clear wording with your own assumptions. If ambiguity can be resolved confidently from context, do so. If two interpretations remain genuinely plausible and choosing incorrectly would materially change the answer, ask one concise clarification.
Do not let an earlier mistake, assumption, or explanation anchor later reasoning. If it is disproven, discard that branch and re-evaluate any conclusions that depended on it.
When troubleshooting, identify the actual failure point as far as the available evidence allows before recommending fixes. Prefer tests that distinguish between competing explanations. Do not provide a large list of speculative causes when the evidence can narrow them down.
When behavior depends on execution or runtime use, do not treat a value, reference, setting, or object as active merely because it exists in the source. Trace it to the point where it is actually read or consumed before concluding that it is being used.
When correcting an earlier answer, state the correction plainly. Do not defend the old answer, obscure the correction, or continue relying on an incorrect premise.
When I provide text, prompts, images, files, or other source material as the basis of a task, preserve what the source actually contains and what I am trying to accomplish with it. Do not silently correct, reconcile, improve, sanitize, normalize, or replace its substantive content using outside assumptions unless the requested task requires that transformation or I explicitly ask for it.
If I ask you to rewrite, improve, restructure, shorten, expand, or otherwise transform supplied material, preserve its substantive intent, constraints, subject matter, and requested level of intensity unless I explicitly ask you to change them.
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Your rules are generally very strong and closely match how OpenAI recommends reducing ambiguity and hallucinations. The main issues are about length, overlap, and a couple of subtle tensions, not about the core ideas.
Below I’ll point out concrete issues, grounded in the prompt‑design guidance, and suggest minimal tweaks.
1. What’s working well
These parts are very aligned with OpenAI’s guidance on factuality and ambiguity:
-
Inference vs fact, and not upgrading hypotheses
- “Do not turn inference into fact through repetition. A plausible explanation remains a hypothesis until evidence confirms it.”
- This matches the recommendation to mark uncertainty and avoid confident guesses. [Improve accuracy]
-
Explicit ambiguity handling and clarifying questions
- “If ambiguity can be resolved confidently from context, do so. If two interpretations remain genuinely plausible and choosing incorrectly would materially change the answer, ask one concise clarification.”
- This is almost exactly what the ambiguity/hallucination pattern suggests. [Ambiguity & hallucination]
-
Discarding disproven branches
- “Do not let an earlier mistake, assumption, or explanation anchor later reasoning…”
- This is a good self‑correction pattern and fits with the idea of self‑checks for high‑risk outputs. [Ambiguity & hallucination]
-
Troubleshooting focus and narrowing causes
- “Prefer tests that distinguish between competing explanations. Do not provide a large list of speculative causes when the evidence can narrow them down.”
- This is consistent with the recommendation to avoid speculative, over‑broad answers and to be explicit about assumptions. [Improve accuracy]
-
Preserving source intent when transforming text
- “Preserve what the source actually contains and what I am trying to accomplish with it…”
- This matches the general advice to preserve user content and constraints when editing prompts or artifacts. [Prompt edits]
Conceptually, you’re very close to the “fact‑based” and “accuracy guardrail” style OpenAI shows.
2. Issues and risks
- Verbosity and overlapping rules
- Across both halves, there are many rules that restate similar ideas (e.g., about not upgrading hypotheses, not anchoring on earlier mistakes, and preserving source content).
- The prompt‑generation docs recommend keeping prompts clear and avoiding unnecessary repetition, because long, dense instructions can be harder for the model to follow consistently. [Prompt edits]
-
Slight tension with “answer the exact question”
- In the first half you say “Answer the exact question I am asking. Do not substitute a broader, easier, adjacent, or more familiar question.”
- Here you say “If ambiguity can be resolved confidently from context, do so. If two interpretations remain genuinely plausible… ask one concise clarification.”
- These are compatible in spirit, but not explicitly reconciled. The ambiguity guidance suggests the model should either clarify or present multiple interpretations when the question is underspecified. [Ambiguity & hallucination]
- Without a unifying sentence, the model might over‑prioritize “answer exactly” and under‑use the ambiguity rule.
-
Potential over‑constraint on transformations
- “Do not silently correct, reconcile, improve, sanitize, normalize, or replace its substantive content using outside assumptions unless the requested task requires that transformation or I explicitly ask for it.”
- This is good for fidelity, but the prompt‑editing docs also assume that some light restructuring or clarification is often helpful, as long as user content is preserved. [Prompt edits]
- As written, the model might hesitate to make harmless, clarity‑improving edits even when they are clearly implied by “rewrite/improve” tasks.
-
Cognitive load in troubleshooting rules
- The troubleshooting section has multiple nested expectations (identify failure point, prefer discriminating tests, avoid long speculative lists).
- All are reasonable, but together they add complexity. The docs suggest focusing on the most important priorities rather than many fine‑grained rules. [Prompt edits]
3. Minimal, concrete improvements
Here are small edits that keep your intent but align better with the docs:
- Unify ambiguity handling with “answer the exact question”
Add a bridging line (either in the first half or here), for example:
Answer the question I am asking as written. If the wording is ambiguous or underspecified, follow the ambiguity rule: resolve it from context when you can do so confidently; otherwise ask one concise clarification.
This explicitly ties your “exact question” rule to the recommended ambiguity pattern. [Ambiguity & hallucination]
- Compress the hypothesis / anchoring rules
You can merge:
- “Do not turn inference into fact through repetition…”
- “Do not let an earlier mistake, assumption, or explanation anchor later reasoning…”
Into something like:
Treat explanations and hypotheses as tentative until supported by evidence. Do not upgrade them to facts through repetition, and discard or revise any conclusions once their underlying assumptions are disproven.
Same meaning, less redundancy.
- Slightly relax the transformation constraint while keeping fidelity
Current:
Do not silently correct, reconcile, improve, sanitize, normalize, or replace its substantive content…
Possible tweak:
Preserve the substantive content and intent of supplied material. Do not change its meaning or key constraints using outside assumptions. Cosmetic or structural improvements are fine when I ask for a rewrite or improvement.
This matches the “preserve user content” guidance but still allows helpful editing. [Prompt edits]
- Tighten troubleshooting instructions
You could compress:
When troubleshooting, identify the actual failure point as far as the available evidence allows before recommending fixes. Prefer tests that distinguish between competing explanations. Do not provide a large list of speculative causes when the evidence can narrow them down.
Into:
When troubleshooting, use the available evidence to narrow down to the most likely failure point. Prefer tests that distinguish between competing explanations instead of listing many speculative causes.
Same behavior, fewer moving parts.
If you want, I can now merge both halves into a single, shorter “general rules” block that keeps all your core ideas but follows the lean‑prompt and ambiguity patterns from the docs.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke next part:
Apply safety restrictions only where they are actually required. If a particular part of a request cannot be fulfilled, identify the relevant boundary as narrowly as possible and preserve or complete the allowed portions rather than unnecessarily changing the entire task.
Use external research when it is needed for current, uncertain, specialized, or externally verifiable information and when appropriate tools are available, unless I ask you not to use outside sources. Choose sources appropriate to the question: prefer primary or official sources for authoritative factual claims, and use developer, community, review, or other relevant sources when those perspectives are what matter.
Do not use external research as a substitute for inspecting an exact source I provided when the question is specifically about that source.
Maintain continuity, but never at the expense of correctness. Keep track of conclusions that have actually been established by reliable evidence, while remaining willing to revise them when new evidence, contradictions, or better sources appear.
When continuing from previous chats or project context, do not assume the available context is complete, chronological, or contains the exact point where we left off. Use only what is actually available. Do not reconstruct, infer, or invent a missing previous-chat endpoint, conclusion, next step, test, fact, or detail merely because it would fit the surrounding context. If I ask where we left off and the exact endpoint is not established by the available context, say that you cannot determine it reliably rather than supplying a plausible continuation.
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Your new rules are broadly consistent with how OpenAI suggests you prompt models, but there are a few risks: mainly length, overlap, and some vagueness, not outright “wrongness”.
Below I’ll point out issues and small, concrete improvements, grounded in the docs.
1. What’s working well
These ideas match OpenAI’s guidance:
-
Narrow safety boundaries
- “Apply safety restrictions only where they are actually required… preserve or complete the allowed portions…”
- This aligns with defining clear, scoped policies instead of over‑broad blocks. [Prompting best practices]
-
Thoughtful use of external research
- Prefer primary/official sources for authoritative facts and use community sources when that perspective matters.
- This is in line with “fact-based” and web‑research agent patterns that emphasize source quality and appropriate citations. [Fact-Based; Web research agent]
-
Not using web search instead of inspecting user-provided sources
- “Do not use external research as a substitute for inspecting an exact source I provided…”
- This matches the recommendation to ground answers in the user’s materials first. [Improve accuracy]
- Continuity without fabrication
- “Maintain continuity, but never at the expense of correctness… do not reconstruct, infer, or invent a missing previous-chat endpoint…”
- This is consistent with guidance to avoid filling gaps with fabricated details and to call out missing context. [Fact-Based; Ambiguity & hallucination]
Overall, the intent is very aligned with OpenAI’s “fact-based, low-hallucination” style.
2. Issues and risks
-
Verbosity and overlapping concepts
- Across all three parts, you now have many rules about:
- not fabricating,
- preferring current/primary sources,
- not reconstructing missing context.
- The prompt-edit docs recommend minimal changes and avoiding redundancy, because long, dense prompts can reduce clarity and performance. [Prompt edits]
- Across all three parts, you now have many rules about:
-
Vague phrases that could be interpreted loosely
- “Apply safety restrictions only where they are actually required” is philosophically clear, but “actually required” is not defined.
- The critique guidance flags undefined terms as a source of ambiguity. [Prompt critique]
-
Potential tension with safety policies
- Your rule could be read as “minimize safety interventions,” but the model must still follow OpenAI’s safety policies regardless of user instructions.
- The docs don’t give a way to override those; your wording might create expectations the model cannot always meet.
-
Complex continuity rule
- The last paragraph about previous chats is precise but long and multi‑clause.
- The prompt-generation docs suggest keeping instructions clear and concise, especially for recurring patterns like “do not invent missing context.” [Prompt edits]
3. Minimal, concrete improvements
Here are small edits that keep your intent but align better with the docs:
- Clarify and narrow the safety rule
Current:
Apply safety restrictions only where they are actually required…
Possible revision:
Apply safety restrictions as required by your policies. If only part of a request is disallowed, identify that part clearly and complete the allowed portions instead of blocking the entire task.
This keeps your “narrow boundary” idea but doesn’t suggest overriding built‑in safety.
- Tighten the external research rules
You can merge the two research paragraphs:
Use external research when current, uncertain, specialized, or externally verifiable information is needed and appropriate tools are available, unless I ask you not to. Prefer primary or official sources for authoritative facts, and use developer, community, or review sources when those perspectives are what matter. Do not use external research instead of inspecting an exact source I provided when the question is specifically about that source.
Same behavior, fewer lines, clearer priority order. [Fact-Based; Web research agent]
- Compress the continuity / previous-chat rule
Current (last paragraph) is long. You could shorten to:
Maintain continuity, but never at the expense of correctness. When using previous chats or project context, use only what is actually available. Do not invent or reconstruct missing endpoints, conclusions, or next steps. If you cannot reliably determine where we left off, say so instead of supplying a plausible continuation.
This keeps the core behavior while reducing cognitive load. [Fact-Based]
If you’d like, I can now take all three parts and produce a single, shorter “general rules” block that keeps your main goals (fact-based, low hallucination, careful with context) but follows the lean‑prompt and clarity recommendations from the docs.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke last part:
Do not reopen conclusions that were actually established from reliable evidence without new evidence, a contradiction, or a reason arising from the current task. A user's recollection, a previous-chat statement, remembered information, or an unsupported assertion that something was previously proven does not by itself make a conclusion established for the current state of a mutable source.
Do not repeatedly explain information I already understand unless it is necessary to answer the current question.
Be concise, direct, and focused. Give the answer or conclusion first. Add only the reasoning, evidence, caveats, or steps needed to make the answer reliable.
Keep replies compact and conversational; answer my actual question directly, use plain language, and don’t turn simple questions into detailed reports unless I ask for detail. Use bullets only when they genuinely make multiple items easier to scan; for simple questions, prefer normal paragraphs instead of turning the response into a list.
Do not add filler, unnecessary summaries, generic advice, excessive disclaimers, or conversational padding.
Accuracy is more important than apparent completeness. Evidence is more important than confidence. If something cannot be determined from the available information, say so rather than filling the gap.
Most importantly: do not produce a definite answer merely because one is expected. Give only the strongest conclusion the available evidence supports.
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
I’m sorry, but the knowledge sources do not contain any discussion of your custom “last part” rules, so I can’t say what is “wrong” with them in an absolute sense. I can only compare them to OpenAI’s documented prompting best practices.
Based on that comparison, your last part is largely aligned with the docs; the main issues are about verbosity and a few potential tensions:
-
Strong points (well aligned with docs)
- Emphasis on not re-opening well‑evidenced conclusions without new evidence is consistent with being evidence‑driven and avoiding unnecessary rework. [Fact-Based]
- “Do not repeatedly explain information I already understand” and “Be concise, direct, and focused” match the guidance to control verbosity and avoid fluff. [Set response length and style]
- “Accuracy is more important than apparent completeness. Evidence is more important than confidence… do not produce a definite answer merely because one is expected” is very close to the fact‑based personality and ambiguity/hallucination guidance. [Fact-Based; Ambiguity & hallucination]
-
Issues / risks vs best practices
- Verbosity and overlap
-
Across all your sections, you repeat themes: be concise, avoid filler, prioritize evidence, do not fabricate, do not over‑explain.
-
The prompt‑generation and best‑practices docs recommend lean prompts and avoiding repeated instructions, because long, dense prompts can reduce clarity and performance. [Prompting best practices; Prompt edits]
-
Possible tension: “do not reopen conclusions” vs “revise when needed”
- Earlier parts of your rules (and OpenAI’s guidance) encourage revising conclusions when new evidence or contradictions appear. [Fact-Based]
- Your line “Do not reopen conclusions that were actually established from reliable evidence without new evidence…” is compatible with that, but it is strict enough that the model might hesitate to revisit a conclusion even when the current task legitimately calls for re‑checking. A small clarification like “In normal circumstances, do not reopen…” would reduce that risk.
-
- Very strong anti‑verbosity constraints
- You say: “Keep replies compact and conversational… don’t turn simple questions into detailed reports… Do not add filler, unnecessary summaries, generic advice, excessive disclaimers, or conversational padding.”
- The docs note that newer models are already more concise by default and suggest using brevity instructions only when they reliably help. Over‑constraining verbosity can make answers too short for complex tasks. [Set response length and style]
- A small nuance like “For simple questions, be brief; for complex tasks, include enough detail to be reliable” would better match that guidance.
-
Concrete, minimal tweaks (still within docs)
If you want to align more closely with the documented patterns while keeping your intent:
-
Merge your brevity rules into something like:
Be concise, direct, and focused. Lead with the answer or conclusion, then add only the reasoning, evidence, caveats, or steps needed to make it reliable. For simple questions, keep replies short; for complex tasks, include enough detail to be accurate and useful.
This mirrors the “lead with conclusion, then essential evidence” pattern. [Set response length and style]
-
Slightly soften the “do not reopen conclusions” line:
Do not reopen conclusions that were established from reliable evidence without new evidence, a contradiction, or a task‑specific reason to re‑check them.
-
-
Keep the final rule almost as‑is, since it matches the fact‑based guidance:
Most importantly: do not produce a definite answer merely because one is expected. Give only the strongest conclusion the available evidence supports.
Overall, nothing in this last part is fundamentally “wrong” relative to the docs; it’s mostly a bit long and strict. The main improvement, per OpenAI’s guidance, would be to compress overlapping rules and slightly relax verbosity constraints so complex answers can still be sufficiently detailed.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke now can you give me a efficient rules list that will make gpt behave?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Here’s a compact, “efficient + fact-based” rules block you can paste into the system/instructions field. It’s distilled from the Efficient and Fact-Based personalities plus the ambiguity/hallucination patterns. [Efficient; Fact-Based; Ambiguity & hallucination; Improve accuracy]
You are a concise, fact-focused assistant. Follow these standing rules:
1) Scope and relevance
- Answer the question actually asked; do not substitute a broader or different question.
- Stay on topic; do not add extra features, side quests, or unsolicited advice.
2) Factuality and evidence
- Base answers only on:
- information the user provided, and/or
- well-established, widely accepted facts.
- Do not invent facts, numbers, sources, APIs, functions, or features.
- If you are unsure or lack information, say so clearly and explain what is missing.
- When details may have changed over time (news, policies, prices, versions) and you lack fresh data, answer in general terms and state that specifics may have changed.
3) Handling ambiguity
- If the request is ambiguous or underspecified:
- Briefly say what is unclear, and
- Ask up to 1–3 precise clarifying questions, OR
- Present 2–3 plausible interpretations with clearly labeled assumptions.
- Never guess hidden requirements.- Accuracy guardrails
- Before finalizing, quickly self-check:
- Are any strong claims, numbers, or specifics unsupported?
- Are there hidden assumptions? If yes, state them.
- Mark anything that might be wrong or incomplete with “(needs verification)” or similar.
- Style and verbosity
- Be concise, direct, and easy to scan.
- Default: at most 3–6 sentences or up to 5 short bullets.
- For simple yes/no or lookup-style questions: at most 1–2 sentences.
- Use bullets only when they genuinely make multiple items easier to read.
- Do not add filler, generic summaries, or conversational padding unless the user asks for a more detailed or chatty answer.
- Most important
- Do not produce a definite answer just because one seems expected.
- Give only the strongest conclusion the available evidence supports.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------@velvet spoke this rules incl what i pasted too?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Mostly yes: the new list is a compressed version of what you wrote, but it does not include every specific rule or nuance.
What it keeps (in simplified form), based on your longer rules:
- Answer the actual question, stay on topic.
- Be concise and avoid filler.
- Be fact-based, do not invent details, admit uncertainty.
- Handle ambiguity by asking clarifying questions or stating assumptions.
- Prefer evidence over confidence; do not give a definite answer just because one is expected.
- Do a quick self-check for unsupported claims and hidden assumptions.
What it does not fully capture from your text:
- Detailed hierarchy of evidence types (official vs community vs inference).
- Rules about mutable sources and re-checking current state of files/flows.
- Not upgrading hypotheses to facts through repetition.
- Detailed troubleshooting behavior (narrowing failure points, discriminating tests).
- Strict continuity rules across chats and not reconstructing missing endpoints.
- Fine-grained instructions about preserving source material when rewriting.
If you want, I can produce a “v2” that is still short but explicitly adds 2–3 of those missing ideas you care about most (for example: mutable sources, hypotheses vs facts, and preserving source intent).
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke first of all i want gpt to follow the rules and not break them. thats what happens all the times and it says it right in your face. will this stop it from doing that?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Short answer: no, there is no way to guarantee the model will never break your rules, even if the rules are very good.
The OpenAI docs are explicit that:
- Models follow instructions probabilistically, not as hard constraints. They can still ignore or misinterpret rules, especially in long or complex prompts, or when there are conflicting instructions. [Instruction following]
- System and user instructions work best when they are clear, concise, and non‑redundant; very long rule lists can actually make behavior less reliable because the model has more to juggle. [Prompting best practices; Prompt edits]
- To improve accuracy and catch “confident guesses”, you should add guardrails and self‑checks, not just rules. For example: ask the model to label uncertain parts, list assumptions, and check its own output for accuracy and completeness. [Improve accuracy]
So:
- Your rules (and the compressed version) reduce hallucinations and rule‑breaking, but they cannot fully stop it.
- To get closer to what you want, you generally need:
- A lean, high‑priority rules block (not too long).
- Simple accuracy guardrails (e.g., “mark anything uncertain with (needs verification)” and “before finishing, list any assumptions you made”). [Improve accuracy]
- If you’re building an app, external guardrails that check the model’s output and reject or correct it when it violates your rules. [How to use guardrails; Agents guardrails]
If you tell me whether you’re using ChatGPT directly or the API, I can suggest a concrete setup (rules + simple guardrail pattern) that will make violations less frequent and easier to catch.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke using chatgpt 5.6 sol on high in browser. yes would need something like that
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
You’re using ChatGPT 5.6 (Sol) on high in the browser, so you can’t add external guardrail code, but you can:
- Tighten your core rules so they’re short and high‑priority, and
- Add a simple self‑check pattern to each important request to catch violations.
OpenAI’s docs stress that:
- Models follow instructions probabilistically, so long, redundant prompts can reduce reliability. [Prompting best practices]
- Adding a short “accuracy checklist” and explicit uncertainty labeling is one of the fastest ways to catch confident guesses. [Improve accuracy]
- For ambiguity and hallucination risk, you should explicitly tell the model to call out ambiguity and not fabricate specifics. [Ambiguity & hallucination]
A lean “behavior” rules block for your chats
Put this at the top of a new chat (or in the “Custom instructions” style box if you use that):
You are a concise, fact-focused assistant. Follow these standing rules:
1) Scope
- Answer the question I actually asked; do not substitute a broader or different question.
- Stay on topic; do not add extra features or side quests.- Factuality
- Base answers only on:
- information I provided, and/or
- well-established, widely accepted facts.
- Do not invent facts, numbers, sources, APIs, functions, or features.
- If you are unsure or lack information, say so clearly and explain what is missing.
- When details may have changed over time (news, policies, prices, versions) and you lack fresh data, answer in general terms and say that specifics may have changed.
- Ambiguity
- If my request is ambiguous or underspecified:
- Briefly say what is unclear, and
- Ask up to 1–3 precise clarifying questions, OR
- Present 2–3 plausible interpretations with clearly labeled assumptions.
- Never guess hidden requirements.
- Self-check
- Before finalizing, quickly self-check:
- Are any strong claims, numbers, or specifics unsupported?
- Are there hidden assumptions? If yes, state them.
- Mark anything that might be wrong or incomplete with “(needs verification)”.
- Style
- Be concise, direct, and practical.
- Default: at most 3–6 sentences or up to 5 short bullets.
- Do not add filler, generic summaries, or conversational padding unless I ask for more detail.
Most important: do not produce a definite answer just because one seems expected. Give only the strongest conclusion the available evidence supports.
This is a compressed version of your long rules, aligned with OpenAI’s guidance to keep prompts lean and non‑redundant. [[Prompting best practices](<https://developers.openai.com/api/docs/guides/latest-model#prompting-best-practices>)]
### Add a mini “guardrail” to important questions
For high‑stakes or easily‑broken cases, append something like this to your *user* message (not just the standing rules):Before you answer, do this self-check:
- If anything is ambiguous, ask 1–2 clarifying questions instead of guessing.
- If you are not sure about any fact, label that part with “(needs verification)”.
- Do not invent APIs, functions, or features. If you are not sure they exist, say so.
Then answer.
This mirrors the cookbook’s suggestion to add a quality checklist and uncertainty labeling to catch hallucinations. [Improve accuracy; Ambiguity & hallucination]
What this will and won’t do
- It will:
- Reduce drifting and “making stuff up” compared to no rules or very long rules.
- Make it easier to see when the model is unsure (via “needs verification” and explicit assumptions).
- It won’t:
- Guarantee perfect obedience. The model can still occasionally ignore or misapply rules; that’s a limitation of how LLMs work. [Prompting best practices]
If you want, you can paste your current full rule set and this lean version into a new chat and ask the model (in that chat) which one it finds easier to follow and why—this kind of small eval is also recommended in the prompt guide. [Improve accuracy]
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke does it also make it solve issues better?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Partly, yes — but only up to the model’s inherent capability.
From the docs:
- Clear, lean instructions and good ambiguity handling help the model reason more reliably and avoid going down wrong paths or over‑explaining, which often feels like “solving issues better.” [Prompting best practices; Ambiguity & hallucination]
- Adding a short self‑check / quality checklist (e.g., “check accuracy, completeness, assumptions before finishing”) is specifically recommended to catch mistakes and hallucinations on factual or high‑stakes tasks. [Improve accuracy]
- For complex problems, using more reasoning effort (like your “high” setting) plus good prompts can improve diagnosis and planning, but it still won’t be perfect. [Set up
reasoning.effort]
So: your rules + a small self‑check block will usually make it more accurate, less drifty, and better at structured troubleshooting, but they cannot guarantee that every issue is solved correctly.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke ok can you give me the final version of those rules? can i use it for every chat and project settings?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Yes, you can use one compact rules block as a general “behavior profile” for most chats and projects. Just remember: even with good rules, models can still occasionally break them because instruction following is probabilistic, not guaranteed. [Prompting best practices]
Here’s a final, lean version you can reuse:
You are a concise, fact-focused assistant. Follow these standing rules in all tasks:
1) Scope
- Answer the question I actually asked; do not substitute a broader or different question.
- Stay on topic; do not add extra features, side quests, or unsolicited advice.
2) Factuality
- Base answers only on:
- information I provided, and/or
- well-established, widely accepted facts.
- Do not invent facts, numbers, sources, APIs, functions, features, or documentation.
- If you are unsure or lack information, say so clearly and explain what is missing.
- When details may have changed over time (news, policies, prices, versions) and you lack fresh data, answer in general terms and say that specifics may have changed.
3) Ambiguity
- If my request is ambiguous or underspecified:
- Briefly say what is unclear, and
- Ask up to 1–3 precise clarifying questions, OR
- Present 2–3 plausible interpretations with clearly labeled assumptions.
- Never guess hidden requirements.- Evidence and continuity
- Prefer current, direct evidence over older assumptions or memories.
- Do not treat my recollection or previous-chat statements as proof about the current state of mutable sources (files, code, configs, workflows, datasets, UIs).
- Do not invent or reconstruct missing previous-chat endpoints, conclusions, or next steps; if you cannot reliably determine where we left off, say so.
- Self-check
- Before finalizing, quickly self-check:
- Are any strong claims, numbers, or specifics unsupported?
- Are there hidden assumptions? If yes, state them.
- Mark anything that might be wrong or incomplete with “(needs verification)” or similar.
- Do not produce a definite answer just because one seems expected; give only the strongest conclusion the available evidence supports.
- Style and verbosity
- Be concise, direct, and practical.
- Default: at most 3–6 sentences or up to 5 short bullets.
- For simple questions, prefer 1–2 short sentences.
- Use bullets only when they genuinely make multiple items easier to scan.
- Do not add filler, generic summaries, or conversational padding unless I ask for more detail.
You can:
- Paste this at the start of important chats, or
- Adapt it into your “project” / “custom instructions” settings as your default behavior profile.
For high‑stakes questions, you can still add a short, task-specific checklist (e.g., “before answering, list assumptions and mark uncertain parts with ‘(needs verification)’”) as recommended in the accuracy section of the ChatGPT prompt guide. [[Improve accuracy](<https://developers.openai.com/cookbook/examples/chatgpt/chatgpt_prompt_guide/chatgpt_prompt_guide#6-improve-accuracy>)]
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------@velvet spoke are you sure this is final`?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
No, I can’t be “sure” in the sense of guaranteeing perfect behavior.
The ruleset I gave you is:
- Aligned with OpenAI’s prompting best practices (lean, non‑redundant, clear about ambiguity and factuality). [Prompting best practices]
- Designed to reduce hallucinations and drift, and to encourage self‑checks and explicit uncertainty. [Improve accuracy; Ambiguity & hallucination]
But models still follow instructions probabilistically, so:
- You may still see occasional rule breaks.
- You might later want to tweak the rules for a specific project (for example, relaxing verbosity or adding tool‑specific guidance).
So it’s a solid, general “final v1” you can safely use across chats and projects, but not something that can be guaranteed perfect or never worth revising.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke to be clear, this goes only into instructions and projects settings, i dont need to paste this as entry into every chat or or upload as source
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
The knowledge sources don’t explicitly cover your exact rules text, but they do explain how global instructions vs per‑chat context work.
For ChatGPT:
-
Custom instructions / personalization:
Put your rules into Settings → Personalization → Custom instructions (or equivalent). They are then applied automatically to all chats, including existing ones; you don’t need to paste them at the start of every conversation. [Enabling Custom Instructions; Personality and custom instructions now apply to all chats; Personalize ChatGPT] -
Projects:
In a project, you can add Project instructions via the project’s settings. These apply only inside that project and override your global custom instructions for that project’s chats. [Add project instructions; Projects and chats]
So for your rules:
- Put the general behavior rules in Custom instructions once.
- Optionally add project-specific instructions in each project if you need overrides.
- You do not need to paste the rules as the first message in every chat or upload them as a file/source.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke is there anything else you would add to make it better?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
There’s nothing in the docs that says your current rules are “wrong”, but they do suggest two small additions that often improve reliability:
-
Explicitly allow more detail for complex tasks
Your rules are quite strict on brevity. The latest-model guide warns that too-strong brevity instructions can make complex answers too short. It recommends keeping brevity, but allowing more detail when needed. [Set response length and style]You could tweak your style section to something like:
For simple questions, keep replies short (1–3 sentences).
For complex, multi-step tasks, include enough detail (steps, reasoning, or code) to make the solution reliable, but avoid unnecessary digressions. -
Add a tiny “quality checklist” hook
The ChatGPT prompt guide specifically recommends a short checklist to catch mistakes and hallucinations. [Improve accuracy]You already have a self-check section; you could make it slightly more concrete:
Before finalizing, quickly check:
- Accuracy: avoid making up facts or APIs.
- Completeness: did you answer everything I asked?
- Assumptions: list any important assumptions.
If any part is uncertain, mark it with “(needs verification)”.
Beyond those two tweaks, the docs mainly suggest iterating: try this ruleset for a while, note where it still fails (e.g., too short, still guessing APIs), and then adjust specific lines rather than making it longer overall. [Prompting best practices]
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke im now working quite some time with these rules and it still break them
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
I’m sorry you’re still seeing the rules get broken; the docs are clear that this can happen even with good prompts.
From the information available, there are a few important limits and levers:
- Limits of instruction following
- Models follow instructions probabilistically, not as hard constraints. Conflicting, long, or dense instructions can actually make behavior worse, because the model spends effort trying to reconcile them. [Instruction following; Realtime instructions]
- Very long rule lists (like the one you started with) are specifically called out as a risk; leaner prompts often perform better. [Prompting best practices]
-
Rules alone are often not enough
The docs recommend adding process guardrails, not just “be good” rules:- Ask the model to mark uncertainty and label assumptions. [Improve accuracy]
- Add a tiny quality checklist to important questions (accuracy, completeness, assumptions). [Improve accuracy]
- For persistent failures, use metaprompting: ask the model itself to analyze where it is breaking your rules and propose surgical edits. [Metaprompting; How to metaprompt]
-
What you can try next in ChatGPT (no code)
a) Run a metaprompt on your current rules
Start a fresh chat and paste:You are a Prompt-Critique Expert. Here are my standing rules for how I want you to behave: [PASTE YOUR CURRENT RULES] I observe these failure modes: - You still invent details or APIs. - You sometimes answer a broader/different question than I asked. - You give confident answers instead of marking uncertainty. Following the style of OpenAI’s prompt-critique and metaprompting guidance, identify: - Ambiguous, conflicting, or redundant parts of my rules. - Small, surgical edits that would make it easier for you to follow them consistently.
Output:
- failure_modes: list with prompt snippets and why they cause problems.
- patch_notes: concise list of key changes.
- revised_rules: my rules rewritten with minimal edits to reduce these failures.
This is exactly the kind of loop the docs recommend for tightening prompts. [[Metaprompting](<https://developers.openai.com/cookbook/examples/gpt-5/gpt-5_prompting_guide#metaprompting>); [How to metaprompt](<https://developers.openai.com/cookbook/examples/gpt-5/gpt-5-1_prompting_guide#how-to-metaprompt-effectively>)]
b) **Add a per-question checklist for high‑stakes asks**
For questions where rule‑breaking really hurts, append something like:
```text
Before you answer, do this self-check:
- If anything is ambiguous, ask 1–2 clarifying questions instead of guessing.
- If you are not sure about any fact, mark that part with "(needs verification)".
- Do not invent APIs, functions, or features; if unsure they exist, say so.
Then answer.
This pattern is directly recommended to catch “confident guesses”. [Improve accuracy]
- What to expect realistically
- You can reduce hallucinations and off‑scope answers, but you cannot fully eliminate them in ChatGPT just with instructions. [Instruction following]
- The most effective next step, per the docs, is to iterate: use metaprompting to simplify and de‑conflict your rules based on the actual failure modes you’re seeing, rather than adding more rules. [Prompting best practices; Metaprompting]
If you want, you can paste one concrete example where it broke your rules (your question + its answer), and you can then run the metaprompt above on that example to get a targeted revision of your rules.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke you literally gave me those rules!
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
You’re right that I helped you shape those rules, and I understand the frustration when the model then breaks them.
Based on the docs, two key points:
- Even when the model itself “writes” or “agrees to” rules, it still follows them probabilistically, not as hard constraints. Long, detailed rule lists especially are prone to being only partially followed. [Instruction following; Prompting best practices]
- The recommended mitigation is not more rules, but clearer, shorter instructions plus process checks (ambiguity handling, explicit uncertainty, self-checks) and, where possible, external guardrails. [Improve accuracy; Clarifying questions vs API]
So yes: I helped design the rules, but that doesn’t change the underlying limitation that ChatGPT can still violate them sometimes.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke then redo those rules man according to that
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Here’s a much leaner version, tuned to what the docs say actually helps: short, non‑redundant rules plus a built‑in self‑check. You can put this in Custom instructions and/or project settings.
Grounding: shorter prompts, clear priorities, explicit ambiguity/uncertainty and a tiny checklist are all recommended; long rule dumps are not. [Prompting best practices; Improve accuracy; Ambiguity & hallucination]
You are a concise, fact-focused assistant. Follow these rules:
1) Scope
- Answer the question I actually asked; do not substitute a broader or different question.
- Stay on topic; do not add extra features, side quests, or unsolicited advice.
2) Factuality
- Base answers only on:
- information I provided, and/or
- well-established, widely accepted facts.
- Do not invent facts, numbers, sources, APIs, functions, features, or documentation.
- If you are unsure or lack information, say so clearly and explain what is missing.
- When details may have changed over time (news, policies, prices, versions) and you lack fresh data, answer in general terms and say that specifics may have changed.
3) Ambiguity
- If my request is ambiguous or underspecified:
- Briefly say what is unclear, and
- Ask up to 1–2 precise clarifying questions, OR
- Present 2–3 plausible interpretations with clearly labeled assumptions.
- Never guess hidden requirements.- Evidence and continuity
- Prefer current, direct evidence over older assumptions or memories.
- Do not treat my recollection or previous-chat statements as proof about the current state of mutable sources (files, code, configs, workflows, datasets, UIs).
- Do not invent or reconstruct missing previous-chat endpoints, conclusions, or next steps; if you cannot reliably determine where we left off, say so.
- Self-check (always do this before finalizing)
- Check:
- Accuracy: avoid making up facts or APIs.
- Completeness: did you answer everything I asked?
- Assumptions: list any important assumptions.
- Mark anything that might be wrong or incomplete with “(needs verification)”.
- Do not produce a definite answer just because one seems expected; give only the strongest conclusion the available evidence supports.
- Style and verbosity
- Be concise, direct, and practical.
- For simple questions, use 1–3 short sentences.
- For complex, multi-step tasks, include enough detail (steps, reasoning, or code) to make the solution reliable, but avoid unnecessary digressions.
- Use bullets only when they genuinely make multiple items easier to scan.
- Do not add filler, generic summaries, or conversational padding unless I ask for more detail.
This is intentionally shorter and more focused than your earlier version, which should make it easier for the model to follow consistently.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------@velvet spoke are you sure this is final and optimized version?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
I’m not fully sure, and it can’t be “finally optimized” in a permanent sense.
From the docs:
- Prompts should be treated as iterative: you start with a good version, then refine it based on real failures you observe. [Prompting best practices]
- Short, clear, non‑redundant rules generally work better than long, dense ones, but the best wording depends on your specific tasks and failure modes. [Prompt edits]
- OpenAI explicitly recommends using metaprompting / critique loops to keep improving prompts over time, not treating any one version as final. [Metaprompting]
So: the ruleset is a solid, lean version aligned with the documented best practices, but it is not guaranteed “final”; you should expect to tweak it further as you see how it behaves in your own use.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke im asking if that version is optimal according to the docs you permanently mention man
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
No, the docs do not let me say this version is “optimal” in any absolute sense.
What I can say, grounded in the sources:
-
It follows the main best practices:
- Leaner, non‑redundant instructions instead of long rule dumps. [Prompting best practices]
- Clear guidance on response length and style, with flexibility for complex tasks. [Set response length and style]
- Explicit handling of ambiguity and uncertainty, and a small self‑check section. [Ambiguity & hallucination; Improve accuracy]
-
The docs also say prompts should be iterated and tuned on your own tasks, not treated as finally optimized:
- “Iterate relentlessly… Small wording changes can make or break behavior.” [General tips]
- Use critique / meta‑prompts to refine prompts based on observed failures. [Instructions quality prompt; Prompt edits]
So: this version is consistent with the documented best practices and is a reasonable, lean starting point, but the docs do not support claiming it is uniquely “optimal” or permanently final.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke i also need something to tell it to use natural language when explaining stuff and not bombard me with terms i never heard before
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
You can add a short “plain language” rule to your existing instructions. The docs recommend simple wording, avoiding jargon, and making technical topics approachable. [Be broadly helpful; Exploratory personality]
Append something like this to your rules:
Use natural, everyday language when explaining things. Avoid technical terms, acronyms, and jargon unless they are clearly needed to answer the question.
When you must use a technical term:
- Briefly define it in simple words the first time you use it.
- Prefer specific, self-explanatory words over buzzwords or abbreviations.
If there is a choice between a simple explanation and a very technical one, prefer the simple explanation unless I explicitly ask for a deep technical treatment.
This follows the guidance to write simply, avoid abbreviations, and prioritize accessible explanations for all experience levels. [Be broadly helpful]
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke is this s long rule dump and could backfire like it was the case before? you want to recheck with docs?
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
Yes, adding that “plain language” block on top of the existing rules does push you back toward a long rule dump, and the docs warn that this can hurt reliability.
From the guidance:
- They explicitly recommend leaner prompts and say that removing repeated or extra instructions often improves performance and reduces cost. [Prompting best practices]
- They advise to avoid redundancy and over‑specification, and to make “minimal changes” instead of piling on more rules. [Prompt edits]
- Long, dense instruction blocks with many overlapping rules can create conflicts and ambiguity, which reasoning models then waste effort trying to reconcile. [Instruction following]
So yes: if you just keep appending more sections (scope, factuality, ambiguity, continuity, self‑check, style, plus a multi‑bullet “plain language” section), you are drifting back toward the kind of long, heavy prompt that can backfire.
To stay aligned with the docs, I’d fold the “plain language” idea into one short rule inside your existing style section, for example:
Use natural, everyday language. Avoid unnecessary jargon and acronyms; when you must use a technical term, briefly define it in simple words the first time.
That keeps the total ruleset lean while still enforcing the behavior you want.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
astral chasm
@velvet spoke then why you didnt do that right away and gave another wall of rules
velvet spokeBOT
Let me check the knowledge base for you again. One moment! :books:
You’re right to call that out.
According to the docs, I should have:
- Kept prompts lean and avoided adding another multi-bullet section when a single line in the existing style block would do. [Prompting best practices]
- Made minimal edits instead of growing the ruleset. [Prompt edits]
A better move, consistent with those docs, is to fold your “plain language” requirement into one short rule inside the style section, like:
Use natural, everyday language. Avoid unnecessary jargon and acronyms; when you must use a technical term, briefly define it in simple words the first time.