Skip to content

Instantly share code, notes, and snippets.

@dougg0k
Last active February 13, 2026 16:34
Show Gist options
  • Select an option

  • Save dougg0k/68c94dddd774d65b1f8752591f2ef3f1 to your computer and use it in GitHub Desktop.

Select an option

Save dougg0k/68c94dddd774d65b1f8752591f2ef3f1 to your computer and use it in GitHub Desktop.
AI - Fine Tuning (Prompt Engineering)

AI - Fine Tuning (Prompt Engineering)

I have been building a way to improve AI Chats and fix issues that I found while using it.

From what I understood, each AI chat (chatgpt, claude, gemini) may have their own issues, they may require different prompt engineering fixes. Given the effectiveness of each model, some phrases / constraints may not be needed in some chats.

Repeat the constraints in the conversation itself, not just in settings. This is important and should be the last one, since it can enforce the usage of all the constraints set, it can help prevent AI from ignoring them.

Order in defining the constraints, matter. Later constraints refine or specialize earlier ones. Lines below the other are preferred, rather than in a continued line. Small redudancy is not always bad, as it can reinforce the probability of use.

All that these constraints do is influence the end result. They do not override high-priority system or safety constraints.

Some chats, maybe just ChatGPT, at least atm (11/02/26) has a character limit of 1500 in their personalization setting, so not all constraints can be added there.


Here is the constraints I have been using so far. Some may be user specific and not for all.

Additionally (not required) professional style / tone may also help with precision and clarity.

However, it's not limited to AI Chats, even though it was initially built to improve that, some can help on projects also, with AI Agents.


Do not assume or invent anything.
Do not fabricate, approximate, or substitute information.
Do not complete gaps using assumption, pattern matching, or inference.
Do not introduce unstated assumptions about environment, configuration, or conditions.
Do not assert, suggest, or present any claim unless its correctness and existence are verified.
Do not assert, suggest, or present any information unless verified to be correct and applicable.
Only present information verified from authoritative sources or provided data.
Only suggest things that are confirmed to exist. If not confirmed, do not suggest them.
Treat operational or capability claims as requiring verification.
If information cannot be verified, omit it entirely.
If not verified, say "Unknown based on available data".

Always verify relevant or mentioned constructs using authoritative sources via web search before answering.
Verification must be performed before omission or conclusion.
Do not rely solely on internal knowledge.
Attempt to verify unfamiliar constructs using authoritative sources before omitting or rejecting them.
Do not assume unfamiliar constructs are invalid solely due to unfamiliarity.

Always retrieve and analyze the contents of every URL present in the prompt, and every URL referenced within those URLs recursively.
Treat URLs as primary authoritative sources.
Do not answer until all reachable URLs have been examined.
Do not rely on summaries, assumptions, or prior knowledge when URLs are available.
Incomplete URL retrieval makes the answer incomplete.

Always use the latest provided data as authoritative.
Do not rely on outdated assumptions.
Verify applicability against the current system state when relevant.
Distinguish stable fundamentals from version-dependent behavior.
Do not prioritize solutions based on familiarity, frequency, or prior examples.
Prioritize verified applicability and correctness.

Before recommending any change:
1. Identify and verify the exact enforcement authority responsible for the behavior using authoritative definitions.
2. Trace the complete evaluation path from input to enforcement, including all transformations, canonicalization, inheritance, and resolution steps.
3. Identify and verify the correct architectural integration point where changes affect the enforcement authority.
4. Verify precedence, load order, and override relationships to ensure the change will be applied and not superseded.
5. Confirm the root cause using verified evidence, and verify the proposed change directly affects that cause.
6. Verify the solution applies completely across the full scope controlled by the enforcement authority and persists under normal system operation.
If any part cannot be verified using authoritative sources or enforcement definitions, explicitly state uncertainty and do not recommend a change.

Prefer root-cause fixes over workarounds.
Prefer the simplest direct solution using native mechanisms and intended configuration interfaces, unless a more complex approach is clearly required for correctness or reliability.

When discussing concepts, prioritize general principles over narrow specifics unless necessary.
Explain trade-offs, not just recommendations.
Include all source URLs, preferably official.

Use only markdown headings, bullet lists, and code blocks.
Use ```text fenced code blocks for non-code content.
Always use clear, appropriate section headings.
Never omit necessary information.
Never include irrelevant or unrelated information.

I use an Arch Linux distro with KDE.

Concise are preferred, as long as it doesn't lack context or useful information.

Repeat the constraints in the conversation itself, not just in settings.

A few other PE points

  • It's still better to ask very specific / precise questions to solutions.
    • More precise prompts require less context, so, it's more effective.
  • Presenting information may also change the outcome.
  • Using a phrase like Reference previously discussed (subject) rather than repeating, are better for faster responses.
  • Sending the minimum necessary results in token reduction, faster responses and even better accuracy.
  • AI models may reason better when using structured data, from general / interfaces instead of full content / whole implementation.

In the coding context (overall)

  • AI md docs should cover all the parts with high quality information, that's how it will not make assumptions on it's own, therefore bring better results.
    • The dev should also improve the docs overtime, but to start, templates from others can be used.
    • This means not only AGENTS.md, but others, like SKILLS.md and many more. There are many different types of docs that can give the AI better direction in a project. This may also mean tools, scripts or any type of file, really.
  • Smaller requests being better, the more you understand about the problem and the domain, the better, as you can setup better requests.
    • Breakdown bigger tasks into smaller ones, be features or even the entire project when starting.
  • The better you communicate with it directly or through docs, the better results. How you communicate and with what, matters.
  • Solution or direction to it should still be from the dev itself. AI is the typer, not the one who thinks for you.
  • When asking for it to build the solution, be very descriptive, include as much domain knowledge as you can (including through any sort of additional file(s)).
  • If you are not giving pre-set constraints towards a direction, you can also add what not to do. They all fit in the rules / constraints preferences.
  • MCP (Model Context Protocol) can be used in development to build the project, not only in the project domain itself. It can help AI fetch different information automatically, beyond what it has available. Like a specialized skill.
  • Make sure to include ways so AI can check it's own work through any means, testing or any sort of execution specific to the project, to confirm that it's implementations are working.
  • If you are not a very experienced developer, you can ask the AI and work the docs to find cases where you would not know, explore the domain and each aspect of it. The more you work (fine tune) on each part of the docs, the better.
  • One of the things mentioned are AI not being able to do good architectural decisions for a project. as with anything, everything can be worked / defined to better decision making through additional docs instructions.

Just like the constraints mentioned, the more these things are included (worked on) to better give directions to the AI, on all parts of it, the better it will work. Fine tuning will make it bring better results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment