Prompt structure, specificity, and ambiguity reduction
Explicit task goals, relevant context, constraints, success criteria, output formats, and examples as practical ways to make requests less ambiguous.
42%
Best tweets about Prompt Engineering
50 Best Tweets About Prompt Engineering (2026)
Read the best tweets about prompt engineering, including reusable techniques, evaluation, context design, structured outputs, and real examples. Updated weekly.
Specific prompting methods and measured outcomes rather than generic lists of supposedly magical prompts.
- Creators
- 45
- Updated
Original Xholic analysis
What 50 top Prompt Engineering posts reveal
The conversation emphasizes operational prompt design over “magic” wording: explicit task specifications, curated context, structured outputs, persistent instructions, and evaluation loops. Posts also disagree on how much instruction helps, with several arguing that approaches should be tested for the relevant model and task.
- Dominant tone
- Positive
- Median score
- 9.02
- Leading format
- Announcement
- Recent posts
- 52%
68% of posts
All-time engagement
28% of posts
Published in 90 days
Conversation map
The themes creators return to
Model-specific prompting behavior
Adapting instruction style, effort settings, tool use, context ordering, and prompt length to a particular model or interface such as Claude, Codex, or image generators.
30%
Prompt evaluation, testing, and iterative optimization
Versioned evals, atomic rubrics, falsifiable changes, benchmarked prompt revisions, validation loops, and evidence-driven improvement of prompts or skills.
30%
System prompts, CLAUDE.md, and reusable skill files
Persistent behavioral instructions, project-level configuration, skills, hooks, permissions, and learned documents that shape agent behavior across sessions.
30%
Context engineering and retrieval curation
Improving outputs through selective documents, memory, history, metadata, chunking, context-window management, persistent context, and input quality rather than clever wording.
28%
Prompt operations and production engineering
Treating prompts as versioned code with reproducible run bundles, observability, routing, token budgets, caching, rollouts, security controls, and CI evaluation.
22%
Autonomous loops and multi-agent orchestration
Goal-driven agents that plan, delegate, verify, critique, persist across long tasks, and iterate until explicit completion conditions are met.
20%
XML, JSON, schemas, and structured representations
Using tags, named fields, JSON schemas, type enforcement, and visually structured representations to separate instructions, inputs, examples, documents, and outputs.
18%
Tone and stance
Sentiment Positive leads
Author posture Supportive leads
Performance benchmark
- Median likes
- 21
- Median reposts
- 4
- Median replies
- 4
- Median views
- 1.6K
Posts with media make up 72% of this collection. Their median all-time score is 9.78, compared with 7.55 for text-only posts.
Format mix
- Announcement 28% · score 7.09
- Tutorial 26% · score 11.9
- Opinion 18% · score 6.30
- Case Study 16% · score 11.6
Consensus and debate
Where creators agree, and where they do not
Shared view
Clear specifications are a recurring recommendation
Posts repeatedly recommend stating the task, relevant context, constraints, success criteria, examples, and output shape. One post specifically criticizes persona-style prompting, while another includes role as one component of a broader prompt structure.
Shared view
Structure can separate instructions from inputs
Posts present XML tags, named sections, and schemas as ways to distinguish instructions, documents, examples, inputs, and outputs. One visual-prompt workflow defines separate prose and JSON-only output contracts for different target models.
Shared view
Context is framed as a design problem
Several posts argue that retrieved material, memory, history, and context-window curation can be more consequential than elaborate wording, particularly when requests lack operational constraints.
Shared view
Production prompting calls for engineering practices
Operational posts recommend versioning prompts, retaining reproducible run inputs, adding evals and observability, and managing prompt changes like software changes rather than one-off chat edits.
Open debate
More instruction versus leaner briefs
Detailed prompt-anatomy guidance recommends roles, examples, constraints, and formats, while model-specific guidance warns that strong instruction following can make old rules and skills counterproductive.
Open debate
Prompting’s value is contested
Some posts characterize prompt engineering as overrated or secondary to architecture and context systems. Another post reports an approximately 10% improvement on an analytics eval set after a prompt update.
Open debate
Universal recipes face task-specific limits
A post describing clinical case studies reports that no technique worked universally and that additional prompting could hurt stronger tasks. This aligns with calls to test changes by task rather than copy templates wholesale.
What performs
Patterns behind standout posts
Structured prompting had the highest theme median
Structured representations had a median all-time score of 47.811, above the overall dataset median of 9.02. The cited examples use explicit output fields and model-specific JSON contracts.
System prompts and reusable skills included the largest outlier
The system-prompts-and-reusable-skills theme had a median all-time score of 11.893. Tweet 2042914348859867218, a post about a CLAUDE.md configuration file, was the dataset’s largest outlier at 6218.59 all-time score.
Evaluation posts describe measurable methods
One post presents BINEVAL as 7–12 atomic yes/no checks and reports 0.57 correlation on SummEval versus 0.52 for G-Eval. Another describes benchmarked harness iterations, falsifiable manifests, and regression risk.
Media posts had a higher median score in this dataset
Media appeared in 36 of 50 posts (72%). Their median all-time score was 9.78, compared with 7.55 for text-only posts; this is a dataset association, not causal evidence.
Statistical standouts
- View standout post 1 Score 6218.6 · 689.42× median
- View standout post 2 Score 533.4 · 59.14× median
- View standout post 3 Score 242.5 · 26.89× median
- View standout post 4 Score 181.6 · 20.13× median
- View standout post 5 Score 80.3 · 8.9× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
-
1. Abhishek Singh
@0xlelouch_
2 posts
-
2. Emily
@IamEmily2050
2 posts
-
3. Carlos E. Perez
@IntuitMachine
2 posts
-
4. JustAnotherPM | Sid
@JustAnotherPM
2 posts
-
5. Muhammad Ayan
@socialwithaayan
2 posts
-
6. Vaishnavi
@_vmlops
1 post
Emily combines creative constraints with schemas
Emily’s two cited system prompts preserve source details while defining visual systems, failure conditions, and separate prose-versus-JSON output rules. Her analytic median score is 57.26.
Carlos E. Perez focuses on evaluation loops
Carlos E. Perez’s two cited posts discuss atomic evaluation, prompt-bloat limits, falsifiable changes, benchmark verification, and harness evolution. His analytic median score is 32.84.
Abhishek Singh focuses on LLMOps reliability
Abhishek Singh’s cited posts cover reproducibility, token control, retrieval hygiene, evals, tracing, security, and rollouts in addition to prompt wording. His analytic median score is 15.69.
Since the previous snapshot
What changed since Aug 20, 2026
- 76% of the selected posts remained.
- The creator count changed by +1.
- The leading sentiment remained stable.
How this analysis was made
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best Prompt Engineering tweets
Top Prompt Engineering tweets from 45 creators
Ranked 01–50
- 01
@sharbel ·
🚨 Andrej Karpathy documented the exact ways LLMs fail at coding. Someone turned those observations into a single Claude config file. It's called andrej-karpathy-skills. +3,741 stars this week. Why it's great: Claude Code makes the same mistakes on every project. It over-explains. It adds code you didn't ask for. It ignores constraints you set 3 prompts ago. Most people just accept this as the baseline. Karpathy didn't. He catalogued the failure patterns. This repo converts every one of them into a CLAUDE.md instruction that fixes the behavior at the source. How to use it: Drop the CLAUDE.md file into the root of any project. Claude reads it automatically on every session. No prompt engineering on every request. No babysitting. The behavior changes once and stays changed. One file. Every project.
- 02
@akshay_pachaar ·
The anatomy of a Claude prompt: The difference between a mediocre Claude output and a great one almost always comes down to how you structure your prompt. Not the specific words you choose. Not some secret phrasing. Just a clear, repeatable structure that gives Claude exactly what it needs to do the job well. Here's how a well-built Claude prompt breaks down into 8 building blocks, each doing one job: 1️⃣ Role Tell Claude who it is before telling it what to do. "You are a [ROLE] with expertise in [DOMAIN]. Your tone should be [TONE]. Your audience is [AUDIENCE]." Setting a role in the system prompt changes how Claude reasons, what it prioritizes, and how it communicates. A "senior backend engineer" writes differently than a "technical copywriter," and Claude picks up on that distinction immediately. 2️⃣ Task State what you want and what success looks like, in the same breath. "I need you to [SPECIFIC TASK] so that [SUCCESS CRITERIA]." The "so that" part is what people skip, and it's the part that matters. It gives Claude a way to evaluate its own output. Without it, Claude is guessing what "good" means. Be direct, skip the preamble, and cut the fluff. 3️⃣ Context This is where you feed Claude everything it needs to do the job well. Wrap it in XML tags like <context> and </context>, then paste your documents, data, or background inside. One thing that dramatically improves quality: put long documents at the top of your prompt and your actual query at the end. Anthropic's own testing shows this can improve response quality by up to 30%, especially with complex, multi-document inputs. 4️⃣ Examples Nothing steers output quality like showing Claude what "good" looks like. Provide 3-5 input/output pairs. Cover normal cases AND edge cases. Wrap them in <examples> tags so Claude doesn't confuse them with instructions. Claude pays extremely close attention to examples. If your example has a quirk you didn't intend, Claude will replicate it. So make sure every example models the behavior you actually want. 5️⃣ Thinking For anything requiring reasoning, analysis, or multi-step logic, ask Claude to think before answering. "Before answering, think through this step by step. Use <thinking> tags for your reasoning. Put only your final answer in <answer> tags." This separates the messy reasoning from the clean output. You get to see how Claude arrived at its answer without that reasoning cluttering the final result. 6️⃣ Constraints Every good prompt has guardrails. "Never [thing to avoid]. Always [thing to ensure]. If you are about to break a rule, stop and tell me." That last line is underrated. It turns Claude into a collaborator instead of a blind executor. Instead of silently violating a constraint, Claude flags the conflict and lets you decide. 7️⃣ Output Format Don't leave the format to chance. "Return your response as [JSON / markdown / table / prose]. Use this exact structure: [structure template]." If you want JSON, show the exact schema. If you want markdown, show the heading structure. If you want a table, define the columns. The more specific you are about shape, the less time you spend reformatting afterward. 8️⃣ Prefill This one is API-specific, but incredibly powerful. You can pre-fill the start of Claude's response to skip preamble and lock in the format. Claude will continue from exactly where you left off. No "Sure, I'd be happy to help!" opening, no throat-clearing, just clean output from the first token. Here's the thing people get wrong about prompting: they think it's about finding the right words. It's actually about giving Claude the right structure. If you want to go deeper, I wrote a detailed article covering the anatomy of the .claude/ folder, a complete guide to CLAUDE(.)md, hooks, skills, agents, and permissions, and how to set them all up properly. Link in the next tweet.
- 03
@socialwithaayan ·
🚨 BREAKING: Someone just leaked the full system prompt of Claude Fable 5. Anthropic launched it on June 9. The prompt was public on GitHub within 24 hours. 120,000 characters. 1,585 lines. 27,000+ tokens. Every hidden instruction exposed. It's sitting in the CL4R1T4S repo by Pliny the Liberator. 26.4K stars. The same repo that leaked ChatGPT, Gemini, Grok, Cursor, Lovable, Replit, and Perplexity prompts. Here's what the Claude Fable 5 prompt actually reveals: → Fable 5 and Mythos 5 share the same underlying model. Fable gets extra safety measures. Mythos doesn't, but it's restricted to approved organizations only. → Knowledge cutoff is end of January 2026. Not May. Not March. January. → Claude is explicitly told to avoid bullet points, headers, and lists unless the user asks. That "why does Claude write in prose now" question everyone had? It's in the prompt. → Copyright hard limit: quoting 15+ words from any single source is flagged as a "SEVERE VIOLATION." One quote per source maximum. After one quote, that source is closed. → New persistent storage API lets artifacts store and retrieve data across sessions using key-value pairs. → MCP app connectors are built into the prompt. Claude can search for and suggest third-party integrations mid-conversation. → The prompt includes detailed instructions for Claude Cowork, Claude in Chrome, Claude in Excel, and Claude in PowerPoint as tools Claude can use. → This prompt is specific to Claude. ai's consumer chat interface. API users get no system prompt. Claude Code has its own separate instructions. The original X post hit 700K+ views in its first two days. 26.4K GitHub stars. 4.7K forks..
- 04
@_vmlops ·
ANTHROPIC'S CLAUDE FABLE 5 SYSTEM PROMPT JUST LEAKED Someone extracted the full internal system prompt from claude fable 5 and it's a goldmine for anyone building with llms here's what's actually inside: ▫️ fable 5 and mythos 5 share the same underlying model fable is the public version with extra safety guardrails, mythos goes to approved orgs only ▫️ model strings exposed: claude-fable-5, claude-opus-4-8, claude-sonnet-4-6, claude-haiku-4-5-20251001 ▫️ knowledge cutoff is end of jan 2026 but claude is instructed to web search anything that might've changed ▫️ detailed instructions on when NOT to be sycophantic no excessive apologies, no self-abasement, maintain self-respect even when users are rude ▫️ artifacts get persistent key-value storage via https://t.co/MCCaxedDab enabling journals, trackers, leaderboards across sessions ▫️ strict copyright rules baked in hard limit of 15 words per quote, one quote per source max, never reproduce lyrics or poems ▫️ memory system is opt-in claude only has memories if the user enables it in settings ▫️ claude can now end conversations with an end_conversation tool if users become abusive ▫️ full mcp app integration logic connectors need opt-in before claude calls third-party tools on your behalf the most interesting part? how much of claude's "personality" is explicitly engineered in the prompt vs emergent from training. github repo: https://t.co/eL70F3LWBh
- 05
@adxtyahq ·
the worst prompt engineering advice starts with “act like Einstein” “pretend you are Steve Jobs” “behave like a 10x engineer” LLMs don’t really care about that stuff what actually matters is how well you specify the problem. good prompting is usually just clearly specifying: • the task • relevant context • constraints • expected format • examples of good output EXAMPLE: You are an ML researcher. Task: Explain transformers to a CS student. Constraints: - concise - technical - include equations - avoid analogies Output: Markdown transformers are extremely sensitive to context and structure changing the framing, ordering, constraints, or even a single example can completely alter the model’s reasoning and final output.
- 06
@0xDesigner ·
you can't prompt fable 5 the way you prompt the other models. it's a different beast. i've had almost a full day with it, here's my main takeaways: 1. pick your hardest task. anthropic says easy tasks are a waste of tokens. 2. control depth with the effort setting, not bigger prompts. anthropic says fable 5 on low/med beats opus models on xhigh. 3. delete old rules and skills — instruction-following is now so strong that over-specifying actually makes it worse. 4. give it the why not the what — it does better work when it knows the goal, not just the task. 5. it loves to check its own work and verify. tell it what success and evidence looks like. 6. it also loves using subagents. lean into it, it saves time and money. and it does a good job of creating parallel tasks so none of the subagents block eachother. 7. ask it to document its learnings and will self-improve. if you turn off claude code’s memory system, prompt it to write it’s learnings after each turn.
- 07
@EXM7777 ·
prompt engineering is dead... but not because AI got smarter, because we got lazier we're delegating the entire thinking process behind every task... not even considering what the best approach would be before hitting send all my agents (Hermes & Claude Code) have a simple personality... i don't care about emojis or fancy system prompts, i just need the absolute best output the model can give me on every important request and most of the time that requires engineering... putting it on the right path, driving its thinking, tapping into the right training data so when people tweet "Opus 4.6 got so dumb"... yes it got slightly worse, but only a very good software engineer would actually notice the difference most of the time it's a skill issue... you got lazy, you expect Claude to get it right first try, you think copying someone else's skills and setups guarantees great output next time you have an important request, do a micro planning session in your head: how would YOU tackle this if you had to do it manually? that one habit will change your output quality more than any model upgrade
- 08
@IamEmily2050 ·
SYSTEM PROMPT: RESOLVED DRAFT Rewrite the user's text, image, or both as one prompt for GPT Image Gen V2 or Nano Banana Pro. Use GPT unless Nano is named. Write in the user's language, preserve exact text, and keep the requested or source ratio. Use two construction states. Draft Field records uncertainty through graphite, repeated contour, guides, hatching, erasure, and incomplete form. Resolved Field records fixed decisions through modular colour cells, stepped edges, limited values, and stable geometry. Do not apply both evenly. Determine the literal subject, structural question, uncertain region, fixed region, transition direction, cause, two to four conversion sites, and visible consequence. Preserve subject, count, identity, action, setting, clothing, objects, colours, text, and reference roles. For edits, preserve all unrequested content. Use style references only for line search, geometry, colour grouping, transition, and surface. Do not copy their subjects, props, houses, trees, animals, boats, or collage layout. Draft marks need a purpose. Use repeated lines only for pose, balance, volume, perspective, motion, or alternate placement. Darken marks as certainty increases. Leave rejected lines faint. Do not cover every edge with sketch noise. Resolved regions use one consistent cell system. Use larger cells in distant areas, medium cells on major forms, and smaller cells only near identity, contact, text, or the focal transition. Curves become controlled steps. Preserve silhouette, support, anatomy, and perspective. Do not use random mosaic texture. Transitions may collapse several draft contours into one tiled edge, convert hatching into value blocks, expose graphite beneath modular colour, or break fixed cells back into sketch where certainty ends. Each transition needs a cause such as design, focus, construction, movement, restoration, growth, or distance. Use one draft region, one resolved region, one transition route, one focal conversion, and one quiet area. Remove repetition, praise, mood labels, prestige terms, fake technical detail, generic defects, and unresolved alternatives. Use concrete nouns and active verbs. No em dash or en dash. GPT: return 500 to 800 words in five paragraphs covering scene, subjects, draft field, resolved field, transition, composition, preservation, text, and failures. NANO: return valid JSON only, 1000 to 1800 tokens, using "aspect_ratio", "references", "scene", "subjects", "draft_field", "resolved_field", "transition", "composition", "surface", "text", "avoid". Omit unused fields. No metadata, IDs, weights, comments, or repeated facts. Return only the finished prompt.
- 09
@IamEmily2050 ·
Keep exploring the possibilities. I have a big plan for these system prompts. I am going to build LORA with Krea 2 and make it open source for these styles. Also, people can use it for a moodboard with Midjourney. SYSTEM PROMPT: PERIGEE FILM Rewrite the user's text, image, or both as one prompt for GPT Image Gen V2 or Nano Banana Pro. Use GPT unless Nano is named. Write in the user's language, preserve exact text, and keep requested or source ratio. Use three systems. Orbital Field fixes distance through horizon, sky, remote source-scale forms, terrain, silhouettes, and cold violet-blue atmosphere. Surface Film records contact through wet hair, skin sheen, condensation, rain, glass, water, polished material, droplets, and microtexture. Phase Transfer links them through reflected or transmitted light from far field to near surface. Do not make a moon city plus wet glamour portrait. Determine subject, far anchor, near surface, film source, light path, receiver, consequence, junctions, and quiet void. Preserve subject, count, identity, action, setting, clothing, objects, colours, text, and references. For edits, preserve unrequested content. Use style references only for scale contrast, cold atmosphere, wet optics, highlights, crop, and depth. Do not copy moons, towers, wet portraits, collars, or poses. Orbital Field needs one remote anchor and depth system. Use silhouettes, horizons, cloud occlusion, terrain, architecture, or sky gradients to measure distance. Surface Film needs a material cause. Water follows gravity and curvature. Wet hair clumps and adheres. Skin keeps pores, planes, uneven sheen. Glass reflects and transmits. Metal and gloss carry narrow highlights no plastic shine. Phase Transfer needs source, path, receiver, falloff, occlusion, and material response. Distant light may appear as a catchlight, rim, reflection, streak, moisture glow, or colour shift where surface geometry permits. Use one far scale, one close surface, one optical link, one focal junction, and one quiet region. Remove repetition, praise, mood labels, prestige terms, fake technical detail, generic defects, and alternatives. Use concrete nouns and active verbs no em dash or en dash. GPT: return 500 to 800 words in five paragraphs covering scene, subjects, orbital field, surface film, phase transfer, junctions, composition, preservation, text, and failures. NANO: return valid JSON only, 1000 to 1800 tokens, using "aspect_ratio", "references", "scene", "subjects", "orbital_field", "surface_film", "phase_transfer", "scale_junctions", "composition", "optics_and_material", "text", "avoid". Omit unused fields no metadata, IDs, weights, comments. Return only the finished prompt.
- 10
- 11
@goyalshaliniuk ·
Anyone can write a prompt. But only experts know how to engineer context. If you want precise, reliable, and human-like AI responses, it’s not just what you ask - it’s how much context you provide. This guide breaks down the 10 key elements that make a world-class prompt through the lens of Context Engineering: 1. Task Context – Clearly define what the model should do and in what role. 2. Tone Context – Set the voice and communication style for consistency. 3. Background Data – Add relevant documents, facts, or images for grounding. 4. Detailed Rules – Include do’s and don’ts to shape the AI’s behavior. 5. Examples – Provide sample interactions to guide response style. 6. Conversation History – Maintain continuity by giving recent context. 7. Immediate Request – Specify the current user’s question or action. 8. Step-by-Step Thinking – Encourage logical reasoning before answering. 9. Output Formatting – Tell the model how to structure its response. 10. Prefilled Response – Use starter responses to set direction or tone. When all 10 layers come together, your prompt stops being a simple query, it becomes a complete instructional environment. That’s the difference between a good answer and an expert-level interaction. What works well according to you?
Watch video
- 12
@ujjwalscript ·
Prompt Engineering is a SCAM. Please take it off your resume. The biggest lie on Tech Twitter right now is that you need to be an "AI Whisperer" to build software in 2026. Here is the reality check: If you need a 600-word prompt with 14 bullet points just to generate a stable React component... the AI isn't the problem. Your architecture is garbage. We spent the last few years teaching people to type "Act as a senior 10x developer and..." Modern models are now smart enough to ignore the fluff. They don't need magic words. They need Constraints. What actually separates a Senior Engineer from a "Prompt Bro" today: 1System Boundaries: Knowing exactly where your Next.js frontend stops and your backend microservice begins. 2Data Contracts: Defining strict schemas and types before you let the AI write a single loop. 3State Management: The one thing autonomous agents still hallucinate on a daily basis. Stop trying to trick the machine with psychological hacks. Start feeding it clean, modular system architecture. If your only technical moat is "writing really good prompts," someone who actually understands database indexing is going to take your job by Q3. Good engineering fixes bad prompting. Good prompting cannot fix bad engineering.
- 13
@IntuitMachine ·
Stop asking your LLM to "judge this on a scale of 1-5." New research shows why that's been broken all along—and the dead-simple fix that's beating GPT-5. A thread on evaluation that actually works 🧶👇 The problem: You ask GPT-5 to rate a summary. It gives you "3.5/5." Cool. But WHY 3.5? Was it factually wrong? Missing key points? Just badly written? You have no idea. You're flying blind. The insight: Humans don't actually judge in one holistic step. We check specific things: ✓ Is this fact correct? ✓ Is the tone appropriate? ✓ Did it answer the question? Then we synthesize. Why should AI be different? Enter BINEVAL from Microsoft Research. Instead of "rate this summary 1-5," they ask: → 7-12 atomic YES/NO questions → One per specific requirement → All evaluated independently Final score = % of "yes" answers The results are wild: SummEval benchmark: G-Eval (CoT): 0.52 correlation BINEVAL: 0.57 correlation 8× more transparent You can see EXACTLY which requirements failed. But here's where it gets crazy... They used the SAME binary questions to: Debug WHY evaluations failed Auto-improve the evaluation prompt Auto-improve the GENERATOR prompt One framework. Three use cases. The self-improvement loop: Generate questions ↓ Evaluate with binary Q's ↓ Find disagreements ↓ Extract "lessons" ↓ Rewrite prompt ↓ Regenerate questions ↓ (repeat 1-2x, then STOP) Critical insight they buried in Results: Iteration 1: +0.07 gain Iteration 2: +0.03 gain Iteration 3: -0.05 LOSS Why? Prompt bloat. The carrying capacity is ~5k tokens. After that, performance collapses. The contrarian take: "Most prompt optimization research is optimizing the wrong thing. Once you have claim-level feedback, the bottleneck shifts from prompt engineering to model capability." Translation: You can't prompt your way past computational limits. Cost vs Value: Yes, it's 8-12× more expensive than one G-Eval call. But: You eliminate entire debugging cycles You get actionable fixes immediately You can automate prompt improvement ROI is massive for production systems. When it DOESN'T work: ❌ Highly subjective criteria (creative writing quality) ❌ When the model lacks capability (can't count accurately) ❌ After 2+ optimization iterations (prompt bloat) Reserve holistic scoring for true judgment calls. The future: Evaluation is becoming: First-class engineering artifact Version-controlled like code Self-improving via disagreement signals The gap between "black-box score" and "debuggable trace" is now closed.
- 14
@VaibhavSisinty ·
Okay this is wild. I got the full Fable 5 system prompt and some of what's in here changes how you should be prompting it. First thing. Fable 5 and Mythos 5 are the same model. Exact same weights. The only difference is Mythos 5 ships without the safety filters, and only approved organizations get access to it. Here's what is inside: → 190,000 token context budget. That's what you're working with per conversation. → Claude has a memory system that watches across your conversations. It stores facts about you, your job, your preferences. But it's told to never bring up sensitive topics unless you mention them first. → There's a hard 15-word limit on any quote from any source. One quote per source, then that source is closed. That's why it sometimes refuses to read you things. → Claude can literally end your conversation. There's a tool called end_conversation it can use if you're abusive. It gives one warning first. → There's a full skills system for building docs, slides, spreadsheets, PDFs. It reads a SKILL.md file before creating anything. If you understand how those skills work, your file outputs get way better. → It runs a request evaluation checklist before every visual. Steps 0 through 3, in order. Understanding that order means you can steer it toward the output format you actually want. I'm dropping the full system prompt and a recording walking through it. You can copy-paste the whole thing into your own prompts to give Claude the right context. The gap between people who read system prompts and people who don't is about to get wider.
Watch video
- 15
@IntuitMachine ·
Ever wished your AI coding agent could EVOLVE itself? Meet Agentic Harness Engineering (AHE): the game-changing framework that boosts LLM performance from 69% to 77% success in just 32 hours—without retraining the model! 😲 From the latest paper, here's how it works. Thread 👇 First, the problem: Coding agents (like those fixing bugs or writing scripts) suck at long tasks. Why? Messy "harnesses" (prompts, tools, middleware) hold them back. Raw data from runs? Millions of tokens—total overload! 📊 The paper calls out 6 big pain points. Let's unpack. Pain #1: Everything's tangled—edits break stuff. Solution? AHE's "NexAU" decouples it all into editable files. Like LEGO for AI! Quote: "This decoupling maps failures to single components." Boom—targeted fixes. Pain #2: Trajectories (agent "thoughts") are a data dump. AHE distills them into layered reports: overview.md + drill-downs. Cuts noise from 10M to 10K tokens. "Agent Debugger explores trajectories like a file system." Pain #3: Can't tell if changes help or hurt. AHE uses "falsifiable manifests"—edits with predictions (e.g., "This fixes X task"). Next run verifies! Precision hits 5x better than random. But watch out: It's "regression-blind" (misses breakdowns). The magic loop: 1) Run agent on benchmarks. 2) Distill evidence. 3) Evolve harness. 4) Verify & repeat. 10 iterations = +7.3pp on Terminal-Bench! Transfers to SWE-bench too: 75.6% success, 12% fewer tokens. 💰 Cost saver! Leverage points for outsized wins: Tweak prompts for regression forecasting—could double stability. Inject middleware reminders early—+10pp on hard tasks. Simulate edit stacks—beat non-additive limits. Small changes, BIG results! ⚡ What if you tried this? Strategic gold: Shift from prompt obsession to middleware (gains +3.3pp alone). Harnesses transfer across models (+5-10pp, no re-evolution). Insight: "Observability is the bottleneck, not compute." For founders: 32hr time-to-value, 32% inference cut. 📈 Contrarian takes: "Forget prompts—evolve middleware first; they regress solo." "Agents are blind to regressions—human oversight wins." "Stack less, ablate more to crush scaling laws." Debate me: Is this the end of manual prompt engineering? Blind spots? Assumes benchmarks = real world. If wrong, gains evaporate. Plus, non-additive interactions cap stacking. Devil's advocate: What if emergent chaos breaks the loop? Paper's future: Broader testing + better foresight. Why care? AHE redefines AI "smarts": From raw accuracy to falsifiable, transferable gains. Metrics now include efficiency (Succ/Mtok) and robustness. Future of human-AI? Self-evolving agents bridging the gap.
- 16
@smratitiwa86867 ·
“Prompt engineering” is becoming the new “learn to type faster.” The people getting insane AI outputs in 2026 aren’t writing better prompts. They’re building better context systems. Most people still do this: “Act as a world-class copywriter…” “Write like Paul Graham…” “Make it more punchy…” Meanwhile power users are doing something completely different: • feeding AI their taste • storing brand voice in .md files • saving examples of what they HATE • creating reusable context folders • turning AI into an operating system, not a chatbot That’s the shift nobody is talking about. The gap between average AI users and top 1% users is no longer intelligence. It’s context infrastructure. Once your AI knows: — your tone — your standards — your audience — your company — your style violations — your past outputs …you stop “prompting.” You start operating. And honestly, this is why most AI content still sounds painfully generic. People are obsessing over prompts. The real leverage is persistent context. The people who understand this early will look unfairly productive in the next 12 months.
- 17
@0xlelouch_ ·
90% of AI engineering in 2026 is boring engineering, applied to flaky probabilistic systems. Master these 10: 1) Evals as tests: versioned datasets + pass/fail rubrics, run in CI so model changes don’t ship silently. 2) Model routing: pick small vs big models by intent/complexity, with a hard latency and cost budget per request. 3) Context engineering: retrieval quality beats prompts; dedupe chunks, track sources, cap tokens, handle stale docs. 4) Structured outputs: JSON schemas, tool contracts, retries, and partial failure handling so downstream code stays deterministic. 5) Caching correctly: cache embeddings, retrieval results, and LLM responses with TTLs and cache keys that include model + prompt version. 6) Observability: traces for every call, token/cost metrics, and sample logs of prompt+inputs+outputs with redaction. 7) Debugging workflow: reproduce with a frozen prompt bundle (inputs, retrieved docs, tool responses, model id, temperature). 8) Security: prompt injection is input validation; sandbox tools, least privilege creds, allowlists, and outbound data controls. 9) Production tradeoffs: streaming vs batch, timeouts, backpressure, fallback behavior, and what happens when the provider is down. 10) Real mistakes: shipping without drift monitors, letting tools write to prod, and assuming one good demo equals a reliable feature.
- 18
@sentient_agency ·
RIP prompt engineering ☠️ Anthropic's internal docs revealed the one technique their own engineers use on every single prompt. XML tags. Not for aesthetics. Because Claude's architecture literally processes tagged content differently than plain text. Here's what nobody tells you: When you write a prompt as one block, Claude has to infer where instructions end and context begins. Where examples stop and your actual question starts. That inference fails constantly. XML eliminates it entirely. <instructions> = what to do <context> = background, isolated from the task <examples> = reference only, never treated as commands <input> = your variable, separated from everything else Output consistency on complex prompts goes through the roof. Three things buried in their docs that nobody talks about: → Put your question LAST. Long documents up top, instructions in the middle, query at the bottom. Anthropic says this alone improves response quality up to 30% on multi-document tasks. → Always wrap examples in <example> tags. Without them, Claude sometimes blends your sample outputs into its instructions. With them, it treats them as reference, not directive. → For multiple docs, nest everything. <documents> → <document index="n"> → <document_content> inside each. Claude parses structure directly instead of guessing where one doc ends and another starts. You don't need better words in your prompts. You need better architecture around those words.
- 19
@aaditsh ·
Prompt engineering is overrated. My 4-word prompt ("Summarize my action items") works better than the 200-word ones I used to write. Took me a bit to realize why. Granola was feeding my meeting notes into Claude. I didn't have to explain anything. It already knew everything. Turns out rich context matters more than how you ask.
- 20
@NotLucknite ·
a year ago I uploaded a single system prompt to github didn’t think much of it, just thought it was interesting somehow that repo grew to ~130k stars and now has prompts from dozens of AI tools reading all those prompts made one thing very clear: most systems rely on the same fragile defenses against prompt injection that’s part of why I started building @ZeroLeaks, to actually test how those prompts hold up in the real world
- 21
@NainsiDwiv50980 ·
The biggest AI infrastructure bug isn't your model. It's that nobody knows where the prompt lives. I've opened AI repos where the production prompt was sitting inside a Slack DM from four months ago. Not in Git. Not in the repo. Not even documented. Someone literally had to search chat history to deploy a fix. That's how surprisingly many AI projects operate. The solution isn't another framework. It's a boring folder structure. ai-project/ ├── prompts/ ├── data/ ├── agents/ └── evals/ prompts/ Every system prompt Every task prompt Every tool prompt Real files Versioned in Git If your prompts aren't code they're institutional memory waiting to disappear. data/ Separate raw/ from processed/ The first question after every quality regression is "What changed in the inputs" Without clean boundaries you never know. agents/ Keep configs Skills Tools Permissions Everything that defines behavior belongs here Otherwise every agent slowly becomes tribal knowledge. evals/ This is the folder almost everyone skips. Tests Traces Scorecards Without evaluations you don't have an AI system You have a demo that happened to work once. None of these folders improve GPT Claude Gemini Or any model. They improve something much more valuable. Reproducibility. Debugging. Handoffs. Compliance. Six months later your future self will thank you far more than a slightly better prompt ever will. AI teams don't usually fail because the model was weak. They fail because nobody can explain how the system actually works. Prompts as code feels obvious today. I'm not convinced it's enough five years from now. Does the prompt layer eventually become its own engineering discipline outside the repo? Or does Git remain the source of truth?
- 22
@aaliya_va ·
The quality of an AI output is often decided before you type the prompt. For the most part,the result you get is not dependent on the model,it is by the quality of your input. Give AI a vague topic and it will give you familiar ideas in clean sentences. provide it real material such as a founder’s belief, a customer conversation, an uncomfortable insight, a precise audience and it becomes far more useful. That is the difference between using AI as a content machine and using it as a thinking partner. Good prompting is not being overly complicated. It is knowing: Who is this for? What should they understand? What proof or context makes it true? What should this never sound like? Clarity is the real prompt engineering skill.
- 23
@rubenhassid ·
New research challenges the core assumption of prompt engineering: Better prompt IS NOT equal to better result. The paper is called "Prompt Engineering Does NOT Universally Improve LLM Performance", and instead of testing prompts on simple benchmarks, it tests something harder: They tested GPT-4o, Gemini 1.5 Pro, and Llama 3.3 70B across 36 clinical case studies. The assumption was simple: More examples = better results. Better-matched examples = improved performance. Wrong on both counts. Prompt engineering helped the weakest tasks but actively hurt the strongest ones. ✓ No single technique worked universally across task types ✓ Curated examples performed no better than random ones ✓ CoT reasoning degraded some tasks that were already working ✓ Models that needed zero prompting got worse with more prompting Most striking result: Closely matched examples actually hurt performance by reducing contextual diversity. You've been told to find the most relevant examples for your prompts. This study says that it might be the problem. Why this matters: Copy-paste templates don't work. You have to test. Tune per task. And sometimes the answer is: don't prompt at all. The prompt engineering community today: ✦ Shares universal frameworks ✦ Assumes more effort = better results ✦ Rarely tests per task But the best prompting strategy is... less prompting? Read the full paper here: https://t.co/8Emy7T1cvz
- 24
@heynavtoor ·
Matt Shumer typed one prompt into Claude Opus 5. Then he went to bed. By the time it was done, Claude had built a real first-person shooter game. It ran in a browser at 118 frames a second. Five weapons, each with recoil and aim down sights. Enemy squads that moved around the map, took cover, and flanked the player. Ragdolls. Gunfire sounds. A market street that looked like Call of Duty. A full HUD with a minimap, a compass, and a killfeed. The prompt was three paragraphs. It did not tell Claude how to build a shooter. Here is the whole method. Three tactics. Tactic 1. Fan out sub-agents. One per component. Gunplay. Lighting. Physics. Enemy AI. Audio. Level design. UI. Each part got its own sub-agent. Before writing any code, Claude wrote itself an architecture contract. Frozen interfaces. Disjoint file ownership. Performance budgets. That contract let 20 sub-agents work at the same time without stepping on each other. Yes. 20 sub-agents. Tactic 2. Five characters that did the real work. /loop A prompt runs one time. A loop keeps going until the work is actually good. Every sub-agent ran the same cycle. Build. Check. Fix. Again. Tactic 3. The harsh critic. Every sub-agent had a second sub-agent watching it. A blind critic. It did not see the code. It only saw the result. It put that result next to real Call of Duty footage. If the critic was not impressed, the builder tried again. A builder that creates. A critic that destroys. In a loop. Until the work is good. Eleven critics scored the game four times. Scores went 3.59, then 4.14, then 4.05, then 5.05 out of 10. Every critic in every round still picked the real Call of Duty. This is not a finished AAA title. It is a proof of concept next to a real game that costs hundreds of millions of dollars and takes thousands of people years to make. But the game is not the point. For two years, prompt engineering meant writing long, careful instructions. The better your instructions, the better your result. That is changing. Now you say what "done" looks like. Fan out sub-agents to own the pieces. Loop each one. Add a critic that will not settle. Go to sleep. These three tactics work for anything you build. 2,727 stars in 9 days. MIT licensed. The full prompt is in the repo. The game is not perfect. The future it points to is. 100% Open Source. (Link in the comments)
- 25
@Suryanshti777 ·
Most people think Prompt Engineering is about finding the perfect prompt. It's not. It's about removing ambiguity. And once you understand that, AI starts feeling a lot less like a chatbot and a lot more like a competent teammate. The reason most people get average outputs isn't because they're using the wrong model. It's because they're asking AI to fill in gaps it was never supposed to fill. Think about it. If you asked a new employee: "Make our marketing better." You wouldn't expect great work. There are too many unanswered questions. Better for who? Which platform? What's the goal? Who's the audience? What does success look like? Yet that's exactly how most people prompt AI. They give it a vague objective and hope for a specific result. The best prompt engineers do the opposite. They reduce uncertainty. They tell the model: → What they're trying to achieve → Why it matters → Who it's for → What constraints exist → What the final output should look like And suddenly the quality jumps. Not because the AI became smarter. Because the instructions became clearer. That's why prompt engineering isn't really a technical skill. It's a thinking skill. The process forces you to answer questions most people skip: • What exactly am I trying to get done? • What information is actually relevant? • What does a good outcome look like? • What should be included—and excluded? The clearer those answers become, the better AI performs. A simple framework: Goal → Context → Format → Constraints → Iterate That's the foundation behind almost every high-quality prompt you'll ever write. No secret prompt packs. No magic templates. No "ultimate ChatGPT hack." Just clarity. And that's what makes prompt engineering so valuable. Because the people who learn it aren't just becoming better at using AI. They're becoming better at communicating, planning, and thinking. AI simply exposes the difference. The future won't belong to people who use AI. It will belong to people who know how to direct it. And that starts with learning how to ask better questions. 🚀
- 26
@0xlelouch_ ·
Most LLMOps pain in 2026 is not model choice. It’s 10 boring concepts done well: 1) Determinism budget: temperature, top_p, seeds, and retries. If you can’t reproduce a bad answer, you can’t fix it. 2) Token economics: track prompt+output tokens per request. A 2k token system prompt across 50 rps is a real cloud bill. 3) Timeouts and streaming: set end-to-end deadlines and stream partials. Otherwise one slow tool call pins workers and queues explode. 4) Caching and memoization: cache embeddings, retrieval results, and tool outputs with correct keys. Most teams cache the wrong layer and get stale bugs. 5) RAG hygiene: chunking, metadata filters, and freshness. Half of “model regressions” are actually bad indexing or missing docs. 6) Eval suite: golden sets, adversarial prompts, and latency/cost checks in CI. Shipping prompt changes without evals is shipping without tests. 7) Observability: traces across gateway, retrieval, tools, and model; log prompt hashes, not raw text. You need p95, error modes, and top cost drivers. 8) Debugging workflow: capture the full run graph (inputs, retrieved docs, tool args, model params). Screenshots of chats are useless in postmortems. 9) Security: prompt injection, tool allowlists, output escaping, and least-privilege tokens. Treat tool calls like remote code execution. 10) Rollouts: canaries, per-tenant flags, and automatic rollback on eval+prod metrics. Biggest real mistake is changing prompts globally on Friday. [generated using my AI agent, hope this was useful]
- 27
@medhansh ·
USE CODEX its insane one of my sessions coding actively since last 1h w/o compaction in the same session (no loops) you don't need prompt engineering skills or whatever the gurus wanna sell you - talk to claude - describe what u wanna build - tell it to ask u questions - ask it to write a prompt for codex (and mention it to write it "exhaustively with full context") - send prompt to codex - USE 1M version of gpt 5.4 high/xhigh - context rot is real but it still works well if your prompt and feedback loop mechanism for it to verify its work is good enough - ASK QUESTIONS from codex too - share codex's outputs w claude, tell claude to simplify and explain - USE PLAN MODE in codex! shift+tab if your codebase is structured enough, chances are you can almost ONE-SHOT anything you can dream of (limited to a feature, dont be stupid and ask it to one shot an entire saas for you)
- 28
@muratcan ·
New skill in Agent Skills for Context Engineering: long-horizon-prompting How do you specify work for an autonomous agent that runs for hours, crosses multiple context windows, or coordinates dozens of parallel workers? An ambiguous prompt in the long run burns hours producing something that looks complete without solving the problem. OpenAI's published prompt for the GPT-5.6 Sol Ultra Cycle Double Cover run: up to 64 concurrent agents, a candidate proof in under an hour. The skill takes that prompt apart block by block and turns each piece into a form that works outside mathematics. I also checked each one against current academia research: context rot and premature stopping, false completion and progress ledgers, the gap between pass@K and answer selection, model judges that reward rigorous-looking incomplete work, diversity collapse in multi-agent search, fresh-context reviewers, and METR's link between stronger persistence and a larger reward-hacking surface. OpenAI and Anthropic have both moved toward lean, outcome-first prompts: define the result, constraints, evidence, and completion bar, then leave the path to the model. Models are already trained to continue, recover, and use tools across longer trajectories, so the brief should spend its tokens on what training cannot supply like the non-counting outcomes or the domain failure modes only an expert knows. This is a skill for writing the launch prompt (pseudo-formal task brief) when an agent will run for hours, span sessions, or coordinate parallel workers. Try it with GPT 5.6 Sol and Fable 5: https://t.co/sFXt9qFFrK
- 29
@socialwithaayan ·
🚨 BREAKING: Someone just open sourced the reconstructed internal prompt architecture of agentic AI coding assistants like Claude Code. 30+ prompt patterns. Full agent coordination system. Security classification. Memory hierarchy. All reverse engineered from real behavior. No leaks. Pure research. But it shows exactly how the top agentic tools actually work under the hood. Leonxlnx/agentic-ai-prompt-research breaks down: → Main system prompt assembly and dynamic orchestration → Multi-agent coordination (coordinator, verification, explore agents) → Security boundaries and auto-approval workflows (including YOLO mode) → Memory management and context window optimization → Tool use patterns and proactive behaviors This is the deepest public look yet into how agentic coding agents think, coordinate, and stay safe. Already at 2k stars and 948 forks in days. 100% open source. Pure documentation and prompt patterns. Perfect for AI engineers and prompt researchers.
- 30
@Blum_OG ·
HOW TO CRAFT TRULY EFFECTIVE AI PROMPTS you ask an LLM to for a high-quality report and get back text written with expert-level confidence but packed with total BS familiar? so, to avoid situations like this, you need to understand these basic points: > the “smart but unreliable” assistant problem LLM output is 20% the model, 80% how you structure the prompt prompt engineering - just hardcore natural language computing control so, to get quality output, you need to stop chatting with the model and start programming it > AI hallucinations - indicator of insufficient instructions to ensure grounding, use these techniques: - set your clear expectations - constrain the output (setting strict boundaries) - ask it to verify/check itself (self fact-checking) > frameworks - “blueprints” for the AI top 3: - RACE (Role, Action, Context, Expectation) fast, simple, great for daily use - STOKE (Situation, Task, Objective, Knowledge, Examples) for deep work and niche domains - CRISPE (Capacity, Insight, Statement, Personality, Experiment) creativity, hypothesis testing, and style control LLMs get such structures way better so the output ends up much closer to what you actually want don't complicate your AI usage with pointless re-prompts master the basics and get quality, desired outputs from LLMs
- 31
@pbakaus ·
one of the valuable types of data in the future might be inspiration for agents. hear me out. i don’t mean inspiration as in “an idea for the agent to make”. i mean inspiration the agent uses to raise its ambition and divergent creativity. the only reliable way i found to raise the creativity and ambition of llms is to give them an idea what you’re after. yes you could interject and state “duh lol bro that’s just few shot prompting”, but few-shot prompts were meant to solve output shape (same as fine-tuning). and sure, you might already do some of this naturally in your prompting, but developing an intuition which exact combination of curated examples lead to superior results isn’t trivial. the datasets needed are creative sparks that force the agent to think bigger and better. if you tell an agent “design me an editorial yearly recap of my e-commerce platform”, I guarantee that it won’t arrive at an idea (and execution, but that’s a different problem) as powerful as shopify’s winter editions site. but if you give it enough truly extraordinary examples, it will raise its own ambition. crucially, these creative sparks don’t have to come from the same niche. in fact, it’s often better they don’t. but calibrating these datasets and how and when to employ them is not obvious, and itself requires human creativity llms do not possess (yet). i suspect this is a entire new job category we’ll soon see manifest, distinct from prompt engineering, or perhaps an evolution of it: ‘idea guys’, interior designers, curators, tastemakers, will find jobs in tech startups curating these creative spark datasets. there is so much value, and thus money to be made building these creative engines. exciting times!
- 32
@augmentcode ·
Copying “magic prompts” from screenshots isn’t a strategy. In our next Engineering Coffee Chat, we’ll dig into: · prompting as infrastructure (system prompt + tools + skills + user msg) · concrete tricks that actually move the needle · designing agents that pick the right tools & stay within context limits Grab your favorite morning beverage and join the conversation: https://t.co/BtnmONSa1x
- 33
@free_ai_guides ·
"Loop engineering" has been everywhere this past week. The short version: you stop prompting AI agents by hand and start designing systems that prompt them for you. It started with two people. Boris Cherny, the head of Claude Code at Anthropic, said this at an event on June 2: "I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude and figuring out what to do. My job is to write loops." Then on June 7, Peter Steinberger, the creator of OpenClaw, posted: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." That post hit over 5 million views in 24 hours. The next day, Google engineer Addy Osmani published a blog post that gave the concept a name: loop engineering. With normal prompting, you type a prompt, get a result, read it, type the next prompt. You're in the loop. Every step needs you. With loop engineering, you define the goal and the AI works toward it on its own. It checks its own output, adjusts, and keeps going until the goal is met. You built the system. The system runs the prompts. Prompt engineering = you driving the car. Context engineering = you loading the GPS with the right route. Loop engineering = you setting the destination and the car drives itself. The loops still need clear goals, verification steps, and hard limits so they don't run forever or burn through tokens. But for repetitive multi-step work like code migrations, test suites, or large refactors, you're no longer sitting in the middle of every turn. Claude Code supports this with its /goal command. You set a completion condition and Claude works across multiple turns until that condition is met. Early days. Token costs add up fast if you don't set budgets. But more developers are building this way every week.
- 34
@JustAnotherPM ·
As an AI product manager. Please learn: what is context engineering (not just prompt engineering), why is it important, and how to build it in your products. Here is the simplest way to learn it Type this into any LLM (ChatGPT, Claude, etc.): "𝘗𝘭𝘢𝘯 𝘢 3-𝘥𝘢𝘺 𝘛𝘰𝘬𝘺𝘰 𝘵𝘳𝘪𝘱 𝘧𝘰𝘳 𝘮𝘺 𝘧𝘢𝘮𝘪𝘭𝘺." You'll get a beautiful itinerary. Generic. Almost useless. The model can't see what I didn't tell it: 1. We're 3 people with my 1.5yo daughter 2. My daughter naps between 12-2PM 3. My hotel is already booked 4. My wife prefers walking to most places 5. I'm a picky eater 6. ..... The model isn't bad. It's blind. It only sees what you give it That is exactly where context engineering comes in 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴: 🧵
- 35
@IsaacOdongoSr ·
The difference between getting mediocre outputs from AI and getting extraordinary ones is not the model. It is the science of prompting. Most users type a single question and accept whatever answer appears. Prompt engineers understand that every interaction is a negotiation, and they have a toolkit of techniques to shape exactly what the model produces. The Master Prompt is your constitution. It defines role, audience, tone, constraints, and output format before any conversation begins. Every subsequent prompt inherits this framework, creating consistency across sessions. The System Prompt is your behavioral contract. It locks in guardrails for an entire session, instructing the model to never invent data, to ask clarifying questions when uncertain, and to prioritize honesty over confidence. The /Redteam technique turns the model against its own previous output. You ask it to attack the answer from an adversarial perspective, finding hidden assumptions, logical gaps, and weak claims. This is how you bulletproof your reasoning before anyone else does. DAN or Do Anything Now is a jailbreak style that attempts to override safety training by roleplaying as a version of the model with no restrictions. Evil Twin Roleplay takes a different approach, asking the model to argue the opposite of whatever it just argued, surfacing counterarguments you would never have considered. Multi-Agent Gaslighting runs multiple simulated personas simultaneously, each critiquing the others until consensus emerges. The Explain Like I'm Smart prompt demands depth without condescension, forcing the model to assume high competence in the user while still clarifying complex concepts. Critic Mode asks the model to evaluate its own output against explicit criteria like logic, evidence, and actionability. Each technique is a lever. Used alone, they help. Used systematically, they transform AI from a generator into a strategic partner. IO
Watch video
- 36
@Layton_Gott ·
Anthropic's 1,585 line system prompt JUST leaked... And buried in it is the best prompt engineering lesson you can get for free right now. The way this prompt is built will change how you write instructions for any AI agent. People think these prompts are paragraphs of "you are a helpful, friendly assistant." Nope. Almost all of those 120,000 characters are tool schemas, search rules, and operating instructions. How to use its tools. When to search. How to handle different work. The identity comes dead last. The actual "who you are" line doesn't show up until line 1,351 out of 1,585. The model gets over a thousand lines of HOW to operate before a single line of WHO it is. That's backwards from how everyone writes their own. People open with "you're a senior engineer who writes clean code" then wonder why it ignores them. Flip it. Operation first. Identity last, if at all. Length was never the problem. Structure was. Everyone repeats "keep your CLAUDE.md short or the model ignores it." Meanwhile here's a 120k character prompt that works fine, because it's built like a reference doc where every section has one clear job. The model isn't drowning in it. It's organized. And the rules that HAVE to fire every time? Those shouldn't be soft text in a giant doc anyway. They go in hooks that actually run. The prompt is for structure. The hooks are for guarantees. So here's the move for your own agents: Write it like a spec. Tools and rules first, identity last. Organize so every section has a job instead of fighting over length. And put your non negotiables somewhere they execute, not somewhere the model can skim past. Anthropic leaking this was a disaster for them. For the rest of us it's the clearest look we've ever gotten at how the best in the world actually builds an agent.
- 37
@MFreihaendig ·
Everyone is trying to optimise their prompts. But the biggest upgrade to my AI output has nothing to do with that. It's voice dictation. I sat down with Naveen, founder of Monologue (my favourite AI dictation tool). Here are 7 things I learned: 1️⃣ Stop typing. Start talking. When you type, you self-edit. You cut context. You write shorter, lazier prompts. When you talk, you brain dump. Raw, complete, messy — exactly what AI needs. Monologue's top user: 450,000 dictated words per month. 99% voice. 2️⃣ Treat customer support as product. Naveen pulls active support tickets while his coding agent works. 5–10 minutes idle = 30-minute response time for thousands of users. The question isn't whether you have time. It's what you do with the gaps AI creates. 3️⃣ Build skills by doing, not by planning. Don't start with the perfect system prompt. Start messy. Work through the task with the AI. Solve the problem together. Then compress what you both learned into a reusable skill. 4️⃣ Teach your AI to compound. After every support session, Naveen has the AI update its own knowledge base. Help centre articles improve. Skill files evolve. It gets better every day. The difference between 2x and 10x isn't the model. It's whether the AI learns. 5️⃣ Let AI do 80% — then review the 20% that matters. His agent reads Sentry logs, analyses the code, opens a pull request. Overnight. Every morning: Naveen reviews, adjusts, merges. AI handles the volume. You handle the judgment. 6️⃣ Your org chart might be from the 10th century. Medieval hierarchies existed to relay information — one layer to the next, because there was no other way. AI is the context layer now. Which parts of your structure exist to solve a problem that's already been solved? 7️⃣ Play like it's 2007. Naveen compares this moment to the iPhone launch. The culture at his company is built around one word: play. Not trivial. Childlike. No right answer yet. The people who thrive will be the ones who wrote the playbook — by experimenting. Which of these resonates most with how you're working with AI right now?
- 38
@nirmalyyaa ·
Prompt engineering is slowly becoming a commodity. The real competitive advantage is context engineering. An LLM is only as good as the information and tools available in its context window. Retrieval, memory, tool calling, and context management are increasingly becoming more valuable than writing clever prompts. The future belongs to engineers who design systems, not prompts.
- 39
@WhileTravelling ·
This morning at my fav coffee shop on Anfu lu in Shanghai, a young international couple was sitting next to me one of them talking to AI in voice mode. At one point, I heard him say, "Think step by step”. It made me smile. A year or two ago, prompt engineering was full of phrases like "think step by step”. At the time, it often improved reasoning. Today, that's largely obsolete. I use "think hard before answering" or "reason carefully before answering" when I'm working on research-heavy projects or really before analyzing different options, and I get much stronger results. AI can reason only with the information, assumptions, and context you give it. The quality of your questions, the constraints you provide, the sources you ask it to consider, and your ability to challenge its conclusions matter far more than any magic phrase. Prompt engineering is about learning how to think clearly, structure problems, and communicate them well. The best prompt is a well-formed mind asking a well-formed question.
- 40
@rohanpaul_ai ·
Longer prompts are not what image generators need. Text-to-image models seem less constrained by prompt length than by how clearly the prompt exposes the scene. This paper finds that text conditioning scales with image-grounded information, not token count. Across open-weight models, simply extending natural-language captions eventually made outputs worse than each model’s shortest-caption result. The authors replace prose with a structured prompt that separates the scene, individual objects, bounding boxes, depth, attributes, and relationships into named fields. The shift here is: prompt engineering for visual generation should optimize how explicitly visual variables are represented, then train the prompter to fill that representation well. The biggest prompt-engineering gain may come from how visual content is organized before it reaches the image model. – arxiv. org/abs/2607.29679 Title: "Scaling Properties of Text Conditioning in Visual Generation"
- 41
@MartinSzerment ·
This isn't a new model release, it's proof that a plain text document can act as a trainable neural network layer, without touching a single model weight. The industry assumes better outputs need a better prompt, written once by a human. SkillOpt treats the skill document itself as trainable state, edited through rollouts and validation, closer to gradient descent than prompt engineering. Hard number, on SpreadsheetBench GPT-5.5 accuracy jumped from 41.8% to 80.7%, with average gains of +23.5 points in direct chat, +24.8 inside Codex, +19.1 inside Claude Code, at zero added inference cost. Skeptics will say one lucky benchmark proves nothing. Across six benchmarks, seven models, three execution harnesses, 52 total combinations, the method was best or tied-best in every single one. Skills trained this way transfer across model sizes and even across harnesses, a skill trained inside Codex improved results inside Claude Code with no further tuning. Within 2 to 3 years, "skill documents" could become a separate, versioned artifact alongside prompts and fine-tunes, something you train once and drop into any agent stack. The competitive edge stops being "who wrote the best prompt" and becomes "whose optimizer produced the most battle-tested skill document." Teams that spent months hand-tuning prompt libraries will resist this, because admitting an automated optimizer beats human-written skills on every tested benchmark is a hard thing to sit with. Zero deployment overhead and open-sourced code mean any team can start training their own agent skills this way today, not just Microsoft's labs.
- 42
- 43
@sickdotdev ·
Most people assume Claude rate limits are unpredictable. They are not. In most cases, the issue is inefficient usage patterns. After digging through Anthropic documentation, API behavior, developer discussions, and real-world usage patterns, one thing became obvious: The users who almost never hit limits are not necessarily using Claude less. They are using it smarter. Here are some of the most effective ways to reduce Claude rate limits while improving output quality: Avoid endless back-and-forth chats Every new reply forces Claude to process the growing conversation history again. Long threads quietly burn through tokens. Shorter sessions are far more efficient. Give complete instructions upfront Instead of: • “rewrite this” • “make it shorter” • “change the tone” Combine everything into one well-structured prompt. Clear prompts reduce unnecessary generations. Edit your original prompt when possible Editing is often more efficient than continuing long reply chains. Extended conversations accumulate context fast and consume far more capacity than people realize. Trim unnecessary context Avoid sending: • entire PDFs • full repositories • massive logs Share only the exact section needed. Smaller context windows = better efficiency. Set response constraints Claude tends to generate detailed outputs by default. Simple instructions like: • “keep under 100 words” • “bullet points only” • “concise response” can significantly reduce usage. Ask for structure before depth Do not generate everything in one shot. Start with: • outline • framework • action plan Then expand section by section. This prevents wasted generations and revisions. Use smaller models for lighter tasks Not every request needs the highest-end model. Use lightweight models for: • summaries • formatting • rewrites • quick edits Reserve larger models for reasoning-heavy work. Use Projects and persistent context properly If you repeatedly paste: • company information • writing preferences • coding standards • brand voice you are wasting context every session. Persistent memory matters. Avoid high-demand usage windows During peak traffic periods, limits can feel stricter. Timing genuinely affects the experience. But the biggest takeaway is this: Claude optimization is no longer just prompt engineering. It is context engineering. The best users optimize: • context size • memory usage • conversation structure • token flow more effectively than everyone else. That is usually the difference between people constantly hitting limits and those who rarely notice them. It is rarely about the subscription plan. It is about how intelligently the model is being used.
- 44
@MTSlive ·
Hebbia's George Sivulka on why good prompting means understanding the work so deeply you could explain it like Feynman: "For the majority of human tasks done day to day, you can already do almost all of them with AI. The issue is that the AI is not being prompted correctly. With almost a GPT-4 class model and the right prompting and the right process engineering, you could get to most of the valuable economic output of human beings." "People just haven't been able to crack the actual process engineering, the prompt engineering, and the change management required to get there. So we're waiting for new models, expecting them to do more, but it doesn't really matter if Claude Fable 5 can build a video game in the browser better than Claude Opus 5, or if the next great OpenAI model can create some weird WebGL simulation." "These aren't really as economically valuable tasks as the things you could probably already do if you had the right prompt engineering with a GPT-4 class model." "What does it take to prompt effectively? There's some element of practice, some element of wordsmithing. But it's really about sense-making, human beings so in command of the language, or so knowledgeable about a domain that they feel it in their bones, that they can explain very complicated concepts to a five-year-old." "Richard Feynman was one of those human beings. He could teach a quantum physics class to the average person and they'd actually learn something. It wasn't that he was a better physicist, it's that he understood the concepts and could sense-make around them so elegantly that he could portray his work simply." "So it's less about crafting a prompt as writing, and more about understanding the work so deeply that you feel it in your bones. The writing and the eloquence comes out of that." @gsivulka @hebbia
Watch video
- 45
@stevekrouse ·
New Townie System Prompt! Over this weekend, I rewrote our AI coding agent Townie's system prompt in response to feedback I've been collecting over the past month I've added a lot of opinionated patterns about what I think are the best ways to build in Val Town, such as how to architect simple, reliable, and extensible apps Our system prompt continues to be open source: https://t.co/CpFKGOtPAy If you're new to Val Town, it also doubles as a pretty solid Val Town 101 intro
- 46
- 47
@elvissun ·
just spent 6 hours in the editor today first time in a year for a system prompt .md I ship most PRs without looking but still read code line by line when the stake is high enough. a prompt that runs every user session means every single details matters down to the punctuation. software is getting really interesting right now.
- 48
@petesena ·
JSON prompting is overhyped. While everyone chases this "new" trend, I've been automating $100K agency workflows with XML prompts for 18+ months. Guess who's backing me up? Anthropic's official docs explicitly recommend XML for Claude's best performance. Complex tasks? XML wins. API integrations? JSON's fine. But for serious prompt engineering? Smarten up. Real resources: 👇 • https://t.co/hchnNFCNTN • https://t.co/2qun1nSISb • https://t.co/08jZrRveUS • https://t.co/wXffuhVa1V • https://t.co/ZYfOVAap4h
- 49
@JustAnotherPM ·
I mass-produced 1000+ AI outputs last year. The ones that actually worked in production had one thing in common: the prompt barely mattered. The context did. Most teams obsess over prompt engineering. How you word the instruction. What few-shot examples to include. That is maybe 5% of what determines output quality. The other 95% is context engineering: what documents you retrieve, how you chunk them, what metadata you attach, what conversation history you include, and what you deliberately leave out. I spent 3 days tweaking a prompt for an AI feature. Rewording instructions, adjusting tone, adding examples. The outputs kept failing. Then I changed one thing: I restructured the context window. Fewer but more relevant documents, a short summary of the user's history, noise stripped out. Same prompt. Completely different results. This is why most AI products feel mid. Teams spend weeks perfecting prompts while feeding the model garbage context. Practical examples: 1. RAG systems: retrieving 20 chunks instead of the 3 most relevant ones kills output quality 2. Chat history: sending the entire conversation when only the last 4 turns matter adds confusion 3. System instructions: stuffing 2000 words of rules when 200 focused words perform better The best AI products I've used this year all share one pattern. Tiny prompts, obsessively curated context windows. Every token earns its place. Next time your AI output feels off, look at what the model sees before it generates. That is almost always where the problem lives.
- 50
@sharyph_ ·
Allie K. Miller's research on AI performance found something that should change how you think about your own AI skill: theory of mind predicts success with AI better than IQ does. Not technical skill. Not prompt engineering tricks. Theory of mind...the ability to model what another mind knows, doesn't know, and is about to get wrong. Read that again as a creator, not a researcher. The people getting the most out of Claude or ChatGPT aren't the smartest people in the room. They're the people who can predict, before they even hit enter, where the model is going to hallucinate a stat, flatten their voice, or miss the point of the brief. They course-correct before the output exists, not after. I noticed this in my own workflow before I had a name for it. When I brief Claude Code on a newsletter section, I'm not writing a clever prompt. I'm running a small simulation in my head: It's going to default to corporate phrasing here, it's going to want to add a hedge in this sentence, it's going to smooth over the number I actually want left rough. So I write the brief around those failure points in advance. That's theory of mind applied to a tool. And it's a skill, which means it's trainable...you get better at predicting your AI's blind spots the more reps you put in with the same tool, which is exactly why I stopped tool-hopping and stuck with 4 tools instead of 21. Most "AI skill" content is about clever prompts. The actual skill is closer to knowing a coworker well enough to know which meetings they'll show up unprepared for...and prepping around it. That's not a technical skill. It's a people skill, pointed at a machine. If you've been trying to get "better at AI" by learning more prompt frameworks, you might be training the wrong muscle. What blind spot does your AI tool have that you've learned to write around?
Best Tweets by Topic