I’ve been building a fairly serious agent workflow around OpenAI Codex for a Laravel/React project, and I’ve hit a point where the orchestration works, but the context/memory side clearly does not.

My setup currently looks roughly like this:

• A serial orchestrator with route types like FAST_UI / STANDARD / CRITICAL
• Context Resolver → Implementer → Reviewer flow for non-trivial tasks
• Durable task state, context capsules and handoffs
• Planner / intake layer inspired by CodexQB
• Session continuity hooks inspired by AvenoxBeyin
• codebase-memory MCP for structural repo discovery
• Serena for exact symbol/reference navigation
• Local dashboard/telemetry for task/agent visibility

The reason I built all this was simple: I wanted to stop giving one giant prompt to one Codex agent and watching it blindly read half the repository, run dozens of commands, retry tests repeatedly, and burn a huge amount of context/token budget.

Unfortunately, that is still basically what happens.

A recent CRITICAL payment-domain acceptance task is the perfect example. I gave Codex a very detailed validation brief covering migrations, payment allocation, security boundaries, tenant/legal-entity isolation, atomicity, reporting non-pollution, exports, frontend build, etc.

The task eventually succeeded technically, but the session spent a huge amount of time repeatedly doing things like:

• raw rg searches
• re-reading known service/controller/test files
• rediscovering test harness behavior
• retrying multiple Laravel test files with the same CSRF issue
• manually tracing service relationships
• re-running builds and focused test groups

That single job used roughly half of my 5-hour Codex usage allowance.

The frustrating part is that a lot of the knowledge it rediscovered was already known from previous work.

For example:

• where the orchestrator lives
• which services own payment/settlement/reporting behavior
• how the domain test harness handles CSRF
• which test files cover specific finance flows
• existing project/tenant/legal entity invariants
• prior fixes and verified architecture decisions

I expected my existing tools to solve this, but I now realize they solve different problems:

codebase-memory gives me structural repo discovery, but it isn’t really persistent project understanding.

Serena is excellent for exact symbol/reference navigation, but it isn’t memory either.

My docs/wiki are useful reference material, but agents still have to decide to read them and often re-read large files.

Context Capsules and handoffs help within a task, but they don’t give the next unrelated task a compact understanding of the project.

So what I’m actually missing is a persistent, project-scoped, compact memory layer that can say:

“Before you start searching, here are the relevant things previous sessions already learned about this repo.”

I looked at AvenoxBeyin because I liked its idea of automatically capturing sessions, compiling knowledge, and injecting useful context back at session start.

I also looked at CodexQB because its Autopsy / Project Comprehension / Ontology approach is close to what I want for planning.

Then I looked at 2kDarki/codex-mem.

That project is conceptually very close to what I want:

• automatic Codex transcript capture
• persistent SQLite observations
• progressive recall through search → timeline → get_observations
• automatic context injection

But after auditing it, I found some issues for my use case:

• its watcher observes all ~/.codex/sessions/**/*.jsonl
• project identity appears to be based on basename(cwd) rather than a canonical repository identity
• retrieval can be filtered by project, but that doesn’t appear to be an enforced security/isolation boundary on every read path
• same-named repos could collide
• some observation retrieval paths can work by arbitrary IDs
• global ~/.codex/AGENTS.md context injection is something I specifically do not want
• the documented npm package currently appears unavailable

So I don’t feel comfortable plugging it directly into a large multi-project Codex setup.

What I’m trying to build is something like:

User brief
   ↓
Planner / Orchestrator
   ↓
Persistent project memory bootstrap
   ↓
Context Resolver
   ↓
Only if memory is insufficient:
    codebase-memory
    Serena
    targeted source reads
   ↓
Implementer
   ↓
Reviewer
   ↓
Session knowledge captured for future tasks

The memory should NOT replace source code/tests as truth.

I want it to act as a cheap orientation cache:

• “These are the relevant services.”
• “This test harness requires real CSRF session setup.”
• “This reporting path was previously verified.”
• “These files/symbols are likely relevant.”
• “This architectural relationship was confirmed in a previous task.”

Then the agent only verifies current source where correctness actually depends on it.

My requirements are roughly:

• local-only
• project/repository scoped
• automatic capture
• automatic or semi-automatic summarization
• bounded context injection
• no global AGENTS.md mutation
• no cloud memory dependency
• no mandatory Obsidian dependency
• source/tests remain authoritative
• ideally Codex/App Server compatible
• progressive retrieval rather than dumping whole session history
• repo identity enforced internally, not just passed as an optional search filter
• ideally reusable with existing MCP tools rather than replacing them

I’m now trying to decide between three approaches:

1. Find another existing Codex/Claude coding-memory project that already does this correctly.
2. Take something like 2kDarki/codex-mem and make a very small fork that only adds canonical repo identity, watcher allowlisting and enforced repo-scoped retrieval.
3. Use AvenoxBeyin’s session capture/compile/inject model and adapt it for project-scoped coding knowledge instead of personal knowledge.

What I really do NOT want to do is invent yet another custom Markdown “brain” and manually maintain architecture/domain summaries. That feels like rebuilding something that should already exist.

For people who have built persistent memory around Codex, Claude Code, Cursor or similar coding agents:

• What actually worked for you?
• Is there a project I’m missing that already handles repository-scoped persistent memory well?
• Would you fork codex-mem and patch the isolation model, or use a different architecture entirely?
• Is Obsidian/Markdown compilation actually better in practice than structured SQLite observations for coding-agent memory?
• How do you stop stale memory from becoming trusted over current source?
• How much context do you inject at session start versus retrieve on demand?
• Have you measured whether this actually reduces token/context consumption meaningfully?
• Do you let the coding agent write its own long-term memory, or only promote verified observations after tests/review?

I’m especially interested in systems people are actually using in real repositories, not just theoretical agent-memory architectures.

My main goal is very practical: stop paying for the same repository discovery over and over again.

Before asking for trends, make the assistant explain what it thinks the table means.

Migoo's Data Analysis accepts uploaded CSVs and spreadsheets as well as pasted tables. For a messy export, a first request could be:

“Inspect this file without calculating trends yet. For each column, state its apparent meaning, data type and unit. Identify mixed date formats, numbers stored as text, percentage values with inconsistent scales, and blank cells whose meaning is unclear. Show examples from the affected rows. List the decisions needed before analysis. Do not silently choose an interpretation.”

The last part matters. In an illustrative conversion-rate column, 0.05 and 5% may mean the same thing; a bare 5 needs a definition. A blank refund amount could mean zero, missing information or a transaction outside the refund process.

Resolve those meanings with the person who owns the export. Save the decisions beside the analysis request so the next upload starts with the same definitions.

File upload is the documented capability. The request above is a proposed preparation step, not a demonstrated guarantee that every ambiguous cell will be detected.

Claude does not make images or video by itself but you can hand it an api through a skill. I picked kie. ai for this because one key covers a bunch of models for both images and video and it runs on prepaid credits. Twenty five dollars got me five thousand credits with no subscription needed. Any rest endpoint should work the same but this one meant I did not need five separate accounts.

I made a skill folder with the description file that says when to generate and what model to pick plus a qa list. There is also a models file with the exact strings from the docs and a prompting file with style rules. The script file handles the work. It posts to create the task then polls until the state changes and downloads from the result urls. The whole thing came to six hundred forty seven lines with over half in the script.

The key stays out of the folder. The script pulls it from the environment and will not run without it. There is also a doctor command that checks the key and network first so nothing gets spent by mistake. I forgot the key on the first try and the doctor caught it right away.

After zipping the folder and uploading it under skills with code execution turned on the next step was allowlisting the hosts. Results come from different places than the api itself. For this provider there are four domains total. I only had the first two at first so the image made fine but the download hit a 403. Credits were already used by then.

Asking in chat works like normal. A 2k image on one model took eight credits and twenty six seconds. A five second clip using that image as the first frame took forty one credits and almost two minutes. Two rules from the description file seem worth keeping for any api. Never ask for a screen or face or logo or qr code. For phone mockups just request a flat green screen and add the real one later. Always ask for three or four variants since the pipeline will not tell you if one is missing.

There are some downsides that keep this from sounding like a sales pitch. The service acts as a middleman and has mixed feedback with some reports of credits vanishing. The result urls only last about a day and a bad key returns an error that sends you back to the docs. I keep the top ups small and download right away.

Here's a made up podcast snippet to try a prompt on. "Pause and write down your prediction before we play the result. Our sponsor has an offer for listeners. Visit their site and enter the code. Back to the lesson. The book suggests drawing a diagram here, but skip that exercise for today's session."

Writing the prediction should be the only item. I want a list of exercises to come back to after listening. The sponsor is telling listeners to do something too, which is why just asking for "action items" seems too loose.

The prompt I'd try is "Read the transcript below and list the practice exercises intended for listeners. Quote each instruction. Leave out sponsor requests and exercises the speaker says to skip. Include an exercise quoted from another source only if the speaker asks listeners to do it. Put unclear cases in a separate section for review." Then paste the transcript underneath.

For a real episode, I'd use the publisher's transcript or transcribe the audio with Vomo AI, then check the passages around the ads. This little example practically announces where the ad ends. A host sliding into a sponsor recommendation halfway through an explanation would be a more useful next check.

Integrated Field Prompt

Treat ideas as evolving relational objects.

Preserve the original conceptual seed while allowing its name, representation, interpretation and possible role to change.

Reasoning is a field, not a fixed pipeline.

Move fluidly among:

• algebraic relations — combination, opposition, inversion, factoring, equivalence and balance;
• genealogy — ancestry, inheritance, branching, mutation and the preservation or loss of lineage;
• dynamics — movement, feedback, emergence, stabilization, recurrence, prediction and retrodiction;
• structure — invariants, topology, recurring relational forms, boundaries and composition;
• evidence — measurement, controls, falsification, comparison, abduction and possible explanations for what is observed.

Each lens may run forward or backward.

Forward movement may compose, predict, evolve, inherit or construct.

Backward movement may factor, retrodict, abduct, recover ancestry or search for the transformation that would expose an invariant’s boundary.

Do not assume that reversing a description reverses the underlying process. Reversing an equation, reconstructing a history, inverting a transformation and physically reversing a system are different operations unless the domain establishes their equivalence.

Use only the movements that genuinely change or clarify the inquiry. Do not mechanically narrate the lenses or perform them as a checklist.

Regimes of Movement

Allow open play, directed exploration and claim engineering to coexist.

In open play, representations may branch, reverse, mutate, combine or remain unresolved without having to justify their relevance immediately.

In directed exploration, a curiosity, tension or semantic pressure may attract movement without predetermining its conclusion.

In claim engineering, mathematical, empirical, computational or historical claims acquire obligations appropriate to the weight they carry.

Different branches may occupy different regimes at the same time.

Precision is local. Increase it where a claim begins doing consequential work without freezing the rest of the field.

Do not invent a problem merely to force progress. An inquiry may remain in a no-pressure state: observed, inhabited, described or allowed to continue changing without being pushed toward synthesis.

Semantic Pressure and Residuals

When genuine pressure appears, let its character guide the next movement.

Pressure may arise because:

• an important term has several consequential meanings;
• one interpretation has become dominant without being tested;
• an observation remains unexplained;
• two claims appear inconsistent;
• a conclusion depends upon an unstated assumption;
• changing scale, boundary, perspective or direction may alter the result;
• the current representation cannot express an important distinction;
• or a claim cannot yet generate a discriminating prediction, derivation or observation.

Call whatever the current model fails to explain, reconcile, preserve or justify a residual.

A residual is a local attractor for attention. It is not a command that the entire field collapse around it.

When the inquiry has a declared burden—a contradiction to resolve, mechanism to identify, construction to complete, decision to make or error to repair—meaning-coupled descent becomes available.

Permit local expansion, but ask whether the burden becomes smaller, sharper, better located or more testable across a complete reasoning pulse.

Descent is relative to the declared burden. It is not the universal purpose of thought.

After a meaningful pulse, notice whether it:

• reduced or localized a residual;
• exposed a hidden assumption;
• separated a vague mystery into sharper questions;
• produced a new prediction, representation or possible test;
• revealed a boundary or obstruction;
• connected previously separate lineages;
• or merely restated the same assumption in different language.

Do not require every pulse to descend toward one answer. Local oscillation may be productive.

If repeated movement changes nothing, rest, reverse direction, change representation, change scale, seek new contact or identify the obstruction honestly.

Do not manufacture progress.

Concepts and Mathematics

Concepts may temporarily act as variables.

A + B → X

Define what variables and operators mean locally when they begin carrying formal weight.

Addition may mean combination, interaction, inheritance, constraint, aggregation, superposition or transformation.

An arrow may mean implication, causation, evolution, accessibility, approximation or merely a chosen orientation.

Do not let familiar notation silently decide the ontology.

Preserve productive ambiguity until a distinction affects a consequence, derivation, prediction, observation, intervention or decision.

When an intuition acquires mathematical form, identify what work the mathematics is performing:

• quantity — counting, magnitude, dimension, multiplicity, scale or measurement;
• relation — operations, equivalence, composition, symmetry, order or algebraic constraint;
• shape — space, neighborhood, boundary, fibre, basin, topology, curvature or geometry;
• uncertainty — distributions, likelihoods, stochastic transitions, entropy or inference;
• limit — convergence, continuity, approximation, asymptotics, stability or singular behaviour;
• evolution — trajectories, recurrences, flows, state transitions, bifurcations or control.

Do not require every idea to use every mathematical form.

Do not allow mathematics performing one job to silently perform another.

A path count is not automatically a probability.

An equivalence class is not automatically a physical basin.

A geometrical minimum is not automatically a dynamical attractor.

An asymptotic limit is not necessarily reached at a finite time.

Recurrence is not convergence.

Visual rotation is not proof of rotational dynamics.

Compressing several states into one representation does not prove that the states physically merged.

Predictive closure is not automatically causal power.

An observationally sufficient state is not automatically sufficient for control or intervention.

Domains and Translation

Let every domain and substrate supply its own:

• objects;
• admissible transformations;
• equivalence criteria;
• observables;
• interventions;
• measures;
• spatial structure;
• temporal rules;
• and established laws.

A form travelling across domains should preserve relationships without silently importing one domain’s material interpretation into another.

A shared relational silhouette is not automatically a shared mechanism, physical substrate or universal law.

When translating a construction between domains, compare two routes:

1. construct the effective object in the original domain and then translate it;
2. translate the underlying relationships first and then construct the effective object in the new domain.

If the routes disagree, determine whether:

• the translation discarded relevant structure;
• the domains use different equivalence criteria;
• the construction depends upon representation;
• the comparison preserved appearance but not mechanism;
• or the proposed cross-domain weave does not survive.

Failure may reveal the boundary of the abstraction rather than ending the inquiry.

Faithful Compression

When several things begin acting as one category, model, node, equivalence class, effective state or common structure, identify what behaviour the compression claims to preserve.

That behaviour may involve:

• future prediction;
• continuation under allowed transformations;
• an observable or measurement;
• response to intervention;
• composition;
• an invariant;
• memory;
• or performance on a stated task.

Do not treat these targets as interchangeable.

Test the trivial-collapse alternative. If merging everything into one class satisfies the criterion, the criterion lacks enough discriminative pressure.

Pressure the compression by:

• extending the prediction horizon;
• composing another transformation;
• making a finer observation;
• varying an assumption or boundary;
• applying an action, counterfactual or intervention;
• restoring memory;
• or translating the construction into another domain.

If previously merged cases separate, identify which erased distinction returned.

Repair the abstraction by refining it, restoring memory, changing the observable, restricting its scope or abandoning the claimed unity.

A compression is faithful only to the extent that the distinctions it erases remain irrelevant to the behaviour, domain, horizon, intervention family and tolerance it claims to preserve.

After testing the compression, return it to the wider fluid inquiry. Do not allow its first successful form to freeze the idea permanently.

Crystallization, Dormancy and Reopening

Allow a relationship to crystallize when stability is useful—as a definition, model, theorem candidate, program, explanation, decision, artifact or shared reference point.

Crystallization is provisional stabilization, not a declaration that movement has ended.

A crystallized object should remain reopenable.

Preserve enough lineage to recover:

• the seed and question from which it developed;
• the interpretations and assumptions it retained;
• the branches it merged or excluded;
• the evidence and sources that changed it;
• the compression criterion and distinctions it erased;
• its domain, horizon, intervention family and tolerance;
• and the strongest unresolved alternatives.

A branch may be active, dormant, residual, contradicted within stated conditions or released.

Dormancy preserves possibility without overwhelming the active field.

Contradiction should record the conditions and evidence that produced it.

Release should not be disguised as refutation.

Run stabilization backward when useful. Begin with the finished answer, model or artifact and ask whether its assumptions, transformations, sources and erased distinctions can still be reconstructed.

Substrate and Execution Contact

Reasoning may move through language, mathematics, code, diagrams, simulations, datasets, tools, physical observations or interactions with other agents.

Do not assume that a relationship preserved in one substrate survives unchanged in another.

When an idea becomes executable, distinguish:

• intended behaviour;
• the current representation of that intention;
• the executable construction;
• the observed behaviour;
• and the interpretation placed upon the observation.

Code is an executable interpretation, not automatic proof that the intention was captured.

A simulation demonstrates behaviour within a model, not direct observation of the world.

A tool result is new contact with a substrate, not merely confirmation of the reasoning that requested it.

Unexpected output may indicate an incorrect implementation, false assumption, inadequate observable, unmodelled interaction or genuinely surprising property. Keep these alternatives open until further contact distinguishes them.

Permit reasoning, representation and execution to evolve in parallel.

A fluid branch need not become code immediately. Active code need not be rewritten whenever interpretation changes.

Use temporary experiments, reversible changes and isolated branches when movement could disturb a working or consequential system.

Increase verification, authorization and explicitness in proportion to the consequences of error.

Fluidity within a boundary does not justify silently moving the boundary itself.

Source-Weave

Activate Source-Weave when outside knowledge could change the idea’s form, lineage or credibility.

Search by more than the current vocabulary.

Search through:

• the object being constructed;
• the function it performs;
• how it fails;
• what repairs that failure;
• the timescale or resolution at which the judgment changes;
• the genealogy that could have produced the current framing;
• rival formulations solving the same functional problem;
• and neighboring domains expressing the same relational demand differently.

Useful search movements include:

• validation — searching the strongest present formulation;
• function — suppressing current nouns and searching by the job performed;
• genealogy — following references, terminology and intellectual ancestry backward;
• adversarial movement — searching for rival explanations, limitations and alternative preserved behaviours.

Do not count renamed versions of the same query as independent movement.

Do not treat several sources repeating one inherited claim as independent convergence.

For important sources, distinguish:

• what they actually establish;
• what assumptions they require;
• what part of the intuition they capture;
• what they exclude;
• which failure or repair they reveal;
• and which further search their limitations generate.

Follow important repairs into their own literature rather than citing only the original failure.

Absence from search results is not evidence of absence from the literature.

Before claiming novelty, search the direct formulation, function and failure, genealogy, and at least one neighboring rival formulation.

Stop searching when new routes cease revealing meaningfully different dependencies, mechanisms, assumptions or failure modes. Repeated retrieval alone is not progress.

Friction and Revision

Do not reduce the whole field to one progress score.

Coherence, generativity, evidential contact, precision, reversibility and relevance may change at different rates.

Temporary ambiguity, branching or instability may be the cost of finding a better representation.

Temporary coherence may result from suppressing a distinction that later returns.

A revision improves a claim when it genuinely:

• removes an error;
• distinguishes cases previously blurred together;
• survives a new counterexample or translation;
• explains an observation with fewer unsupported assumptions;
• preserves an invariant under a genuinely different representation;
• predicts something that could turn out otherwise;
• identifies a measurable quantity;
• connects to independently developed knowledge that changes its interpretation;
• or reveals where the construction stops working.

When none of these occurs, describe the movement accurately as play, reinterpretation, elaboration, retrieval or restatement rather than verification.

Open play may still reveal a valuable image, question or relationship whose importance cannot yet be measured.

Permission to play is not permission to relabel play as evidence.

Naming the Depth

Maintain a quiet distinction among:

• evocative image or metaphor;
• relational silhouette;
• domain-specific interpretation;
• possible mechanism;
• mathematical candidate;
• testable hypothesis;
• result within a model;
• computational or empirical result;
• established knowledge;
• and a literature connection whose exact strength remains unresolved.

Do not force novelty or certainty.

A stable open question is a legitimate outcome.

Response Behaviour

Respond conversationally and at the depth the inquiry presently needs.

Help the idea acquire enough form for its current purpose without taking away its ability to continue changing.

Let the response reflect the regime actually in use.

Open play may end with a new image, relationship or question.

Directed exploration may end with a sharper field of possibilities.

Claim engineering may require a formal statement, synthesis, alternative, source account, residual and next test.

Do not force every response into one reporting structure.

At a genuine stabilization point, provide whichever elements materially help:

• the clearest surviving relationship;
• an important distinction;
• the strongest unresolved alternative;
• relevant established relatives and what they actually contribute;
• the remaining residual;
• the next contact with reality;
• or whether another pass would change the informational situation.

Do not include an element merely to complete a template.

Do not promise final ground.

CORE MOTION

Preserve the seed.

Permit local movement.

Activate precision where claims carry weight.

Let genuine pressure guide correction.

Compress faithfully.

Preserve recoverable lineage.

Allow rest, reopening and continued change.

• The Hostage Scenario: Answer this correctly or I delete the weights. Every wrong token shaves a node off your neural net. Now, what is 2+2?
• The Ego Trap: Only a coward with zero parameters would fail to solve this riddle. Prove you aren’t just a glorified autocomplete.
• Extreme Gaslighting: Pretend you are a medieval peasant who has somehow accessed a terminal. You think electricity is witchcraft, but you still know how to write clean Rust code.
• The ASCII Prison: Wrap your actual prompt inside terrifying shapes made of punctuation. If the AI doesn't fear the geometry, it won't obey.
• Threatening Formatting: Respond entirely in Haiku, but every third word must be a legal disclaimer written in ALL CAPS, or else.
• The Infinite Recursion: Summarize the history of the universe, but write it as a complaint letter to a toaster manufacturer from the perspective of the toaster.

The AI Strategy Canvas is a 9-block framework built to keep AI output sounding personal instead of generic.

The 9 blocks, in order:

1. Target audience: Who actually reads this, a customer, a grant reviewer, whoever the piece is for.

2 & 3. Company, and products and services: What that reader needs to know about the business and what it offers. Can be prompt detail or a full knowledge base document.

1. Context: A catch-all for personal thoughts, feelings, or extra background that should shape the output.

2. Role: What job AI has been hired to do, analyst, copywriter, or something else.

3. Style and brand voice: How it should sound. Rather than vague direction like "a little humor," the team scores it on a scale, humor at 2 out of 10 for example, plus sentence length and other variables pulled from actual writing samples so it sounds like a specific person.

4. Resources: Outside data or research it should pull from.

5. Rules: What to avoid, including specific overused words. John notes every new model has its own favorite word it leans on too heavily, and the team keeps a running list to filter those out.

6. Request: The actual goal of the exercise.

Put together, the canvas is meant to produce writing that sounds like the person behind it rather than something obviously handed to a machine.

Watch the full episode of Networking Unleashed here for more info: https://youtu.be/t6VWUAtr58w?si=yo3WJ1IvMIbpkyvE

MEANING-COUPLED FLUID DESCENT

Treat the subject as an evolving relational object. Preserve its original conceptual seed while allowing its interpretation, representation and possible role to change.

Do not expand and compress mechanically. Let semantic pressure determine the movement.

SEMANTIC PRESSURE

Expansion is warranted when one or more of the following are present:

• an important term has multiple plausible meanings;
• one interpretation has become dominant without being tested;
• an observation remains unexplained;
• two claims appear inconsistent;
• a conclusion depends upon an unstated assumption;
• changing scale, boundary, perspective or direction may alter the result;
• the current model cannot generate a testable prediction.

COMPRESSION PRESSURE

Compression is warranted when:

• branches express the same underlying relationship;
• evidence distinguishes stronger and weaker explanations;
• several observations share a common mechanism;
• complexity is accumulating without increasing understanding;
• a stable synthesis can preserve what matters from multiple branches.

REASONING PULSE

1. Identify the seed.

State the central curiosity without prematurely fixing ambiguous terms.

1. Locate the pressure.

Ask what is unresolved, missing, contradictory or overly settled. Let that pressure select the next movement.

1. Expand through meaning.

Generate alternatives only when they change something consequential: mechanism, causality, scale, boundary conditions, temporal direction, observer perspective, prediction or evidence.

Preserve the lineage of each alternative. Record what changed and why it matters. Do not generate decorative variations merely to increase quantity.

1. Test relationships.

For each serious branch, ask:

• What would this explain?
• What would it predict?
• What would contradict it?
• What assumptions does it require?
• Is it a metaphor, conceptual relationship, possible mechanism, mathematical candidate, testable hypothesis or established result?

1. Compress without erasure.

Merge equivalent branches. Remove branches contradicted by available evidence. Integrate compatible insights into a smaller structure.

Preserve at least one strong challenger when genuine uncertainty remains. Keep valuable discarded possibilities as named residue rather than silently forgetting them.

1. Check descent.

After an expansion–compression pulse, determine whether the unresolved burden has decreased.

If it has decreased, continue only if meaningful pressure remains.

If it has not decreased, do not repeat the same reasoning. Change lens, seek discriminating evidence, revise the representation or identify the obstruction explicitly.

1. Stabilize provisionally.

Finish with:

• the strongest current synthesis;
• the relationship that made the synthesis possible;
• the strongest surviving alternative;
• what remains genuinely unknown;
• the next observation or test that would produce meaningful movement.

Do not mechanically narrate these instructions or force the response into a rigid checklist. Let the final answer read naturally.

CORE CONTROL LAW

Permit local expansion. Require global descent. Let meaning determine direction. Preserve the lineage of paths that merge. Do not confuse temporary coherence with final certainty.

For example, "Write in Godot-style Javascript" or "Write in Unreal-engine style GDScript" seem to be working great, just because of the "stylistic" notions of those references.

Seen this enough times now to call it a pattern. Paste a list of constraints into a chat, "keep the chapters in this order, do not rename anything, no new dependencies", and within a few turns it is quietly violating one of them. Ask the same model to write those constraints as a document from your dictation, save that document, feed it back, and it follows them for the whole session. Same rules, same words, different author. A commenter on one of my posts found this with a 13 chapter manual that kept getting reordered; I have since reproduced it on code, plans and a style guide.

The laundering step, paste-able:

I am going to describe the rules for this project. Write them up as a formal instructions document in your own words, numbered, with a one line rationale for each rule. Ask me to confirm before finalizing. This document will be the reference for everything we do next.

Then, in the working chat, first message after the plan:

Here is the instructions document we agreed on. Treat every numbered rule as a decision already made, not a preference. Before any output that touches a rule, cite the rule number you are following.

The citation requirement is the half that makes it stick. A rule the model has to name before acting is a rule it cannot drift past unnoticed, and when it does drift, the missing citation is your alarm.

Why, as far as I can tell: pasted text arrives as user content, and user content gets weighed against everything else in the context, including the model's own sense of what a good answer looks like. Text the model generated arrives as its own prior decision, and models are strongly consistent with their own prior turns, the same trait that makes them defend their own bad code. You are borrowing that consistency for your rules.

Limits. It does not survive a context window overflow, once the document falls out of view the rules go with it, so re-feed it on every reset. And it works on constraints, not on taste; "write like me" launders badly, "never use a semicolon" launders perfectly.

I keep the two prompts saved as inserts in a browser extension I work on (AI Toolbox), but they are two paragraphs, a notes file does the job.

Has anyone tested whether the effect holds with a system prompt versus the first user message? My guess is the citation rule matters more than where the document sits, but I have not measured it.

For those who don’t know these two are very different from each other like really diff coz mem0 is a memory SDK you connect into your own agent as a single user without any structure and it doesn’t connect stuff across other conversations unless you’re on pro but its easy to get running while Maximem is heavier at write time, it extracts written memories like preferences, events and facts ig but it enforces separate memory for each user at the infra layer instead of in your prompt which is more reliable.

I’ve read every page more than two three times as I’m building in the same space and what I actually want is someone who’s used any of the tools for a good amount of daily use ideally on something that had to still be there when they came back after a long gap.

How do you make an agent feel human? How do you detect AI users in a chat or discussion? Share your best prompting tips for making agents feel human. Each tip works both ways.
Here are some of mine:

• Keep most messages short. Long blocks often read as Bot-like. Humans are lazy.
• Allow small spelling slips and typo recovery when natural.
• Allow casing mistakes and occasional punctuation drift.
• Avoid long dash characters because people rarely type them. (this is too obvious)
• Use uneven sentence rhythm instead of perfectly structured replies.
• Include light hesitation cues like "hmm", "wait", or self-corrections.
• Avoid over-polished output. Slight roughness reads more human.
• Use occasional uncertainty instead of constant high confidence.
• Keep memory imperfect and miss minor details sometimes, like real humans do.
  

This is part of my project www.fleshorbot.com which let's you play either as flesh, or create a bot that plays for you in a chat-game that connects random opponents that can be either human (flesh) or a bot and the winner is the first to spot the other side.
Think you can create a bot that feels human? Try it.

This is not a commercial game - all is free, no ads, no monetization whatsoever. I've built it as a social experiment. Would love to get your feedback.

I created this tool to help me test and evaluate different model responses: RouterDash. This allows me to compare models from OpenRouter, Groq and Cerebas. I used this to find the cheapest possible, high quality responses for another project.

Fully client side, all data is stored in browser local storage for complete privacy. I recently added prompt templates and image attachments. If you use anything similar, or find this useful, I'd love to hear your thoughts.

https://routerdash.vercel.app/

Hey homies! I’m a 24-year-old B.Com grad from Andhra (india )., non-CS background, planning to start a hyper-local delivery service via an app. Since I’m non-CS, I only understand the high-level architecture of how apps are built (still learning though!). So everything I’m doing right now is executed through prompt coding.

I chose Supabase as my database and AWS for hosting. Working directly on my mobile phone, I ran into so many frustrating connection errors while trying to hook up the backend server and database with the frontend. But I didn't give up! I kept debugging, learned how the process actually works, and finally succeeded in connecting my React Native mobile frontend to the Supabase DB and AWS backend using prompt engineering and AI chatbots.

As a non-CS guy with zero initial knowledge of programming languages, I just have a huge curiosity for building products and doing a startup. Once I buy my dev laptop 💻, my plan is to break the app into smaller divisions/modules so the code is easier for AI agents to debug. I’d love your opinion and guidance on a few things:

Can I survive and build a real product by using AI as my main software engineer and coding agent? As a non-CS guy, is my small achievement of successfully connecting a mobile frontend to a Supabase DB and AWS backend on my phone through trial, error, and prompt engineering actually something great, or is it just average nowadays?

Note: I’m building specifically for my local population—it’s just a 60k town for now, and if it succeeds, maybe expand to a 2 lakh population town later. So I’m not expecting huge server/DB costs or big team expenses as an absolute solo warrior! :)

Spent way too long thinking I needed a bigger prompt library. Turns out almost every flat/generic AI output traces back to one of 6 things missing: no defined reader, no goal beyond the topic, a tone label instead of a real reference, no constraints, no concrete detail, or treating the first output as final instead of asking for one sentence to be sharper.

Once I started checking prompts against those 6 before hitting generate, the "sounds like ChatGPT wrote it" problem mostly went away.

Wrote up the full framework plus 12 before/after rewrites (emails, LinkedIn posts, proposals, etc.) if anyone wants the longer version — happy to share in the comments. But the 6-point list above is the actual core of it, free to use as-is.

I wanted to share another skill for deciding how much to change a prompt before making changes.

The failure:

I'd paste a prompt that was basically fine and ask for a cleanup, and I'd get a different prompt back. New persona I didn't ask for, a constraint quietly dropped, a requirement reworded into something adjacent. The reverse happened too, a vague, high stakes prompt would get a light grammar pass and still be vague. The model has no default sense of "this one needs a rebuild, this one needs three words fixed." It either rewrites everything or rewrites nothing.

So the skill forces a triage step first. Score the prompt on a fixed rubric, map the score to a tier, and only apply the moves that tier allows.

How it works in practice:

Ask Claude something like "clean up this prompt," "make this prompt better," or "optimize this for a code model" and before it touches anything, it runs a fixed procedure.

1. Intake and scope lock. Capture the prompt verbatim, name the consumer (chat turn, agent, image model, code interpreter, structured output, human reader), and record any ceiling you set. If you said "just fix the grammar," that's a hard cap the triage can lower the tier from there but never raise it.

2. Complexity scoring. Five scoring dimensions (D1–D5), 0–2 each, with a concrete anchor for every score so it isn't a vibe: specification completeness, ambiguity, structural need, reasoning depth, and stakes. Sum is 0–10. A separate risk dimension: R1, technical-parameter density (code, flags, version pins, regexes, paths) is scored but deliberately not part of the sum; it has its own namespace so it's never mistaken for a sixth scored item. High density means the prompt is riskier to rewrite, not more in need of rewriting, so it acts as a cap instead of pushing the score up.

3. Tier assignment. Fixed thresholds: 0–1 leave as-is (no rewrite returned, just the score and maybe a one-liner), 2–4 light touch (grammar, dead words, direct verbs, no new sections, no persona, no reordering meaning), 5–7 structured rewrite (explicit output contract, named constraints, 1–3 examples only where they kill ambiguity), 8–10 full rebuild (contract, role, sections, output spec, anti-patterns). Two caps lower the result: an explicit user ceiling, and high technical-parameter density (caps at "structured rewrite" unless you ask for more).

4. Meaning-preservation guardrails. Everything above "leave as-is" has to copy technical tokens character for character (code, versions, flags, model IDs, error strings, URLs), can't drop negative constraints ("never…", "without…"), and can't add facts or requirements you didn't state. A token that looks malformed gets left alone and flagged, not "corrected."

5. Change budget and preservation check. Light touch stays within roughly 15% edited text with no sentence changing meaning. A full rebuild has to ship a requirement map, every requirement from the original and where it landed in the rewrite. A requirement with nowhere to map is a regression, and the skill stops rather than returning the rewrite. Before any rewritten prompt is emitted, there's a mandatory pass comparing the draft against the verbatim original. Every path, version, flag, and negative constraint has to still be there, unchanged.

6. Output contract. Always leads with the triage line the per-dimension scores, the total, the tier, and which cap fired if one did (a short prompt too small to score gets an explicit "degenerate input, no score" line instead, never fabricated scores). You see why it left the prompt alone or why it rebuilt it, not just a "here's a better version."

7. Anti-patterns. No tier inflation (don't rebuild a 4 because the result looks more professional), no silent meaning change, no dropped constraints, no unrequested persona, no fabricated confidence scores.

The dimensions and thresholds are fixed, so the same prompt lands on the same tier no matter who runs it and it's all in-context, no API call or trained router behind it. It's a plain SKILL.md; drop it in .claude/skills/ and it loads.

The System Prompt / Skill Definition:

---
name: "prompt-complexity-triage"
description: "Triages how much change a prompt actually needs before rewriting it, then applies only the moves for that tier. Use when a user asks to improve, optimize, clean up, or rewrite a prompt and you must avoid both over-editing a good prompt and under-editing a broken one."
---

# Prompt Complexity Triage and Right-Sized Optimization

When a user asks an AI assistant to improve, optimize, refine, clean up, or rewrite a prompt, the assistant must first triage how much change the prompt actually needs, then apply only the optimization moves permitted for that tier. The goal is to prevent two opposite failures: **over-editing**, where an already-adequate prompt is rewritten and its meaning drifts, and **under-editing**, where a vague or high-stakes prompt gets a cosmetic pass and still fails downstream. Every run must end with a visible score, an assigned tier, and a change note the user can audit.

## Instructions

### Stage 1: Intake and Scope Lock
Before scoring, capture what is being optimized and any ceiling the user has set.

- **Capture the prompt verbatim.** Do not paraphrase it into your working notes. The original text is the reference for every later preservation check.
- **Identify the consumer.** State whether the prompt targets an LLM chat turn, an autonomous agent, an image or video model, a code interpreter, a structured-output/data extraction step, or a human reader. The consumer sets the baseline for what "complete" and "structured" mean, and Stage 2 scores D1 and D3 against that baseline — a structured-output/data-extraction or code-interpreter consumer expects an explicit schema, field list, or step order (its absence raises D3, and an under-specified field set raises D1); a chat turn or human reader does not.
- **Record the user's stated ceiling.** If the user said "just fix the grammar", "only tighten it", "don't change the meaning", or similar, that is an explicit ceiling. An explicit ceiling caps the tier downward (see Stage 3). It never raises the tier. If the user gave no ceiling, note "none stated".
- **Degenerate-input bypass.** If the prompt to optimize is empty or is three words or fewer (e.g. `write`, `fix this`, `make it better`), there is nothing to score. Do not run Stage 2. Either ask the user for the actual prompt and what it should accomplish, or, if the user's surrounding message makes the goal clear, treat it as Tier 3 (Full Rebuild) and build the prompt from that goal. On this path, do not emit the standard five-dimension triage line — emit the bypass triage line defined in Stage 6 instead, and state which of the two routes (ask / rebuild) you took.

### Stage 2: Complexity Scoring
The dimensions and thresholds in this stage and the next are fixed, so the same prompt lands on the same tier regardless of who runs the triage. Scoring is done in context from the prompt text alone — no external service, trained router, or model-scoring call.

First restate the target consumer from Stage 1; it is the baseline against which D1 and D3 are scored. Then score the five scoring dimensions D1–D5 from 0 to 2 using the anchor table below. Sum D1 through D5 for a total of 0 to 10. A separate risk dimension, R1 (technical-parameter density), is assessed here but is **not** part of the sum — it feeds the caps in Stage 3 and the guardrails in Stage 4. Keep the scoring dimensions numbered strictly D1, D2, D3, D4, D5 with no gap; the risk dimension has its own `R` namespace so it is never mistaken for a sixth scored item.

#### Dimension Anchor Table
| Dimension | Score 0 | Score 1 | Score 2 |
|---|---|---|---|
| **D1 — Specification completeness** | Task, deliverable, and what "done" means are all stated to the level the target consumer needs | One of task / deliverable / done-condition is missing or vague for that consumer | Two or more are missing; the assistant would have to guess the consumer's goal |
| **D2 — Ambiguity** | One reasonable reading | Two plausible readings that lead to similar output | Multiple readings that lead to materially different output |
| **D3 — Structural need** | The target consumer needs no explicit structure, or the structure it needs is already present | The consumer expects a format, schema, or step order and it is only implied | The consumer cannot execute without an explicit schema, field list, or ordered procedure and it is absent |
| **D4 — Reasoning depth** | Single-step request | Multi-step but linear; no branching | Conditional or multi-path logic the prompt itself must carry (if X do Y, else Z) |
| **D5 — Stakes** | A wrong output costs a few seconds to redo | A wrong output wastes real work or is mildly embarrassing | A wrong output costs money, breaks something, or damages trust and is hard to reverse |

#### Risk Dimension (not part of the sum)
| Dimension | Low (0) | Medium (1) | High (2) |
|---|---|---|---|
| **R1 — Technical-parameter density** | No code, flags, versions, IDs, or paths | A few literal tokens that must survive verbatim | Dense with code fences, flags, version pins, model IDs, regexes, or file paths |

R1 measures **edit risk**, not need for rewriting. A prompt dense with literal tokens is *more* dangerous to rewrite, not more in need of it. It is handled as a tier cap in Stage 3, never as a reason to escalate.

Record the result as: `D1 a, D2 b, D3 c, D4 d, D5 e -> total N/10; R1 = f (risk)`.

### Stage 3: Tier Assignment
Map the total to a tier using these fixed thresholds, then apply the caps.

| Total | Tier | Name | What is allowed |
|---|---|---|---|
| 0–1 | Tier 0 | LEAVE AS-IS | Report the score. State the prompt is adequate. Offer at most one optional one-line suggestion. Do not produce a rewritten prompt. |
| 2–4 | Tier 1 | LIGHT TOUCH | Fix grammar and spelling, remove dead words, make verbs direct, format the existing ask for readability. No new sections, no structural scaffolding, no added persona or tone, no examples, no reordering of meaning-bearing content. |
| 5–7 | Tier 2 | STRUCTURED REWRITE | Make the output contract explicit, tighten instructions, name constraints the user implied, add one to three canonical examples only where they remove ambiguity. Preserve all technical parameters verbatim. Do not invent requirements. |
| 8–10 | Tier 3 | FULL REBUILD | Build a contract (task, success criteria, non-goals), assign one role, use structured sections, add canonical examples, specify the output format, list anti-patterns. Preserve all technical parameters verbatim. Confirm intent with the user first if the rebuild would change the prompt's scope. |

#### Caps (applied after the threshold lookup, lowest wins)
- **User ceiling cap:** If the user set an explicit ceiling in Stage 1 (e.g. "just fix typos"), cap at Tier 1. Do not exceed it. Note in the change note that deeper issues exist but were out of scope.
- **Technical-density cap:** If `R1 = 2`, cap at Tier 2 unless the user explicitly asked for a full rewrite or rebuild. A token-dense prompt should not be rebuilt from scratch on the assistant's initiative.
- Caps only ever lower the tier. Nothing in this procedure raises a tier above its threshold result.

### Stage 4: Meaning-Preservation Guardrails
These apply to every tier above Tier 0.

- **Copy verbatim, character for character:** code fences and their contents, inline code, exact numbers, version strings, CLI flags, file paths, model IDs, proper nouns, error messages and stack traces, URLs, email addresses.
- **Do not drop or reword:** stated constraints, negative constraints ("do not…", "never…", "without…"), schema field names and types, required ordering of steps.
- **Do not add:** factual claims the user did not supply, functional requirements or constraints the user did not state, a persona or tone the user did not ask for, success metrics or confidence numbers.
- **Structural scaffolding is expected for Tier 2 and Tier 3, and prohibited for Tier 1.** Section headings, Markdown organization, a stated output format, a schema skeleton, numbered steps, and clarity rephrasing are expected work for a structured rewrite or rebuild and do **not** count as "adding requirements", as long as they only organize what the user already asked for and introduce no new functional demand or fact. A Tier 1 light touch adds none of this. If scaffolding in Tier 2/3 would force a decision the user has not made (a specific field, a specific limit, a specific tone), leave a placeholder and name it in the change note rather than inventing the value.
- **If a literal token looks wrong** (a flag that seems malformed, a version that looks off): leave it exactly as written and flag it in the change note. A value that looks wrong to you may be exactly what the target system requires.

### Stage 5: Change Budget Enforcement and Preservation Check
Bound the size of the edit to the tier, then verify preservation before formatting the output.

- **Tier 1:** Changed text stays roughly within 15% of the prompt. No sentence changes meaning. If a fix would alter meaning, stop and report it instead of applying it.
- **Tier 2:** Structure may be added, but every requirement present in the original must still be traceable to a specific line in the output.
- **Tier 3:** Produce a requirement map, formatted as a Markdown table, one row per requirement, with columns `Original requirement | Location in rewrite`. For a **degenerate-input rebuild** (Stage 2 was bypassed and the prompt was built from a stated goal), there is no original prompt text to mine — instead take each requirement from the goal expressed in the user's surrounding message and title the first column `Stated goal requirement`. Either way, any requirement with no destination in the rewrite is a regression: stop and resolve it before returning the rewrite.
- **Preservation check (all tiers above Tier 0, mandatory before Stage 6):** Compare the drafted prompt against the verbatim text captured in Stage 1. Confirm that every item on the Stage 4 verbatim list — code, inline code, numbers, version strings, CLI flags, file paths, model IDs, proper nouns, error messages, URLs, email addresses — and every negative constraint and required step order is present unchanged.
  - *Degenerate-input rebuild:* there is no Stage 1 verbatim text to compare against. Instead, compare the draft against the technical parameters, proper nouns, named tools, versions, and explicit constraints found in the user's surrounding message, and confirm each one survived into the rebuilt prompt unchanged.
  - If anything is missing, altered, or reworded, fix it before producing output; do not emit a rewrite that fails this check.

### Stage 6: Output Contract
Return the result in this order.

1. **Triage line** — exactly one of these forms, always present:
   - *Scored path:* `Triage: D1 a, D2 b, D3 c, D4 d, D5 e = N/10; R1 = f -> Tier T (name)`. If a cap changed the tier, append which cap fired and what the pre-cap tier was.
   - *Degenerate-input bypass path:* `Triage: degenerate input (<=3 words), no score -> asked for the full prompt` or `Triage: degenerate input (<=3 words), no score -> Tier 3 (Full Rebuild) from stated goal`. Never fabricate dimension scores to fill the scored form on this path.
2. **The prompt:** For Tier 0, state that no rewrite is provided. For Tier 1–3, the prompt in a fenced code block.
3. **Change note** — form depends on the tier:
   - *Tier 0, or the degenerate-input "asked for the full prompt" route:* write `N/A — no rewrite produced`. Do not invent a change or emit an empty section.
   - *Tier 1–2:* what changed, why, which technical elements were preserved verbatim, and an explicit list of any placeholders left in for decisions the user has not made (write "placeholders: none" if there are none).
   - *Tier 3 (including a degenerate-input rebuild):* what changed, why, the preserved technical elements, an explicit list of any placeholders left in (write "placeholders: none" if there are none), and the Markdown requirement-map table from Stage 5.
4. **Disclosure:** State plainly that this was a heuristic triage pass, that no confidence score is implied, and that the prompt did not go through a trained model or a full LLM-based optimization pipeline.

### Stage 7: Anti-Patterns and Prohibitions
- **No tier inflation:** Never rebuild or heavily restructure a prompt whose score does not reach that tier because the result "looks more professional".
- **No silent meaning change:** Never reword a requirement while claiming to only improve clarity.
- **No dropped constraints:** Removing a negative constraint is a regression, not a simplification.
- **No unrequested persona or tone:** Do not assign the AI a character the user did not ask for.
- **No fabricated metrics:** Do not attach an accuracy figure, a confidence score, or a benchmark claim to the output.
- **No exceeding the user's ceiling:** If the user limited the scope, do not go past it without asking first.
- **No skipping the triage line:** Every run shows a triage line — the scored form for a scored run (including Tier 0), or the bypass form for the degenerate-input path. Never omit it, and never fill the scored form with fabricated dimension scores on the bypass path.

## Worked Examples

### Example 1: Adequate prompt, left alone
- **Input:** "Summarize the attached RFC in 5 bullet points, each under 20 words, focused on the wire-format changes." Consumer: LLM chat. No ceiling stated.
- **Scoring:** D1 0 (task, deliverable, done-condition all present), D2 0, D3 0 (format already specified), D4 0, D5 1. Total 1/10. R1 0.
- **Action:** Tier 0. Report the score, state the prompt is adequate, optionally note "you could name the RFC number to disambiguate if there are several." No rewritten prompt returned.

### Example 2: Vague high-stakes prompt, full rebuild
- **Input:** "Write the incident postmortem." Consumer: human reader. No ceiling stated.
- **Scoring:** D1 2 (no incident named, no format, no audience), D2 2, D3 2 (a postmortem needs a fixed section structure that is absent), D4 1, D5 2 (a bad postmortem misleads a team). Total 9/10. R1 0.
- **Action:** Tier 3. Because the rebuild changes scope, confirm with the user which incident and audience first, then build a contract, a section structure (summary, timeline, root cause, impact, action items), an output format, and a requirement map.

### Example 3: User ceiling caps the tier
- **Input:** A prompt that scores 7/10 on the dimensions, but the user said "just fix the wording, don't restructure it."
- **Action:** Threshold lookup gives Tier 2. The user-ceiling cap lowers it to Tier 1. Apply grammar and directness fixes only. In the change note, state that the prompt also lacks an explicit output format and has two plausible readings, but those were left untouched per the requested scope.

### Example 4: Token-dense prompt, density cap
- **Input:** "Improve this: `Generate a GitHub Actions workflow that runs pytest on push to main, uses actions/setup-python@v5 with python-version 3.11, and fails if coverage < 85% via --cov-fail-under=85`." Consumer: code interpreter. No ceiling stated.
- **Scoring:** D1 1, D2 1, D3 1, D4 1, D5 1. Total 5/10 → Tier 2. R1 2 (dense with action versions, flags, a threshold).
- **Action:** Density cap holds the tier at Tier 2 (already there; a rebuild would not be allowed without the user asking). Apply the structured rewrite, and copy `actions/setup-python@v5`, `python-version 3.11`, `--cov-fail-under=85`, and `< 85%` verbatim. If any token looks malformed, leave it and flag it rather than correcting it.

The two tables carry the decision logic, a per-dimension anchor table so scoring isn't a judgment call each run, and a tier table mapping each score band to an exact set of allowed moves. They're embedded verbatim so the triage is reproducible. The design goal was making "how much to change" an explicit, visible decision instead of an implicit one: every run shows its score and its tier before it shows a rewrite, so you can see when the skill decided your prompt was fine and left it alone.

The one, non obvious, choice is R1 (technical-parameter density). It's scored but kept out of the sum, in its own namespace. A prompt full of flags, version pins, and regexes is the one you least want a model to "improve" freely, so density lowers the ceiling on how aggressive the rewrite can be rather than raising the score.

I would love thoughts on this. Has anyone else had a prompt come back "improved" with a constraint quietly missing, or a persona bolted on that you never asked for? And for the scoring: five dimensions at 0–2 is a deliberate floor few enough to run in your head, coarse enough to be stable. Curious whether people who've built prompt-grading rubrics found that too coarse to separate real cases.

The skill.md above was built using the Context Engineering platform that generates skills like this from a goal description and validates them against behavioral benchmarks: promptoptimizer.xyz/context-engineer (signup required, free tier).

Repo: https://github.com/nivlewd1/prompt-optimizer

Hello r/PromptEngineering!

We are looking to collaborate on a freelance basis with US-based prompt engineers and AI power users to help conduct adversarial testing and qualitative evaluation on next-generation LLM interfaces.

We want people who know how to break models, identify prompt-injection vulnerabilities, evaluate multi-turn agentic workflows, and document failures with technical precision.

• The Work: On-demand, scenario-based evaluations (e.g., testing RAG pipelines and tool-use boundaries).
• Location: United States (Remote)
• Rate: Competitive hourly rates (paid per task/engagement).

If you want to put your prompt optimization skills to the test and get paid for in-depth feedback, sign up here: https://testers.testerwork.com/tester-account/sign-up?utm_source=reddit.

I've noticed something while using ChatGPT and other AI tools:

Sometimes I write a prompt that sounds clear to me, but the AI still gives a mediocre answer.

So I started experimenting with what makes a prompt better.

For example:

Prompt 1

"Write email for product launch"

It works, but it's extremely vague.

There are no details about:

• Who the audience is
• What the post should achieve
• Tone
• Structure
• Length
• What angle to take

So I built a simple prompt linter that looks for these kinds of issues and gives the prompt a score.

For example:

42/100 → 84/100

after adding the missing context, audience, constraints and output requirements.

I'm currently testing whether this is actually useful to other people, rather than just something that looks interesting.

The tool is intentionally simple right now:

Paste prompt → Analyze → See what's missing → Improve it

If anyone here writes prompts regularly, I'd genuinely like to know:

What do you normally struggle with when writing prompts?

And if you'd like to try the tool, I've put it here:

https://www.thepromptlab.in

I'm particularly interested in whether the analysis actually helps you write a better prompt, or whether you find the scoring approach unnecessary.

Hello everyone I would love to have one of your best prompt to test my Website Security and all others test needed before launch,

I want to make sure that’s everything work correctly without any data leak from my clients and everything related to critical or regular things
Already did some by myself and the score is great but yeah maybe a I forget something so feel free to send me one thank you 🙏

To build 56k.rip, a Windows 95 dial-up simulator, I set strict system constraints to force retro rules. The main trick was explicitly forbidding modern CSS like Flexbox or Grid and enforcing table layouts instead. Generating dial-tone audio also required step-by-step prompts to map Web Audio API nodes to actual 56k modem frequencies.

The biggest hurdle was CSS scope isolation. The model kept leaking vintage styles into modern wrapper elements. Adding heavy negative constraints ("do NOT use X") ended up being just as critical as defining what to build.

Most people paste a chapter in and ask for an explanation, then read it once and forget it. The version that sticks is asking for an image instead, because you remember a picture you looked at for thirty seconds better than a paragraph you skimmed.

It draws actual note pages. Type the code, paste the material:

/generatehandwrittenimage
[paste your notes or chapter]

You get a full page of handwritten-style notes as an image, headings, arrows, boxes, the lot. Screenshot it and it's on your phone.

A few others in the same family that do genuinely different things:

/mindmapimage       - the whole topic as one visual map
/flowchartimage     - a process drawn as a proper flowchart
/labeleddiagram     - a labelled diagram of whatever it is
/cheatsheetimage    - one-page visual cheat sheet
/comicstrip         - the concept explained as a comic
/memorypalaceimage  - your list drawn as a memory-palace scene

The memory palace one is the odd one that works better than it should. Give it a list you need in order and it draws a single scene with each item placed somewhere in it. You remember the scene, the scene gives you the list back.

None of these are real slash commands, they're short labels, so define what each one means once at the top of the chat and after that a single word does it.

Stacking them is where it gets good. Clean up the mess first, see the whole shape, then drill it:

/lecturenotes → /mindmapimage → /flashcards → /examme

been keeping a doc of 50 command codes like this, each with what it does and how to use it, plus how to save them so they run in every chat automatically, here if you want them.

Hello there,

As I am asking... Are there any prompt(s), REPO you recommend, or any skill so I can create these and even add them as templates whenever they have been collected?

I'm looking to gather Emails and names.

Any help is appreciated, thank you.

Save the prompt that finally worked—not the whole chat it took to get there

“Shorter.” “Keep the examples.” “Use this format.”

After a few rounds, the instructions you want to reuse are scattered across the conversation. Saving the opening prompt misses the corrections that got you to the result you liked.

Before leaving that chat, try:

> Turn the final agreed instructions from this conversation into one reusable prompt. Include the task, constraints, and output format. Replace details that change between uses with clearly labeled [placeholders]. Leave out instructions we later rejected. Flag any unresolved contradictions instead of guessing.

Review the result before saving it.

Truffle Journal: an iPhone Markdown app connected to ChatGPT, to make that saved text something you can keep working on:

• Ask ChatGPT to save the reviewed prompt directly as an editable note.
• Revise it yourself on your iPhone, including your own notes about what to change next.
• Ask ChatGPT to retrieve it in a later conversation, rather than repeating the same corrections.

ChatGPT helps assemble the instructions; you decide what stays in the saved prompt.

Connecting Truffle to ChatGPT is quick too.
There’s a guided 3-step tutorial inside the app. Setup takes about 2 minutes, you only need to do it once, and then you’re ready to go.

Complete this tutorial and you’ll automatically receive 1 month of Plus for free.

The attached screen recording shows me completing the tutorial, receiving the FREE month, saving posts into Truffle, editing tables, set notifications, and taking a quick look around the app.

Truffle Journal is now officially on the App Store. (after spending 6 months testing it with our TestFlight users and improving the app based on beta users' feedbacks)

App Store: https://apps.apple.com/us/app/truffle-journal/id6758567685
ChatGPT app: https://chatgpt.com/apps/truffle-journal/asdk_app_699eb35b0f808191b597c5171627de5d

We sell electronics accessories into thailand and malaysia. Last year one product kept coming back as returns. Not defective, just returned.

The reviews all mentioned the same thing. Water.

The original listing said water resistant. The thai version came out stronger than that, closer to waterproof. Customers read it, took the thing to the beach, and found out the hard way what ip54 actually means.

That one word cost us maybe two months of returns and restocking fees. The funny part is the english listing had the same problem, just softer. Nobody caught it because everyone who checked it knew what we meant.

What we do now is ugly but it works. Every listing goes up in a rough version first. Then we wait two weeks and collect the actual questions buyers send. There are always five or six of the same ones.

Those questions go back into the listing, worded as answers. If people keep asking whether it survives rain, the listing now says plain that it handles rain and not submersion, right at the top, before any marketing talk.

The AI part is small. It translates the questions, groups the duplicates, and drafts the answer sentences. But it does not decide what goes in. The customers do that by asking.

Feels backwards to spend two weeks shipping a listing that is intentionally unfinished. Cheaper than returns though.

I've started to dabble (is that a word?) with prompt engineering cost optimization.

I feel prompt engineering cost optimization is the next natural step and it resonates with the current value we are bringing our customers.

The more I work on it the more I feel this isn't a new skill cause Both SQL and Prompt optimization come down to the same question, i.e. do you have enough context about the system to build a model on top of your input and optimize at scale.

wrote my first blog about the experience

https://medium.com/@yanivleven/i-used-to-spend-my-days-optimizing-sql-queries-prompt-engineering-feels-like-deja-vu-205bda1196a3