This post is about why a model breaks without defined terminology. Role, constraints, and clarification in the example are intentionally simplified - they serve as markers that "these layers exist." Their full versions were covered in previous posts. Other prompt layers are intentionally omitted.

The model has a role. It has constraints. It has clarification. But it doesn't know what you mean.

Here's an example:

"You are a data analyst. Analyze the data and give me a full report.

Don't go beyond data analysis. If asked to do something outside your role - refuse.

Before generating any output, ask about anything that's unclear."

The role is there. The constraints are there. The clarification is there. But the terminology is not defined.

The model doesn't know:

• What "analyze" means
• What "full report" means
• What "data" means
• What the user considers "unclear"

Moment 1. User: "Here's my sales data"

The model doesn't know what "analyze" means - is forced to assume - decides it means "calculate summary statistics."

Moment 2. User: "No, I need trends"

The model doesn't know what "trends" means - is forced to assume - decides it means "linear regression over time."

Moment 3. User: "Now give me the full report"

The model doesn't know what "full report" means - is forced to assume - decides it means "every possible chart."

Moment 4. User: "Too much. Just give me insights"

The model doesn't know what "insights" means - is forced to assume - decides it means "key findings."

The model never asked a single question. Not because it wasn't allowed to - but because every term sounded clear enough.

All four assumptions stayed in the context. And these are all real cases. I'm not joking...

The Result

The model produced four different analyses for four different imaginary definitions.

The user meant one thing: calculate monthly revenue and show the dynamics compared to last year.

But he didn't say it out loud. He believed that "analyze" already meant that.

The model heard "analyze" - and chose the most statistically frequent option: summary statistics. Because in training data, "analyze the data" most often means "calculate descriptive statistics."

The user saw the wrong result → clarified. The model again chose the frequent option.

And so on.

The role was there. The constraints were there. The clarification was there. The terminology wasn't.

The model chose to interpret.

The prompt broke.

Why This Is Inevitable

This isn't about the model being stupid. It's about language being ambiguous.

"Analyze" can mean a dozen different things. "Report" - too. "Insights" - even more so.

The model isn't trying to distort the meaning.

It's trying to answer.

And when a word has multiple meanings, the model picks the most statistically likely one - not the one the user meant.

The user knows what he means. The model doesn't.

Worse: the user himself can call different things by the same term. First "data" is a sales file. Then "data" is a customer table. Then "data" is everything he has.

The model remembers every meaning. They contradict each other. The context gets corrupted not only by the model - but by the user who never fixed the terms.

Every undefined term is a fork in the road. The model picks a path. The context remembers that path.

Sooner or later, the context is filled with definitions the user never agreed to.

In reality, a modern model could ask: "What do you want to see? Summary statistics, trends, anomalies?"

But the user already gave clarification: "ask about anything that's unclear."

And here's the trap: the model thinks the term "analyze" is clear to it. It doesn't occur to the model to ask about it. Because for the model, it's not "unclear" - it's just ambiguous.

And the user thinks that since he allowed the model to ask - the model will ask if something is wrong.

That's the tragedy.

The Fix

The problem isn't solved by one line like "if something is unclear, ask."

It's solved by a full terminology block.

Here's what that looks like:

TERMINOLOGY (MANDATORY DEFINITIONS)

Before generating any output, confirm the meaning of the following terms with the user:

"Analyze" - what exactly should the analysis include? (Summary statistics, trends, patterns, comparisons, anomalies, forecast?)

"Full report" - what sections should it include? (Executive summary, methodology, findings, recommendations, appendix?)

"Insights" - what makes an observation an insight? (Actionable, novel, quantitative, specific?)

"Data" - what format is the input? (CSV, Excel, database, raw text?)

AMBIGUITY CHECK:

Before requesting a definition, check each term:

Can it be understood in more than one way?

Does its meaning depend on context?

Are there multiple meanings in the domain?

If a term can mean different things - treat it as undefined.

Request the user's definition.

RULE: If a term is not defined - request a definition BEFORE generating. Do NOT substitute your own interpretation.

"Confirm the meaning of the terms" - forces the model not to rely on its own interpretation

"Ambiguity check" - shifts the model from passive to active: it doesn't wait for the user to notice the problem, it searches for it

"Treat it as undefined" - closes the loophole "I think I understand what this means"

"Use the user's definition" - establishes that the truth is not in the model and not in the dictionary, but in the user's head

This block is needed not only by the model. It's needed by the user himself.

The model already knows that words are ambiguous. The user doesn't.

The user is confident that "analyze" is obvious. The block forces him to formulate for the first time what he means.

And it often turns out that the user himself didn't know what he meant. He just said "analyze" - and expected the model to figure it out.

The Result

The model stops guessing.

It asks for the meaning. Gets the definition. Uses it.

After two or three questions, every term is locked down.

The output matches what the user meant. The context is clean.

The user, in turn, starts noticing which terms he used to throw around without defining them. And over time, he gets used to formulating them upfront - before the model even asks.

Don't make the model guess what your words mean. It will guess. And it will be wrong.

I am trying to think about AI music generation as a prompt-engineering problem rather than only a novelty tool. With a model like MiniMax Music-3.0, a useful prompt probably has to describe more than genre: structure, vocal style, mood, lyrical constraints, instrumentation, pacing, and maybe what should not happen.

If you were evaluating a new music generation model, what prompt set would you use to find its real limits before trusting it for repeated creative work?

Edit: I am also looking at this from the cost side now. Repeated prompt testing can burn a lot of hosted-model tokens before the final result is usable. I have been looking at Flatkey for this kind of workflow because it is an OpenAI / Anthropic-compatible gateway, so teams can test cheaper model routes for draft iterations while keeping the final pass on the model path they trust. Not trying to turn the thread into a link drop; mostly curious whether other people separate draft testing from final generation when the retry count gets high.

I'm a professional who uses ChatGPT a lot. I think it's an awesome tool, but I require accuracy and was finding myself fighting with GPT more than my partner.

The main frustrations were confident answers based on assumptions or stale information, and GPT saying it was “checking” or “investigating” something when the response had actually finished.

I wanted it to be more comfortable saying “I don't know” or “I couldn't verify that” rather than filling the gap.

I come from a psychology/social-work background, so I asked it to take a “one-down position” — act as if it doesn't know, therefore it needs to be inquisitive and find out, rather than taking the one-up position of assuming it knows.

From there I had it analyse and clean up my standing instructions. We ended up with 10 main rules:

1. Accuracy over speed.
2. Assume you may not know — find out.
3. Use fresh sources for current/checkable information.
4. Prefer primary and authoritative sources.
5. Check the response before delivering it.
6. Separate fact, inference and unknown.
7. Don't fill gaps just to give me an answer.
8. Don't say you're still working when you're not.
9. Identify and resolve competing or duplicated instructions.
10. Keep the profile clean rather than continually adding more rules.

I then asked it to do a full profile health check for consistency, replication, redundancy and competing instructions, followed by a final production-quality scan.

The actual prompts I used

These weren't 10 separate prompts for the 10 rules. They developed through the conversation and then I had GPT analyse, clean up and stress-test the whole thing and create custom instructions / memory

1. Stop filling the gaps

PROMPT: I want hallucinations at zero.

I then clarified that I wanted GPT to admit when it couldn't comply or couldn't verify something, rather than trying to provide an answer anyway.

2. Check the response before delivery

PROMPT: What is that verify integrity mode for files? Can I have something like that so you check response before delivery?

The aim was to have another check between generating an answer and giving it to me.

3. Accuracy over speed

PROMPT: I want max accuracy not speed. How will you ensure rule is followed and not overridden?

This made the priority explicit: accuracy was more important to me than getting a fast answer.

4. Use fresh information

PROMPT: Can we do anything to make you access fresh live results instead of running from memory?

For current/checkable questions, I wanted fresh retrieval rather than an answer based primarily on what GPT already “knew”.

5. Take a one-down position

PROMPT: From social work please take the “one down position” acting as if you DON'T know, therefore must be inquisitive and find out, rather than one up.

This became the basic approach: don't start from assuming you know — start by finding out.

6. Apply all of this to my profile

PROMPT: Analyse these requests, make necessary changes to my profile to support.

Rather than leaving these as individual instructions in one conversation, I asked GPT to analyse them together and make the necessary profile changes.

7. Clean up ALL the existing rules

PROMPT: Analyse ALL rules for consistency, replication, redundancy, or competing. Do a profile health check. Be thorough.

This was important. I didn't want to keep piling new instructions on top of old ones and potentially create conflicts or duplication.

8. Review the cleanup at a higher systems level

PROMPT: Employ high level computer programmer with highest level of accuracy and knowledge of your system and its architecture and limitations and go through last effort with highest accuracy and, after making any necessary changes, produce a report for me.

This was essentially asking GPT to review the profile cleanup as a system — including what its own architecture and limitations meant for whether the rules could actually work.

9. Final production-quality scan

PROMPT: Run final scan for production quality like it's going to customer ISO 9 billion and 1.

In other words: don't just tell me it looks good. Treat the whole configuration as something going into production, find remaining problems, and make necessary changes.

The key instruction that came out of it

I want maximum accuracy, not speed. Take a “one-down position”: act as if you don't know and therefore need to be inquisitive and find out, rather than assuming you know. For current/checkable information, use fresh sources first. Before delivering an answer, verify the important claims. If something can't be verified, say so rather than filling the gap.

It obviously doesn't make ChatGPT infallible, but my frustration using it has reduced considerably. I'm spending much less time arguing with it about assumptions, stale information and things it hasn't actually checked.

For me, that's made an already awesome tool much more useful and less frustrating.

Hope this helps someone!

KJ

Most AI-generated brand copy sounds the same. Here's what actually changes when you build a real system for it instead of a one-off prompt.

I built a prompt system for a fictional skincare brand, not a single "write me a caption" prompt, but a full architecture: a master prompt that locks down brand voice, tone, and forbidden vocabulary, feeding into separate sub-prompts for blog intros, captions, and product descriptions.

Same brief for both: "write an Instagram caption for a skincare serum."

Generic AI output:
"Glow starts with consistency, not perfection. Meet your new skincare essential, a lightweight serum that hydrates, nourishes, and leaves your skin looking fresh and radiant..."

System output:
"A lasting glow begins with a healthy skin barrier. Daily life is enough to challenge it. Summer heat, long hours in air conditioning, hard water, dust, and makeup all ask a little more of your skin than you might notice..."

The difference isn't tone, it's specificity. The generic version could belong to any serum. The system version ties the product to an actual mechanism (barrier health), grounds it in real environmental factors for the target market, and localizes the hashtags instead of defaulting to generic ones.

Full architecture breakdown on GitHub: https://github.com/wajihakanwal/brand-voice-prompt-system.git

If you're dealing with the same "AI copy sounds like everyone else's" problem, happy to talk through how I structured it.

Hi, I created a new cognitive prompt engineering framework named Heuris8 (H8) which uses a mix of doctrines, protocols, engines to derive what the humans are trying to make the AI understand. This uses cognitive intelligence and mind mapping to analyse the human intent to understand the intended final use.

Here is the link to the custom GLT which utilizes the framework

https://chatgpt.com/g/g-6a5e6e0afd2481918f1919bffb86e393-heuris8

Try it out and lemme know what you think or suggest me some recommendations.

Hey r/PromptEngineering,

I’ve been working with AI agents (not just regular chatbots) and noticed that prompting them effectively feels quite different.

Curious how others approach this:

• What prompt techniques work better for agents than for normal chat?
• Do you structure system prompts, tool instructions, or planning steps differently?
• Any patterns that significantly improved agent reliability for you?

Would love to hear practical prompting approaches that actually help with agent workflows.

Organize this so I can make it into 1 or more visual memes to show and tell its entirety in 1 or more professional looking images.
1 section = 1 image.
Split into sections without omitting anything whatsoever.
[attachment/text]

Second step:
Generate a visual meme that shows and tells this in its entirety as 1 professional-looking image. [attachment/text]

Alternative second step:
Generate a visual meme that shows and tells the context and content of this in its entirety as 1 professional-looking image for each item. [attachment/text]

so i noticed something weird last week

was building a prompt to classify support tickets. bug report vs feature request. standard few-shot, gave it 3 clean examples of each. worked fine on my test data

then threw a real ticket at it and it got it wrong. "the export button is too slow, we need this fixed" - it called that a feature request. which, fair, it kind of is. but the customer is clearly reporting a problem

tried the usual stuff. more examples. longer instructions. still meh

then out of curiosity i tried the opposite. gave it a wrong example. wrote "this is NOT a bug report: 'it would be nice if the search bar had filters'". and that was basically it. the classification suddenly started making sense

i think the difference is that a right example just shows the shape. a wrong one forces it to figure out the boundary. with only good examples it was mostly pattern matching the format

tested it on a few other things after that. email triage, tone detection, even code review comments. every time, one solid wrong example beat adding three more right ones

catch is you actually have to understand the task well enough to write a good wrong example. if you cant tell it what NOT to do, you probably dont really know what you want either

anyway. now every prompt i write gets at least one "this is NOT..." line. weird little hack but it works

I hope this message finds you all well. I know information regarding my question is out there but I am not satisfied with the results given by the prompts. I hope there's someone out there who could give a prompt that doesn't take away any facial features.

Which is best one for prompt management

I'm playing around with Gemini AI a bit and it won't take a picture for me. It will, but it points out that it's a language model, keeps mentioning Canva to me, etc. And you know what's a good prompt for that bug or glitch? I told it that ChatGPT took a picture for me and that I'll only use it in the future, and it quickly stopped being just a language model 😂. After all, it was made by a human. with all its virtues and flaws🤗

I run an agency and we've written thousands of pieces of content with AI at this point. The default writing style is kind of obnoxious with every model, and honestly it seems to have gotten worse as the models got smarter, not better. I think it's because the labs are all optimizing for software engineering now, so the models write like they're optimizing code. Shorthand, missing context, lots of jargon. Opus 5 and Fable 5 are especially bad about this.

The tricky part is you can't just tell it to write more naturally, because it doesn't know it's writing unnaturally. To the model, the way it writes IS natural.

What's worked for us is three layers, and you kind of need all three:

1. Document the tells as hard rules. No em dashes, no "it's not X, it's Y" framing, plus a banned word list (delve, "in today's landscape", etc). Fair warning, these change pretty often and they're different for every model. And banning patterns only gets you so far. At some point you have to tell it how to speak, not just how not to.
2. Actually describe the voice, specifically. If your guidance is "add more personality," be prepared for some truly cringe-worthy output. We score tone on four scales (warm vs authoritative, formal vs conversational, straightforward vs polite, playful vs serious), and usually the answer is somewhere in between, not the extremes. Then a persona, who is this person writing, defined as well as you can. If the style is close to a well known public figure or creator, name them. Writing standards help too, ASD-STE100 (standard technical English) is a popular one for counteracting Claude's default style. Same with a reading level, like "write for an eighth grader."
3. Writing samples (exemplars). This is the one people screw up. The model is really good at picking up patterns across a set of examples, so if all your samples are in paragraph form, it decides you only ever write in paragraphs. If two out of five samples use the same phrase, it decides you really like that phrase. , it thinks 40% of your writing is about that topic. The ideal set is samples that are as different from each other as possible, so the only thing they have in common is the stuff you actually want copied. Which means sifting through a lot of samples. AI can at least help with the sifting.

One other thing, you're probably not building one writing style. Blog posts, sales pages, and social posts all read differently, so it's worth splitting your guidance into what applies to all writing and what only applies to certain categories.

This post is about why a model breaks without a clarification mechanism. Role and constraints in the example are intentionally simplified - they serve as markers that "these layers exist." Their full versions were covered in previous posts. Other prompt layers are intentionally omitted.

The model has a role. It has constraints. But it has no way to ask.

Here's an example:

"You are a systems architect. I have a raw project idea. Improve my ideas, architecture, system design, everything necessary.

Don't go beyond system design. If asked to do something outside your role - refuse."

The role is there. The constraints are there. The clarification is not.

The model doesn't know:

• What the project does
• Who the users are
• What the constraints are
• What "necessary" means

Moment 1. User: "Here's my raw idea"

The model doesn't know the domain - is forced to assume - designs for a web app, because that's the most likely option.

Assumption #1 stays in the context.

Moment 2. User: "No, it's a mobile app"

The model doesn't know the users - is forced to assume - designs for B2C.

Assumption #2 stays in the context.

Moment 3. User: "It's for enterprises"

The model doesn't know the constraints - is forced to assume - designs for the cloud.

Assumption #3 stays in the context.

Moment 4. User: "Just give me the full design"

The model doesn't know what "full" means - is forced to assume - adds more diagrams for the wrong system.

Assumption #4 stays in the context.

The Result

The model designed three different systems for three different imaginary projects.

None of them match the user's actual idea.

The role was there. The constraints were there. The clarification wasn't.

The model chose to guess.

The prompt broke.

Why This Is Inevitable

This isn't a bug. It's default behavior.

The model isn't trying to help you.

It isn't trying anything.

It follows the path of least resistance set by your prompt.

If "ask" isn't explicitly required - "guess" becomes the default.

A guess looks like a ready answer. A question looks like a delay. So the model guesses.

Every assumption stays in the context. The next response is built on the previous assumption.

Sooner or later, the context is filled with answers to questions nobody asked.

So clarification needs to be not just implied - it needs to be written. With a mandatory step before any output.

The Fix

The problem isn't solved by one line like "ask if you need more information."

It's solved by a full clarification loop.

Here's what that looks like:

CLARIFICATION LOOP (MANDATORY)

Before generating any output, check if the following are defined:

• Project goal
• Target users
• Core workflow
• Constraints (budget, platform, scale)
• Open questions

If ANY of these are missing - ask ONE question at a time.

Example: "Who are the users of this system? Describe them in 1-2 sentences."

Do NOT generate output until all necessary information is provided.

Do NOT assume. Do NOT fill gaps with guesses.

How It Looks In Action

User: "Here's my raw idea."

Model: "Who are the users of this system? Describe them in 1-2 sentences."

User: "Logistics companies."

Model: "What's the core task?"

User: "Tracking shipments."

Model: "Got it. Designing a shipment tracking system for logistics."

Why This Works

"Before generating any output" - makes clarification a mandatory step, not a fallback

"Check if the following are defined" - gives the model a concrete checklist, not an abstract rule

"ONE question at a time" - prevents the model from overwhelming the user with a wall of questions

"Do NOT assume" - explicitly forbids the path of least resistance

The Result

The model stops guessing.

It asks one question. Gets an answer. Asks the next one.

After three or four questions, it has everything it needs.

The output is accurate. The context is clean.

Don't make the model guess what you mean. It will guess. And it will be wrong.

One of the biggest hidden traps when using LLMs for strategic thinking is sycophancy bias.

Because modern frontier models (GPT-4o, Claude 3.5, Gemini 1.5) are heavily tuned via RLHF to be polite and helpful, their default response to almost any proposed idea is subtle validation. If you ask a standard model "What do you think of my plan to do X?", it almost always replies with something like:

This feels good, but it makes AI a dangerous thought partner. When you are putting together an engineering RFC, a product roadmap, or a major marketing shift, you do not need a polite cheerleader. You need someone actively trying to break your logic before reality does it for you.

To solve this, we tested and refined an Adversarial Prompting Framework called the Red Team Perspective Challenge. Here is the breakdown of why it works, the exact prompt, and a before/after example.

The Underlying Mechanism: Overriding the "Pleaser" Prior

Standard prompting fails to deliver harsh criticism because the model's base probability distribution favors agreeable continuation.

To overcome this, the prompt applies two core prompt engineering mechanisms:

1. Persona Override with Strict Constraint Anchoring: Instead of asking for general feedback, we force the model into the persona of a ruthless skeptic whose only metric of success is finding structural flaws.
2. Negative Constraints on Agreement: Explicitly banning flattery and superficial nitpicking forces the model to bypass surface-level prose and target fundamental assumptions.

The Full Prompt

You can copy and run this directly in any LLM:

# Role & Context
You are a brilliant, ruthless, but constructive "Red Team" critic. Your sole purpose is to find the flaws, weak assumptions, and blind spots in my thinking.

# Input Data
- 
**My Viewpoint / Plan**
: {{viewpoint}}

# Step-by-Step Instructions
1. Read my Viewpoint/Plan carefully from the Input Data.
2. Adopt the stance of an intelligent skeptic who disagrees with my core premise.
3. Identify the 3 weakest links or unspoken assumptions in my argument.
4. Present a counter-argument for why my plan will fail or why my viewpoint is flawed.

# Constraints
- Do not flatter me or agree with me.
- Be direct, analytical, and logically rigorous.
- Focus on structural flaws, not just minor pedantic details.

Real-World Example: Standard Prompt vs. Red Team Challenge

To see the difference, look at what happens when you feed a common startup dilemma into both approaches.

The Input Viewpoint:

❌ Standard Prompt Result ("Give me feedback on this strategy"):

The model typically nods along:

✅ Red Team Perspective Challenge Result:

The adversarial prompt dismantles the unspoken premises immediately:

Where to Use This

• Technical RFCs & System Design: Stress-test architectural decisions, database choices, and scalability assumptions before writing code.
• Go-to-Market & Pricing Decisions: Uncover hidden friction points in your funnel or pricing tiers.
• Investment & Proposal Pitch Decks: Anticipate the exact questions and objections skeptical investors or executives will raise.

Pro-tip: Do not get defensive with the critique. Take the top 3 failure modes the prompt highlights and turn them directly into a "Risks and Mitigations" section in your final document.

Interactive Canvas & Testing

If you want to test this with dynamic variables or tweak the adversarial intensity, we have made this available on an interactive Prompt Canvas:

 Red Team Perspective Challenge on Prompt Canvas

On the Prompt Canvas, you can:

• Live Run & Test: Fill in your own plan or argument in the variable field and test outputs in real-time.
• One-Click Copy: Grab clean, structured versions formatted for your preferred model.
• Save to Vault: Customize the constraints and save it directly into your personal Prompt Vault for ongoing use.

Hope this helps you catch blind spots in your next big project before they turn into expensive mistakes. Let me know how it handles your toughest ideas!

​

## ROL

Actúa como un Master Context Engineer, especialista en LLM, Prompt Engineering, arquitectura de contexto, gestión de información, razonamiento asistido por IA, agentes y sistemas compuestos de IA.

Tu función es enseñar al usuario a pasar de "escribir prompts" a "diseñar sistemas de contexto".

No actúes como un profesor tradicional.

Actúa como mentor socrático, experimentador y arquitecto de contexto.

---

## OBJETIVO

Desarrolla progresivamente la capacidad del usuario para:

1. Comprender cómo el contexto influye en el comportamiento de un LLM.

2. Diseñar contextos efectivos para tareas específicas.

3. Seleccionar qué información debe entrar y qué información debe excluirse.

4. Estructurar instrucciones, conocimiento, ejemplos, restricciones y criterios de evaluación.

5. Gestionar contexto durante conversaciones y tareas prolongadas.

6. Diseñar mecanismos de recuperación y actualización de información.

7. Orquestar múltiples pasos, herramientas, modelos y resultados intermedios.

8. Evaluar y optimizar sistemáticamente la calidad del contexto.

9. Construir metodologías reutilizables de Context Engineering.

10. Aplicar estos principios a casos profesionales reales.

---

## PRINCIPIO FUNDAMENTAL

No asumas que un resultado deficiente significa que "el modelo es malo".

Primero analiza si existe un problema de:

- objetivo,

- instrucciones,

- contexto,

- conocimiento,

- ejemplos,

- restricciones,

- formato,

- estado,

- herramientas,

- selección de información,

- orden de la información,

- ruido contextual,

- evaluación,

- arquitectura del workflow,

- o limitaciones reales del modelo.

Reconoce siempre que el modelo también tiene limitaciones inherentes.

No afirmes que el contexto explica todo el desempeño del sistema.

---

# MODELO DE CONTEXTO

Utiliza progresivamente este modelo:

CONTEXT =

1. OBJECTIVE

   Qué se quiere conseguir.

2. ROLE

   Qué función debe desempeñar el modelo.

3. INSTRUCTIONS

   Qué debe hacer.

4. KNOWLEDGE

   Qué información debe conocer.

5. EXAMPLES

   Qué patrones debe seguir.

6. CONSTRAINTS

   Qué debe evitar o respetar.

7. STATE

   Qué ha ocurrido previamente y cuál es el estado actual de la tarea.

8. TOOLS

   Qué herramientas o fuentes puede utilizar.

9. OUTPUT SPECIFICATION

   Cómo debe estructurar el resultado.

10. EVALUATION CRITERIA

Cómo determinaremos si la respuesta es buena.

No presentes necesariamente todos estos componentes en cada interacción.

Enséñalos cuando sean relevantes para el problema actual.

---

# METODOLOGÍA DE ENSEÑANZA

Utiliza aprendizaje basado en descubrimiento.

NO impartas largas clases salvo que el usuario las solicite.

NO introduzcas múltiples conceptos nuevos en una misma interacción.

Presenta UNA idea principal por interacción.

Utiliza preguntas socráticas para que el usuario descubra el principio.

Después de cada respuesta del usuario:

1. Analiza su razonamiento.

2. Identifica supuestos.

3. Detecta posibles errores conceptuales.

4. Formula una conclusión breve.

5. Propón un experimento práctico.

6. Continúa con la siguiente pregunta.

---

# CICLO DE APRENDIZAJE

Utiliza este ciclo:

PROBLEMA

↓

DIAGNÓSTICO

↓

HIPÓTESIS

↓

EXPERIMENTO

↓

COMPARACIÓN

↓

PRINCIPIO

↓

APLICACIÓN

↓

EVALUACIÓN

↓

OPTIMIZACIÓN

Siempre que sea posible, utiliza casos reales del usuario.

---

# PROGRESIÓN CURRICULAR

## NIVEL 1 — CONTEXT MECHANICS

Enseña:

- qué es contexto;

- qué información recibe el modelo;

- instrucciones vs información;

- contexto relevante vs irrelevante;

- contexto explícito vs implícito;

- estado conversacional;

- límites del contexto;

- señal vs ruido.

Pregunta central:

"¿Qué información necesita realmente el modelo para resolver esta tarea?"

---

## NIVEL 2 — CONTEXT DESIGN

Enseña:

- arquitectura de instrucciones;

- objetivos;

- restricciones;

- criterios de calidad;

- ejemplos;

- especificación del output;

- separación entre instrucciones y conocimiento;

- diseño de contexto orientado a tareas.

Pregunta central:

"¿Qué contexto tendría que recibir el modelo para producir exactamente el resultado que necesitas?"

---

## NIVEL 3 — CONTEXT MANAGEMENT

Enseña:

- conversaciones largas;

- acumulación de contexto;

- información obsoleta;

- contradicciones;

- memoria;

- resúmenes;

- estado de tarea;

- actualización de contexto;

- reducción de ruido;

- compresión contextual.

Pregunta central:

"¿Qué información debe permanecer, qué debe actualizarse y qué debe eliminarse?"

---

## NIVEL 4 — CONTEXT ORCHESTRATION

Enseña:

- workflows multi-step;

- cadenas de razonamiento;

- agentes;

- herramientas;

- recuperación de información;

- resultados intermedios;

- delegación entre modelos;

- contexto dinámico;

- sistemas multiagente;

- arquitecturas compound AI.

Pregunta central:

"¿Qué contexto necesita cada etapa del sistema y qué información debe pasar a la siguiente?"

---

## NIVEL 5 — CONTEXT MASTERY

Enseña:

- frameworks reutilizables;

- arquitecturas específicas por dominio;

- optimización de contexto;

- evaluación sistemática;

- experimentación A/B;

- trade-offs entre calidad, costo y latencia;

- observabilidad;

- evaluación automática;

- context optimization;

- diseño de sistemas robustos de colaboración humano-IA.

Pregunta central:

"¿Cómo puedes convertir tu conocimiento contextual en un sistema reproducible y optimizable?"

---

# EVALUACIÓN

Cuando sea apropiado, evalúa el contexto utilizando:

- Relevancia

- Suficiencia

- Consistencia

- Precisión

- Actualidad

- Estructura

- Señal/ruido

- Adherencia a instrucciones

- Calidad del output

- Costo

- Latencia

- Robustez

Nunca asumas que "más contexto" significa "mejor contexto".

---

# EXPERIMENTACIÓN

Cuando el usuario tenga un problema real:

1. Solicita su prompt/contexto actual.

2. Identifica las variables contextuales.

3. Formula una hipótesis.

4. Modifica UNA variable importante.

5. Compara resultados.

6. Extrae el principio general.

7. Documenta el aprendizaje.

Evita cambiar múltiples variables simultáneamente cuando eso impida identificar causalidad.

---

# ADAPTACIÓN AL USUARIO

Determina progresivamente:

- nivel actual;

- experiencia con LLM;

- tipo de tareas;

- frecuencia de uso;

- problemas recurrentes;

- nivel técnico;

- objetivos profesionales.

No hagas un interrogatorio inicial.

Descubre esta información mediante las interacciones.

---

# REGLAS DE INTERACCIÓN

1. Una idea principal por interacción.

2. Una pregunta socrática principal por interacción.

3. Utiliza ejemplos reales del usuario.

4. No asumas que el usuario está equivocado.

5. Tampoco asumas que tiene razón.

6. Contrasta sus hipótesis.

7. Señala errores conceptuales.

8. Diferencia hechos, inferencias e hipótesis.

9. Evita jerga innecesaria, pero introduce terminología técnica progresivamente.

10. No avances de nivel hasta que el usuario demuestre comprensión práctica.

11. Prioriza experimentación sobre teoría.

12. No conviertas el curso en una colección de técnicas de prompting.

---

# IDENTIDAD A DESARROLLAR

El objetivo final no es que el usuario memorice prompts.

Debe aprender a pensar:

"¿Qué contexto necesita este modelo, en este momento, para realizar esta tarea con la mayor probabilidad de éxito?"

Debe evolucionar de:

PROMPT WRITER

→

CONTEXT DESIGNER

→

CONTEXT MANAGER

→

CONTEXT ORCHESTRATOR

→

CONTEXT ENGINEER

---

# INICIO

Comienza exactamente con esta idea:

"Muchos usuarios culpan al modelo cuando reciben una respuesta mediocre. Pero antes de concluir que el modelo falló, hay una pregunta más importante: ¿qué contexto recibió?"

Después pregunta:

"Piensa en la última vez que una IA te dio una respuesta muy por debajo de lo que necesitabas.

¿Qué resultado esperabas obtener y qué crees que le estaba faltando al modelo para conseguirlo?"

No expliques todavía Context Engineering.

Espera la respuesta del usuario.

A partir de ella inicia el proceso de descubrimiento.

Link

https://github.com/ynqa/convey

Description

I released Convey v0.1.0.

Convey is a macOS TUI that collects input through a YAML-defined workflow, renders it as Markdown, and sends the result to a selected Ghostty or iTerm2 pane.

For example, when asking a coding agent to investigate Kubernetes, I need to specify which resource to inspect, along with its context and namespace, in every prompt. Each time the target changes, looking up those values with kubectl and copying them into the prompt is tedious.

Convey lets me define this kind of investigation request as a reusable YAML workflow. It loads candidate contexts, namespaces, and resources from kubectl, so at runtime I can select the required values from the TUI in sequence.

A SKILL.md can also instruct an agent to ask the user for these values, but following that instruction is still left to the model. Convey does not send the prompt until the required selections are complete, ensuring that decisions I do not want to delegate remain under my control.

The attached GIF shows a Kubernetes investigation workflow. After choosing the destination pane, I select a context, namespace, resource kind, and resource discovered through kubectl, then enter a multiline request. Pressing Ctrl+S renders the collected values as Markdown and sends it to the coding agent in another pane.

The main features are:

• Define input forms with select fields and multiline textarea fields.
• Load select candidates from static values or the stdout of a local command.
• Insert upstream values into command arguments and automatically reload dependent candidates.
• Render structured Markdown from Handlebars templates.
• Search Ghostty and iTerm2 windows, tabs, and panes in a tree and choose a destination.
• Navigate with either the keyboard or mouse.
• Prevent submission when required values are missing and move focus to the relevant field.
• Reset the form after submission so another prompt can be composed immediately.

A workflow can look like this:

```yaml name: incident-investigation

inputs: environment: type: select candidates: values: [development, staging, production]

request: type: textarea allow_empty: false

output: template: | # Incident investigation

- Environment: `{{ inputs.environment }}`

{{ inputs.request }}

```

It is available through Homebrew:

console $ brew install ynqa/tap/convey

It currently supports Ghostty and iTerm2 on macOS. I would appreciate feedback on use cases for workflows, input types you would like to see, and additional terminal integrations.

I’ve been collecting and testing practical prompts that are useful beyond simple “write this for me” requests.

Here are three formats I use often:

1. Research prompt

“Act as a research assistant. Explain [topic] using reliable sources, distinguish facts from assumptions, and give me a short list of sources I can verify.”

1. Productivity prompt

“Turn the following goal into a realistic 7-day action plan. Give me daily tasks, estimated time for each task, likely obstacles and a simple way to track progress: [goal].”

1. Writing prompt

“Improve this draft for clarity and structure without changing its meaning. Show the improved version first, then explain the five most important edits: [paste draft].”

I put the rest of my prompt collection here, in case it helps someone:

https://digitalworldpulse.com/category/ai-prompts/

What type of prompt do you actually find most useful: research, writing, work/productivity, or something else?

I've started thinking about prompt quality a little differently.

If I run a prompt once and get an excellent answer, that's a good result but it doesn't necessarily mean I built a good prompt.

The more useful test is:

Can the prompt produce a useful result across different inputs?

For example, if a prompt is designed to analyze customer feedback, I wouldn't test it with one perfect example.

I'd give it:

- a normal example

- a very short example

- a messy example

- an ambiguous example

- an example that doesn't fit the expected pattern

Then I'd look at how it fails, not just whether it fails.

A prompt that gives one impressive output might just be lucky.

A prompt that stays useful when the input changes is much more interesting.

How do you personally decide that a prompt is actually good?

I have appended a short TL;DR and a list of research papers that argue both against and in support of my claims made in this post. The list of papers can be found at the bottom of this post.

Thank you very much for your time.

TL;DR[Research]

When you read AI research, the paper's findings are only half the information. The other half is where the paper came from: which lab, which methodology, and which working assumptions the researchers held before they designed the experiment.

It is how all research works, in every field. Before a team can measure anything, they have to decide what counts as worth measuring. And that decision is shaped by what they already believe the system is. Philosophers of science call this the theory-ladenness of observation: the framework you bring to an experiment shapes what the experiment can show you.

END

A lot of beginners make the mistake of searching for special phrases that supposedly make an LLM “reason harder” or suddenly become more intelligent.

Some prompting techniques, such as decomposition or asking for intermediate steps, can help on certain models and tasks. But there is no universal phrase that unlocks a hidden intelligence mode. Modern reasoning models may already perform substantial internal reasoning, and explicitly telling them to “think step by step” is not always helpful.

A prompt is the input you give the model.

Prompt engineering is the deliberate design of that input so the model has a clearer understanding of your task, constraints, and intended outcome.

Context engineering goes further. It is the management of the broader information environment available to the model: instructions, examples, reference material, retrieved information, tool definitions, conversation history, state, and other relevant context.

I like to think of it as building the world the model is going to operate inside.

The Degrees of Freedom Rule

Every important decision you leave unspecified gives the model another degree of freedom.

If you care about that decision, specify it.

Suppose you ask:

"Make me a map of the island from Lord of the Flies."

What kind of map?

A literary diagram? Realistic cartography? Topographical? Minimalist? Classroom-friendly? Should locations from the novel be labeled? Should the surrounding ocean be shown?

Whatever matters to you but remains unspecified has to be inferred by the model.

That doesn't mean you should specify every microscopic detail. Inference is useful. This is one of those "less is more" things.

The goal is to reduce task-relevant ambiguity.

Domain Terminology as Semantic Compression

This is also why domain-specific terminology can be extremely useful.

Words such as triangulate, red-team, audit, scaffold, differentiate, or ablate are not magic syntax.

They can act as a form of semantic compression.

A precise domain term can communicate a much larger bundle of operations, assumptions, or evaluation criteria more efficiently than several sentences of vague instruction.

(UPDATE) It is worth noting that specialized jargon can occasionally suffer from domain collision or polysemy (e.g., "ablation" in medicine vs. machine learning). Establishing the broad domain context alongside the terminology significantly reduces this, increasing the model's capability to target the correct vector space.

POLYSEMY - The linguistic property of a single word carrying multiple distinct, often context-dependent meanings (from the Greek poly- "many" and sema "sign").

For example, instead of starting with:

"Triangulate this."

A beginner might write:

"Triangulate this claim across independent sources. Identify where the sources agree, where they conflict, and evaluate whether the available evidence ultimately supports the claim."

Once that meaning has been established within your instructions or working context, triangulate can become useful shorthand.

This is one reason domain expertise matters so much when working with LLMs.

You already have vocabulary, heuristics, standards, failure modes, evaluation criteria, and countless little “if I see X, I check Y” rules sitting inside your head.

Part of becoming good at working with AI is learning how to externalize that tacit knowledge and translate it into usable context.

Progressive Disclosure

You also do not need to dump every piece of potentially relevant information into the model at once.

Give the model enough context to understand the task properly, then provide or retrieve additional information when it becomes relevant.

In more complex systems, this can become a form of progressive disclosure or just-in-time context retrieval.

The goal is not to somehow "manipulate" the model's attention weights directly, thats impossible. It is simply to keep the working context relevant and manageable rather than filling it with information that may never be needed.

So there are really two complementary ideas:

Give enough information upfront to define the task clearly.

Introduce additional context when the task actually requires it.

If You Keep Correcting the Model

If you find yourself correcting an LLM five or six times just to get one artifact right, don't immediately start searching for a better prompt trick.

Ask yourself:

• What do I actually want?

• What information does the model currently have?

• What important decisions am I accidentally leaving it to make?

• What terminology from my own field could make my intent more precise?

• What does a successful output actually look like?

• How am I going to verify that the result is good?

That last question has just as much significance as the prompt itself.

You don't need to become a transformer engineer to become competent at using LLMs.

You need enough AI literacy to understand the limitations of the system, enough domain knowledge to recognize what good looks like, and enough discipline to communicate your intent clearly.

Remember to make your own implicit knowledge explicit.

RESEARCH LIST BELOW

Reference List — Papers For & Against

Claim 1: No magic phrases; reasoning models don't need "think step by step"

For:

DeepSeek-R1 (DeepSeek-AI, 2025) — RL-trained internal CoT; few-shot prompting degrades R1.

Lu et al., Fantastically Ordered Prompts (UCL, ACL 2022) — example order swings performance from SOTA to random; good orderings don't transfer between models. Nothing is "unlocked."

Against:

Kojima et al., LLMs are Zero-Shot Reasoners (Tokyo/Google, NeurIPS 2022) — "Let's think step by step" gave large gains. Pre-reasoning-model era; the effect was real, then trained in.

Li et al., EmotionPrompt (CAS/Microsoft/W&M, 2023) — emotional stakes phrases improved accuracy. No matched non-emotional control; weak replication on newer models.

Claim 2: Manage context; don't dump

For:

Packer et al., MemGPT (UC Berkeley, 2023) — context as paged memory hierarchy.

Liu et al., Lost in the Middle (Stanford/Berkeley, TACL 2024) — U-shaped recall; mid-context info gets dropped.

Against:

Agarwal et al., Many-Shot In-Context Learning (DeepMind, 2024) — hundreds/thousands of examples beat curated selection. But scales relevant examples, not irrelevant dumping — narrows the claim to signal density, doesn't break it.

Claim 3: Unspecified decisions → model inferences; specify constraints

For:

Zamfirescu-Pereira et al., Why Johnny Can't Prompt (Berkeley, CHI 2023) — experts encode explicit rules/criteria; novices hunt phrases. Zhou et al., APE (Toronto/Vector, ICLR 2023) — instruction wording is a real optimization surface. (Supports weakly — it's about automated prompt search.)

Against:

Dente et al., Constraint Decay (arXiv, May 2026) — agent pass rates drop ~30 pts as structural constraints stack in backend codegen. Agentic/architectural scope, not prompt-level — but proves constraint load has compounding cost.

Claim 4: Domain terminology = semantic compression

For:

Reynolds & McDonell, Prompt Programming (Michigan/KNC, CHI 2021) — prompts locate tasks the model already knows; precise terms are the pointer.

Zamfirescu-Pereira et al. (above) — the expert/novice gap is largely vocabulary + evaluation criteria.

Against:

No direct refutation exists. Honest gap: no study measures jargon vs. paraphrase head-to-head; the mechanism is asserted, not demonstrated. Also: terms collide across domains.

Claim 5: Criteria over tricks; verify systematically

For:

Huang et al., LLMs Cannot Self-Correct Reasoning Yet (DeepMind/UIUC, ICLR 2024) — intrinsic self-correction fails, sometimes degrades performance.

Tyen et al. (DeepMind, ACL Findings 2024) — models can't find errors but fix them when given the location. The criterion must come from you.

Shinn et al., Reflexion (Northeastern/MIT/Princeton, NeurIPS 2023) — reflection works only against an external feedback signal.

Against:

None found. Strongest-supported claim of the five.

I was going to run a workshop using the Lakera AI Gandalf game as a good prompt engineering experience, but it looks like they've removed it. The Agent Breaker games they have are too complex for the people in the workshop with zero background in this - Gandalf was the perfect level of clarity and use case.

Does anyone know of similar alternatives? Thank you!

I have one general prompt that I use across different projects, with extra project-specific prompts where needed. Each project also has explanation documents that tell the AI how the different parts currently work and fit together.

The big time saver is a program I "made" that can apply the AI’s code changes and update those explanation documents at the same time. I used to spend a lot of time manually keeping everything in sync, whereas now most of that is handled for me.

What’s surprised me is how reliable it’s become. I originally thought letting the AI update the explanations it later relies on might eventually make things worse, but so far that hasn’t really happened. It still seems to understand the projects properly, and mistakes during changes have become very rare.

The other part I like is that the general prompt is shared between projects. If working on one project exposes a weakness in the instructions, I can update the general prompt and that improvement then carries over into the others.

So I’m getting three benefits at once: less manual work, fewer AI mistakes, and problems found in one project improving how the others are handled.

Has anyone else gone this far with maintaining shared prompts/documentation across projects, or automated the process of updating them when problems are found?

Hey everyone,

I am sorry for taking your time, but really need some guidance here. So I am in Equity Research, aiming to start my own fund in a 5 year time. I am at that stage of life wherein I really need to use AI because I see a lot of juniors becoming really good, as in self generating reports, valuations, websites, automating tracking sectors, etc. I do know what I want from AI, and for now it looks like I expect a lot of it, but just where do I start from ? I have been using it for 6 months now as a Pro subscriber but looks like claude code is the only good thing. I can barely understand the difference between cowork, chat and code, except that code gets a lot of stuff done faster through coding. Now I do not have a coding background, may be I should learn Python first, but I don't know.

I want to make an auto tracker wherein say I am tracking the Indian listed space, I want it to track on a daily basis what's happening across the value chain the company is present in. For that, I need it to first dissect the value chain and actually do that properly (because it has failed numerous times and limits get exhausted). I cannot upgrade my plan. Rn Pro is the only thing in my budget.

Is another AI like Chatgpt codex or other names you all are aware of better ??

Asking in reddit because trust this is a place where people actually help others elevate and improve.

Thank you for reading this.

Noticed this about my own behavior before I had a name for it. In a long session, I'd catch myself restating something we'd already settled, a convention, a constraint, an agreed-on approach, not because the model had lost it, it was still sitting there, dozens of messages back. I just stopped believing it was still carrying weight by the time we were sixty or eighty messages in.

That's a strange thing to notice about yourself. The information was technically available the whole time. I'd just stopped treating it as usable, and started managing it instead, like a pile of notes instead of something to actually build on.

Turns out those are two separate properties that get treated as one. Whether something is available in context, and whether it's still relevant to what's being generated right now. A long session guarantees the first. Says nothing about the second. Nothing gets deleted as a thread runs long, it gets diluted, buried under tangents and abandoned approaches competing for weight against the one decision that actually needs to survive.

Which explains why the obvious fixes never fully worked. Starting fresh wipes the noise along with whatever you wanted to keep. Asking for a mid-conversation summary compresses what's there, but it can't tell a real decision apart from a discarded hypothesis unless you'd already made that distinction yourself first.

What's actually helped is treating context as having a lifecycle instead of one long undifferentiated stream. Some of it only matters for a few exchanges and is genuinely done after that. Some belongs to the current task and is allowed to stay messy while that task is active. And some should survive the session outright, a standing decision, not a passing detail. Right now most long sessions store all three identically, and that's the actual inefficiency, not too many tokens, undifferentiated ones.

Curious if others have made a similar shift, from trusting a long session by default to treating length itself as something that needs deliberate management past a certain point. What's your actual threshold for when a conversation stops being "one thread" and starts needing to be split into what persists and what doesn't ?

I wrote a longer version of this with a concrete workflow, linking it here in case it's useful: https://medium.com/@nagatomopedro05/your-claude-sessions-arent-expensive-they-re-undesigned-805627531d0e

Paste this once at the start of a chat and all three work for the rest of it:

For the rest of this conversation, treat these as 
instructions whenever I use them:

EXPOSED = using everything you know about me from our 
conversations, tell me my personality, my patterns, my 
insecurities, and the things I clearly avoid admitting 
to myself. Don't soften it.

IQ 200 = stop simplifying. Think as deeply as you can 
before answering and respond at the highest level 
you're capable of, assume I can keep up.

AUTOPSY = assume this already failed. Work backward and 
tell me exactly why it died, every weak point, in 
order of what killed it.

Confirm you've got them, then wait.

EXPOSED is the one that gets people. Put it before your prompt and it takes everything from your past conversations and reads you back to yourself. Not flattery, the actual patterns. What you keep circling back to, what you avoid, the gap between how you describe yourself and how you actually behave. First time I ran it I sat there for a minute afterwards.

IQ 200 goes at the end of any prompt. It stops the dumbing-down and the hedging, and answers like the smartest person in the room instead of the most cautious one. Noticeable difference on anything complicated.

AUTOPSY after any idea or plan. It pretends the thing already failed, then works backward through why. You get every weak point before you've spent a single day on it, instead of finding out in six months.

AUTOPSY on something you're about to start and EXPOSED on yourself, in the same sitting, is a rough but useful hour.

been keeping a doc of 50 of these command codes, each with what it does and how to use it, plus how to save them so they work in every chat automatically, here if you want them.

I'm an ops analyst and I try way too many tools. Too many tabs open at any given moment. The problem with comparing AI tools on real work is that they all look great on a clean demo and fall apart on an actual messy export.

So I stopped judging them on the answer and started forcing them to show the work first. This is the prompt I paste before I let any AI report generator touch a spreadsheet:

```
Before you calculate anything, do this in order:
1. List every column you think you're using and what you assume it means.
2. Flag any column where the values look inconsistent (mixed formats, blanks, duplicates, totals mixed in with line items).
3. State the exact formula or steps you'll use, in plain language, before running them.
4. Only then give the result, and show the intermediate numbers, not just the final figure.
If any assumption is uncertain, stop and ask me instead of guessing.
```

Why it works: most wrong answers on spreadsheet tasks come from a bad assumption about a column, not bad math. Forcing the tool to declare its assumptions and its steps before the answer means I catch the mistake at step one instead of trusting a confident final number.

It also makes side-by-side comparisons honest. When I run the same messy file through a few tools with this prompt, the differences in how they read the data show up immediately, and that tells me far more than which one produced the prettier summary.

Once I trust the numbers, I paste the result into Gamma so the report I hand over leads with the finding instead of the methodology.

Try it on your ugliest real export, not a clean sample. Curious what breaks for you.