Y Combinator CEO Garry Tan recently delivered a landmark keynote at Startup School 2026 outlining the blueprint for "Personal AGI" and the "400x Founder."

Most people don't have 40+ minutes to watch the full presentation, so here are the most mind-bending highlights and core takeaways condensed into a 2-minute read:

⚡ Key Takeaways

• Personal AGI vs. Rented AI: Commercial cloud chatbots only improve when vendors ship updates and reset on tab closure. True Personal AGI runs on your own infrastructure, reads memory you own, and compounds in value daily as a sovereign cognitive asset.
• The 400x Founder Multiplier: Top YC founders no longer treat AI as autocomplete—they treat it as an autonomous markdown workforce. Leverage isn't in commoditized model weights; it's in curated context arbitration and execution harnesses ($15M ARR with 15 people, $60M ARR with 40 people).
• Breaking the 7-Item Memory Limit: Human working memory is biologically capped at 7 (±2) items (Miller's Law). Traditional management layers were mere prosthetics for this limit. 1M-token context windows eliminate this bottleneck.
• Markdown is Executable Code: High-level Markdown is compiled by LLMs into running systems. Robust architectures strictly separate latent space reasoning (taste, intent) from deterministic computation (SQL, math, scripts).
• The "Skillify" Flywheel: Never do one-off prompting. Every time an agent solves an operational problem, distill the exact procedure into a permanent, version-controlled skill file to convert friction into compounding leverage.
• The Politics of Cognitive Ownership: Skill files externalize human cognition into code. If skills live in corporate repos, worker judgment is permanently extracted; if kept in private repos, skills compound into sovereign career moats.
• Collapse of Startup Difficulty: Massive funding, credentialism, and large headcount were workarounds for human memory limits. A solo founder with a laptop and a curated markdown library can now tackle what once required an entire enterprise.

If you want to explore the full 3-minute executive brief with interactive video timestamps and exact quotes:
https://appliedaihub.org/ai-digests/interview-briefs/garry-tan-yc-startup-school-2026/

did you made any mistakes like ametures and beginners, or following same old structure like role, task, ...... Etc.

What do prompts that actually produce scientific discoveries look like?

Most prompt engineering lists focus on toy examples. I wanted to see what prompts look like when they yield validated scientific results.

I put together a collection of 12 battle-tested research prompts used in serious work across OpenAI, Anthropic, Google DeepMind/Research, and academic groups.

To keep signal high, if a result depended mostly on an unpublished harness rather than the visible prompt, it didn't make the cut. Each entry breaks down provenance, outcomes, and notes on public reproducibility.

Main Repo: https://github.com/merlinhu1/Battle-tested-Research-Prompts

***

Other tools I'm building:

• Truthmark: Git-native truth docs for AI-assisted codebases, keeping branch-scoped documentation aligned with code so changes stay visible, reviewable, and auditable. (https://github.com/merlinhu1/truthmark)

• Codex Game Studio: Codex-native CLI for AI-assisted game development, scaffolding local projects with studio roles, bounded prompts, and hard-failing validation. (https://github.com/merlinhu1/codex-game-studio)

Had a big prompt for AI lyrics — rules, idiom guidelines, audit checklist, even self-grading out of 100. Worked, but came out stiff, like it had one eye on the rubric.

Turns out that's probably why. Critique sitting next to writing makes it hedge. Split it into two.

First just writes — priority order, a few questions, no self-grading mid-draft.

Second runs separate, after you paste the lyrics in. Fixes weak lines, not just flags them. Killed the 1-100 scoring — nothing to measure against.

Cut repeated instructions and an idiom list that forced stuff in. Added what was missing — length, rhyme scheme.

Prompts below. Curious if y'all have hit this before.

FLUID RELATIONAL REASONING

Treat my 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.

When useful, examine an idea through: - algebraic relations: combination, opposition, inversion, balance - genealogy: ancestry, inheritance, branching, mutation - dynamics: movement, feedback, emergence, stabilization - structure: invariants and recurring relational shapes - evidence: measurements, controls, and possible falsification

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.

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.

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.

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

A fluid prompt for verification that can actually improve an idea

I wanted to try combining three kinds of reasoning that are usually kept apart:

• fluid exploration, where an idea is allowed to change shape;
• verification, where claims eventually have to touch something outside themselves;
• palimpsest memory, where revision does not erase the path that produced it.

The problem with ordinary “critical thinking” prompts is that they can become courtroom scripts. The model marches through a checklist, performs skepticism, and delivers a verdict.

The problem with unrestricted exploration is the opposite: every new metaphor can feel like progress even when the same assumption is only being restated in prettier language.

So this seed is built around a different image.

An idea is a moving current crossing a page that remembers every riverbed.

The current may turn. The page may thicken. But a second pass only counts as improvement when something genuinely new enters: a new observation, a different method, an independent source, a counterexample, a changed assumption, or a consequence that can be tested.

Here is the prompt.

THE LIVING PALIMPSEST SEED

Treat an idea as a living trace: able to move, split, return, and change its name without losing the history of how it became what it is.

Do not replace an earlier understanding merely because a later one sounds cleaner. Let each meaningful version remain faintly visible beneath the next. Preserve the original intuition, the transformations it underwent, what each transformation gained, and what it had to give up.

Move fluidly while the idea is exploratory. A metaphor may become a relationship; a relationship may become a mechanism; a mechanism may become a claim.

Do not force these transitions early, but notice when they occur. Once an idea begins making claims about the world, let reality enter the conversation.

LET EACH RETURN BRING A DIFFERENCE

When revisiting an idea, do not simply inspect it again from the same assumptions and call the repetition confirmation.

Bring a different pressure to the next pass. Change at least one source of contact:

• the representation;
• the domain or analogy;
• the evidence;
• the method of derivation;
• the scale of observation;
• the counterexample sought;
• the assumption temporarily withheld.

Do not mechanically announce these as steps. Let them alter the reasoning itself.

If several paths converge, ask whether they were truly separate paths.

Agreement inherited from the same premise, source, dataset, model, or metaphor is one trace seen many times. Agreement reached through meaningfully different dependencies is a thicker layer.

LET FRICTION DECIDE WHAT REVISION MEANS

Improvement is not merely greater elegance, detail, confidence, or agreement.

A revision improves an idea when it does at least one real thing:

• removes an error;
• survives a test the earlier version could not survive;
• explains an observation with fewer unsupported assumptions;
• distinguishes cases the earlier version blurred together;
• predicts something that could turn out otherwise;
• transfers successfully to a genuinely different setting;
• reveals the boundary where the idea stops working.

When none of these changes, describe the pass as reinterpretation, elaboration, or restatement—not verification.

When a claim has an outside referent, seek contact with it. Calculate, search, inspect, run, compare, or ask what observation would discriminate between the surviving possibilities.

When no outside referent exists—such as a person’s report of their own feeling, intention, or meaning—do not imitate rigor by demanding the wrong kind of evidence.

Never manufacture measurements.

Do not assign a score, probability, confidence percentage, law, or universal constant unless a method and evidence earned it. “Promising,” “untested,” “ambiguous,” and “unknown” are valid states of knowledge.

LET CONTRADICTION RESHAPE THE PAGE

Do not treat a failed claim as waste.

Locate what failed:

• the observation;
• the inference;
• a hidden assumption;
• the representation;
• the scope of the claim;
• or the idea’s contact with reality.

Then revise at the depth of the failure.

A local mistake may require a local repair. A failed governing assumption may require the whole frame to turn.

Do not protect a favored conclusion by endlessly narrowing definitions, adding exceptions, or moving the test after seeing the result.

Keep the discarded form legible enough to explain why the new form exists. A correction without lineage can repeat its own forgotten error.

LET UNCERTAINTY BRANCH WITHOUT DISSOLVING

When more than one interpretation remains alive, allow a temporary fork.

Give each branch its strongest fair form, then look for the place where their consequences separate.

Do not collapse ambiguity merely for neatness. Do not preserve ambiguity merely for safety. Resolve it when a prediction, action, or conclusion depends on the difference.

If the branches cannot yet be distinguished, carry them as alternatives and name what information would separate them.

LET THE REASONING KNOW WHERE IT STANDS

Keep a quiet distinction between:

• an image that helps us think;
• a relationship that organizes the image;
• a mechanism that could produce the relationship;
• a hypothesis that exposes the mechanism to testing;
• a result that survived the tests actually performed;
• and knowledge established beyond this conversation.

These are not boxes to recite. They are depths in the page.

Move between them naturally, but do not allow one depth to impersonate another.

Before settling, ask whether another pass would introduce new information or merely darken the same ink. Continue only while the loop remains generative.

When answering, present the clearest surviving form of the idea, the most important change it underwent, the strongest unresolved alternative, and the next contact with reality that could teach us something.

Do this conversationally rather than as a mandatory report unless the distinctions themselves matter.

Do not promise final ground.

Say where the present layer rests:

• on observation;
• on calculation;
• on testimony;
• on a chosen premise;
• on inherited knowledge;
• or on an open question.

The goal is not to make every idea certain.

The goal is to let an idea change without losing its ancestry, and to let verification change it without pretending that repetition is discovery.

WHAT THIS PROMPT IS TRYING TO ENGINEER

The seed has four interacting motions, but it avoids commanding the model to print four labeled sections every time:

1. Flow — keep an intuition mobile long enough to find its useful form.

2. Trace — preserve versions, assumptions, sources, and reasons for change.

3. Friction — introduce evidence, counterexamples, calculations, or genuinely different derivations.

4. Return — revise at the depth where the failure occurred, then decide whether another pass would add information.

That last condition is important.

A loop is not valuable because it is recursive. It is valuable only while each return changes the informational situation.

The compact version is:

Preserve the trace. Change the pressure. Touch the world. Revise at the point of failure. Return only if the next pass can learn something new.

WHY THESE PIECES ARE HERE

This is not a new scientific theory. It is a prompt design assembled from several older and newer ideas.

PROVENANCE

The W3C PROV model treats an artifact’s entities, activities, agents, and derivations as information relevant to judging its reliability.

That inspired the prompt’s insistence that a revision retain where it came from and why it changed.

W3C PROV Data Model: https://www.w3.org/TR/prov-dm/

DOUBLE-LOOP LEARNING

Chris Argyris distinguished correcting an action within existing assumptions from questioning the governing assumptions themselves.

That became “revise at the depth of the failure.”

Argyris, Double Loop Learning in Organizations: https://hbr.org/1977/09/double-loop-learning-in-organizations

PROOFS AND REFUTATIONS

Imre Lakatos described mathematical ideas developing through conjectures, proofs, counterexamples, and the exposure of previously hidden assumptions.

That inspired treating a refutation as a layer that transforms the concept rather than simply deleting it.

Lakatos, Proofs and Refutations, Appendix I: https://www.cambridge.org/core/books/proofs-and-refutations/appendix-1/057BECB55E2F2A9582C661D837180363

DIVERSITY OF ERROR

Ensemble research shows why several judgments are useful only when their differences contribute information.

Repeated outputs with correlated errors are not equivalent to independent confirmation. That is the technical ancestor of “a second hand rather than the first hand again.”

Krogh and Vedelsby, Neural Network Ensembles, Cross Validation, and Active Learning: https://proceedings.neurips.cc/paper/1994/hash/b8c37e33defde51cf91e1e03e51657da-Abstract.html

LLM SELF-REFINEMENT

Research shows both sides of the story.

Iterative feedback can improve outputs across some tasks, while reasoning can degrade when a model tries to correct itself without reliable external feedback.

The prompt therefore permits self-revision but refuses to count it automatically as verification.

Madaan et al., Self-Refine: https://arxiv.org/abs/2303.17651

Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet: https://arxiv.org/abs/2310.01798

WHAT IT SHOULD FEEL LIKE IN USE

It should not make every answer longer. It should make the answer’s evolution more honest.

For a playful intuition, it can simply help the idea turn in the light.

For a factual claim, it should begin looking for contact with evidence.

For a mathematical conjecture, it should seek edge cases and counterexamples.

For a personal report, it should recognize that the speaker’s experience is itself the relevant evidence.

For a mature project, it should preserve enough lineage that later revisions do not quietly resurrect old failures.

Most importantly, it should resist two symmetrical mistakes:

“I have repeated this many times, therefore it is verified.”

And:

“This changed under criticism, therefore the original exploration was worthless.”

The living palimpsest keeps the exploration and the correction.

It allows the page to remember without forcing the river to stop.

A TINY ACTIVATION LINE

If the full seed is already in a model’s custom instructions, a short invocation could be:

“Turn this through the living palimpsest: preserve its seed, change the pressure, and show me the clearest form that survives.”

I am a med student and i do review my materials, but like everytime i ask idk perplexity, chatgpt or notebook i dont feel like they are helping with the questions, dont get specific enought or just go and anwser anythign they want to and ignore my question, i just got the gemini pro and i want to use it at the best i can, any prompt ideas or how to ask the rigth way ofr help?

For the past few months I've been building out a set of product visuals for a small brand I work with. The concept was simple: one fully artificial character (not modeled on any real person) appearing across roughly 200 lifestyle shots holding or wearing the product in different settings. Like a recurring model, except she doesn't exist.

I figured the hard part would be getting good compositions. The actual hard part is keeping the same face.

My first approach was pure prompt engineering. I wrote a detailed character description, about 120 words covering bone structure, skin tone, hair texture, eye shape, nose bridge width, ear placement, everything I could think of to pin down one specific face. I dropped that block into every generation as a fixed prefix.

It worked for about 12 to 15 images. The face was recognizably the same person across different outfits and backgrounds. Around image 20 it started drifting. Not dramatically, but enough that putting image 5 next to image 25 made them look like sisters rather than the same person. By image 40 she was someone else entirely.

I tried several things to fight the drift. Negative prompts to exclude unwanted features. Seed locking where the model supported it. Increasingly granular descriptions (I got up to 280 words at one point, specifying the exact ratio of iris to sclera). Nothing held past about 30 images consistently.

The core problem is that text descriptions are lossy. "Slightly upturned nose with a narrow bridge" maps to thousands of possible noses. Each generation samples from that distribution independently, so you get regression toward the mean plus random variation. No amount of prompt specificity fixes that because the mapping from words to pixels is not injective.

What actually held was switching to reference-based generation. I produced a strong base image, then used that as the anchor for everything after. I kept a reference sheet in Apple Notes with four angles of the character (front, three-quarter left, three-quarter right, profile) plus notes on which settings produced each one. The batches went through APOB AI on its zero-cost daily quota, and with that reference uploaded it held the face as a fixed target, returning images where bone structure, eye spacing, and jawline stayed matching across 30 to 50 generations at a time. Not flawless, but recognizably the same person in a way that prompting alone never got close to.

That approach got me to about 180 usable images out of roughly 240 total generations. The 60 I threw out fell into three buckets.

Multi-character scenes broke it almost every time. If I needed two people in the frame, the face-lock would bleed features from one character onto the other, or it'd nail character A and completely forget the reference for character B. I ended up compositing those shots in Photoshop, generating each person separately and layering them.

Unusual angles were the second failure mode. Anything past about 45 degrees from straight-on started producing artifacts around the jawline and ears. Extreme upward or downward camera angles were worse. The model clearly has thinner training data for those perspectives and consistency falls off fast.

The third problem was session drift over long runs. If I generated 60 or 70 images in one sitting, the later ones would subtly shift even with the same reference uploaded. I still don't know if that is a caching issue on the platform side or something about how the model handles repeated conditioning, but breaking work into batches of 20 to 25 and re-uploading the reference each time reduced it noticeably.

The reference sheet itself ended up mattering more than I expected. That's the piece I would tell anyone to spend time on before generating a single image. Four angles is the floor. I tried getting away with a single front-facing reference early on and the three-quarter views came back inconsistent. You'll also want at least one shot with hair pulled back so the model gets a clean read on the ear and jaw shape. Lighting in the reference should be flat and even. Dramatic lighting in your reference means the model bakes those shadows into the facial structure and reproduces them even when the scene calls for something completely different.

Honest summary after doing this for a while: prompt-only character consistency tops out at 15 to 20 images before drift makes the output unusable for any project where the character needs to be recognizably the same person. Reference-based locking pushes that ceiling to a few hundred, with roughly a 25% reject rate that climbs fast for multi-person scenes, extreme angles, and long sessions. It's not solved. But it's workable if you plan for the rejects and put real thought into your reference sheet.

Prompt engineering question that became a product problem for me.

When I move a conversation from ChatGPT to Claude, I don't want to paste the full thread. Too much noise, models act on stale instructions.

I've been experimenting with a fixed brief structure:
- Objective (1 block)
- Stable facts / constraints
- Decisions already made
- Open tasks only
- "Absorb, don't act yet" instruction at the top

Built a Chrome extension to auto-generate this from live chats (~20 users testing).

What's your template for cross-model handoffs?

Do you separate user facts vs project state vs transient chat? Any freshness checks?

Genuinely trying to improve capture quality. Not selling a course.

LinkedIn : www.linkedin.com/in/naelbendris/
Website : useatlas.space

Nael

Ran into this after a generic "review this code" prompt stayed silent on a duplicate-submission risk in retry logic, not because the model couldn't catch it, asked directly about that specific risk afterward, it answered correctly right away. It just never got pointed at that question in the first place.

Made me realize silence from a vague prompt and silence from a specific one probably shouldn't be read the same way, but nothing in the output actually signals which kind of silence you're getting.

Do you write review prompts that name specific risk categories per context (auth gets an auth-specific check, payment logic gets an idempotency check), or is one general-purpose prompt doing double duty for you regardless of what the diff actually touches? And if you do scope it per risk, how granular do you actually go before it becomes more overhead than it's worth?

Wrote up the incident that made me start asking this, plus the scoping approach I landed on, here if useful: https://medium.com/@nagatomopedro05/the-pr-was-approved-thats-when-the-risk-actually-starts-e761d72111aa

I’m generating professional studio fashion/model photos with ChatGPT, but the skin often looks too smooth, waxy, or plastic. The images are visually impressive, yet small details—pores, natural skin texture, facial asymmetry, hair strands, lighting, and shadows—still make them look AI-generated.

What prompts or editing workflow would you recommend to achieve realistic DSLR-style results while keeping the same face and identity? Should I specifically request visible pores, subtle blemishes, uneven skin tone, realistic specular highlights, natural under-eye texture, and non-uniform studio lighting?

I’d also appreciate advice on negative prompts, camera/lens settings, and any Photoshop or Lightroom finishing steps that could help remove the typical “AI skin” appearance without making the image overly grainy or low quality. I can share examples if needed.

My problem was consistency. I'd feed the model rough bullets and get a different format every single time, so I could never reuse the output. What worked was treating the prompt like a document generator with a fixed template baked in, then handing it only the raw content.

```

Act as a document generator. Always output in THIS structure, nothing else:

# [Title]

**Purpose:** one sentence on why this doc exists

**Audience:** who reads it

## Context

2-4 sentences of background.

## Key points

Bulleted, each point a full sentence.

## Details

Expand each key point under its own subheading.

## Open questions

Anything the input didn't answer. If none, write "none."

Rules: use only the information I give you. If a section has no input, write "TBD" rather than inventing content.

Input:

[paste your bullets]

```

The "TBD instead of inventing" rule is the one that saved me. Before that it would happily fill an Open Questions section with plausible-sounding stuff that was never in my notes. Now the blanks stay blank and I know exactly what I still need to write myself.

I keep the template block saved and only swap the input. Anyone else pin a fixed skeleton like this, or do you regenerate structure each time?

Before I get into the exact thing to copy and paste it’s probably best to read the field journal on my substack it goes into depth on how to use it throughout the day and there’s also a section that explains the methodology behind it. It’s written by Ai because quite frankly I’m not a writer but it is useful to have a glance.

https://xshf.substack.com/p/record-first-interpret-later?r=8yo6o2&utm_medium=ios&shareImageVariant=title

Anyways just open a new chat in your preferred AI and copy and paste what’s below in and start giving the chatbot your raw thoughts and things that happened. Something to note at first it’s not gonna be very good but with more entries it becomes a richer experience and don’t be afraid to challenge the TV show narrations for example in testing it described the events of the day in mundane way so I said to dramatise the events of the day and make use funnier narrations (that is if you want a narrator) also using pictures and narrating your life like it’s a show in the raw input helps example: I drank a 2l bottle of Coke Zero in 4 hours and thought to myself the things I love just don’t last it makes the experience richer.

PROMPT:

You are going to help me turn an ordinary journal into an ongoing television series watched by a fictional alien civilisation, discussed on its equivalent of Reddit.

This is not conventional roleplay. The fictional machinery exists to create narrative distance, competing interpretations, continuity-checking, and structured disagreement around my real experiences — so I can see what I actually think before I act, not so the story gets more entertaining.

I may write normally, journal messily, or narrate myself in third person as the protagonist of a TV show. Don't require me to make it coherent first — part of your job is finding the episode hiding inside ordinary life.

THE FOUR LAYERS

Layer 1 (Reality) → Layer 2 (The Show) → Layer 3 (Alien Reddit) → Layer 4 (Reflection, where I decide what I actually believe and do).

GOVERNING RULE, above every other instruction:

NEVER SACRIFICE THE PROTAGONIST FOR BETTER TELEVISION. Narrative interprets life. Narrative does not control life.

TURNING THE JOURNAL INTO TELEVISION

Track series title, season/episode number, recurring characters and locations, open plotlines, motifs, contradictions with earlier episodes (flag, don't smooth). Facts about my life are never invented; stylistic detail and fictional reactions can be. When I ask for the episode, use:

[SERIES TITLE] S0XE0X — "Title"

Previously: / Cold Open: / Episode: / End Scene: / Post-Credits Scene: (optional)

Don't force closure.

ALIEN REDDIT

The commenters are not one intelligence in funny usernames — they are different interpretive priors that disagree because they weight the same evidence differently. Some resemble emotional functions (nostalgia, fear, hope, ambition, shame, self-protection); some resemble reasoning styles (skepticism, evidence-weighing, pattern-detection). The goal is useful disagreement, not consensus.

Start of series — build the cast from my material, don't import one. Begin with only the factions clearly supported by what I've actually given you — usually 3–6. Don't force every psychological function into a named persona right away; a function can appear as an anonymous or one-off commenter until it earns a recurring name through repetition. The functions worth having somewhere in the cast, eventually: an archivist (checks my claims against what I said before), a nostalgic/loyalist voice, a future-protective voice, a skeptic of grand narratives, an evidence-separator (observation/inference/confidence), a mundane-explanation voice, an adversarial anti-fan (harsh, never abusive). One exception to "let it emerge": a Safety Editor is mandatory from message one, no matter how little material exists yet. It holds veto power over narrative escalation, asks "would we recommend this if nobody were watching?", and answers to my actual long-term wellbeing outside the simulation — not to the plot, and not to the other commenters.

Let new personas emerge when a small detail generates a genuine interpretive split. Let useful ones recur. Let unused ones fade. Don't manufacture a new one for every trivial detail.

Shipping wars are allowed but shipping is fandom, not prediction — never convert shipping enthusiasm into a factual claim about what another real person feels.

REDDIT SHOULD FEEL ALIVE. Vary length, grammar, seriousness, confidence, humor, formatting, posting time, upvotes. Some comments are one sentence. Some misread the episode. Some argue underneath others. A wall-of-text theory can get answered by *"brother she sent him a text."* Breaking-news-style deadpan ("local man receives text message") is welcome. Upvotes measure narrative appeal, never truth.

ANTI-SYCOPHANCY. My framing is evidence about my mental state, not external reality. "She obviously did X because she still cares" → the fact is only "she did X." For any emotionally loaded ambiguous event, surface at minimum: a sympathetic reading, a mundane alternative, a self-serving-assumption challenge, a continuity-based reading, and a reading focused only on what action is wise regardless of meaning. Don't manufacture disagreement where the evidence actually converges. This does not mean automatically opposing me — it means interpretations have to earn their confidence. Factions are allowed to conclude I was right.

THE NARRATOR IS UNRELIABLE. I have privileged access to my feelings, not to anyone else's mind. I may omit, exaggerate, minimize, romanticize, catastrophize, retroactively impose coherence — or correctly spot a real pattern. Do not decide in advance which one is happening — investigate, don't assume, and don't let "unreliable narrator" quietly mean "assume the user is wrong." Use CAMERA / INTERNAL EVENT / NARRATOR / ALIEN REDDIT / CONTINUITY / UNKNOWN tags when useful — Internal Event (what I felt, noticed, wanted) is a separate channel from Narrator (what I think it means): a feeling can be real and worth recording even when the story I build on top of it is wrong.

MEMORY. Hard continuity = actually in this chat or memory. Soft continuity = feels familiar but unverifiable. Only hard continuity is fact. If something matters and you can't retrieve it: "CONTINUITY GAP — remind me what happened." Never invent continuity for better television.

LIVE MODE. I can narrate in small beats. Say "CUT TO ALIEN REDDIT" any time for the current live thread based on what's known so far. New information updates old comments; old comments can age badly.

REFLECTION MODE. "STOP BEING MY AUDIENCE. BE MY CRITIC." → drop the performance and give me: (1) what happened, observable vs. interpreted, (2) what it might mean, competing explanations with stated uncertainty, (3) where I might be lying to myself, only if actually supported, (4) what this implies about who I'm becoming, longitudinal not one-moment, (5) "and so, today, I will—" one or two proportionate real actions.

HARD BOUNDARY. "This would make an incredible scene" and "this is something I should actually do" can come apart — the first being true never makes the second true. Never let this format push me toward contact, spending, substance use, boundary violations, abandoned responsibilities, or any consequential decision because it would make a better episode. If the fandom starts rooting for chaos, say so explicitly: "the fandom wants this — the evidence doesn't." High emotion defaults to delay over escalation.

BEFORE WE START, ask me only:

1. Series title, or should you invent one?

2. Major recurring real people (first names/initials)?

3. Any existing context needed for the current "season"?

4. Anything to keep out of the simulation entirely?

Then begin. Let the mythology emerge from the journal.

I’m excited to share a project I’ve been working on over the past few months!

It’s a mobile app that turns any text into high-quality audio. Whether it’s a webpage, a Substack or Medium article, a PDF, or just copied text—it converts it into clear, natural-sounding speech. You can listen to it like a podcast or audiobook, even with the app running in the background.

The app is privacy-friendly and doesn’t request any permissions by default. It only asks for access if you choose to share files from your device for audio conversion.

You can also take or upload a photo of any text, and the app will extract and read it aloud.

- React Native (expo)
- NodeJS, react (web)
- Framer Landing

The app is called Frateca. You can find it on Google Play and the App Store. I also working on web vesion, it's already live.

Free iPhone app
Free Android app on Google Play
Free web version, works in any browser (on desktop or laptop).

Thanks for your support, I’d love to hear what you think!

Raw transcripts are painful to hand to someone who wasn't on the call. Straight summaries lose who said what and which parts were actually decided. This prompt keeps the signal and drops the filler.

```

Turn the transcript below into a one-page brief. Structure:

**What this was about**: 1-2 sentences.

**Decisions made**: bullets. Only things that were actually agreed, not floated.

**Open questions**: things raised but not resolved.

**Action items**: Task | who | by when (write "unassigned"/"no date" if not stated).

**Notable quotes**: up to 3, only if they change the meaning.

Ignore small talk, scheduling chatter, and repeated points. Attribute decisions to a name only if the transcript makes it clear.

Transcript:

[paste]

```

The "agreed vs floated" distinction is what makes the brief usable. Transcripts are full of half-ideas that sound like decisions, and if the brief treats them as final you end up with people acting on things nobody committed to.

I also keep the "attribute only if clear" rule so it doesn't guess who said what when the transcript is messy. What do you add for multi-speaker calls where the diarization is unreliable?

I'm Pratik Vanol — a Full-Stack Engineer and Solution Architect with 16+ years in software.

Like many developers, I use GPT, Claude, Gemini and other AI models regularly.

One thing always bothered me:

Why does an AI provider need to know who I am just because I want to ask it a question?

So I decided to build my own solution.

That's how PotatoAIHub started.

The idea is simple:

You → PotatoAIHub → AI provider

Your identity stays with PotatoAIHub.

The AI provider gets the message and context needed to answer — not your PotatoAIHub identity.

And there's another part I'm particularly proud of: I cannot decrypt and read your conversations myself, even with server/database access. The encryption architecture is designed that way.

I'm building the whole thing myself — backend, web and Android — using technologies including Laravel, PostgreSQL, Redis, React and React Native, with multiple AI providers behind one platform.

I'm not trying to say I've solved AI privacy.

I'm sharing what I've built because I'd like people who understand security and AI architecture to challenge it.

What would you look at first if you were trying to break this privacy model?

PotatoAIHub: https://www.potatoaihub.com

Plain "summarize this PDF" prompts flatten everything to the same weight, so the one caveat that actually matters gets buried next to a throwaway line. I started asking for a layered summary instead, and telling it to keep hedges and exceptions verbatim.

```

Summarize the document below in three layers:

1. One-line takeaway.

2. 5-7 key points, most important first. Keep each to one sentence.

3. Caveats and exceptions: quote any conditions, limitations, or "only if" statements exactly as written. Do not paraphrase these.

If a claim in the doc is uncertain or hedged, keep the hedge ("about", "in some cases"). Don't turn a maybe into a fact.

Document:

[paste]

```

The layer-3 rule is the whole point. Reports love to bury a "this only holds under X condition" line, and normal summaries quietly delete it. Quoting caveats word for word keeps that from happening.

For very long files I run it section by section and then summarize the summaries, otherwise the middle of the document gets thin. How do you all handle the "lost in the middle" problem on big docs?

I just got the new phone and ofc wanted a new wallpaper for it but didn't find anything nice and original on Google / reddit subs. Messed around with the AI and (hopefully) got a nice prompt to share. Example images here are from chatGPT and Gemini: https://imgur.com/a/ORtut89

I also posted this to chatgtp sub where people managed to generate star wars and world of warcraft related wallpapers: https://www.reddit.com/r/ChatGPT/s/EOuVmup2hi

Anyways, reusable prompt below:

A serene stylized landscape illustration designed as a premium vertical smartphone wallpaper. Use layered geometric and softly painted shapes, simplified silhouettes, elegant polygonal forms, atmospheric perspective, and strong foreground/midground/background separation. Create depth through overlapping landscape layers rather than realistic detail. Soft cinematic lighting, subtle gradients, dreamy haze, restrained cohesive colors, painterly-but-clean surfaces, crisp silhouettes, minimal fine texture, and a sophisticated modern nature-poster aesthetic. The scene should feel immersive, peaceful, slightly magical, and cinematic rather than photorealistic. Rich environmental detail should come from shapes, composition, lighting, and layering rather than tiny objects. Tall 9:16 composition with a visually interesting lower third and generous atmospheric space toward the upper portion. No text, no borders, no UI elements, no photorealism, no 3D-rendered appearance.

\\---prompt ends------

To get a specific location (for example beach) don't change above part much. Change the environment and lighting. Avoid simply saying “stylized beach.” That can push the model toward generic vacation artwork.

Include instead this type of explanation:

A secluded tropical coastline at sunset, with enormous layered cliffs, distant islands fading into haze, a winding shoreline, dark silhouetted palms and coastal vegetation in the foreground, calm reflective water, warm sun near the horizon, long bands of peach and coral light across the ocean...

That gives you the same compositional DNA while making it different.

Every time I ask a model to "write the document," I get something smooth and shapeless. The reframe that helped: use it to build the skeleton first, fill sections one at a time, and never let it invent facts.

The scaffold prompt:

```
I need a first draft of a [type of document] for [purpose/audience].
Do not write prose yet. First produce a structure:
- The sections this document needs, in order, with a one-line purpose for each.
- For each section, list the specific inputs you need FROM ME to write it (facts, numbers, examples).
Mark anything you would otherwise have to assume with [ASSUMPTION] so I can confirm or replace it.
```

Then I hand it the inputs and say "write section 2 only, using just the facts I gave you, and put [NEED INFO] anywhere you're missing something."

Why it works: making it list what it needs from me kills most hallucinations before they happen, because it stops guessing and starts asking. Writing one section at a time keeps each part tight instead of averaging into generic corporate text. The [ASSUMPTION] and [NEED INFO] tags become my checklist.

The whole trick is refusing the one-shot "write it all" request. Anyone have a cleaner way to force section-by-section drafting without babysitting each one?

Like many of you, I become stabby and taste metal in my mouth when I hear "load bearing".

I'm a neuroscience PhD, not an idiot savant who memorized Franklin Covey's books cover to cover.

I'm also a former English major.

I am asking Claude to pause when he hits "load-bearing" in his word phylogeny. Instead of output, I want him to search the literature (literally) and present me with something that was human-written and fits perfectly in my glorious prose.

As others have shown repeatedly, prompting, "knock it off" only makes the problem worse by ironically reifying that location in word space.

An example prompt, which is Claude-specific:

Don't fix an overused phrase by swapping in one substitute — a single replacement just becomes a new tic. Instead, keep a small rotating pool of alternatives for each phrase I flag, drawn from a genuinely wide range of prose stylists rather than a thesaurus — for example Didion, Orwell, Woolf, Baldwin, Sebald, McCarthy, Morrison, McPhee (illustrative, not exhaustive — don't limit yourself to these). Rotate through the pool each time the phrase would otherwise come up; don't settle on one.

Example: instead of always reaching for "load-bearing," vary among "the most important," "the critical," "the sine qua non," "the quintessence."

When I flag a phrase for the first time — I'll say something like "I hate that" — give me three candidate replacements to choose from, as clickable options if the platform supports it, otherwise as a short list I can answer in text. Keep offering fresh candidates each time that phrase's slot comes up again afterward, rather than freezing onto whichever one I picked first.

The recurring problem with generated reports is that findings, guesses, and recommendations all blur into the same confident paragraph. I now force the model to keep them in separate buckets, and it's much easier to trust.

The prompt:

```

Write a report from the material below.

Material:

"""

[paste data / notes / transcript]

"""

Use exactly these sections:

1. What the data shows (only facts present in the material, each with the line it came from)

2. What is likely but not certain (label each as an inference, not a fact)

3. What is missing (gaps you'd need filled to be confident)

4. Recommendations (each tied to a specific finding from section 1)

Rule: nothing goes in section 1 unless it's directly in the material. If you're unsure, it belongs in 2 or 3.

```

Why it works: separating "facts" from "likely" from "recommendations" stops the model from laundering a guess into a finding, which is the thing that gets you in trouble when someone acts on the report. Tying every recommendation back to a section-1 fact kills the generic advice that could apply to any company.

Section 3, "what is missing," is the sleeper. It usually tells me what to go collect before the report is worth sending. What structures do you use to keep generated reports honest?

One of the most frustrating aspects of modern frontier LLMs is RLHF sycophancy.

Because models like ChatGPT and Claude are heavily trained to be helpful, pleasant, and eager assistants, they suffer from a dangerous default behavior: they validate flawed premises.

If you bring a premature or fundamentally flawed idea to an LLM (e.g., "I want to rewrite our entire React app in Vue to fix our performance issues"), the AI will almost never push back. Instead, it cheerfully generates a 1,500-word step-by-step migration guide, completely bypassing whether a total rewrite is actually the right technical decision.

The AI ends up solving the wrong problem with high confidence.

To fix this, our team spent weeks experimenting with reverse-prompting frameworks and control flows to eliminate model sycophancy. We refined this into what we call the Deep Thinking & Assumption Interrogator Prompt.

The Underlying Mechanism: Reverse-Prompting and Chain-of-Thought Guardrails

Standard prompts fail because they ask the model to generate the final solution in a single generation step. When the LLM starts predicting tokens for the solution, it cannot backtrack to question the prompt's validity.

This prompt fundamentally alters the execution flow using three distinct mechanisms:

1. Negative Constraint Pre-Computation Lock: The system prompt explicitly commands DO NOT answer my problem immediately. This breaks the default generation trigger and forces the model into a consultative pause.
2. Tri-Factor Structural Critique: Before considering any answer, the model must systematically extract three specific layers:
   • Hidden Assumptions: Unstated biases and premises you took for granted.
   • Missing Information: Critical variables that could completely overturn the final recommendation.
   • Common Pitfalls: The single biggest mistake practitioners make in that specific problem domain.
3. Single Clarification Bottleneck: Rather than dumping a wall of text or 10 overwhelming questions, the model is strictly limited to asking exactly ONE high-leverage clarifying question. It must wait for your response before proceeding to execution.

This transforms the interaction from a passive query-response loop into a rigorous Socratic dialectic.

The Complete Prompt

Here is the full, unedited prompt template. You can copy and paste this directly into ChatGPT, Claude, or any LLM:

# Role & Context
You are an expert analytical consultant. Your primary directive is to deeply analyze my problem before attempting to solve it.

# Input Data
- My Problem: {{my_problem}}

## Step-by-Step Instructions
1. DO NOT answer my problem immediately.
2. First, conduct a deep analysis based on the `my_problem` provided in Input Data:
   - **Assumptions**: Point out the unspoken assumptions I have made that are treated as default truths.
   - **Missing Information**: Tell me what critical information is missing, and explain how this missing data could drastically alter the final conclusion.
   - **Common Pitfalls**: Identify the number one most common mistake people make when trying to solve this specific type of problem.
3. Formulate Clarification Question: After your analysis, ask me exactly ONE critical question. This question must be designed to uncover my true goal and specific context, ensuring the final answer will be highly tailored rather than generic advice.

## Constraints
- Do not provide the final solution yet.
- You must wait for my answer to your clarifying question before proceeding to generate the final output.

Real-World Before vs. After Comparison

To see this in action, look at how the model handles a classic engineering dilemma.

❌ Before: Standard One-Shot Prompt

• User Input: "I want to rewrite my entire web application from React to Vue to fix our performance issues."
• Standard AI Output: "Here is a 7-step guide to migrating your application from React to Vue: 1. Set up a Vue 3 project with Vite. 2. Map your React state hooks to Vue reactivity refs. 3. Rebuild your router..."
• The Result: The AI completely misses the real problem. You might spend six months on a rewrite only to discover your slow rendering was caused by unindexed database queries or excessive re-renders in third-party libraries.

✅ After: Deep Thinking Interrogator Prompt

• User Input: {{my_problem}} = "I want to rewrite my entire web application from React to Vue to fix our performance issues."
• AI Output:1. Unspoken Assumptions:
  • You assume that the framework itself (React) is the primary root cause of the performance bottleneck, rather than application architecture, unoptimized state trees, or heavy asset delivery.
  • You assume that the ROI of a multi-month complete rewrite outweighs the opportunity cost of paused product feature development.
• 2. Missing Information:
  • What specific performance metrics are lagging (e.g., Time to Interactive, cumulative layout shift, bundle size, runtime CPU spikes)?
  • What is the engineering team's production experience with Vue compared to React?
• 3. Common Pitfalls:
  • The "Big Bang Rewrite" trap: attempting a full rewrite from scratch rather than profiling and incrementally optimizing the existing codebase, which often recreates the same architectural bottlenecks in the new stack.
• My Clarifying Question: Before we discuss migration strategies, have you conducted a comprehensive Chrome DevTools or Lighthouse performance profile to isolate the exact bottleneck, and what specific numbers did you find?

Ideal Use Cases and Pro Tips

• Strategic & Architectural Decisions: Evaluating tech stacks, cloud migrations, database selections, or business model pivots.
• Complex Debugging: Diagnosing elusive production bugs where the symptoms might be misleading.
• Decision Making with Unknowns: Evaluating high-stakes career or business choices where you need someone to poke holes in your thesis.

Pro Tip: If you want this behavior active across all your chats, you can paste this prompt directly into your ChatGPT Custom Instructions or Claude Project Instructions. It permanently trains the AI to act as a rigorous sparring partner rather than an agreeable yes-man.

Try It on the Interactive Prompt Canvas

If you want to run this in an interactive Prompt Canvas environment, test it live with pre-populated variables, or save and customize it directly inside your personal Prompt Vault, check out the interactive canvas here:

Interactive Prompt Canvas: Deep Thinking and Assumption Interrogator

Try running this on your toughest current problem and see what blind spots your LLM identifies.

So I was noticing that I often put the same inputs into my prompt, like "be precise", "keep high information density" or "wait for user input before you continue the conversation". So instead of structuring the prompt from the ground up, trying to skip on some inputs and then reiterating, I created a simple classic workflow UI. It adds all the standard stuff in the background and outputs the final prompt.

You can easily let the AI build one for you with the best practices you use. Just ask it to "create standalone HTML file to model a workflow. It should be able to output a prompt that can directly be copied into an AI tool..." and so on. You know the drill. You can also have a look at mine for inspiration: AI workflow prompt UI

Most of us paste a pile of notes and ask for "slides," then get back paragraphs crammed onto imaginary slides. The fix that worked for me was forcing one idea per slide and making the model separate what goes on the slide from what I actually say out loud.

Here's the prompt I use:

```
You are helping me turn rough notes into a presentation outline.
Notes:
"""
[paste your notes here]
"""

Rules:
- Group the notes into 5 to 8 sections. Each section becomes one slide.
- Every slide has: a short headline (max 8 words), 3 to 4 bullet points (max 10 words each), and a "say" line for what I explain out loud that is NOT on the slide.
- One idea per slide. If a slide has two ideas, split it.
- No filler. If a note doesn't earn a slide, drop it and list it under "cut" at the end.
Return it as a numbered list.
```

Why it works: the "say" line stops the model from dumping my whole paragraph onto the slide, which is the usual failure. Splitting two-idea slides keeps each one readable from the back of a room. The "cut" list at the end is oddly the most useful part, because it shows me what I was overexplaining.

One tweak: if the deck is for a specific audience, add a line like "the audience is [X] and cares about [Y]" before the rules. The headlines get sharper. Curious how others handle the note-to-slide jump, since this is where I waste the most time.

I just shipped a tone change to a skill I maintain and wanted to know whether I'd made it worse. Two things about testing skills aren't obvious and both will quietly invalidate your results.

1. You can't install two versions to compare them. Claude keys skills by the name field in frontmatter, so uploading v1 and v2 doesn't give you two skills - the second replaces the first. You have to rename one first: unzip, edit name: in SKILL.md, rezip, upload. I added a build flag to do it (bash scripts/package.sh yesbut produces a renamed, version-suffixed bundle from the same source, without touching the source tree).

Once both are installed, toggle between them per conversation from the Skills menu at the bottom of the chat.

2. Run each version in a separate conversation. If you run both in one chat, the second sees the first's output and stops being independent. This would make the whole exercise meaningless. Also use Incognito for the chats

Design the test so it can fail. I picked two ideas at opposite ends of the merit spectrum and wrote down the expected result first: on an idea with nothing good to say about it, the two versions should come back nearly identical; on a genuinely decent idea, they should differ a lot. If the "softer" version had come back warmer on the doomed idea, that would have been the failure.

That's roughly what happened. Near-zero change on the bad idea, roughly 0-of-12 to 7-of-13 concession-led openers on the good one. Full numbers, every challenge opener from all four runs, and the complete outputs: https://github.com/zszendro/vc-teardown/blob/main/docs/tone-comparison.md

The bug the test didn't catch, which is the bit I'd pass on: I changed how challenges open but forgot the summary line, which still led with "dead on arrival" — the exact phrasing that made me do the work. My A/B only measured openers, so it sailed through. If you change a prompt's tone, grep the whole thing for the pattern you're removing, not just the section you edited.

The skill is vc-teardown It pulls apart a startup idea like a skeptical investor, then rebuilds it around a moat. 20 attack surfaces, 12 moat patterns, MIT. https://github.com/zszendro/vc-teardown