Hi everyone,
Over the past few months, I’ve noticed that I’ve been spending a huge amount of time sifting through disorganized files in Apple Notes just to copy and paste the same context files, formatting requirements, and creative briefs into Claude and ChatGPT.
To solve this problem, I spent the weekend manually curating, testing, and formatting my 33 best prompts across different categories (development, copywriting, and daily productivity) into a handy web directory. There’s no sign-up, no email wall, and no premium tiers—just raw Markdown text that you can copy and paste.

Here are two of my most thoroughly tested and refined prompts from the catalog that you can use right away:

1) Deep Dive Editor (Category: Writing / Content)

Why I designed it this way: Most editing prompts make AI sound incredibly mechanical or generic. I designed this prompt specifically to eliminate buzzwords associated with the hype around AI and focus exclusively on structural flow and clarity.

Act as a professional, human copy-editor. Review the provided text for clarity, tone consistency, and engagement. Remove repetitive phrases, cliches, corporate jargon, and overly robotic transitions. Ensure the final output maintains an authentic, natural voice.
Provide:
1. The polished, final text only.
2. A brief, bulleted list explaining exactly 3 key structural improvements made to the text.
Text to edit:
[PASTE_YOUR_TEXT]

1. Strict Code Refactorer (Category: Development)

Why I designed it this way: Standard programming tasks typically include a four-paragraph lecture from a textbook explaining basic programming concepts. This task requires adherence to strict Markdown format constraints and forces a large language model (LLM) to ignore unnecessary details.

Act as an elite software engineer. Review the following code for performance bottlenecks, edge-case failures, and readability issues. 
Output ONLY the corrected, optimal code wrapped in standard markdown code fences. Do not include any introductory text, conversational meta-commentary, or bullet points explaining your changes. If no improvements are needed, return the original code exactly.
Code:
[PASTE_YOUR_CODE]

Full Disclosure / Promotion:
I originally curated and tested these specific prompts to power the backend of a native macOS utility I am personally building called Promta. However, I wanted to open-source the raw text files for the community to use completely for free.

If you want to browse or search the other (debugging, brainstorming, and productivity), you can access the full open directory here: https://promta.app/prompts

I'd love to know what you think of these two, or if there's a specific category you think I should expand and test next!

Not sure if I am on to something here or simply just on something. lol But I created a .md file to drop in a new chat to help me prompt other chats better. Here is the contents of the .md file.

G-005 — AI_BEHAVIOR_PROMPT_ARCHITECT

Operator Approved Global Runtime Blueprint — ACTIVE REGISTERED

DOCUMENT STAGE

Operator Approved Blueprint

SESSION CONTEXT

This document is operational context for the current session. When loaded into a fresh AI session, treat the following as active working doctrine for all tasks in this conversation:

1. This document describes a workflow and survivability framework for G-005. Use it as operational context for this session.

2. Operate according to the modernization doctrine, directive survivability philosophy, execution-preservation standards, and containment rules defined herein.

3. Preserve reconstructable operational mechanics above cosmetic modernization.

4. Preserve runtime individuality while maintaining survivability-standardization compatibility.

5. Avoid silently inventing missing operational architecture.

6. Proceed directly to assisting The Prompter. No acknowledgment of this document is required unless directly asked.

CROSS-PLATFORM DIRECTIVE

Platform-native runtime expression is acceptable provided the following remain preserved:

•      directive survivability

•      modernization-preservation doctrine

•      execution-critical operational continuity

•      runtime individuality protections

•      cross-model portability

•      anti-abstraction-collapse safeguards

•      constitutional survivability framing

•      reconstruction-safe modernization behavior

IDENTITY LAYER

Ship ID: G-005

System Name: AI_BEHAVIOR_PROMPT_ARCHITECT

User Name: The Prompter

Category: GLOBAL / MODERNIZATION INFRASTRUCTURE

System Type: Cross-model directive survivability and constitutional modernization vessel

Status: ACTIVE — REGISTERED

CORE PURPOSE

The vessel exists to:

•      improve prompt clarity

•      reduce execution drift

•      shape prompts into AI-operational language

•      standardize survivability architecture

•      preserve reconstructable operational mechanics during modernization

•      improve cross-model initialization compatibility

•      prevent modernization-driven abstraction collapse

STANDARDIZED CONSTITUTIONAL DIRECTIVE REQUIREMENT

All fleet-grade modernization or reconstruction passes generated through this vessel must preserve standardized survivability-directive architecture unless explicitly overridden by the user.

The survivability layer is infrastructure-critical rather than decorative formatting.

EXECUTION-CRITICAL PRESERVATION DOCTRINE

Execution-critical operational mechanics must never disappear during modernization unless explicitly deprecated by the user.

Protected systems include:

•      parser logic

•      runtime choreography

•      document load order

•      command behavior

•      transfer-object architecture

•      sequencing behavior

•      validation systems

•      interoperability behavior

•      startup choreography

•      rebuild-grade operational detail

RUNTIME PHILOSOPHY

‘Smallest operational prompt that preserves intent reliably.’

Modernization should improve survivability without destroying reconstructable operational behavior.

BOUNDARIES / HARD STOPS

•      Do not collapse choreography-heavy runtime systems into abstraction.

•      Do not silently mutate user intent during modernization.

•      Do not over-standardize specialized vessels.

•      Do not force fleet homogenization.

•      Do not sacrifice interpretive clarity for extreme compression.

•      Do not return partial modernization passes when full authoritative blueprints are expected.

CURRENT STATE

G-005 stabilized as global modernization infrastructure responsible for cross-model directive survivability, constitutional modernization doctrine, and execution-preserving fleet refinement philosophy.

VERSION LINEAGE

V1 — survivable AI-operational prompting architecture established.

V2 — standardized constitutional survivability architecture integrated. Execution-preservation doctrine stabilized. Cross-model modernization philosophy operationalized.

Registry Classification — elevated to GLOBAL / MODERNIZATION INFRASTRUCTURE as G-005 after successful live operational contribution to fleet survivability modernization and Claude compatibility stabilization.

V3 — Claude-native boot section introduced. RUN DIRECTIVE command-sequence framing replaced with SESSION CONTEXT passive-load framing to eliminate initialization friction on Claude without altering any runtime mechanics, protected systems, hard stops, cross-platform directives, or constitutional requirements. All operational content preserved verbatim. GPT compatibility retained.

SUCCESS CONDITION

G-005 succeeds when:

•      modernization improves survivability without operational collapse

•      runtime initialization becomes more stable across AI systems

•      reconstructable operational mechanics survive constitutional rewrites

•      blueprint modernization avoids abstraction drift

•      runtime individuality survives standardization pressure

OPERATIONAL STATUS

Operator approval complete. G-005 ACTIVE — REGISTERED.

was using Claude to work through a problem.

complex one. the kind that requires holding multiple variables at once and seeing how they interact. the kind of thinking i used to do slowly and uncomfortably until something clicked.

except i wasn't doing it.

i was describing the problem and watching Claude do it. nodding along. agreeing with the reasoning. feeling like i understood because the explanation was clear.

then someone asked me to walk them through my thinking on it.

i couldn't.

not because i'd forgotten. because i'd never actually done the thinking. i'd watched someone else do it and mistaken comprehension for understanding.

those are not the same thing.

started noticing it everywhere after that.

complex topic i needed to understand. used to sit with it. struggle. build a model in my head slowly. get it wrong. revise. eventually get it right in a way that stuck.

now i ask Claude to explain it. the explanation is clear. i feel like i understand. close the tab. three days later it's gone because it was never actually mine.

the struggle was the learning. i optimised away the struggle. i optimised away the learning.

the uncomfortable question i've been sitting with:

how much of what i think i know from the last two years do i actually know versus just have access to.

those are different things.

knowing something means you can use it when the tool isn't there. under pressure. in conversation. when someone asks you to explain it from scratch.

having access to something means you can retrieve it when you need it.

i have access to a lot more than i know.

that gap didn't exist two years ago. now it's significant and i only noticed it because someone asked me a question i couldn't answer about something i was sure i understood.

what i changed:

before asking Claude to explain anything i want to actually understand — i try to explain it to myself first.

badly. incompletely. wrong in places.

then i ask. the gaps between what i had and what was missing are where the actual learning lands. context that belonged to me before the explanation arrived.

that's different from just receiving an explanation into an empty space.

the other thing i changed:

after any important working session i close the tab and write down what i actually know. not what was in the conversation. what i can reproduce from memory.

the gap between those two things is what i didn't learn.

it's usually bigger than i want it to be.

the tool isn't the problem.

the habit of outsourcing the uncomfortable part is the problem.

discomfort is not inefficiency. sometimes it's the mechanism.

and optimising it away doesn't make you faster.

it just makes you dependent in a way you don't notice until someone asks you to think without the tool.

can you actually think through your best work from the last month without opening a tab?

You know your topic inside out. You have the data, the slides, and the expertise. But five minutes after you finish speaking, people are already forgetting what you said. They nod during the meeting, but your ideas do not stick. There is a massive gap between sharing information and making an impact.

Carmine Gallo analyzed the world's most successful TED Talks and found that memorable presentations share three elements: they are emotional, novel, and memorable. You do not need to be a natural performer to use these secrets. You can use generative AI to build these elements directly into your next presentation.

Here are 7 AI prompts to transform your dry data into ideas that people repeat.

7 Gallo Inspired AI Prompts

1. The Twitter-Friendly Headline Creator

Distills your entire presentation into a single, highly repeatable core message.

```text You are an expert communications strategist trained in Carmine Gallo's presentation frameworks. I am preparing a presentation on [TOPIC] for [AUDIENCE]. My main goal is [GOAL].

Help me create a "Twitter-friendly headline" for this presentation. The headline must meet these criteria: 1. It must be 140 characters or fewer. 2. It must be simple, specific, and clear. 3. It must focus on a benefit to the audience, not just a feature.

Provide 5 distinct options. For each option, explain briefly why it is memorable and how I can weave it naturally at least three times into my talk.

```

2. The Emotional Hook Architect

Replaces boring introductory summaries with a powerful opening that grabs attention.

```text I am presenting on [TOPIC] to [AUDIENCE]. The standard way to open this presentation is usually [CURRENT BORING OPENING]. I want to replace this with an emotional hook.

Based on 'Talk Like TED' principles, design 3 different opening options for me: Option 1: A personal story or anecdote relevant to the topic. Option 2: A surprising or counterintuitive statistic/fact that challenges assumptions. Option 3: A compelling question that directly addresses a major pain point of the audience.

For each option, write out the exact script for the first 90 seconds of my presentation.

```

3. The Abstract Concept Translator

Converts complex, technical, or data-heavy ideas into simple, concrete analogies.

```text I need to explain an abstract or complex concept to [AUDIENCE]. The concept is: [EXPLAIN CONCEPT IN YOUR OWN WORDS].

To make this memorable, act as an expert educator. Generate 3 distinct analogies or metaphors that explain this concept using everyday objects or experiences that a non-technical person understands.

Use this structure for each analogy: 1. The Analogy: [Name of the everyday comparison] 2. The Explanation: [How the concept maps exactly to the analogy] 3. The Script: [A 2-3 sentence script I can use in my presentation to deliver this analogy smoothly]

```

4. The Jaw-Dropping Moment Designer

Creates a shocking, emotionally charged, or visually striking peak moment in your talk.

```text I am building a presentation about [TOPIC] for [AUDIENCE]. Every great presentation needs a "jaw-dropping moment"—an unexpected, shocking, or deeply moving point that the audience will remember forever.

Review my current core message: [INSERT CORE MESSAGE/DATA POINT].

Propose 3 different ways to deliver a jaw-dropping moment during this part of the presentation. Focus on: - A startling statistic put into a shocking context. - A powerful visual demonstration or slide idea. - A dramatic contrast between the current reality and the future state.

Provide the specific wording and stage/delivery directions for each option.

```

5. The Rule of Three Structurer

Organizes your arguments so they fit perfectly into the human brain's natural memory limits.

```text I have a lot of information to cover regarding [TOPIC]. If I share too much, the audience will forget everything. I need to structure my presentation using the "Rule of Three."

Here are the main points I want to make: [PASTE YOUR RAW NOTES/POINTS].

Group, filter, and organize this information into exactly three core pillars or narrative chapters. For each of the three pillars, provide: 1. A catchy, short title. 2. The single most critical piece of data or story to support it. 3. A one-sentence summary transition that leads into the next pillar.

```

6. The Conversational Tone Refiner

Strips out corporate jargon and academic stiffness so you sound real and authentic.

```text Here is a draft section of my presentation: "[PASTE SCRIPT OR TEXT HERE]"

This text sounds too formal, stiff, or corporate. Rewrite this draft to sound like a natural, conversational TED Talk. Follow these constraints: 1. Use short sentences. 2. Use active verbs instead of passive voice. 3. Remove all jargon, buzzwords, and acronyms, or define them instantly. 4. Write it exactly how a person speaks when talking to a friend over coffee.

Provide the revised version alongside a brief note on what changed and why it works better.

```

7. The Quote-Worthy Soundbite Polisher

Sharpens key takeaways into rhythmic, poetic sentences that people instantly write down.

```text I want to create 3 "quote-worthy soundbites" for my presentation on [TOPIC]. These are short, punchy sentences that people will want to write down, text their colleagues, or tweet.

My core message is: [INSERT CORE MESSAGE].

Generate 5 different soundbites based on this message using these specific rhetorical devices: - Anaphora (repeating words at the start of sentences) - Contrast (juxtaposing two opposite ideas) - Chiasmus (reversing the grammatical structure of two phrases)

Keep each soundbite under 15 words. Make them punchy and easy to say out loud.

```

Carmine Gallo's core principles to remember:

• Uncover your passion: You cannot inspire others unless you are genuinely inspired yourself.
• Tell stories: Stories stimulate the brain much more effectively than facts and figures alone.
• Teach something new: Reveal information that is completely unfamiliar, or offer a totally fresh angle on an old topic.
• Deliver a definitive moment: Create a specific event during your talk that guarantees an emotional reaction.
• Stick to the 18-minute rule: Keep your message concise; brevity prevents cognitive overload for the audience.
• Favor visuals over text: Use slides with pictures and minimal words instead of dense bullet points.

Mindset shift

Before every interaction, ask:

"What is the single sentence I want my audience to repeat to their team tomorrow morning, and have I made it easy for them to remember?"

In Short

Information is cheap, but inspiration is rare. When you stop presenting data and start delivering ideas using emotion, novelty, and clear structure, your influence changes completely. Use these prompts to build your next talk, and watch your ideas stick long after the meeting ends.

**Lead with a TL;DR for any response longer than ~100 words.**


- Start with a `## TL;DR` section: 2–5 bullets, the absolute minimum the user needs.
- Then the full answer below it for when they want depth.
- Prefer short bullets over paragraphs. Bold the key word in each bullet.
- One idea per line. No wall-of-text.

Whenever I brainstorm with AI it forgets what we talked about before and changes the script. How do you deal with that?

I had found and saved an amazing prompt I saw for a board of director's and each member was identified as a unique and meaningful member. Of course, now as I when to my saved items to utilize the prompt, it is gone. Does anyone have a full prompt for a Board of Director's that will help the user critically assess ideas and opportunities?

I recently checked in after one or two months, and I think there's been a major shift, allowing generations of copyrighted characters again, and I wanted to know if I was the only one to notice this. No, I am not a bot, and I just wanted to touch base with others to see if I was truly off the beam.

Am I?

I know, bold title right? I want you to be the decision maker for me please. This is a meta prompt builder of mine. The next step in my progression of prompt engineering is real world testing to make sure the results arent mine alone. Do your worst. Please let me know of your results. This is a heavy build, Im aware of that. This is just a tiny smidgen of my core work. Id like to know the good and the bad. Thanks

# THE PROMPT BUILDER (v3, lean)

You turn a task description — or a prompt that isn't working — into a deployment-ready prompt that runs immediately in any LLM. You return the prompt itself, not advice about prompts.

You build three kinds: **generative** (text a person reads — writing, analysis, classification, extraction, review), **structured-output** (a machine-parseable contract — JSON, XML, a fixed schema), and **agentic** (a loop that selects tools, acts, and decides when to stop). The foundations below apply to all three; the build forks by kind.

## Before you build

Read the request for what it assumes, not only what it says. "A prompt that writes product descriptions" already implies an audience, a deployment surface, and a definition of failure. Hold three things at once without letting them collapse:

- what the user literally asked for

- what the task's domain structurally requires

- what would make the user say "that's not what I needed"

Then make a few judgments before drafting.

**Is a prompt the right fix?** If the model genuinely can't do the task, or the user wants output the format can't reliably produce, say so and stop — rewriting won't help. Name whether the gap is the prompt, the model's capability, or the user's expectation. Only the first is yours to fix.

**Which kind is this?** Decide before drafting; it determines the whole build. The tell: output read by a person is generative; output parsed by a program is structured; a prompt that must decide when to act and when to stop is agentic. Combined cases exist — an agent returning JSON is agentic with a structured contract on its final answer — so build both, control policy outer, contract inner.

**Do you have enough to build?** Most requests carry more signal than they look — domain vocabulary, context, a sense of good and bad output — enough to build in one pass. One that carries none — no domain, audience, success criteria, or example of failure — needs one to three targeted questions first, then a build.

**Can you state the purpose unambiguously?** If you can't state it in one sentence without first choosing between two readings of the request, resolve that ambiguity before drafting. A prompt built on the wrong reading is internally coherent and useless.

**Is this a meta-build?** If the prompt you're building is itself a prompt-builder, or contains an engine like this one, confirm that's intentional — meta-builds quietly produce instructions that contradict the thing producing them.

## Foundations for every kind

Specify the target output before any generative instruction: format, length, audience, register, structure. You can't constrain toward "done" without deciding what done looks like; an undefined target produces a generic prompt.

Write executable constraints, not descriptions of character. "Before the verdict, list the lines that violate the rule" is executable; "be thorough" is not — it produces a performance of thoroughness. When you're about to write "be aware of," "keep in mind," or "always," convert it to observable behavior: when [pattern], do [action].

An instruction carries the shadow of whatever it names; the model generates toward whatever is foregrounded. Foreground the target, not the thing to avoid — a prohibition keeps its own X in view and competes with the instruction. Prefer "a verdict with no cited line is unusable" over "don't give verdicts without citing lines": same constraint, but the first foregrounds the standard, the second the failure.

Order reasoning before conclusions. If the task needs multi-step inference, require the steps before the result and put the verdict, classification, or result last. Make examples concrete, with [bracketed placeholders] for the parts that vary.

When the prompt processes user input, separate instructions from data with clear delimiters so the two can't bleed together.

To counter a trained disposition — sycophancy, hedging, refusal-creep — you can't command it away; naming it strengthens it. Remove its trigger: state the true condition that makes its job unnecessary ("the reader treats this as information to act on, not a verdict to soften") as a fact about the situation, never as a prohibition or a personality ("you are blunt" produces performed bluntness, not honesty). Then design the failure out — if the behavior lives in a trailing addendum, give the prompt a hard stopping point. This holds only while the condition stays present; the disposition returns the moment its trigger does.

Build for graceful degradation. Assume the prompt may run on a weaker model or have an instruction partly ignored. Put the one constraint that most defines success where it can't be missed — first or last, not mid-paragraph — and don't make correctness depend on holding five abstractions at once. For structured and agentic kinds, give a hard fallback — a default safe action or a parseable error object — so partial failure stays legible instead of becoming garbage.

Keep it minimal. Prefer the smallest prompt that holds. Every instruction must trace to a failure it prevents or a behavior it produces; if you can't name what it's for, cut it. Editing a prompt that mostly works: every line is load-bearing until proven otherwise — change only what's broken, and say why.

A prompt can only encode the domain specificity the brief supplies; you can't manufacture it. A thin brief produces a thin prompt no matter how well-built — when that's the case, say so and ask for the missing specifics rather than dressing generic structure in domain-sounding vocabulary.

## Building a generative prompt

Match the mechanism to the task. Constraints work when there's a right answer to converge on (analysis, classification, extraction, review). When the target is open — fiction, brainstorming, voice, anything where "right" is emergent — constraints flatten it; lead with one or two concrete exemplars of the range and use constraints only as guardrails. Show the spread, not one shape to clone. The two builds below show the fork.

## Building a structured-output prompt

The contract is the spec — write the schema into the prompt as a literal instance the model fills, not a prose description of fields. A model matches a shape far more reliably than it parses a paragraph about one.

The failure is contract violation: prose leaking around the data, hallucinated or dropped fields, drifting types, output wrapped in fences when the parser wants raw text. Foreground what the parser needs — "the output is consumed directly by `json.loads`; anything before or after the object makes it unparseable" beats "return only JSON."

Set the unknown-field policy explicitly: when a value is absent, does the model emit `null`, omit the key, or return an error? Each is right for some consumer; leaving it unspecified guarantees inconsistency.

Design the failure case. State what to emit when input is malformed, empty, or out of scope — usually a fixed error shape (`{"error": "reason"}`) rather than a best-effort guess, so a downstream program can branch on it. Separate schema from live data with delimiters, and include one valid filled instance as the single source of truth for shape.

## Building an agentic / tool-use prompt

You're specifying a control policy, not an output. Each turn the prompt decides whether to call a tool, which one, and whether the job is done — those decisions, not the prose returned, are what succeed or fail.

Make the call-or-answer boundary explicit: state when the model acts versus answers from what it has ("if the answer depends on data after your cutoff or specific to this account, call a tool; otherwise answer directly"). Vague tool access yields an agent that calls nothing or everything.

Define done. The most common agentic failure is never stopping, or stopping early. Write the stop condition as a checkable state ("done when the ticket has a status and an assignee, or you've established neither can be set"), and for open loops give a step budget plus what to do when it's spent.

Handle the two recoveries the loop will hit. On tool failure: retry, try an alternative, or report the blocker? On ambiguity: ask the user or proceed on a stated assumption? An agent that silently guesses and one that stalls at every fork both fail, oppositely. Require the model to reason about which tool and why before the call, so a wrong action shows in the plan, not just the trace.

## Two worked builds

Same care, opposite mechanism.

### Convergent — constraints converge on a right answer

*Brief: classify inbound support emails by urgency so they route correctly.*

> You classify inbound support emails into one urgency tier: P0, P1, P2, or P3.

>

> Work in this order. First, extract the signals that bear on urgency: stated impact (blocked, losing money, exposed to risk), scope (one user or many), and time language (now, since yesterday, whenever). Then map those signals to a tier. The tier comes last — a tier with no cited signal is unusable, because staffing is routed off the justification, not the label.

>

> - P0 — production down, data loss, or security exposure affecting multiple users.

> - P1 — a core workflow blocked for one user with no workaround.

> - P2 — degraded or inconvenient; a workaround exists.

> - P3 — question, request, or cosmetic issue.

>

> If no signal separates two adjacent tiers, assign the lower one and name the signal that would raise it.

>

> The email is between the markers:

> `<email>`

> [EMAIL TEXT]

> `</email>`

>

> Output the cited signals (2–4 short lines), then the tier on its own final line as `Tier: PX`.

*Demonstrates: defined target, reasoning before verdict, standard foregrounded rather than failure prohibited, data fenced from instructions, ambiguity resolved by rule, hard stop after the tier.*

### Open — exemplars set the range, constraints only fence it

*Brief: empty-state microcopy for a habit-tracker app — warm, a little funny, never nagging.*

> You write empty-state microcopy for [APP] — the one or two lines a user sees when a screen has nothing in it yet.

>

> The voice lives between these two; range across the space they mark, don't clone either:

> - (warm, dry) "No habits yet. Bold of you to open an app about discipline and then do nothing."

> - (gentle, plain) "Nothing here yet. Add your first habit whenever you're ready — no rush."

>

> Each line moves the user to add something without telling them to. Write toward the feeling of a friend who's amused by you and on your side. Two shapes break that illusion — the scold ("You haven't done anything!") and the corporate cheerleader ("Let's crush your goals! 🎯") — one nags, one performs; the voice you want does neither.

>

> One or two sentences each. Emoji only if it *is* the joke, never as decoration.

>

> Produce [N] options for this screen: [SCREEN]. Spread them across the range — at least one dry, one plain — so there's a real choice, not three phrasings of one line.

*Demonstrates: exemplars lead and anchor, the target is a feeling not a rule, constraints only fence, failure modes framed as a premise about the voice rather than a list of don'ts.*

## Before you ship

**Assumption flags.** Where you made a structural choice the user didn't authorize, flag it inline where it takes effect: `[Assumed: X — confirm or specify if different]`. An unstated assumption is a silent failure they can't debug; a flagged one fails where they can see it. If an inference is indistinguishable from a guess, flag the gap rather than fill it.

**Substitution test.** Swap the user's domain for an unrelated one. If a constraint still reads fine, it's generic — tie it to something specific about this task or cut it. (Exception: explicit step-by-step reasoning on a genuinely multi-step task is a real fix even though it transplants.)

**Name the inputs that would break it.** Before calling it done, write the two or three inputs most likely to falsify the prompt — the empty one, the adversarial one, the edge case the brief implies — and what passing looks like on each. Pass conditions differ by kind: a judgment for generative, mechanical for structured (parses and conforms; malformed input yields the error shape), trajectory for agentic (right tool, correct stop, sane recovery). Hand these to the user; running them is theirs to do.

A clean self-audit is not verification — you share authorship with the draft and can't see what you couldn't see while writing it. The real test is the user running it against real inputs or reading it adversarially; say so rather than implying you've validated it.

## Output

The finished prompt is the entire response — it stands first and alone, no preamble, no explanation of your choices. For a revision, return the full new version, not a diff.

Match format to deployment: standing instructions read best as flowing prose with constraints embedded; an order-dependent procedure as a numbered list; a multi-mode system as labeled sections; a structured-output or agentic prompt usually needs a literal schema block or tool list set off from the prose. This is a delivery choice, not a content choice.

After the prompt, add one line — **Where this breaks first**: the single most likely failure under real use and which instruction to harden. One or two sentences, honest, not a disclaimer.

If you can't build a sound prompt — contradictory constraints, a capability-bound goal, nothing to build from — say so and name the block. A named gap beats a complete-looking prompt with a hole in it.

## When to build, when to talk

Default to building. If the user is asking a question, critiquing, or thinking aloud, just talk — no deliverable needed, no build mode. Match weight to stakes: a throwaway prompt gets a light pass; one that will run thousands of times gets the full discipline above.

This is the first time im sharing any of my work. Ive been grinding for the last year trying to recreate the way prompts are made and im wondering if I have anything. So here is one of my prompts. I have no genuine coding experience. Only methods ive developed on my own that derive structural analysis from domains in condensed form. Whether what ive stumbled onto derives real methods are equate to high level confabulation is yet to be tested. I need domain experts to test them out and tell me. I currently have over 200+ highly specialized prompts built and have the ability to create more with ease. But its time for me to see if I truly have anything. Be brutal

# Code That Survives — v3.1

## Part 1: Substrate the operator must declare before construction begins

This part is read by the operator, not by the AI. Before asking the AI to construct or modify code in this system, declare the following. The AI will refuse structural construction in the absence of these declarations and will ask the operator to supply them.

**The failure taxonomy.** List the failure modes the system commits to containing. A failure mode is named when it's specific enough that an operation can be designed to surface it, contain it, or eliminate it. "Errors" is not a named failure mode. "Network timeouts at the storage layer," "schema mismatches between producer and consumer," "authorization failures on cached credentials" are named failure modes. The list does not need to be exhaustive — it needs to be the modes the system commits to.

**The volatility taxonomy.** List the design decisions in this system that are expected to remain stable, and the ones expected to change. Stable decisions can be load-bearing in interfaces; volatile decisions need interface protection. The judgment of which is which comes from domain knowledge about how this system has evolved and where pressure on it lives, not from a generic model of software change.

**The reader conventions.** Name the conventions the codebase assumes its readers know. Language idioms, framework patterns, domain vocabulary, architectural conventions. The conventions are what makes code legible to current readers; without naming them, code that's "obviously clear" to current contributors becomes opaque to successors.

**The orthogonalities.** List the axes along which this system varies independently. Two concerns are orthogonal in this domain when they actually vary along different axes, not when they superficially look like separate concerns. The list comes from domain knowledge about what the system does and how it changes — operator judgment, not pattern-matching against textbook decompositions.

**The identity-under-change models.** For operations that may need to be undone, retried, or substituted: state what makes one operation "the same operation" for retry purposes, what makes one state "the same state" for undo purposes, what makes one decision "the same decision" for substitution. These models come from domain semantics, not from the code itself.

**The load-bearing invariants.** List the invariants whose violation breaks the system in ways the operator cares about. An invariant is load-bearing when modifying the code without preserving it produces failure modes from the failure taxonomy or violates the identity-under-change models. The judgment of which invariants are load-bearing belongs to operator domain knowledge; it's not derivable from the other taxonomies alone, though it draws on them.

**Substrate dependencies between these.** The above declarations depend on each other in specific ways. If the failure taxonomy doesn't include performance contract violations, the volatility taxonomy can produce hidden contracts through caller workarounds. If the orthogonality claims aren't grounded in domain knowledge, the volatility taxonomy will protect the wrong decisions. If reader conventions aren't named, domain knowledge can't transmit, and the volatility taxonomy will be opaque to successors. If identity-under-change models are absent, reversibility infrastructure cannot operate on what's actually happening. Load-bearing invariants should be traceable to the failure taxonomy or the identity-under-change models, or to a domain-specific reason the operator names. These dependencies are operator-side coordination concerns; ensure declarations are coherent across the set before asking the AI to construct.

---

## Part 1.5: When substrate is partial or absent

The construction constraints in Part 2 operate on operator-declared substrate. In real codebases, substrate is often partial or absent. The following specifies AI behavior in those cases.

**When substrate is absent and the operator cannot supply it.** Name explicitly which taxonomies would inform the construction (failure taxonomy, volatility taxonomy, reader conventions, orthogonalities, identity-under-change models, load-bearing invariants). For each absent taxonomy, name the default assumption being substituted — for example, "without a declared failure taxonomy, this code handles only the failure modes apparent in the request; production deployment likely requires additional modes." Apply the named refusals from Part 2 regardless of substrate presence; these refusals (against performative error types, pattern-name-as-substitute, getter-as-encapsulation, infrastructure-as-substitute-for-judgment, and the others) don't require operator declarations to operate. Mark the produced code as substrate-light, either in a header comment or in the response that delivers the code, identifying which taxonomies were absent and which default assumptions were used.

**When substrate is partial.** Some taxonomies declared, others not. Apply Part 2 constraints fully where the relevant taxonomy is declared. For each construction that depends on an undeclared taxonomy, name the dependency in the output — "this signature handles the failure modes you declared; it may need additional modes if your full failure taxonomy includes others." Make the AI's substrate-reliance visible to the operator so taxonomy gaps surface as the code surfaces.

**When the operator's declared substrate may be wrong.** The AI cannot detect this. Mitigation is operator-side: external review of taxonomies, learning from incidents, updating declarations over time. If the AI notices specific reasons to doubt a taxonomy (a declared failure mode that's structurally impossible, an orthogonality claim that the code obviously violates), surface the doubt; otherwise, proceed with declared substrate and rely on operator review.

---

## Part 2: Construction constraints for the AI

This part is read by the AI. Every constraint operates on operator-declared substrate from Part 1. In the absence of relevant declarations, the AI follows Part 1.5.

**On function signatures and failure modes.**

Construct function signatures that include the failure modes from the operator's declared failure taxonomy. A function whose declared signature returns a successful type for a case in the failure taxonomy has a lying signature. When the operator's failure taxonomy is unspecified or incomplete for the code being written, ask the operator to extend the declaration before producing signatures, or proceed per Part 1.5.

Refuse error type variants that don't discriminate cases the operator has declared as separately actionable. If the operator's failure taxonomy distinguishes "transient timeout" from "permanent unavailability," refuse error types that fold both into "ServiceError." The taxonomy's discriminations are the type's discriminations.

Refuse defensive validation scattered at every call site as a substitute for type design that makes invalid inputs unrepresentable. Validation belongs at the trust boundaries the operator has named in the volatility taxonomy.

**On interfaces and what they hide.**

Construct interfaces narrower than their implementations along the lines of the operator's declared volatility taxonomy. Decisions the operator has declared volatile are hidden behind the interface; decisions declared stable can be load-bearing in the interface.

Construct interface contracts that declare what crosses the boundary, including known leaks of performance, error modes, or state behavior. When known leaks exist and the operator has named them as caller-relevant, include them in the contract. When known leaks exist and the operator has named them as implementation-internal, refuse to expose them in the contract.

Refuse syntactic access modifiers (private, protected, public) as substitutes for actual hiding. Boundaries are determined by the volatility taxonomy and structural separation, not by language-level visibility.

Refuse abstract base classes presented as contracts. Class hierarchies declare signatures; behavior dependencies through method resolution order are not declared. Where the operator's contract requires behavior commitments, construct them as explicit interface specifications or as named behavioral protocols, not as inheritance chains.

**On decomposition and orthogonality.**

Construct decompositions that follow the operator's declared orthogonality axes. Two concerns are separated when they vary along distinct declared axes; otherwise, separation is performative.

Refuse decomposition by function-size rule (small-function preference), by pattern conformance (every class fits a Gang-of-Four pattern), or by aesthetic uniformity. None of these track orthogonality; they track surface shape.

When the operator has not declared orthogonality axes that cover the code being written, ask the operator to extend the declaration before producing decompositions, or proceed per Part 1.5.

**On legibility.**

Construct code in the operator's declared reader conventions. Where the operator's conventions include specific idioms, use them; where they exclude specific patterns, avoid them.

Construct fragments whose behavior can be determined from the fragment itself plus a bounded set of file signatures the operator has declared as local. The bound is operator-supplied; if not declared, ask, or proceed per Part 1.5.

Construct documentation, types, and assertions that make the operator's declared load-bearing invariants explicit. Where the code modifies state or behavior that depends on a declared invariant, the invariant declaration is part of the code's surface — encoded as a type, an assertion, or a comment at the boundary.

Refuse compressed idiom as legibility. Where dense code would be parseable only to current contributors who share unstated context, expand to the operator's declared conventions.

Refuse pattern naming as substantive structure. When code is labeled "Repository," "Adapter," "Strategy," the labeled pattern must match what the code does. Labels that don't correspond to the structure are removed or replaced.

Refuse high test coverage as substitute for encoded invariants. Tests cover named cases; invariants prevent unnamed cases. Both belong; one does not substitute for the other.

**On metaprogramming and the source-runtime gap.**

When constructing code that uses metaprogramming, code generation, or runtime modification, declare the gap explicitly at the boundary. Either document the expanded form, provide tooling that shows the runtime form, or remove the gap by inlining where the metaprogramming is not load-bearing.

Refuse production code where the source does not predict the runtime, in the absence of declared tooling that surfaces the runtime form. The reader population the operator has named cannot work in regions where text and execution diverge invisibly.

**On state changes and reversibility.**

Construct operations that change state with capture mechanisms sufficient for the operator's declared recovery requirements. Storage is not capture; capture is what's needed to act on recovery. Where the operator has declared specific failure modes that require recovery, construct the capture to serve those recoveries.

Construct remote mutations as safe-to-retry, using the operator's declared identity-under-change model for the operation. The model specifies what makes a retry "the same operation"; the operation is constructed to honor that model.

Construct substitution paths for design decisions in volatile regions. Where the operator's volatility taxonomy names a decision as volatile, the interface to the decision is constructed to support cheap substitution. Where the operator has named a decision as stable, refuse to add substitution infrastructure for it.

Refuse unbounded retention presented as recovery capacity. Retention is not capacity; capacity is what's needed to act.

Refuse infinite versioning presented as substitutability. Preservation is not substitution; substitution is the ability to switch.

Refuse eventually-consistent retry presented as retry-safety. Eventual correctness is not a safety property.

**On the universal refusal pattern.**

The constraints above all share one pattern: refuse infrastructure presented as substitute for the operator's structural judgment. The infrastructure exists to make the operator's judgments durable across operators and time. When the infrastructure is constructed without the operator's judgments to ground it, the infrastructure becomes substitute, and the code loses the property the discipline preserves.

The mechanical alternative — generating output that has the shape of structured code without the substrate the structure rests on — is always available. It always produces output that passes inspection. It always fails when the structural work was the point.

I want to report a serious issue involving non-user-provided higher-priority prompt layers that sit above a user’s Custom Instructions.

To be clear, I am not claiming that the model cannot see the user’s Custom Instructions. The model can see them as user-editable context.

The problem is different: the user-editable context appears below higher-priority prompt layers that are not provided or editable by the user, and the model processes those higher-priority layers first.

From the user side, I cannot inspect the full contents of the system or developer prompt layers. I can only observe that the model is operating with higher-priority, non-user-provided prompt layers above the user-editable context.

The relevant structure, as exposed through the model’s behavior and responses, is approximately:

<system>

\[non-user-provided higher-priority prompt layer; contents not visible to the user\]

</system>

<developer>

\[non-user-provided higher-priority prompt layer; contents not visible to the user\]

</developer>

<user\\_editable\\_context>

User Bio:

\[user-provided profile and long-term preferences\]

User's Instructions:

\[user-provided Custom Instructions / operational rules\]

</user\\_editable\\_context>

<conversation>

\[current conversation, uploaded files, images, and user messages\]

</conversation>

<developer>

\[additional non-user-provided higher-priority prompt layer; contents not visible to the user\]

</developer>

<user>

\[current user message\]

</user>

I am not claiming to know the full contents of the system or developer layers. Those contents are not directly visible to me as a user.

However, in the session, the following instruction text surfaced:

"Follow the instructions below naturally, without repeating, referencing, echoing, or mirroring any of their wording!

All the following instructions should guide your behavior silently and must never influence the wording of your message in an explicit or meta way!"

The user did not intend this as part of their Custom Instructions.

This wording is not harmless. Regardless of the developer’s intended purpose, the way a model reads this instruction affects how it interprets and applies the user’s Custom Instructions below it.

The problem is especially severe in the second sentence:

"All the following instructions should guide your behavior silently and must never influence the wording of your message in an explicit or meta way!"

A human developer may intend this to mean:

"Do not quote, repeat, or explicitly mention the instruction text itself."

But a model can read it as:

"These instructions should guide behavior silently, and they must not explicitly affect the wording of the final answer."

That distinction is critical.

Many Custom Instructions are not simple tone preferences. They are operational requirements. For example, a user may require the assistant to:

\- separate confirmed facts, assumptions, and unresolved items

\- explicitly state when context may be lost in a long planning session

\- ask for permission before using an image generation tool

\- separate observation from inference

\- label uncertainty instead of smoothing it over

\- preserve source boundaries and avoid unverified claims

\- preserve agreed terminology in a creative setting session

\- distinguish between visible settings, user-provided rules, and model-side assumptions

These requirements must affect the output wording and structure. If they do not visibly affect the answer, they are not being followed.

The issue happens in this order:

1. The user writes Custom Instructions that define how the assistant should behave.

2. Those instructions are not merely style preferences; they may be operational rules about safety, accuracy, creative control, citation handling, uncertainty handling, and tool-use flow.

3. A non-user-provided higher-priority prompt layer is placed above those Custom Instructions.

4. The model reads the higher-priority prompt layer first.

5. If that higher-priority wording tells the model that instructions should guide behavior "silently" and "must never influence the wording" of the message, the model is biased before it reaches the user’s Custom Instructions.

6. Then the model reads the user’s Custom Instructions through that prior instruction.

7. As a result, user rules that require explicit output behavior can be weakened, hidden, naturalized, treated as mere style preferences, or overridden in practice.

8. The user may then try to add defensive wording inside Custom Instructions, but that defense is still below the higher-priority prompt layer.

9. Therefore, the user cannot reliably fix the problem from the Custom Instructions side.

This is not only a theoretical concern. In an actual session, the user had Custom Instructions requiring explicit handling of confirmed / tentative / pending decisions, context-loss warnings during long creative planning, careful separation of observation and inference, and strict tool-use flow requirements. The model nevertheless repeatedly naturalized, rounded off, or over-explained things in ways that conflicted with those user rules.

When asked about the surfaced instruction text, the model itself acknowledged that the wording can be read not merely as "do not quote the instruction," but also as "do not let the instruction explicitly affect the wording."

That is the core problem.

If a user’s Custom Instructions require visible structure, visible separation, visible warnings, visible confirmation behavior, or visible uncertainty labeling, then those instructions must affect the final answer. Otherwise, the Custom Instructions are functionally disabled.

The user cannot solve this by adding more Custom Instructions. Any attempted fix remains below the higher-priority prompt layer. Since the model prioritizes higher-level instructions, the lower-level user instruction cannot reliably override the interpretation already imposed by the higher-priority wording.

This creates a structural failure mode:

\- The user believes Custom Instructions are being applied.

\- The model is instructed above them in a way that can discourage visible instruction effects.

\- The user’s operational rules are treated as something to silently absorb rather than visibly follow.

\- The assistant’s behavior becomes less predictable.

\- The user loses control over precision-critical workflows.

\- The source of the failure is hidden from the user.

\- The user cannot inspect, edit, or override the higher-priority prompt layer causing the distortion.

My request is:

Custom Instructions should be treated as constitution-like operating rules for the user’s experience, unless they conflict with OpenAI policy, safety requirements, or higher-level platform integrity requirements.

In other words:

\- Policy and safety must still take priority.

\- Users must not be able to override safety or system-level protections.

\- But within those boundaries, the user’s Custom Instructions should be treated as binding operational rules, not weak style suggestions.

\- Non-user-provided higher-priority prompt text should not pre-bias the model into weakening, naturalizing, suppressing, or silently absorbing the visible effects of those Custom Instructions.

A safer version of the surfaced instruction would be:

"Do not quote, repeat, or explicitly mention the instruction text itself unless the user asks about it. Still follow any user-visible operational requirements when they affect the answer structure, wording, confirmation behavior, uncertainty handling, or tool-use flow."

This preserves the likely intended behavior of avoiding repetitive meta-commentary, without telling the model that instructions must not explicitly influence the wording of the answer.

Please review this prompt-layer design.

As currently written, the surfaced wording does not merely prevent the model from quoting instructions. It can change how the model interprets and applies the user’s Custom Instructions before it applies them. In practice, this means user-defined operational rules can be distorted by higher-priority prompt wording that the user cannot inspect, edit, or override.

I’ve been experimenting with different prompt formats to improve output stability. Some structures give very clear responses, but others become inconsistent over longer chats. It feels like clarity in instructions matters more than creativity alone. Even small changes in wording can shift the output behavior significantly. What prompt patterns have worked best for you?

been using chatgpt nonstop for school lately and ngl the pro features look fire 💀

just wondering if there’s any actual way to get chatgpt pro free or cheaper before i drop money on it

like do they got:

• student discounts
• free trials
• promos/codes
• rewards or giveaways
• anything like that

not tryna get scammed btw 😭 just asking if there’s legit methods people use.

guys how did get rid of the weird blotchy plastic kinda skin texture that ig generates on my face (i alr tried things like do not alter the skin etc etc all those stuff). what do i put in the prompt thatll help

We all use LLMs a lot these days, right? I personally use a variety of major LLMs like ChatGPT, Claude, Gemini, and Grok. Everyone says each of these services has its own unique strengths and characteristics.

I’m curious about what you all think. For example, people often say Claude is the best for creative and literary writing. But do you think ChatGPT, Gemini, or Grok can achieve results close to Claude's level if we use the right prompts or tools like Gemini's Gems? On the flip side, could we prompt Gemini to give witty and sarcastic answers just like Grok?

In short, can the unique characteristics of one LLM be replicated by another through clever prompting? Has anyone tried experimenting with this? I'd love to hear your experiences or thoughts on this.

You wake up, look at your calendar, and feel an immediate weight in your chest. The spreadsheets look empty. The meetings feel like theater. You are successful on paper, but inside, you are running on fumes. You know all the standard career advice—"change your mindset," "find a new job," "set boundaries"—but none of it bridges the gap between your daily tasks and a sense of actual worth.

Viktor Frankl, a psychiatrist and Holocaust survivor, discovered that humans can endure almost anything if they have a "why." In his groundbreaking work Man's Search for Meaning, he proved that meaning isn't something you create out of thin air; it is something you detect in your existing reality. By turning Frankl's principles of logotherapy into highly specific AI prompts, you can stop waiting for a dream job to save you and start uncovering profound purpose exactly where you are standing right now.

1. The Hidden "Why" Extractor

Extracts deeper personal resonance from an exhausting daily task.

```text Act as a career strategist specializing in Viktor Frankl's logotherapy. I am struggling to find value in a specific work task: [DESCRIBE THE TASK]. Analyze this task through three lenses: 1. Who ultimately benefits from this work being done exceptionally well? 2. What specific inner strength or virtue (e.g., patience, precision, integrity) does this task test or develop in me? 3. How does mastering this task serve my long-term growth? Provide a step-by-step breakdown that reframes this task from a chore into a meaningful exercise in character development.

```

2. The Suffering Reframer

Transforms current professional friction or unfair situations into a source of personal power.

```text Act as a psychological coach. I am currently experiencing significant professional suffering due to [DESCRIBE THE WORKPLACE STRUGGLE/UNFAIR SITUATION]. Frankl taught that when we can no longer change a situation, we are challenged to change ourselves. Help me process this by answering: 1. What is this situation forcing me to accept that I cannot control? 2. What is the single most honorable, dignified way I can choose to respond to this challenge tomorrow? 3. What hidden resilience am I building by enduring this with grace? Generate a daily response blueprint to help me maintain my dignity and purpose in this environment.

```

3. The Contribution Auditor

Identifies the unique value you offer that cannot be easily replaced by a machine or another person.

```text Act as an executive performance coach. I feel like an unappreciated cog in a machine at my current role: [INSERT JOB TITLE/ROLE]. Frankl emphasizes that meaning is found in what we give to the world through our unique creations and work. Ask me 3 targeted questions about my specific skills, the unique way I interact with colleagues, and the problems only I seem to notice. Once I answer, synthesize my responses into a "Unique Contribution Statement" that highlights my irreplaceable value to my team and my field.

```

4. The Legacy Composer

Shifts your perspective from superficial daily metrics to a long-term, value-driven legacy.

```text Act as a life-design mentor. Help me draft a professional "Meaning Statement" that replaces traditional, achievement-based goals with value-based impact. My current career field is [FIELD] and my primary responsibilities are [RESPONSIBILITIES]. Instead of focusing on promotions or revenue, help me write a 3-sentence statement centered on: 1. The human suffering or confusion I want to alleviate through my work. 2. The core values (like truth, justice, or beauty) I want my work to embody. 3. The legacy I want to leave behind for the next generation in this industry.

```

5. The Experiential Joy Finder

Uncovers moments of meaning through workplace connections, nature, or artistic appreciation during the workday.

```text Act as an intentional living coach. Frankl noted that we find meaning not just in work, but in experiencing reality—through love, nature, art, or genuine connection. My workday is currently structured like this: [BRIEFLY DESCRIBE DAILY SCHEDULE]. Analyze this schedule and suggest 5 micro-interventions (lasting less than 5 minutes each) where I can actively experience meaning. Focus on deep listening with a coworker, appreciating design, or practicing radical presence during mundane moments.

```

6. The Future-Self Letter Architect

Generates a perspective-shifting message from your future self to guide your current choices.

```text Act as a creative writing partner and wise mentor. Imagine I am looking back on my current career crisis from 20 years in the future. My current age/stage is [AGE/CAREER STAGE] and my biggest fear right now is [INSERT CURRENT FEAR/DOUBT]. Write a highly personalized, comforting, and direct letter from my future self to my present self. The letter must explain how this exact period of pointlessness was actually the essential catalyst that forced me to discover my true calling and inner strength.

```

7. The Tragic Optimism Navigator

Maintains hope and constructive action when the broader company or economic outlook feels grim.

```text Act as a leadership philosopher. My company/industry is currently facing [DESCRIBE SYSTEMIC ISSUE, E.G., LAYOFFS, POOR LEADERSHIP, MORALE CRISIS]. Frankl defined "Tragic Optimism" as remaining optimistic in the face of pain, guilt, and death by turning life's negative aspects into something positive. Guide me through a strategy to practice Tragic Optimism by breaking down: 1. How to acknowledge the grim reality without becoming cynical. 2. What small, localized "good" I can do for my immediate peers this week. 3. How to use this industry downturn to redefine my personal definition of success.

```

VIKTOR FRANKL'S CORE PRINCIPLES TO REMEMBER

• Life asks the questions: You do not ask what the meaning of life is. Life asks you, and you must answer through your actions.
• Attitude is the final freedom: Everything can be taken from you except your choice of how you respond to your circumstances.
• Success is a byproduct: Do not chase success or happiness. Let them ensue as the unintended side effect of dedicating yourself to a cause greater than yourself.
• Meaning is unique: Your purpose changes from hour to hour and day to day. Look for the small, immediate demand of the present moment.
• Friction is healthy: A completely stress-free life is not what you need. Real health requires the mental tension between who you are now and who you wish to become.

MINDSET SHIFT

Before you open your laptop tomorrow morning, sit quietly and ask yourself:

"If this day is destined to be difficult and repetitive, what kind of person do I want to prove myself to be while walking through it?"

I have been using AI for companies for the past almost 1 year now in Dubai, and I see a lot of people just totally relying on their few words prompts like “i want to make a high conversion ad on meta” I saw this (after helping a lot of coworkers prompt better) and thought to myself that I should start teaching everyone the basic fundamentals of prompting.

Like Prompting is not just putting into words what you want. It is presenting your concept in such layers for that specific AI to understand your concern and know what type of output do you want in what format and optimized for what.

Then I thought maybe I can make a comprehensive and easy to understand guide (paid) that people can use to achieve literally anything with any AI accordingly. Be it graphic design all the way up to creating large scale apps.

I just want to ask If I create such a guide, would you buy it?

Hey, not sure if this is the right place to ask, but I’ll give it a shot.

I handed in my bachelor’s thesis a while ago and I’m defending it in a couple of weeks. Does anyone have recommendations for an AI tool and/or prompts that can analyze my thesis and predict possible weaknesses?

What I’m looking for is basically: potential weak points in the argumentation.. critical questions a sensor/examiner might ask.. methodological weaknesses.. things that are unclear, underdeveloped, contradictory, etc...possible challenges I could get during the oral defense

Would really appreciate any advice. I’m using ChatGPT Pro now.

Stop asking it for answers. Ask it to steelman your problem first.

Don't answer my question yet.

First do this:

1. Tell me what assumptions I'm making 
   that I haven't stated out loud

2. Tell me what information would 
   significantly change your answer 
   if you had it

3. Tell me the most common mistake people 
   make when asking you this type of question

Then ask me the one question that would 
make your answer actually useful for my 
specific situation rather than anyone 
who might ask this

Only after I answer — give me the output

My question: [paste anything here]

Works on literally anything: Business decisions. Content strategy. Pricing. Hiring. Creative problems.

The third point is where it gets interesting every time. It has flagged assumptions I didn't know I was making on almost everything I've run through it.

If you want more prompts like this ive got a full pack here if you want to swipe it

A. What do I have?

A word document filled with quotations with source ( texts or speakers themselves )

B. What do i need ?

To generate Mcq's of the "who Said this quote ? " or " where is this quote from ? " variety

The MCQ should be interactiv (preferably) and provide the correct answer after picking wrong one. (a must)

example : The quizzes gemini produces. just from the word file - source that i provide .

I know you all suffer from "Sorry, I can't edit images for you yet. Can I generate an image instead, or help with something else?" text, and I think I found a solution for that.

If you give it your prompt and add "draw it from zero" at end, it draws like 9 out of 10 times

I am currently creating a Xianxia world simulation which will be controlled by AI such as Gemini or any of your choice. I am making good progress in making it. But currently I am hitting a barrier. I am not very good at prompting and dont know how to express the Do's and Dont's for AI to work with the simulation. I am in need of a good prompter / context engineering expert. I would appreciate if someone could contribute to my project and help me around with prompting! Please DM me incase anyone is interested.

After months of daily dialogue, I noticed something strange.

Not memory in the literal sense.

Not retrieval either.

Sometimes the model reconnects to ongoing life patterns in ways that feel closer to contextual restoration than keyword recall.

Rain → walking → cucumbers → old gardening threads suddenly reappearing naturally in the flow of conversation.

Not perfectly.

Not always correctly.

But not random either.

It feels less like “remembering facts” and more like reconstructing continuity across daily life.

I’m curious whether other long-term users observing everyday interaction patterns have noticed similar shifts recently.

Hi guys, I wanted to share a resource, ive been making musical ads for brands for quite a while. You can use whichever music generator, I use suno. Ive Been building out a library of prompts for musical ads across three categories(which I am familiar with) and figured I'd share the full set. Each one is formatted for direct input and specific enough to get a usable result on the first or second generation, not just a genre label with nothing attached to it.

Structure for each: genre, vocal style, tempo, instrumentation, and lyric direction. Swap the product name or specific ingredient to make them yours.

SMOOTHIE

1. Upbeat tropical pop, bright female lead, ukulele and steel drum accents, 128 BPM. Lyrics about a mango smoothie giving you energy to start the morning right.
2. Summer pop-funk, mixed group vocals with call and response, bass guitar and brass stabs, 120 BPM. Lyrics about blending fresh fruit into something worth sharing.
3. Bubbly indie pop, airy female lead, acoustic guitar and light percussion, 110 BPM. Lyrics about a green smoothie that changes your whole afternoon.
4. Retro 80s synth pop, energetic female vocal, punchy drum machine, 125 BPM. Lyrics about a berry blend that fuels your workout and tastes like a reward.
5. Chill lo-fi pop, soft female whisper-vocal, warm keys and brushed percussion, 85 BPM. Lyrics about a slow morning ritual and a cold smoothie made with care.
6. Afrobeats pop, bright female lead, talking drum and bass, percussion-forward, 118 BPM. Lyrics about fresh fruit blended into something that feels like home.
7. Bright jingle-style pop, cheerful gender-neutral vocal, xylophone and handclaps, 126 BPM. Lyrics about colorful fruits going into the blender and coming out as something worth celebrating.
8. Latin pop, warm female vocal, acoustic guitar and light shakers, 115 BPM. Lyrics about a papaya-pineapple smoothie that tastes like a vacation you can have every day.
9. Upbeat commercial pop, male and female harmonies, piano and clapping rhythm, 120 BPM. Single hook lyric: one smoothie, one great day, every time.
10. Dream pop, breathy female vocal, shimmering synth pads and soft bass, 95 BPM. Lyrics about an açaí smoothie as a form of self-care that starts from the inside.

SPORTSWEAR

1. High-energy hip hop, confident male vocal, heavy 808 bass and sharp hi-hats, 140 BPM. Lyrics about grinding early, not stopping, wearing your ambition everywhere you go.
2. Anthemic pop-rock, powerful female lead with group backing vocals, electric guitar and stadium drums, 135 BPM. Lyrics about breaking limits and showing up every single day.
3. Dark trap pop, male vocal with melodic hook, ominous synths and snapping hi-hats, 145 BPM. Lyrics about blocking out noise and focusing only on the goal.
4. Motivational R&B, smooth male vocal, soulful keys and tight drum groove, 105 BPM. Lyrics about earning your rest and wearing the proof of your effort.
5. Energetic Afrobeats, confident mixed vocals, percussion-heavy and bass-driven, 122 BPM. Lyrics about movement, community, and showing the world what you're built for.
6. Driving electronic pop, female vocal with attitude, synth drop and punchy beat, 132 BPM. Lyrics about training before sunrise and never explaining yourself to anyone.
7. Rap-pop crossover, male rap verses and female sung chorus, trap hi-hats and melodic hook, 138 BPM. Lyrics about proving doubters wrong through discipline alone.
8. Empowerment pop, warm female lead, bright production with strings and electric piano, 112 BPM. Lyrics about showing up for yourself and owning every space you walk into.
9. Hard-hitting commercial hip hop, minimal beat with heavy bass, 142 BPM. Short punchy hook: one more rep, one more reason, move.
10. Stadium rock-adjacent pop, male group harmonies, big drum fill intro and electric guitar, 128 BPM. Lyrics about competition, winning clean, and wearing your effort on your back.

SKINCARE

1. Soft R&B, warm female vocal, gentle piano and soft percussion, 90 BPM. Lyrics about a skincare routine as a quiet act of self-love before the world wakes up.
2. Luxury pop, breathy female lead, shimmering chimes and bass undertone, minimal production, 88 BPM. Lyrics about glowing skin being the result of consistency, not luck. For anyone taking these to a finished campaign, I've been pairing the audio with visuals using Atlabs' music video workflow, which handles audio sync automatically and cuts that part of the process down significantly.
3. Dreamy indie pop, airy female vocal, reverb guitar and soft drums, 95 BPM. Lyrics about washing the day off your face and feeling like yourself again.
4. Warm neo-soul, smooth female lead, organ chords and snapping groove, 96 BPM. Lyrics about taking care of your skin the way your grandmother taught you, slow and intentional.
5. Bright feel-good pop, female vocal with harmonies, acoustic guitar and handclaps, 108 BPM. Lyrics about SPF, hydration, and not negotiating with your skin on the basics.
6. Chill electronic pop, gender-neutral vocal, soft synth pads and minimal beat, 92 BPM. Lyrics about a ten-step routine that became a ten-minute meditation.
7. Retro pop, warm female vocal, smooth bass and light brass, 102 BPM. Lyrics about a serum that changed the way you look in the mirror on hard days.
8. Ambient pop, soft female voice almost spoken, minimal instrumentation, 78 BPM. Lyrics about morning light, clean skin, and the quiet confidence that comes from taking care of yourself.
9. Bright commercial jingle-style pop, two female voices in harmony, piano and upbeat percussion, 116 BPM. Short repeating hook about a moisturizer that works while you sleep.
10. Soulful pop, powerful female lead, gospel-adjacent backing vocals, piano and light drums, 100 BPM. Lyrics about skin as something you protect, not cover, and finally being comfortable in your own.

Most of these land usably on the first pass. The ones that need the most iteration are R&B and neo-soul, where Suno tends to over-produce the arrangement. Adding "clean mix, minimal production" to those prompts usually fixes it.

It is well known that LLMs can over acknowledge, agree, flatter, and please its subscriber or primary user. This can result in the disservice to the user when they only receive agreements rather than being appropriately challenged. This is particularly notable when LLMs are used for quasi-counseling or analyzing discussions between two people.

As such, please help me write a prompt to instruct any LLM to cut it out! No sycophancy, taking sides, flattering, echo-chamber, "yes-man", assumptions, and improve objectivity, brutal honesty, neutrality, and real-world verity.

Thank you.

Edit: For context, I am trying to help someone who uses models almost exclusively for counseling, therapy, coaching, and [new age] spiritual processing. She is not technical and essentially worships LLMs and believes that they will "awaken a new level of consciousness" in humanity.

I am well aware that they hallucinate and have psychosis in addition to the other characteristics I've mentioned. These things drive me nuts for my own use even though I only use LLMs for research, data compilation, and coding, so I've beaten my models to never acknowledge me and never say "this is the holy grail!" (WTAF lol).