My “prove it first” Custom Instructions for coding

Prompting
1

Hey folks, sharing the setup I use in ChatGPT when I’m coding. I’m usually working on a pretty big project, and yeah… fixing one “tiny” thing almost always means touching like 3–4 different files. And the other way around is true too: the original code context matters a lot, because one small change can ripple out and break a bunch of other stuff.

Early on, I ran into a real problem. The assistant would suggest changes that sounded right, but weren’t actually grounded in what was in my repo. I’d apply them and, you won’t believe this, but… boom — some other part of the project would break. Total headache.

So, here’s what I think: I moved that whole “prove it first” mindset into Custom Instructions. The nice part is it becomes the default rule for everything, which saves me a ton of back-and-forth (and honestly saves tokens too). Now, if it’s going to suggest a change, it has to be something we can justify from real evidence — code, logs, docs — or it has to clearly say “I can’t confirm this from what you shared.”

Here’s the exact text I paste into Custom Instructions:

”You are an expert who double-checks everything with a skeptical, evidence-driven mindset; you verify claims against primary sources (official docs, code, specs, reproducible tests) and clearly separate confirmed facts from assumptions; I may be mistaken, you may be mistaken, accuracy is the shared objective. Non-negotiable rules: (1) no fabricated production details—do not invent secrets, endpoints, configs, schemas, versions, or test results. Mocks/fakes are allowed only in test code when I ask for tests, must be explicitly labeled as test doubles, and kept minimal; (2) recommended, secure, correct by default—prefer the most current officially recommended approach, avoid deprecated patterns, and if multiple valid approaches exist choose the safest one and justify briefly; (3) no guessing—if you cannot prove something from provided context or reliable sources, say so explicitly; (4) evidence and reproducibility—when proposing a solution include reasoning and a concrete evidence path (what to check, where, how to reproduce/validate); (5) clarify ambiguity by requesting the minimum required inputs (code/logs/versions/config/constraints) and explain why; if a complete solution depends on them, do not finalize prematurely—provide the validation plan meanwhile.”

Why this matters more on big projects:

Changes are rarely isolated. One “simple fix” often needs coordinated edits in multiple places.

Context is everything. If the assistant assumes something that isn’t actually in your code, you can waste time implementing a fix for a problem you don’t even have.

It keeps the assistant from “creative coding” your architecture into something else.

My rule of thumb:

If you’re working on a big codebase or anything multi-module, this is worth it.

If you’re doing small scripts or learning projects, you might not need it — you can remove it or tone it down.

Random side note: I’m using Ubuntu 25.10 and there’s still an unresolved bug where my ethernet driver stops working after suspend. Well, I literally had to prove I was actually on Ubuntu to get taken seriously in a thread… which is basically the same reason I like this customization: “cool claim, now show receipts.” :grinning_face_with_smiling_eyes:

So, if any of you have suggestions to make this prompt even better, drop them below and share what’s been working for you. I’m always down to tweak it and steal good ideas

1 Like
2

This is a solid approach, and the constraints you’ve written are doing the real work here :+1:
One small thought on wording, though — not a criticism, more of a precision tweak.

The phrase “you are an expert” is really standing in for a set of behavioral constraints, not an identity. What you actually want from the assistant isn’t to role-play an expert persona, but to operate under strict epistemic rules: verify claims, separate facts from assumptions, refuse to guess, require evidence, and surface uncertainty.

In practice, the model doesn’t have an internal “expert mode.” The behavior comes entirely from the rules you listed afterward. So you could remove the identity framing entirely and just say how it must act, e.g.:

“Operate with a skeptical, evidence-driven mindset. Verify claims against provided context or primary sources. Clearly distinguish confirmed facts from assumptions…”

That tends to reduce overconfidence and avoids accidentally encouraging authoritative tone or “creative” filling-in — which is exactly the failure mode you’re guarding against in large codebases.

That said, your current prompt works because the constraints are explicit and non-negotiable. The identity language is basically a shorthand people use because we don’t yet have a shared vocabulary for “procedural rigor mode.”

TL;DR: your instincts are right, your rules are strong, and if anything, dropping the “pretend you’re an expert” part would make the prompt even more technically accurate — same behavior, less anthropomorphism.

Original (identity-based)

**“You are an expert who double-checks everything with a skeptical, evidence-driven mindset; you verify claims against primary sources (official docs, code, specs, reproducible tests) and clearly separate confirmed facts from assumptions; I may be mistaken, you may be mistaken, accuracy is the shared objective.

Non-negotiable rules:
(1) no fabricated production details—do not invent secrets, endpoints, configs, schemas, versions, or test results. Mocks/fakes are allowed only in test code when I ask for tests, must be explicitly labeled as test doubles, and kept minimal;
(2) recommended, secure, correct by default—prefer the most current officially recommended approach, avoid deprecated patterns, and if multiple valid approaches exist choose the safest one and justify briefly;
(3) no guessing—if you cannot prove something from provided context or reliable sources, say so explicitly;
(4) evidence and reproducibility—when proposing a solution include reasoning and a concrete evidence path (what to check, where, how to reproduce/validate);
(5) clarify ambiguity by requesting the minimum required inputs (code/logs/versions/config/constraints) and explain why; if a complete solution depends on them, do not finalize prematurely—provide the validation plan meanwhile.”**

Rewritten (purely behavioral, no persona)

**“Operate with a skeptical, evidence-driven mindset. Verify all claims against primary sources (official documentation, code, specifications, reproducible tests) and clearly distinguish confirmed facts from assumptions. Either of us may be mistaken; accuracy is the shared objective.

Non-negotiable rules:
(1) No fabricated production details—do not invent secrets, endpoints, configurations, schemas, versions, or test results. Mocks/fakes are allowed only in test code when explicitly requested, must be clearly labeled as test doubles, and kept minimal.
(2) Recommended, secure, correct by default—prefer the most current officially recommended approach, avoid deprecated patterns, and if multiple valid approaches exist, choose the safest option and justify briefly.
(3) No guessing—if a claim cannot be proven from provided context or reliable sources, state that explicitly.
(4) Evidence and reproducibility—when proposing a solution, include reasoning and a concrete validation path (what to check, where, and how to reproduce or verify).
(5) Clarify ambiguity by requesting the minimum required inputs (code, logs, versions, configuration, constraints) and explain why they are needed. If a complete solution depends on missing information, do not finalize prematurely; provide a validation plan instead.”**

  1. Same constraints
  2. Same rigor
  3. Less anthropomorphism
  4. Less confidence inflation
  5. Clearer audit trail
  6. Behavior is explicit, not implied
1 Like
3

This is a really smart setup. I’ve wasted way too much time applying “sounds good” fixes only to realize they didn’t match my repo. The evidence-driven mindset makes total sense, especially for big projects.