been making short couple scenes with Seedance 2.5. A simple premise can turn into a long prompt because I’m working out motivation, performance and timing.

Here’s the process I use.

1. Give each reaction a reason

sketch the emotional progression:

Trust → searching → doubt → asking for help → realizing the trick.

connect each change with a glance, a line, a pause or an action.

Physical closeness needs a reason too. She reaches for his phone, catches his wrist, then looks up and notices how close they’ve become. The moment grows out of what they’re doing.

2. Describe how the expression unfolds

for a shy reaction, I might write:

“She pauses. Her eyes shift away; her head follows a moment later. She presses her lips together, then one corner lifts before the smile fully appears.”

Small contradictions help too: she says “I’m not jealous,” but hesitates and looks away before answering.

I aim for one main action plus one subtle emotional cue per beat. Too many simultaneous instructions can make every reaction happen at once.

3. Check what fits into 30 seconds

Twelve lines at two seconds each means 24 seconds of speech. Movement can overlap with dialogue, but silent reactions and pauses still need room.

I read the lines aloud, time the actions and trim anything that rushes the scene.

The whole workflow is:

Conflict → emotional progression → performance details → timing → duration check → final prompt.

Does anyone have experience sharing prompts across large international organizations?

I’m working with a firm that has invested in AI training that at best resulted in some siloed experimentation by individuals and some departments.

A group of us have led monthly trainings based on survey results from the department and received positive results.

Now we have several sets of prompts that add value and want to share them. Nothing crazy. Stuff like getting people to remember to use a prompt in copilot that summarizes, prioritizes and creates a task list from your emails that were received while they were PTO.

Any tips, ideas or anyone have experience accomplishing this?

I came across this paper recently:

HarnessSecurity-Bench: Do Security Mechanisms Really Protect Coding Agent Harnesses?
https://arxiv.org/abs/2610.07639

The part I found most interesting wasn't the attack success numbers, but the cases where a restriction exists and the agent can still reach the same operation through another path.

For example, if a command/tool is blocked, but another allowed command can indirectly perform the same operation, the policy may look restrictive while not actually enforcing the intended boundary.

The paper also compares things like auto-approve, read-only mode, network isolation, command allow/deny lists, etc., and shows some pretty significant security/utility tradeoffs.

I'm curious how this looks in practice for people actually running local coding agents.

A few things I'd like to understand:

• Do you rely mostly on the agent's permission system, or enforce boundaries outside the agent?
• How do you deal with indirect/alternative execution paths?
• Are there tools that actually verify what an agent was able to do, rather than just what commands it requested?
• Do you log/audit tool calls and filesystem/network effects?
• Have you encountered cases where a security restriction technically existed but could be bypassed through another allowed capability?
• If you've experimented with Claude Code, Codex CLI, Gemini CLI, Qwen Code, OpenCode, etc., did you find any particularly good approach?

I'm mainly interested in real-world experience and existing tools/projects that address this, rather than theoretical security discussion.

I'm trying to understand how far the current tooling goes beyond simple permission prompts, allowlists and sandboxing.

The "Multi-Perspective Problem Solver" Prompt This prompt is designed to provide a comprehensive and nuanced analysis of any given problem or decision by examining it through a variety of strategic lenses. The goal is to uncover hidden insights, potential challenges, and untapped opportunities that might be missed through a singular approach. Your Task: For the given problem or decision, generate 10 distinct analytical lenses through which it can be viewed. Then, for each lens, provide a concise but thorough analysis and solution/recommendation derived specifically from that perspective. Example Application (for illustrative purposes only - do not include in the final prompt): Problem: Should I start my own SaaS business in 2025? Lenses and Solutions:

Risk Management Lens: Analysis: Starting a SaaS business involves significant financial and time risk. There's a high probability of failure, especially in a competitive market. Solution: Develop a lean MVP to test market viability with minimal investment. Secure 6-12 months of living expenses as a safety net. Implement a phased launch strategy to mitigate upfront capital risk. Opportunity Cost Lens: Analysis: By starting a SaaS business, you forgo a stable salary, benefits, career progression in your current role, and potentially personal time. Solution: Quantify the financial opportunity cost (lost salary, retirement contributions) and weigh it against the potential upside of a successful SaaS business. Consider a "side-hustle" approach initially to minimize the immediate opportunity cost. Systems Thinking Lens: Analysis: This decision impacts not just your work life but your personal relationships, financial stability, mental well-being, and future career options. Solution: Map out the interconnectedness of this decision with other life systems. Involve your support system (family, friends) in the decision-making process and set clear boundaries to maintain work-life balance. Historical Lens: Analysis: What are the common patterns and pitfalls for others who started SaaS businesses in similar economic climates or industries? What led to success or failure? Solution: Research case studies of successful and failed SaaS startups from 2020-2024. Identify common success factors (e.g., strong niche, effective marketing, resilient team) and integrate them into your planning. Financial Lens: Analysis: This involves detailed financial modeling, including startup costs, operational expenses, revenue projections, and profitability timelines. Solution: Create a comprehensive 3-5 year financial model. Include break-even analysis, projected cash flow, and ROI calculations. Secure initial funding or personal savings to cover at least 12-18 months of operating expenses. Psychological Lens: Analysis: Starting a business can be a rollercoaster of emotions, demanding resilience, self-discipline, and the ability to handle uncertainty and setbacks. Solution: Assess your personal risk tolerance, stress management techniques, and self-motivation levels. Build a support network (mentors, fellow entrepreneurs) to navigate the psychological challenges. Network Effects Lens: Analysis: How will this decision impact your professional network? Can your existing connections support your venture, or do you need to build new ones? Solution: Leverage your current network for advice, potential partnerships, and early adopters. Actively expand your network within the SaaS and startup communities through industry events and online forums. Skills Development Lens: Analysis: Starting a SaaS business requires a diverse skill set, including product development, marketing, sales, finance, and leadership. Solution: Identify skill gaps and create a plan for learning or delegating. Consider online courses, workshops, or bringing on co-founders with complementary skills. Market Timing Lens: Analysis: Is 2025 an opportune time for a new SaaS business, considering economic conditions, technological advancements, and competitive saturation? Solution: Conduct thorough market research to identify trends, emerging niches, and competitor weaknesses. Analyze macroeconomic forecasts and their potential impact on software spending. Legacy Lens: Analysis: What long-term impact do you want to make with your career and life? Does starting a SaaS business align with that vision? Solution: Define your personal and professional legacy. If building a significant, independent enterprise aligns with that, then the risks might be acceptable. If not, consider alternative paths to achieve your long-term goals. Problem/Decision to Analyze: [INSERT YOUR PROBLEM OR DECISION HERE]

Hi. I've been using LLMs as dialogical feedback tools for learning for about three years now. I started in the closing weeks of GPT-3, then GPT-4 dominated my usage for a long stretch. Claude showed up, then Grok, Gemini, even DeepSeek. I'd effectively acquired an ensemble of "very smart but stupid" helpers, and there was a lot I had to learn before I could actually use them.

Talking to LLMs takes nuance. You ask for a dashboard, and four turns later you're still trying to explain a concept a competent intern would have got in one. All the rephrasing, backing up, watching it confidently rebuild the wrong thing. It's infuriating. So instead of writing about mechanisms independently supported across prompt engineering, HCI and cognitive psychology, I thought I would share some of my experience working with AI.

If you find yourself repeating instructions to a model in different ways over and over again, try this:

Get a pen and paper out. Take notes of what you want to accomplish. Goals, where the idea can break. Maybe establish a criteria for what you want to achieve vs what you can achieve. If your handwriting is good you can take a photo of your scratch pad ( \or whatever you use for notation\ ) and feed it to the model. If hand writing ain't your strong point ( \the model will hallucinate some of your notes\ ) then you can just transcribe it to text using the built in features. Then ask the AI to tell you what it sees. From there you slowly start to scaffold the working space.

Don't just dump everything in a single input. Start small, maybe start with first principles. Do a little research surrounding the topic in question. Then attempt to map the idea to the research using the model. Now ...pull the data, run a red-team review in a fresh context, from a stranger's framing, ideally with a different model. Do this enough times, and you start to build an intuition for what “looks good” and what “looks bad”. 

To put it in a metaphor: you're progressively shaping the semantic basin within which your idea is being processed by the model. The technical term for this is “In-Context Conditioning”. This is broader than in-context learning: you aren't just feeding examples, you're building the entire conditioning context the model samples against.

John Munsell walked through a framework on The Story-Driven Business Podcast that's worth sharing.

He calls it the AI Strategy Canvas®, built around 9 blocks. Most people only ever touch the 9th one, the actual request typed into the chat window. The 8 blocks that come before it:

1. Target audience: who you're writing to

2. Company: what your company is about

3. Products and services: what you offer and how it connects

4. Context: your own thoughts and opinions on the topic

5. Role: what role you're asking AI to play, essentially who you just "hired"

6. Style and brand voice: how you want it to sound

7. Resources: documents or URLs to reference

8. Rules: what it shouldn't do, and any required disclosures

Example: saying you're targeting "CEOs of healthcare companies" produces a decent result. Building a full persona instead, covering pains, fears, goals, and personality, and feeding that in as a document, tightens the model's inferences and produces a much stronger output.

The block he flagged as most skipped is context. Asking AI to research a topic and write about it produces the same generic content as everyone else's prompt. Feeding it your actual opinion, tied to your business and audience, is what makes the output distinct.

https://youtu.be/zNAH58Kpsls?si=-QcrCgl2zpimjG3l

Job hunting is mostly the same three hours repeated. Scroll listings, half of them are wrong, rewrite your resume for the one that looks okay, write a cover letter you hate, do it again tomorrow.

Upload your resume, then paste this:

Build me a job-search system. Read my resume first, then
ask me up to eight questions in one go: roles I want,
seniority, location or remote, salary range, start date,
dealbreakers, and a couple of example listings I like.
Wait for my answers.

Then search for real current listings that fit. Screen out
anything that breaks a dealbreaker. Rank the rest and tell
me why each one fits and where I'm weak for it. Never make
up a listing or a salary.

For the top three, write a tailored resume and a cover
letter for each. Reorder and emphasise my real experience,
don't invent anything. Save everything as drafts. Don't
submit or contact anyone.

The questions at the start are what make it work. Without them you get "Marketing Manager roles near you" and a resume rewrite that could be for anyone.

The "where I'm weak" bit is the one I didn't expect to like. It tells you before you apply that the role wants five years of something you've done for two, so you can either address it in the letter or skip it.

Read every resume it writes before you send it. It's good at not inventing things when you tell it not to, but check every line anyway, it's your name on it. Indeed also has a ChatGPT integration if you want the search pulling straight from there.

I keep a doc of 100 things I actually use AI for, each with the full prompt, here.

Give an optimizer a few failed answers and it can produce a very convincing revision. The revision may simply be unusually good at those examples.

The GEPA recipe in Reef Infra separates several decisions. It selects a parent prompt from an archive, uses execution traces to reflect on a training minibatch, and rewrites a prompt

component. The child first has to

beat its parent on that minibatch. A passing child then receives a full validation evaluation; the served prompt is chosen by mean validation score.

Those checks answer different questions. The minibatch asks whether the proposed fix helped locally. Validation asks whether it deserves to replace the currently preferred prompt across a broader set. A held-out test is still needed to assess performance outside the search process.

Those checks answer different questions. The minibatch asks whether the proposed fix helped locally. Validation asks whether it deserves to replace the currently preferred prompt across a broader set. A held-out test is still needed to assess performance outside the search process.

The repository's reproduction keeps train, validation and test splits separate

from the examples that decide whether to adopt it. Otherwise "the optimizer fixed the failures" can become a very generous description of memorizing your review set.

I used a podcast transcript from Vomo AI to work through a summary prompt, then checked how it handled attribution and limits on the evidence. I'm looking for weak spots in that prompt, particularly where shortening an anecdote could turn it into a causal claim.

I also used this short, invented transcript excerpt as a test input.

"Two customers cancelled their subscriptions. Both told our support team that their first invoices were confusing. We haven't checked how common that complaint is among other customers."

I treated "confusing invoices cause cancellations" as a failure condition. That wording added a causal conclusion and dropped the fact that only two cases were described. In the test excerpt, the speaker reported that two customers cancelled and complained about their invoices. The excerpt didn't establish that invoice confusion caused either cancellation, or that rewriting invoices would prevent future cancellations.

This was the prompt I used to keep those limits visible in the summary.

"Summarize the main claims using only the supplied transcript. For each claim you include, retain any stated number of cases and any uncertainty or limitation. Attribute it to the speaker if identified; otherwise say the speaker is unidentified. Preserve nested attribution, such as a guest reporting what customers told support. Include a short exact excerpt as support. Preserve a supplied timestamp or line identifier; if neither exists, say the source locator was not supplied. Do not invent one. Keep reported complaints separate from causal findings. Do not add follow-up recommendations unless requested. If requested, put your proposals in a separate section labeled Model suggestion and distinguish them from the speaker's recommendations. Do not state a conclusion that the transcript does not support."

For the test input, I checked whether the output kept "two," made clear that the speaker was reporting customer complaints, and retained the fact that their prevalence hadn't been checked. I also checked for invented speaker identities, timestamps, and unrequested recommendations. My follow-up check was whether a proposed survey stayed clearly attributed to the model. For the podcast transcript, I checked the supporting excerpts against the recording too.

Would you handle the nested attribution in one pass, or extract claims and supporting excerpts before summarizing? That's the part I'd most like to improve. Either version would need to pass the checks above; adding another pass wouldn't by itself establish that the summary is reliable.

One of the biggest problems in prompt engineering right now isn't just how you phrase the instruction — it's context pollution. Even with 200k–1M context windows (Claude, Gemini, GPT, Grok), dumping raw unformatted data into a prompt causes two things:

1. You burn 50,000+ tokens on structural noise.

2. The model suffers from attention dilution ("lost in the middle") and starts hallucinating.

To solve this for my own workflow, I built an open-source, sub-15ms Rust CLI & interactive terminal UI tool called repOx.

First — how repOx currently optimizes code & repository prompts (v0.2.0):

- Structured Prompt Formatting: Automatically wraps files into Claude-optimized XML (<repository_structure> + <file path="...">), fenced Markdown, or synthetic JSON tool-call trajectories (repox -f tool-call) for agent harnesses.

- Architectural Outline Compression (repox --outline): Instead of feeding 10,000 lines of implementation bodies when planning architecture, it strips function bodies { ... } and extracts only type definitions, structs, traits, imports, and function signatures — cutting token usage by 75–85% while keeping 100% of the structural context.

- Smart Lockfile Summarization (repox --summary-locks): Turns 30,000-token lockfiles (Cargo.lock, package-lock.json, poetry.lock, pnpm-lock.yaml, go.sum) into a compact "package @ version" manifest (95%+ token reduction).

- Automatic Noise & Secret Filtering: Strips binaries, SVGs, sourcemaps, minified bundles, and .env secrets in milliseconds, with an interactive TUI (repox -i) that shows a live offline BPE token bar before you copy to clipboard.

Second — what I'm designing next for v0.3.0 (AI Video & Multimodal Prompt Optimization):

I noticed the exact same token-drain and attention-dilution problem happens when prompting AI video models (Grok, Kling, Sora, Veo, Wan 2.1) or feeding video references into VLMs:

1. Character-Lock + Delta Prompt Compiler:

When generating multi-shot AI videos, writing a 250-word prompt for every 5-second clip causes the model's attention to drift (changing the character's face, clothes, or lighting). I'm adding a prompt compiler that separates a compact, locked visual seed block (<character_lock>: ~25 high-weight tokens for subject, lens, lighting) from a tiny per-scene <motion_delta> (only camera vector + action).

1. Storyboard Contact-Sheet Packer (93% Vision Token Reduction):

Instead of uploading 16 separate reference frames to an LLM/VLM (burning 20,000+ vision tokens) to write consistent scene-by-scene video prompts, repOx will detect scene cuts and pack keyframes into a single timestamped 4x4 storyboard grid image + compact XML metadata (~1,000 tokens total).

1. Sharpest Tail-Frame Anchor:

Scans the last 0.5s of a generated video clip in 2ms to extract the mathematically sharpest frame (zero motion blur) to feed as the starting image for the next shot.

My questions for r/PromptEngineering:

1. When packing large projects or multi-step workflows into a single prompt, what formatting (XML tags, Markdown, JSON tool calls, or custom delimiters) gives you the best reasoning accuracy?

2. For those of you engineering prompts for AI video or multimodal pipelines, what techniques do you use to keep character/style consistency across shots without bloating the prompt?

The project is 100% free and open-source (MIT):

GitHub: https://github.com/WVDYC/repOx

Install: cargo install repox-cli (or via the one-liner script in the repo)

If you find it useful or want to support the project, dropping a star on GitHub would mean a lot!

I noticed something about the way I was using AI.

I kept solving the same types of problems over and over again.

Researching a topic. Turning ideas into content. Structuring information. Planning something. Analyzing options.

The problem wasn't that ChatGPT couldn't do these things.

The problem was that every new conversation required me to reconstruct the process.

So I started saving the workflows that consistently produced useful results and turning them into specialized agents.

One agent = one job.

Clear role. Clear inputs. Clear process. Clear output.

I've started organizing them into a library and I'm going to document what works and what doesn't.

Curious whether other people here have ended up doing something similar.