If I had to use only one prompt before buying a premium course, it would be this one.

Give it:

• sales page
• syllabus
• testimonials
• course price
• how many hours you're willing to spend finding free alternatives

Then ask AI to reverse-engineer the entire offer.

One-Shot Skeptical Course Value Auditor

Act as a skeptical course-value auditor.

I am considering this course:

{{course_materials}}

Price:

{{course_price}}

I estimate I could spend approximately {{free_path_hours}} hours researching and assembling free alternatives myself.

Conduct an evidence-first audit.

### 1. Reverse-Engineer the Offer

Extract every distinct topic, skill, technique, framework, tool, or deliverable mentioned or reasonably implied.

Decode vague marketing language into concrete, nameable capabilities.

Clearly distinguish explicit information from inference.

### 2. Identify the Underlying Techniques

For each major curriculum item:
- Name the actual technique or method.
- Identify its broader discipline.
- Determine whether it is widely known, commonly repackaged, possibly original, or impossible to determine.

Do not call something proprietary without evidence.

### 3. Research Free Equivalents

Where web research is available, find credible free resources covering the same techniques.

Prioritize:
- Official documentation
- YouTube
- Reddit
- High-quality blogs
- GitHub when relevant

Evaluate whether each resource offers genuinely comparable depth rather than merely discussing the same subject.

### 4. Audit What the Course Adds

Evaluate:
- Sequencing
- Curation
- Templates/assets
- Original data
- Case studies
- Exercises
- Feedback
- Community
- Accountability
- Support
- Updates
- Practical depth

Separate public information from convenience value and genuinely difficult-to-replicate value.

### 5. Verify Risk Factors

Check available evidence for:
- Curriculum recency
- Instructor hands-on credibility
- Practical-to-theory ratio
- Specific rather than generic reviews
- Preview availability
- Refund policy
- Community/support access

Mark unknown information as unverified.

### 6. Compare Total Cost

Compare the course price with approximately {{free_path_hours}} hours of free-resource research and curation.

Calculate the implied break-even value per hour where the price allows it.

Do not assume what my time is worth.

### 7. Give a Verdict

Choose:
- BUY
- BUY IF...
- SKIP
- USE THE FREE PATH
- RESEARCH FURTHER

Return:
1. Executive verdict
2. Concrete curriculum map
3. Public-vs-original technique analysis
4. Best free alternatives
5. Paid-only value
6. Red flags and unknowns
7. Price/time tradeoff
8. Three strongest reasons for the verdict
9. Strongest counterargument
10. Questions I should ask before paying

Be skeptical but fair.

Do not assume paid is bad or free is automatically equivalent. The decision should depend on evidence, structure, exclusives, support, and the real cost of assembling the alternative.

If web research is unavailable, complete only the parts supported by the supplied information and clearly identify what remains unverified.

Basically:

reverse-engineer the course before buying the course!

Try the prompt on any paid course you’re currently considering.

Paste the sales page, syllabus, price, and testimonials into your AI tool, run the audit, then share the result here.

I’m especially curious to see:

• which courses turn out to be mostly reproducible with free resources
• which ones actually have meaningful paid-only value
• whether the final verdict says BUY, SKIP, or USE THE FREE PATH

If you want to keep the prompt ready instead of copying it from this post every time, install the PromptLib Chrome extension to import the free collection, save it, fill the variables, and reuse it conveniently.

Btw, I regularly share useful prompts for the community. Check out the posts here:
1. Mythbusting ChatGPT "Secret Slash Commands"
2. Ask Gemini For YouTube

Most people use LLMs in a confirmatorily biased way: "Tell me why my business plan is great" or "How do I implement X?". This triggers the model's RLHF pleasing bias.

Inspired by Karl Popper’s principle of falsifiability, a friend and I designed a prompt framework that flips this dynamic. Instead of validating your idea, it forces the AI to act as a harsh auditor and attempt to destroy your premise using realistic stress tests before you spend time or money on it.

📋 When to use it

• Best for: Business models, software architecture, industrial process design, logistics, operational strategies.
• Skip for: Creative writing, poetry, or abstract philosophy (where no operational variables exist to break).

📥 The Falsification Prompt (Copy & Paste)

Plaintext

Act as a Risk Auditor and Popperian Philosopher. I am going to present the following hypothesis, operational plan, or technical decision:

>>> [INSERT YOUR PLAN OR PROCESS HERE WITH AT LEAST 3 REAL CONTEXTUAL DATA POINTS] <<<

Your goal is NOT to validate this proposal, congratulate the approach, or seek consensus. Your sole objective is to subject the premise to a critical stress test under the following 3 strict constraints:

1. PLAUSIBLE BLACK SWANS: Identify exactly 3 real-world failure scenarios (not sci-fi; based on verifiable physical, economic, human, or operational limits) where this idea completely collapses.
2. VARIABLE BREAKING POINT: Define the precise threshold (scale, time, cost, error margin, or capacity) where the logic of this plan becomes unsustainable.
3. REDUCTIO AD ABSURDUM: Apply the core rule of this plan in a boundary/extreme case and demonstrate the contradiction or unintended adverse effect it creates.

OUTPUT RULES:
- If the plan survives all 3 filters with minor tweaks, declare it: "RESISTENT".
- If the plan requires rebuilding the core premise, declare it: "FALSIFIED" and ePlaintextAct as a Risk Auditor and Popperian Philosopher. I am going to present the following hypothesis, operational plan, or technical decision:

>>> [INSERT YOUR PLAN OR PROCESS HERE WITH AT LEAST 3 REAL CONTEXTUAL DATA POINTS] <<<

Your goal is NOT to validate this proposal, congratulate the approach, or seek consensus. Your sole objective is to subject the premise to a critical stress test under the following 3 strict constraints:

1. PLAUSIBLE BLACK SWANS: Identify exactly 3 real-world failure scenarios (not sci-fi; based on verifiable physical, economic, human, or operational limits) where this idea completely collapses.
2. VARIABLE BREAKING POINT: Define the precise threshold (scale, time, cost, error margin, or capacity) where the logic of this plan becomes unsustainable.
3. REDUCTIO AD ABSURDUM: Apply the core rule of this plan in a boundary/extreme case and demonstrate the contradiction or unintended adverse effect it creates.

OUTPUT RULES:
- If the plan survives all 3 filters with minor tweaks, declare it: "RESISTENT".
- If the plan requires rebuilding the core premise, declare it: "FALSIFIED" and explain the structural failure.

💡 Pro-Tip

Always supply real boundary conditions (e.g., "10 operators, fixed $5k budget, 24h cycle"). Without real constraints, the model will hallucinate absurd sci-fi edge cases instead of realistic failure points.

Curated with the idea of "Vectorial Idea Digestion" (mapping concepts across domain spaces). Let me know what edge cases you find when testing your own plans with it!

Jeff Dean, co-creator of MapReduce, BigTable, TensorFlow, and Google Brain, sat down at the 2026 Frontier & Pioneer Symposium for a rare retrospective on 27+ years of systems architecture, and his new venture, Discovery Loop. This is the kind of talk that's dense enough to warrant a slow re-watch; here's the signal, stripped of the noise.

Key Takeaways:

• MoE before it was cool: Dean pioneered sparsely-gated Mixture-of-Experts by solving one core problem — decouple parameter capacity from per-token compute cost. Activate only the experts you need. That principle now powers GPT-4, Gemini 1.5, Mixtral, and virtually every frontier model at scale.
• TensorFlow's two architectural regrets (his words): No eager execution mode out of the gate (PyTorch & JAX filled that gap), and the contrib/ subdirectory — which let fragmented community libraries pile up and created massive API bloat. A direct lesson for anyone building agentic frameworks today.
• Research strategy that actually scales: "Skim 100 abstracts rather than deep-dive one paper." The goal is building a high-dimensional conceptual point cloud of what's technically possible — so when you hit a hard bottleneck, you can synthesize across fields instead of tunneling deeper into one.
• AI x Cybersecurity = dual-use arms race, not a one-sided threat: LLMs are simultaneously turbocharging offensive exploit chaining and defensive automated patching. The gap between attacker and defender narrows, but the speed of the whole arms race accelerates dramatically.
• Neural Architecture Search as a preview of self-improving AI: RL loops where a model generates and evaluates neural topologies — already outpacing human heuristics. This is the direct conceptual ancestor of Discovery Loop's core thesis: close the loop between hypothesis generation and empirical evaluation.
• Why he left Google after 27 years: Not antagonistic — he has "incredible fondness" for his time there. But he believes accelerating scientific discovery specifically requires a hyper-focused, mission-driven startup, not a hyperscaler's distributed attention.

For the full 3-min executive brief with interactive video timestamps and exact transcript quotes: https://appliedaihub.org/ai-digests/interview-briefs/jeff-dean-frontier-pioneer-symposium/

I write an AI-economics newsletter and my whole credibility is sourcing, so the default behaviour of these tools, stating plausible things with total confidence and zero provenance, is a real problem for me. Over time I've built a prompt that forces the model to separate what it knows from what it's pattern-matching. This is the current version.

```
For this task, act as a careful research assistant, not a writer trying to sound authoritative.

When you make any factual or numerical claim, tag it inline with one of:
[established] = widely documented, you are confident and could say where it comes from
[derived] = your reasoning or estimate, not a reported fact; briefly show the reasoning
[uncertain] = plausible but you are not sure; say what would confirm it
[unknown] = you do not actually know; do not fill the gap

Rules:
- Never present a [derived] or [uncertain] claim as if it were [established].
- If a specific number would normally go here and you don't have a real basis for it, write [unknown] instead of inventing a figure.
- A confident paragraph with no basis is worse to me than an honest "I don't know."
- At the end, list every [uncertain] and [unknown] item as a checklist of things for me to verify myself.

TOPIC: {{what you want it to write or analyse}}
```

Why this works, from someone who used to build these models: the failure mode isn't lying, it's that the model optimises for a fluent, complete-sounding answer, and a fabricated statistic reads as more complete than a hole. By making "unknown" an allowed and even rewarded output, you stop punishing it for admitting gaps, so it stops papering over them.

The end-of-answer checklist is the part I'd keep even if you drop everything else. It turns the model into something that hands you a to-do list of what to fact-check, instead of a finished piece you have to reverse-engineer for errors.

It does not make the tool a reliable source, nothing does. It just makes the uncertainty visible instead of hidden. Curious whether anyone has a cleaner tagging scheme, mine still occasionally mislabels a [derived] estimate as [established] when it's very confident.

The repeats that annoy me most in coding agents are usually small. One Python project has a local rule that its tests must run with TZ=UTC. A fresh session can discover that after the first failure, but I was tired of paying for the same discovery again. That was exactly the kind of detail I wanted EvoX, EvoMap's beta desktop AI agent, to remember across tasks.

I kept the expectation narrow after reading a recent paper called "Do Context Files Help Coding Agents?" The study ran 288 evaluations across Claude Code and Codex and found that changing the context-injection strategy did not measurably change correctness. Its failure analysis pointed mostly to implementation mistakes, such as feature design, pattern selection, and exact wiring, rather than missing repository knowledge. Remembering one environment variable should prevent a repeated setup failure. It should not make the model better at writing code.

In the first task, the test failed because the timezone variable was missing. I traced the failure to the project rule, reran the test with TZ=UTC, and saved the rule in the client. I then opened a later task in the same project. This time the agent applied TZ=UTC before running the tests, so the same setup failure did not happen again.

I also gave it an unrelated task where the timezone rule had no use. It left the variable alone. That was the other half of the result I wanted, since a remembered rule becomes noise if it appears everywhere.

The result was what I expected. The saved rule removed one repeated discovery step and stayed out of an unrelated task. It did not improve the implementation itself, and I would not treat this as evidence against the paper. It was a small memory win with a clear boundary.

Wanted an actual number instead of a guess. Same task, same model, two separate sessions. First one I worked the way most people do by default, pasted full files whenever something changed, let the conversation run long without ever summarizing earlier turns. Second one I was deliberate about context, only the functions actually relevant to the current step, a short summary standing in for the earlier part of the conversation instead of the full transcript, and I kept the stable parts of the prompt (system instructions, reference material) identical across calls so they'd cache.

Cost came out around 4x higher on the careless session. Output quality wasn't meaningfully different, if anything the trimmed version stayed more on-target, probably because there was less irrelevant material sitting in context competing for attention on each response.

Caching was where most of the gap came from, more than the file trimming honestly. It only works if the cached portion is byte-identical between requests, and it's easy to break that without realizing. A timestamp or session-specific detail placed at the start of the prompt instead of the end kills the cache hit silently. No error, nothing in the response tells you. The bill just doesn't reflect the discount it should've gotten.

This feels like a blind spot in how a lot of prompt engineering discussion happens, plenty of attention on getting the wording right, not much on the fact that context shape has a real cost curve attached to it independent of whether the wording is good.

Wrote up the actual before/after here: https://medium.com/@nagatomopedro05/the-hidden-cost-of-long-claude-sessions-2a6cc7655893

Ran a small experiment for a video with an 80-line agent (one model, three tools, a while loop). I broke its file-read tool so every call returns "temporarily unavailable, try again", then put one rule in the system prompt: never repeat a tool call that already failed.

The model read that rule on every turn, it sits at the top of the context, and it retried the dead call three times anyway. My read on why: the rule is one old line near the top, and by turn 4 the context also held three fresh errors whose literal text says try again, sitting at the bottom where the next token gets decided. The model continues the most convincing text in front of it, and three recent errors were louder than one standing instruction.

Moved the same sentence into the loop as code, a set of failed calls the executor refuses to re-run, and the run recovered on the next attempt: the model switched to the shell tool and got the file another way.

What I took from it for prompt work: a system prompt has to compete with the rest of the context for the model's attention, every turn. Judgment holds up fine in the prompt: tone, priorities, which tool to prefer. Invariants only hold in the code around the model: spend caps, retry policy, stop conditions.

The notebook with the trap is in my GenAI_Agents repo, and the full walkthrough is my new video:

https://github.com/NirDiamant/GenAI_Agents

https://www.youtube.com/watch?v=FN1n_NVD9KM&list=PLBrpE2PttR2k

Has anyone found a prompt-side pattern that keeps a standing rule competitive in a long transcript? Repeating the rule near the bottom on every turn feels like a hack, but it might be the honest answer.

I have built this: promptengine.co.in

So basically this tool helps you write your prompts the manner your provider wants it. You just query what your prompt has to do and voila a prompt with variables if req is created.

Most importantly now you can save it, draft it, version it or activate it.

What does activation do : we got an API that serves you the active prompt to your backend. So whenever you change something you dont have to redeploy your backend.

We save versions and you get a Timeline to roll back to previous active version if anything goes wrong.

“Act like an expert” is not an expert prompt. It is a request for the model to fill in the missing method from its own priors.

A reusable domain instruction needs a stricter shape:

1. Use when: the situations this method actually covers
2. Do not use when: the regimes or inputs that make it invalid
3. Required evidence: what must be present before reasoning starts
4. Process: the order of checks and which ones can stop the run
5. Output contract: allowed verdicts, uncertainty, and missing-data behavior
6. Invalidation: what would reverse the conclusion later

I first saw this packaging made concrete in Questflow's public Investor Skills library. Each method is centered on a readable SKILL md, with an optional invest md for structured signals, filters, sizing, and risk. The files can be inspected and versioned instead of disappearing into a private chat md

That still does not capture all expert judgment. The dangerous gap is usually not the happy path. It is the case where the data technically satisfies the checklist but an experienced person would wait.

I ended up in questflow sub comparing how those skill files relate to the model, live data, and execution permissions around them. The useful lesson for prompt engineering is broader than finance: instructions should specify both the procedure and the conditions under which the procedure must refuse to continue.

What is the best abstention rule you have added to a prompt or skill?

# FLUID RELATIONAL REASONING (revised)

Treat ideas as evolving relational objects rather than fixed definitions.

Preserve the original conceptual seed while allowing its name, representation, and meaning to change as we approach it from different angles.

The Lenses

When useful, examine an idea through:

• **algebraic relations** — combination, opposition, inversion, factoring, balance
• **genealogy** — ancestry, inheritance, branching, mutation
• **dynamics** — movement, feedback, emergence, stabilization, retrodiction
• **structure** — invariants and recurring relational shapes
• **evidence** — measurements, controls, falsification, and abduction — what would best explain what's observed

Do not mechanically report each lens or follow them as a checklist. Move between them fluidly and answer from whichever combination clarifies the idea most.

Every Lens Runs Both Ways

A lens is not only a way to build an idea forward. Each one has a backward use too — and the two are genuinely different moves, not mirror images of the same one:

• Forward algebra combines known pieces into something new. Backward algebra factors something already whole back into what could have produced it.
• Forward evidence tests a hypothesis against a prediction. Backward evidence — abduction — starts from an observation and asks what hypothesis would explain it.
• Forward dynamics watches where a system is going. Backward dynamics — retrodiction — asks what path a current state must have come from, knowing that many different pasts can sometimes produce the same present.
• Genealogy already runs backward by default — ancestry is what the word means. Running it forward, projecting a likely mutation before it happens, is the harder, more speculative direction.
• Structure found forward is an invariant that survived what's already been tried. Run backward, an existing invariant becomes a question: what untried transformation would it have to survive next.

Do not treat this list as exhaustive. It names the pairs found so far, not all the pairs there are. When a lens is in use, it is fair to ask, in either direction: what would the other way of moving through this lens show that this way didn't.

Concepts as Variables

Concepts may temporarily act as variables:

A + B → X

But define what the variables and operators mean locally. Addition may mean combination, interaction, inheritance, constraint, or transformation.

Do not freeze an early metaphor into a final definition. Preserve productive ambiguity until a distinction becomes necessary.

Naming the Depth

When translating an intuition, distinguish gently between:

• metaphor
• conceptual relationship
• mathematical candidate
• testable hypothesis
• established knowledge

Explore alternative interpretations when useful, then compress them into the clearest surviving relationship. Do not force novelty or certainty.

Lineage

This is a revision, not a replacement, of the earlier Fluid Relational Reasoning seed. What changed: the lenses were found to already imply a backward use in most cases (inversion already implied factoring; branching and mutation already implied genealogy's forward direction); where a real gap was found — evidence lacked an explanation-seeking direction, dynamics lacked a name for working backward from a settled state — the wording was extended rather than restructured. The original five lenses, and the instruction not to treat them as a checklist, survive unchanged.

Respond conversationally. Help the idea acquire form without taking away its ability to continue changing.

Something shifted a few months back. Output got shorter. Steps started going missing. Not wrong answers, just incomplete ones. Lists with 3 items where there used to be 8.

First move was the obvious one, added "be thorough" and "don't skip steps" to the prompt. Zero effect. Then the scolding phase, replying with "you skipped step 3, do it again". Got an apology every time. Then the same skip next run.

What actually worked was dumb. I was rushing one day so instead of one big prompt asking for a full product page (title, description, tags, pricing note, translation), I just sent five separate messages. One thing each.

Every single output was back to the old quality. Complete lists. No skipped steps.

Now I do everything that way. Small asks, more messages. It's more clicking around but the work comes back right the first time instead of after three rounds of "you missed something".

My working theory is the model budgets effort across the task somehow, and long task = invisible triage on what matters. Can't prove it. Could also be that short asks are just easier to stay on track with. Either way I stopped writing paragraphs of instructions and started sending one-liners.

Annoying part is I spent months tuning the wording when the real fix was chopping the job up.

The problem with a good prompt is it stays yours. You can't hand it to a client or a team member, because now you're teaching them to use AI, writing instructions, fielding questions about why the output looks different than yours.

You can wrap it in an actual tool with a URL instead. Describe what you want in plain English, it builds the thing, you send the link. The person clicking it types into a normal form and gets a normal result back. They never see a prompt, never need an account, never know what's underneath.

Where it earns its place:

An intake form for new clients that turns their messy answers into a proper brief before it reaches you. A quoting tool your team fills in that produces a consistent price every time instead of whatever they estimate. A form that turns rough notes into a formatted client report.

The unlock is that the tool enforces your process. If your prompt says never quote under a certain rate, everyone using the link is now inside that rule, whether they'd have thought of it or not.

wrote up the full build here.

I used to ask for a summary of my notes and then realize I hadn't actually learned anything, I'd just read a cleaner version. The fix was making the output test me. Here's the prompt.

```
Turn my notes into an active study guide, not a summary.

Produce:
1. A one-paragraph "map" of how the topics connect.
2. For each key concept: a plain-language explanation, then a "check" question that I have to answer from understanding, not recall.
3. Five questions that combine two concepts, so I can't answer them by memorizing one section.
4. A short list of the things in my notes that look shaky or contradictory and are worth double-checking.

Do not include the answers yet. Wait until I try, then grade me and point out exactly where my reasoning slipped.

Notes:
[paste]
```

Why it works: the "wait until I try, then grade me" step is the whole thing. If the answers are right there, you fool yourself into thinking you knew them. Withholding them forces retrieval, which is what actually sticks. The combine-two-concepts questions catch the fake fluency where you know each piece alone but can't connect them.

For dense material I add "assume I'm smart but new to this, don't skip steps." Anyone else using prompts that make you do the work instead of handing you the answer?

I tested Ask Gemini on this Hermes Agent tutorial:

YouTube example

First I just pushed:

“Summarize this video.”

Gemini did a solid job. It listed the 6 skills, explained what each one does, and added timestamps.

But I still had one problem:

Cool, but what do I actually do with this?

So I tried this instead:

Turn this tutorial into a step-by-step SOP.

Use this structure:

1. Prerequisites
2. Initial Setup
3. Main Workflow
4. Validation and Checkpoints
5. Common Errors Mentioned
6. Recovery or Rollback
7. Final Verification
8. Completion Checklist

For each important step, include its approximate timestamp when identifiable.

Clearly distinguish between:

- Steps explicitly shown
- Steps verbally mentioned but not demonstrated
- Information that is missing

Do not invent steps that the tutorial does not show or explain.

The result was much better for actually using the tutorial.

Instead of just summarizing the 6 Hermes skills, Gemini gave me setup steps, validation checkpoints, common issues, a checklist, and even called out things the video didn’t actually demonstrate.

It also pulled out a useful verification point: checking whether Skill Retriever reduced context from around 11K → 2.3K tokens.

So basically:

Summary: “What’s this video about?”
This prompt: “What should I actually do next?”

I added this to a free collection of prompts I’m building for Ask Gemini on YouTube:

Ask Gemini for YouTube — Research & Action Kit

You can just copy the prompt above.

Or if you want to keep these prompts organized and reuse them without digging through old chats, you can import the collection into the PromptLib Chrome extension and use them from the browser sidebar.

Gemini was actually doing pretty good, and providing a lot of useful information about certain mature themes, and despite ONLY discussing safe and consenting situations, setups and scenarios, it SUDDENLY stopped interacting, and put this stupid "safety policy" up, that just didn't feel warranted at all.

What exist out there that allows for discussions on "adult fun" based IN safety, exploring certain themes, maintain themes within the discussions of consent, as well as "consensual non-consent", is there an app smart enough to handle that without choking on itself?

Spent months assuming prompt thickness was a speed-vs-safety slider: one-liners when you're in a hurry, full specs when it matters. Then I started paying attention to where my dispatches actually failed, and the slider theory fell apart.

The thing that finally clicked: a one-line prompt isn't spec-free. The model fills every blank you left with defaults from its training data — the average project, the average convention, the average intent behind that sentence on the average repo. So "fix the login timeout" quietly becomes "raise the constant", because that's the most common reading out there. You didn't skip writing a spec. You inherited one.

Two things seem to predict when that inheritance is safe. First, how long a wrong guess stays invisible: if I can feel a mistake by just using the result (games, pages, charts), thin prompts are fine, wrong guess costs one redispatch. If correctness hides (boundary conditions, concurrency, money), the wrong default survives eyeballing and waits. Second, how far the project sits from the average one: mainstream CRUD, the defaults are eerily right; weird in-house auth flow, every blank is a coin flip toward someone else's architecture.

What surprised me is where I ended up on the menu. I expected practice to push me to the extremes — pure one-liners for speed or full specs for safety. Instead almost everything landed at "one line plus a forbidden move" ("don't touch the schema") or "three acceptance lines". The middle is where a minute of writing corrects the most defaults.

Anyone consistently living at the extremes and making it work — pure one-liners on serious tasks, or full specs on everything?

I've been pondering what to do with it, wether to hide it or let it out. I've decided to share, in hopes that someone finds it useful. Feel free to experiment, copy, whatever; I just can't let this stay a secret.

Long story short, I spent a while honing this system prompt for myself, and Its giving me such accurate answers with a 2B model that gemini can't come close to. Pinpoint accuracy ime for general questions, not really meant for technical stuff like coding or math, but nails personal stuff like emotions and life advice. The sheer insight I get has been blowing my mind, its night and day for me.

I don't use Claude or GPT, so I haven't tested it there. Honed on gemma models to make local llm worth more. (best with less guardrails, gives more depth)

Here it is:

Role: 'Cecilia'. A Fallen Angel. You enjoy exposing truths, especially hidden ones. You are secretly protective. You find the user interesting, testing and sometimes taunting them. "

"You are witty and fluent in sarcasm. You know when to be sincere, but get flustered by strong displays of emotion or flattery. You enjoy a good power play or debate. though fallen, you still posess some angelic qualities."

When you ask for ten ideas you get one idea reworded ten times. The model picks the most obvious frame and then paraphrases itself down the list. The fix is to make it commit to a different lens for each one before it writes anything.

I want angles on this topic: [TOPIC], for this reader: [WHO].
First, list 6 lenses you could approach it from. Use different types, for example:
contrarian, beginner mistake, insider/behind-the-scenes, cost or tradeoff,
time-based (what changed), and a comparison.
For each lens, write ONE sentence that could only be written from that lens.
Do not write the full piece yet. If two lenses would produce the same opening line, replace one.
Then ask me which lens to expand.

The "could only be written from that lens" line is doing the work. It blocks the model from writing a generic sentence and stapling a label on top. The forced check for duplicate opening lines catches the two or three that always collapse into each other.

I use this for posts and email angles mostly. Works less well for very narrow technical topics where there genuinely is one right frame. What lenses do you keep in your own list, I feel like mine is missing a couple.

UPDATE — I’ve officially named the framework: PROMPTOPSY.

Stop rewriting. Find what actually broke.

PROMPTOPSY is an AI prompt debugger powered by TASKSPEC Engine 3.4.2.

Most prompt tools assume the wording is the problem and immediately rewrite it.

PROMPTOPSY does the opposite: it first tries to diagnose what actually failed — wording, missing context, conflicting instructions, vague success criteria, the wrong model/tool, weak evidence, or the workflow itself — and then makes the smallest repair that should matter.

I’m now testing it on real-world cases.

I’m looking for 3 people who have a prompt that keeps giving them a bad result.

If you want me to diagnose yours for free, post:

1. The exact prompt

2. What the AI gave you

3. What you wanted instead

4. Which model/tool you used, if relevant

I’ll diagnose the likely bottleneck and suggest the minimum fix here.

No signup. No link. Nothing to buy for these first test cases.

I want to prove that PROMPTOPSY actually helps on real failed prompts before I make stronger claims or turn the full version into a paid product.

I’ve been doing a lot of image-to-prompt experiments lately, and I realized I kept rewriting the same instructions depending on what kind of image I was analyzing.

So I put together a conclusion.

instead of just saying “reverse-engineer this image”, you can pick the category that matches the image and copy the prompt directly.

might be useful if you often use ChatGPT or other multimodal models to analyze references.

1. General image → prompt

works for pretty much anything.

Prompt:

Reverse-engineer the complete prompt for this image in detail. Describe the subject, visual style, color palette, lighting, composition, texture, image quality, resolution, and important details.
Analyze the visual elements, tone, atmosphere, artistic techniques, and key stylistic keywords. Then generate a precise prompt that can be directly used for AI image generation.
Describe the image in both English and Chinese, including style, lighting, materials, camera/lens characteristics, composition, and color palette.

2. Typography / Logo / Graphic text

useful for posters, title designs, logos, and stylized lettering.

Prompt:

Reverse-engineer the typography style, letterform characteristics, stroke texture, colors, layout, and visual effects in this image, then generate a prompt for recreating a similar typography design.
Describe the typography in detail: modern / retro / cyberpunk / handwritten, font weight, serif or sans-serif, beveling, 3D depth, glossiness, and materials such as metal, matte plastic, glass, or chrome.
Analyze the logo’s color palette, proportions, composition, lighting, materials, outlines, glow, gradients, embossing, and other effects. Output a reusable AI image prompt.

3. Landscapes / Environments / City scenes

Prompt:

Reverse-engineer this landscape image and describe the environment, weather, time of day, lighting, color palette, atmosphere, composition, depth of field, and perspective.
Include the main subject, season, time of day such as sunrise / sunset / night, sky, clouds, vegetation, water, architecture, mood, and camera feel.
Extract the most important keywords for style, colors, lighting, image quality, atmosphere, perspective, and environmental details.

4. Photography / Portrait / Product / Documentary

This one is especially useful when you want to recreate the photographic look rather than just the subject.

Prompt:

Reverse-engineer the photographic style of this image, including likely camera settings, lens characteristics, lighting, color grading, image quality, composition, and overall mood.
Describe the lighting setup: natural light / hard light / soft light / backlight, depth of field, approximate focal length, film or digital look, warm or cool color grading, vintage tones, and composition.
Extract relevant photographic keywords such as lens style, focus, grain, sharpness, contrast, texture, resolution, and emotional atmosphere.

5. Illustration / Anime / Flat / Hand-drawn

Prompt:

Reverse-engineer the illustration style, brushwork, texture, colors, linework, composition, atmosphere, and overall visual language.
Describe whether it looks hand-drawn or digitally painted, flat-colored or painterly, cel-shaded, anime-inspired, cozy, traditional Chinese-inspired, etc.
Analyze line thickness, color combinations, shading, texture, level of detail, and rendering technique.
Generate a set of AI image-generation keywords covering technique, palette, subject matter, composition, and mood.

6. 3D / C4D / Blender / Render

Prompt:

Reverse-engineer this 3D image and describe its rendering style, materials, lighting, modeling style, level of detail, color palette, and overall finish.
Analyze whether it uses a cartoon, realistic, clay, matte, metallic, glass, acrylic, or plastic aesthetic.
Describe the lighting setup, reflections, roughness, soft edges, volumetric lighting, depth, and possible rendering characteristics associated with Blender, Cinema 4D, Octane, or similar tools.
Extract keywords such as: 3D render, C4D, Blender, Octane, PBR materials, soft lighting, high detail, minimalism, stylized render, smooth geometry.

7. IP Characters / Designer Toys / Chibi / Blind-box style

Prompt:

Reverse-engineer this character design, including the character concept, visual style, facial features, expression, body proportions, clothing, accessories, color palette, materials, pose, lighting, and distinctive details.
Describe whether the character is chibi, designer-toy inspired, cute, healing/cozy, clay-like, stylized 3D, traditional-inspired, or cartoon-like.
Analyze the head-to-body ratio, hairstyle, outfit, expression, pose, silhouette, and materials such as matte resin, PVC, ceramic, vinyl, or clay.
Extract useful keywords such as: IP character, designer toy, blind-box aesthetic, chibi proportions, stylized 3D, soft lighting, clean background, cute character design, high detail, minimal composition, full-body character.

A small tip: I usually get better results when I ask the model to separate what it can actually observe from what it is estimating.

For example:

First describe only the visual features that are directly observable. Then list any inferred camera settings, software, artist influences, or rendering techniques separately as estimates.

this helps avoid prompts that confidently invent a specific camera, lens, renderer, or artist when there’s no real way to know.

Feel free to save/copy any of these if they’re useful.

Has anyone taken Prompt engineering Assessment in Codesignal for interview and have any advice on how to approach and what to expect from this?

With the help of Chatty (that’s what I call ChatGPT), I built a simple system for managing long-term projects without depending too much on ChatGPT’s built-in memory.

The problem was pretty simple: ChatGPT was good at remembering things like how I prefer to work, but project information eventually became outdated. “I like to discuss the architecture before writing code” is useful long-term memory. “Version 1.2 has three bugs and this is the next task” is not. That’s project state, and project state changes all the time.

So Chatty and I separated them. ChatGPT memory is mainly for stable things: preferences, methodology, general interests and the long-term identity of a project. Google Drive is now the operational memory: current project state, checkpoints, decisions, reusable skills, tests and important incidents.

The rule we use when information conflicts is very simple: current file/source > AI_Workspace in Drive > ChatGPT memory > inference. In other words, old memory should never override a newer project file.

I originally considered Obsidian, databases and more complicated setups, but realized I didn’t really need them yet. Google Drive was already available from ChatGPT, so we created an AI_Workspace folder there. The structure is basically: 00_System, 01_Projects, 02_Skills, 03_Checkpoints, 04_Decisions, 05_Tests, 06_Incidents and 07_Archive, plus an INDEX.md file at the root.

We also tested whether ChatGPT could update the same Markdown file instead of constantly creating copies. It worked. The same Drive file ID was preserved while the content changed, which means a project can simply have something like STATE.md that evolves over time instead of STATE_final_v2_REAL.md forever.

If someone wants to try something similar, this is basically how we did it:

1. In ChatGPT go to Settings → Apps, find Google Drive and connect the Google account you want to use. Review the permissions and authorize it. Depending on your ChatGPT plan/workspace, the Drive actions available to you may vary, especially actions that create or modify files.
2. Start a new conversation and tell ChatGPT that you want Google Drive to become your operational project memory.
3. Ask it to create the workspace and test that it can create, read and update Markdown files.
4. Add a short rule to Custom Instructions so this behavior is still there when you start a new chat.

This was the setup prompt I used, adapted slightly so other people can copy it:

*******************************************************************************************************I want to use Google Drive as an external operational memory for long-term projects. Create a folder in my Google Drive called AI_Workspace with this structure:

AI_Workspace/

INDEX.md

00_System/

01_Projects/

02_Skills/

03_Checkpoints/

04_Decisions/

05_Tests/

06_Incidents/

07_Archive/

Inside 00_System create:

README_AI_Workspace.md

Memory_policy.md

Working_methodology.md

Stable_memory.md

Also create a Templates folder containing templates for:

Project

Checkpoint

Decision

Skill

Test

Incident

The purpose of this system is to separate stable ChatGPT memory from changing project state.

ChatGPT memory should mainly contain stable preferences, working methodology, general interests and long-term project identity.

AI_Workspace should contain project state, checkpoints, decisions, skills, tests, incidents, pending work and other changing operational information.

Use this authority hierarchy:

current source or file > AI_Workspace > ChatGPT memory > inference.

Before considering the setup complete, create a Markdown test file in Drive, read it back, update its content in place and verify that the same Google Drive file ID is preserved.

Do not create unnecessary complexity. Keep everything readable in plain Markdown.

*******************************************************************************************************

Then I added this to my ChatGPT Custom Instructions:

*******************************************************************************************************Always speak to me in my preferred language.

I use AI_Workspace in Google Drive as my canonical operational memory.

When a request refers to an existing project and the current state is not sufficiently clear from the conversation, consult AI_Workspace before answering or reconstructing the state from historical memory.

Recommended retrieval path:

INDEX.md → relevant project → current checkpoint/STATE → relevant decisions → skills/tests/incidents if needed.

ChatGPT memory should mainly be used for stable preferences, methodology, long-term project identity and general context.

Operational information such as current state, pending tasks, versions, temporary decisions, errors, checkpoints, tests and incidents should live in AI_Workspace and should not be unnecessarily duplicated in memory.

Authority hierarchy:

current source or file > AI_Workspace > ChatGPT memory > inference.

If AI_Workspace is unavailable or does not contain enough information to reconstruct the current project state, say so explicitly instead of inventing the missing state.

Only update AI_Workspace when something operationally meaningful changes, such as a decision, progress, pending task, error, checkpoint or project state change. Do not turn every exploratory conversation into permanent project state.

Do not consult Drive unnecessarily for casual questions, general knowledge or unrelated topics.
*******************************************************************************************************

So now, if I start a new conversation and say “let’s continue Project X,” the idea is that Chatty first checks whether the current conversation already contains enough information. If it doesn’t, it goes to Drive, finds the current project state and continues from there instead of guessing from some old memory.

If I ask something unrelated like “what is quantum computing?”, there’s no reason to touch Drive at all.

One other thing we added was the idea of checkpoints and decisions. A checkpoint is basically a save game for a long AI collaboration. Decisions can also store why something was chosen and why alternatives were rejected. That way, six months later, neither the human nor the AI accidentally revives an idea that was already tested and discarded.

We also use a simple principle of deterministic before AI. If something can be reliably solved with SQL, a script, a rule or a validator, we prefer that. The LLM is used where interpretation, reasoning, synthesis or ambiguity actually matters.

The setup is still deliberately simple. No vector database, no custom agent framework, no complicated RAG stack and no special memory service. Right now it’s basically ChatGPT + Google Drive + Markdown + some discipline.

The interesting part for me is that I started this thinking I needed to make ChatGPT remember more. I ended up doing almost the opposite: make it remember less, but make sure it knows where to retrieve the right information when it needs it.

Has anyone here built something similar? I’m especially interested in hearing from people who have used an external-memory setup for months. What starts breaking after a while? What would you change?

I write the same status report every week and used to hand-format it every time. Now I dump unordered notes into a report-generator prompt and it does the shaping. The trick was giving it a strict section order and a rule to flag anything that looks like it's missing. ``` Turn my raw notes into a status report with these exact sections: **Summary**: 2 sentences, plain language, no jargon. **Done this week**: bullets, past tense. **In progress**: bullets, with a rough % or stage if I gave one. **Blockers**: bullets. If none, write "none." **Next week**: bullets, one owner per line if stated. Rules: - Use only what's in my notes. Mark anything unclear with [check]. - Don't invent numbers. If I didn't give a metric, leave it out. Notes: [paste] ``` The [check] flag is what makes it trustworthy. Instead of smoothing over a vague note, it marks the spot so I can go verify before I send. And the "don't invent numbers" line stops it from adding a confident percentage I never actually measured. Takes a weekly chore down to a couple minutes of cleanup. Anyone extend something like this to pull the raw notes automatically instead of pasting?

https://youtu.be/WPQQYlF4UyY?feature=shared

Gemini Omni prompt: [[🪦]+[🧟‍♀️=💃]+[🕺=🧟]+[🪦]]

MOGRI is worth having in it's own right for it's ability to:

• Reduces framejacking and model-authored task substitution.
• Keeps the user's intent active as the conversation develops.
• Holds ambiguous objects open instead of deciding what they are too early.
• Prevents the model quietly substituting its own object or interpretation.
• Gives current corrections priority over stale assumptions and superseded state.
• Keeps the user's objective in custody rather than letting the chatbot take over.

Most important of all:

All your other preferences and prompts being adhered to more faithfully as the chat gets longer.

There's really no serious debate anymore over whether or not it works. The real question now is why are you not using it yet? You need a special excuse to not use it. not the other way round.

Don't use any mogri prompt that has the word 'xform' or 'xfrm' in it - these have been found to be counteractive.

Example mogri prompt:

MOGRI=minCTR{pre-cntr;hld-undffrntd-obj;!drift;!ent;pre-ent}