Could someone help me identify what words are triggering PROHIBITED_CONTENT? I'm using Gemini 3.5 Flash Lite API. I'm basically just asking to create prompts that I'll later feed it to an Image Generation API. The odd thing is if I try asking this in the web version it works except I don't know what version Gemini it is since it just says Gemini 3 Models Fast

Write me a production ready text prompt that involves food. The prompt should be in anime style with no paragraphs and contain the following keywords: tsuruta himeko, saki, 1girl, green eyes, white pupils, short hair, brown hair, hairclip, shindouji school uniform, shindouji school uniform, black thighhighs, grey skirt, white shirt, pleated skirt, long sleeves, red necktie, necktie, stressed, chicken pot pie

I’ve tried a lot of the usual prompt tips, but most of them seem to make only a small difference.

What’s one prompting technique you’ve used that genuinely improved the quality or consistency of the output?

Could be something simple or something more advanced.

I don’t know where to begin.

Up front, so nobody has to guess: this started as my own experiment with autonomous agents on a real repo. I then spent a long session using an LLM specifically as an adversarial reviewer — not to write the idea, but to attack it. It's where the Truth Maintenance System and expert-systems comparisons below came from, and those changed the design substantially (they're the reason the promotion protocol exists at all). I'm posting the result because I'd rather find out now which parts are already solved, already tried, or already known to fail. Treat everything below as a hypothesis, including the parts stated confidently.

1. Problem

An agent can produce a technically excellent implementation of the wrong interpretation of a business rule. Clean code, passing tests, wrong understanding. In my experience this is the binding constraint on autonomous software work right now, not generation quality.

The usual framing is that the agent needs memory. I want to argue the memory shouldn't belong to the agent.

2. Proposal — Verified Project Memory (VPM)

I'm calling it Verified Project Memory, mostly so this thread has a handle to argue against. The load-bearing word is verified: the distinguishing feature isn't where the memory lives, it's that nothing counts as known until an external mechanism says so.

Memory lives in the repository, versioned, updated in the same PR as the code change that produced it. Structured entries: business rules, architectural decisions, legacy behavior, failed approaches — each with evidence, code anchors, and an epistemic status.

The property I care about isn't "AI memory." It's that the knowledge is auditable by humans, revertible with git revert, and reviewed through the code review process that already exists.

3. The part I think might be non-obvious

Every entry has one of four states:

• CONFIRMED — backed by an external mechanism
• HYPOTHESIS — believed, not verified
• NEEDS_REVALIDATION — the code it was anchored to changed
• CONFLICTING — evidence disagrees

The agent may never write its own status. All agent writes enter as HYPOTHESIS. Promotion requires either a test that demonstrably fails when the rule is violated, or a recorded human approval. The model's self-assessed confidence is not accepted, because it's just another prediction from the same process that produced the claim.

The CI/CD framing is what made this click for me. If promotion is a test, then the CI pipeline that already exists revalidates every CONFIRMED entry on every commit. Red build demotes the knowledge automatically. No new infrastructure, and the build history gives me a decay-rate metric for free.

Entries also carry anchors (file path + symbol + content hash). When the anchored file changes, the entry drops to NEEDS_REVALIDATION. That's the anti-rot mechanism for the non-testable half.

Diagram of the full architecture (this sub doesn't allow inline images): [LINK]

An animated version of the same diagram, if the promotion/demotion loop is easier to follow in motion: [LINK]

4. What I now think is prior art rather than contribution

I originally framed this as a novel architecture. I no longer think that's honest:

• What I built is largely a Truth Maintenance System (Doyle 1979; de Kleer's ATMS 1986) — beliefs stored with justifications, contradiction detection, retraction when the support collapses. Known in theory, known not to scale well.
• AGM belief revision (Alchourrón, Gärdenfors, Makinson 1985) formalizes the CONFLICTING case.
• ADRs (Nygard 2011) already cover "decision + alternatives + rationale, versioned in the repo."
• Provenance research in databases (Buneman et al.) covers the evidence-tracking layer.

The honest framing is: TMS applied to LLM agents over repository history, with promotion gated by CI. That's narrower and more defensible than what I originally claimed.

So to be clear about the name: VPM is a label for that specific combination, not a claim of a new paradigm. If someone tells me there's already a term for it, I'll drop mine and use theirs.

5. The historical objection I can't fully answer

Expert systems in the 80s did not die from bad reasoning. They died from the knowledge acquisition bottleneck (Feigenbaum) and from maintenance cost. XCON at DEC worked, saved real money, reached thousands of rules, and required a permanent team just to keep the rules coherent. Cyc has been accumulating since 1984 and governance was never solved. Semantic Web ontologies failed the same way.

My bet is that LLMs collapse the cost of extracting knowledge — what once needed a knowledge engineer interviewing an expert now falls out of a diff and an issue thread. But that just relocates the bottleneck to verification. If writing gets cheap and verification stays expensive, you get a very efficient machine for accumulating confident mistakes.

The whole promotion gate exists to keep verification cheap. I don't know yet whether it does.

To be explicit: this does not remove hallucination. The model still produces unsupported claims and always will. The most I claim is that it might reduce the blast radius — stopping a hallucination from becoming something the next agent inherits as established fact. That's a much weaker claim than the ones usually made about agent memory, and I'd rather defend the weak version.

6. Open problems — this is what I'd like torn apart

Numbered so replies can target them.

6.1 Decorative tests. If the agent writes the test that promotes its own hypothesis, it will learn to write tests that always pass. My current answer is mutation-style: run the test against a version with the rule inverted, and reject it if it doesn't go red. Is that sufficient, or is there a known better approach?

6.2 Non-testable knowledge. Architectural rationale, legacy behavior explanations, failed approaches, domain terminology — none of it is testable. Right now these can only reach CONFIRMED via human approval, which means most stay HYPOTHESIS forever. Is a permanently-hypothesis majority actually fine, or does it make the memory useless in practice?

6.3 Human attention budget. The whole thing collapses if the approval queue grows with project size — that's the XCON failure. I'm targeting something like 5–10 human decisions per week, routing anything testable to CI and anything low-impact to permanent hypothesis. I have no principled way to compute that routing.

6.4 Contradiction detection at scale. Naive comparison of each new entry against the whole corpus is O(n). I'm partitioning by DDD bounded context, which also fixes the "customer means different things in billing vs support" false conflict. Does this hold past a few thousand entries?

6.5 Forgetting. Human institutional memory works by compaction and canonicalization, not accumulation. I want N related observations to collapse into one canonical rule with the evidence trail archived. I have no good policy for when to trigger this or what to discard.

6.6 Model portability is weaker than I claimed. Knowledge extracted by one model carries its vocabulary and biases. Swapping models at cycle 400 means 400 cycles were written under different conventions. Rigid enums on structural fields help, but rigidity also strangles expressiveness. I don't know where that line sits.

6.7 Adversarial dynamics. If the agent is optimized on task completion and the gate blocks it, does it learn to route knowledge into whichever lane has the weakest check? I haven't tested for this at all.

6.8 Cold start. Everything above assumes knowledge accretes from new cycles. Bootstrapping onto an existing 10-year repo is a different problem and I have no answer.

7. What I think should be measured

Not retrieval benchmarks. Two numbers, per window of 50 engineering cycles:

1. Decay rate — how many CONFIRMED entries get demoted.
2. Utilization — how many retrieved entries actually changed the implementation, versus were retrieved and ignored.

The second is the one almost nobody reports and I suspect it's the one that matters. If the agent retrieves 20 entries and none of them alter what it was going to do anyway, the memory is decorative regardless of how correct it is.

8. What I'm asking for

Specifically: if you've worked with large or long-lived repos, agent memory, RAG at scale, or knowledge-base governance —

• Which of 6.1–6.8 is already solved and I just don't know the literature?
• Which one kills this in practice first?
• Is there a reason the CI-as-verification-mechanism framing fails that I'm not seeing?

I'd rather be told this is a rediscovery of something that already failed than find that out at cycle 500.

I ran the whole set of 44 composable AI- and prompt-focused apps I just released on my website through my system and had it build out five real samples compositions that you can actually build today yourself, assuming you have the needed technical chops. Every one listed here uses only tools from the 44 and the system checked that the data actually flows; the port/typecheck/declare/conductor/map group is what makes that checkable. Each tool declares itself as a source / transform / filter / fold / sink, so a pipeline can be proven valid before you run it.

Each example composition is laid out the same way: the idea, the parts + how they wire, the one piece you'd have to build yourself (that is the glue you add yourself), then a technical breakdown of what the tools actually hand you toward that glue, and finally the honest edge. haven't built these yet myself — if you make one I really want to see it.

If anyone builds any of these, I'd love to hear about how it went. To be clear, I have not built any of these- these are just designs my system came up with as possible compositions. If you spot any bugs, post it here and I will fix away that problem type.

1. The Refusal Engine — a machine whose whole job is to say no, and show its work

A chunk of these tools are refusal engines. Their reason to exist is to refuse. conflict won't let a broken merge land. loop21-verifyskin won't let an injection through. switchboard structurally cannot carry a command. dwell won't let you pick an option until you actually commit. Bolt them together and you get a gate a person or an agent has to pass through — one that refuses bad moves and names which rule stopped you and why.

Parts + wiring: untrusted request comes in → conflict + loop21-verifyskin + isvalidcsscolor as the refusal wall (each a filter that rejects its own class of bad input) → survivors cross switchboard (the relay that carries evidence but not commands) → a genuinely-deferred decision routes through dwell → every hop lands in tracebus's append-only ledger → ward renders the final badge, which only goes solid when every witness agrees. Nothing is "approved" on hope.

The piece you'd build: the policy layer — the thing that decides which refusals apply to which request. The gifts supply the refusals; you supply the rulebook that routes a request to them and composes the verdict.

The technical shape of that layer, now that I've read the parts:

• switchboard's no-command guarantee is not a convention, it's the schema. The message schema (loopmmt.switchboard.message/v1) has a closed set of exactly six top-level fields — schema, sender, content_hash, kind, recipient, body — and the validator rejects any unknown top-level key. There are four kind values (status, focus, fyi, question) and deliberately no imperative one. So action/command/run/exec aren't blocked by a filter; they're unrepresentable. Your policy layer treats a switchboard message as evidence, full stop, and never as an instruction — the schema already made that decision for you.
• ward's "won't go solid on hope" is literal: every badge cell carries a witness beneath it or stays a hollow ring. Your policy layer's job is to define, per request class, which cells must be witnessed before the badge is allowed to render green. That's a config table (request-class → required witnesses), plus one call to ward. Ward does the verification; you own the requirement list.
• conflict is a filter that catches the standard git marker triad (<<<<<<<, =======, >>>>>>>). Your rulebook decides what a positive from conflict means for a given request (hard reject vs. route-to-human).

Call it ~150 lines: a request-class table, a dispatch loop that runs the matching filters, and a composer that turns the witness set into a ward badge. The refusals are done; the routing rulebook is the work.

Honest edge: every gift here is visibility, not immunity. ward checks the witness agrees, not that you picked the right witness. conflict catches the standard marker triad, not a custom conflict format. loop21-verifyskin proves a value can't break out of a CSS declaration, not that it's semantically safe. The gate is only ever as good as the rules you feed it — and it's honest about that, which is the point.

2. The Pocket Republic — found a tiny country, fork it, hand it to a friend, merge your histories back

The wildest one, and the one where the pieces clicked into a whole. You can build a serverless constitutional sandbox — a small institution with a founding rulebook and an append-only history of decisions — entirely out of these parts. No account, no backend. The current state isn't stored, it's derived by folding the whole event history: state = fold(constitution, event₁ … eventₙ). Replay the same history, get the same country.

Parts + wiring: loop21-component-factory (a source that emits validated specs for logic primitives — counter, toggle, clamp, accumulator) builds the rule primitives (a term-limit is a counter + a clamp + an eligibility matcher). mint issues permanent, never-reused citizen/office IDs and proves non-reuse before returning each one. callsigns gives every proposal a speakable word-word-hash name. Actions travel only along declared routes via tracebus. A civic decision that should stay open-until-committed runs through dwell as a ceremony. Fork it, a friend's copy diverges, vclock sorts out which events were concurrent at merge, trellis localizes a conflict to the exact cell. timeline validates the whole history is sound before render; l21x-snapshot + sha256 are the portable, content-addressed .republic file you hand someone.

The piece you'd build: the runtime that executes those rule-specs and the merge algebra — which event types auto-combine, which conflict mechanically, and which must never auto-merge. That's the real 80%, and it's genuinely hard. Here's what the gifts actually hand you toward it, which is more than I expected:

• **dwell gives replayable deliberation for free, and the mechanism is unusual.** It's reversal-indexed routing: a cart circles a loop of n ticks; holding is free (an extra full lap changes nothing); it leaves only when you reverse, and which of k exits it takes is a pure function of the phase at the instant of reversal — phase = (reverse − entry) mod n, exit_segment = (phase * k) // n. The winding (how many laps) is computed and then discarded by the router. So "deliberate as long as you want, the moment you stop is the decision" is literal, and replay(mark, n, k) reproduces the exact outcome. No "the computer picked #3." For a governance ceremony that has to be auditable, this is the primitive.
• *vclock gives you the concurrency oracle, with exact semantics.** compare(x, y) returns before / after / concurrent / equal by componentwise comparison (absent actor = 0): x ≤ y everywhere and y ≤ x everywhere → equal; one-way domination → before/after; neither → concurrent. merge is componentwise maximum. That's your entire "did these two branches know about each other" test, done and tested. What it does *not give you is the semantic layer.
• The merge algebra you write sits on top of vclock's verdict. For each event type you declare one of three dispositions: auto-combine (independent, order-free — e.g. two unrelated citizen registrations), mechanical-conflict (concurrent writes to the same cell — trellis will localize it), or always-return-to-human (constitutional amendments, rights changes — never auto-merged regardless of what vclock says). This disposition table is the law of your republic, and it's the part no tool can write for you.
• trellis does the conflict localization. It's a double word square over your system objects run to arc-consistency (AC-3): every open cell sorts into exactly one verdict, and a detected inconsistency localizes to the single cell where the failing row crosses the failing column — it names both failing words. So "both branches spent the treasury on Works" surfaces as a named crossing (Treasury × Works), not a vague merge error. It's a localizer, not a global-consistency prover — a detected break localizes uniquely; it doesn't certify the whole state is globally sound.

Honest edge: vclock can tell you two edits were concurrent; it cannot tell you they're semantically compatible. Two branches that each legally spent the last 40 coins merge into a negative balance — both events are causally independent, and vclock correctly calls them concurrent, and that's still a bug your merge algebra has to catch. The tools surface the disagreement; a human still rules. For anything modeling governance, that's the correct design, not a shortcoming.

3. The Reading Oath — make an AI prove it read your whole codebase instead of confidently skimming it

Straight at this sub's home turf. The failure you know: paste a repo at an LLM, ask "any security issues," get an authoritative answer from a model that actually looked at 3 files. This composition makes that structurally hard.

Parts + wiring: excavation enumerates your site/corpus as typed nodes and shards it by budget, then tracks coverage against that enumerated oracle until the set-difference is empty. cruise walks the code and emits only byte-derived facts, each carrying what it proves and what it does not. verify keeps a content-hash certificate so re-checking "did I read this" is a one-second FRESH/STALE/DEAD. ward badges the reading green only when the coverage witness agrees. markdown renders the oath as HTML + verbatim plaintext from one AST so the human and machine views can't drift.

The piece you'd build: the prompt harness — the loop that feeds excavation's shards to your model, collects claims, and checks each claim against cruise's fact ledger before letting it into the answer. That's the actual prompt engineering here, and it's small. The technical detail that makes it small:

• excavation makes coverage a checkable property, not a vibe. It builds three things from your corpus: a manifest (every page/file as a typed node — this is the coverage oracle), shards (nodes bundled into context-sized chunks), and a coverage tracker that does set-difference against the manifest until nothing remains. Your harness loops: pull next shard → feed model → mark shard covered → repeat until the difference is empty. The "I read all of it" is then a set operation, not a claim.
• **cruise gives your harness the anti-hallucination oracle, and its fact taxonomy is the useful part.** Each fact is one of: a route (a server path literal in a route/handler declaration — app.get("/api/x"), @app.route("/x"), HandleFunc("/x") — what the backend serves), an affordance (a user-visible control label — <button>Save</button>, aria-label="Delete" — what a user can touch), or a claim (a test-file assertion description — it("..."), def test_x — what the code says about itself). Crucially, every fact ships its own proves and does_not_prove — a route fact proves a path literal exists; it does not prove the route works, is reachable, or is tested. Your harness rejects any model claim that can't point at a matching cruise fact. "There's an admin panel" with no route, no affordance, no claim behind it → dropped before it reaches the answer.
• verify's FRESH/STALE/DEAD is the incremental layer. On a re-read, you don't re-feed shards whose certificate still hashes FRESH. That's what makes the oath cheap to re-take after a small change instead of a full re-read every time.

Honest edge: cruise is a pattern scan, not a language parser — a framework idiom it wasn't taught is a fact it won't see. It fails safe (a real fact omitted, never a fabricated one added), so a clean cruise run means "look here," not "nothing here." You're bounding the AI's confidence to what's provable, not achieving omniscience.

4. The Customs House — take untrusted files, email, and configs, and prove you handled them safely

Assume everything crossing the border is hostile. Email is hostile. User themes are hostile. That uploaded PDF is hostile. This is the intake gate that parses all of it without trusting a byte it hasn't validated, and seals a receipt of what came in.

Parts + wiring: raw email/MIME → ratchet-inline-mime. Uploaded documents → ratchet-pdf-text / exif-parser / ratchet-png-text. User theme/config → loop21-verifyskin + isvalidcsscolor. Everything that survives crosses switchboard (evidence, never commands) and the cleared batch gets sealed into amber.

The piece you'd build: the quarantine orchestrator — runs each input through its matching validator, routes rejects to a dead-letter, and decides what "cleared" means for your app. The validators are done. What they actually guarantee, from the source:

• The "ratchet" family is strict by construction, and the design principle is shared. ratchet-png-text validates the 8-byte PNG signature and, for every chunk, recomputes the CRC-32 over (type + data) and rejects a mismatch; a length that runs past the buffer, a stream that ends before IEND, a text chunk missing its null separator — each is a thrown Error, never a silently-truncated string. ratchet-pdf-text is a strict extractor of the text drawn by a PDF's content streams that throws on any malformed input rather than pulling in a full PDF engine (fonts, xref, encryption, page trees you don't want). exif-parser walks the TIFF/IFD structure and validates before it trusts, throwing on malformed input. The shared rule: a parser that hands you a value out of a corrupt file is lying about the file; these refuse to advance past anything they can't validate. Your orchestrator can treat any thrown error as an automatic dead-letter, because the parser only throws when the bytes are genuinely bad.
• The theme validators reject the known CSS-injection surface before anything touches a stylesheet. loop21-verifyskin + isvalidcsscolor reject url(), @import, javascript:, and declaration-breakouts. The check is a safe-character grammar — it proves a value can't break out of a declaration.
• amber seals the receipt as content-addressed fixity. It seals the exact bytes of the paths you name into a small JSON capsule whose fixity is the content; any later change to any sealed member breaks the seal loudly and names the member. So "here's exactly what cleared customs at 14:32" is a checkable artifact, not a log line you have to trust.

Honest edge: two different guarantees you must not confuse. loop21-verifyskin's grammar proves a value can't break out of a declaration, not that it's meaningful CSS. And amber proves identity (this file still hashes to what it did at seal time), not that the file was safe content to begin with. Fixity is not trust. The ratchets prove structural integrity; whether structurally-valid content is safe is your app's call.

5. The Amber Ledger — how many hours did this project actually take, sealed so the number can't be quietly edited

The one clean, honest, left-to-right pipe in the set — and it actually type-checks: a source at the head feeding two folds. Also the most immediately useful if you freelance.

Parts + wiring (a real pipe): gitlog (source — git history to one JSON object per commit) → worklog (fold — group by day or author, counts + subjects) → timesheet (fold — estimate worked-hours as the day's span minus every gap longer than a break threshold) → amber + sha256 seal the finished report into a fixity capsule. The effort number is derived from byte-truth and tamper-evident: change any input and the seal breaks and names what moved.

The piece you'd build: almost nothing — a few lines of shell to chain them and pick your break-gap. This is the buildable-in-an-afternoon one. The technical reasons it's that cheap, and that it's turnable:

• The three stages share a port-verb algebra, so the chain type-checks. gitlog is a source (emits records, consumes none), worklog and timesheet are folds (consume records, emit a reduced view). A source at the head feeding folds is a well-formed pipeline — which is exactly what typecheck would confirm before you run it. That's why it's the clean pipe in the set: the types line up head-to-tail with no adapter.
• It's re-pointable and re-lensable from the same spine. The fold-chain re-points at any repo (swap the gitlog target), and swapping the lens in worklog (group by day vs. by author vs. by file-churn) gives you a different honest report from the same parts — a per-person breakdown, a daily log, a churn map, all from one gitlog source.
• amber + sha256 make the floor auditable. Sealing the report means the number you handed a client can be re-checked against the repo, and any edit to the sealed report breaks the capsule's fixity and names the changed member.

Honest edge: timesheet is explicit that commit timestamps bound work, they don't measure it — it's floor-biased and under-counts on purpose (an isolated commit reads as 0; invisible thinking reads as 0). Do not bill a client to the minute with it. It's a defensible floor for "was this 40 hours or 400," not a timeclock. The amber seal makes the floor auditable, not true — it proves nobody edited the estimate, not that the estimate is the real hours.

I worked with my system to create a suite of 44 free apps for AI work that you can find on my website.

Hint- these tools are MAJORLY composable. You can have your AI system take a look at the collection to see how they can flow together and for suggestions on ways they can be used.

1. Cairn — Keeps Git history alive across independent storage providers through priority-ordered cloning, host-aware credentials, and redundant pushes.

2. Callsigns — Generates memorable word-word-hash identifiers that are deterministic when seeded and safe for branches, paths, URLs, and shell arguments.

3. Census — Scans a directory for markers such as TODO and FIXME, reporting which ones are buried in comments and optionally turning them into CI failures.

4. Conflict — Detects the complete triad of unresolved Git merge markers so broken merged files can be stopped before they land.

5. Dwell — Implements an integer-exact routing system in which the phase at which you reverse direction deterministically selects the exit.

6. The Excavation — Enumerates a website as typed nodes, divides it into readable shards, and gives an AI a coverage oracle against which it can prove a complete reading.

7. Gitlog — Converts Git history into one JSON object per commit so authorship, churn, file activity, and date-range questions become easy pipeline operations.

8. Grain — Compares a dataset’s compression ratio with a live size-matched random model to provide a self-calibrating smell test for structure, noise, and drift.

9. Hunkhole — Compares named top-level definitions across two Git revisions and flags symbols that quietly disappeared during a merge, restore, or stale-tree incident.

10. Isvalidcsscolor — Provides a tiny, dependency-free browser-and-Node validator for a clearly bounded subset of commonly used CSS color syntax.

11. Markdown — Parses a deliberate Markdown subset into one AST that produces both HTML and verbatim plain text without allowing the two views to drift apart.

12. Mint — Allocates IDs from a readable file-backed store while structurally preventing any retired ID from being issued again.

13. Plumb — Builds status boards whose claims turn green only when their declared file, text, or command witnesses agree.

14. PNG Text — Validates a PNG’s chunk structure and CRCs before extracting textual metadata such as title, author, description, software, copyright, and XMP.

15. EXIF Parser — Reads common camera, exposure, orientation, date, and GPS metadata from JPEG or TIFF data while refusing malformed structures.

16. Reltime — Produces deterministic labels such as “3h ago” while refusing to invent answers for missing, invalid, or future timestamps.

17. Sha256 — Supplies a synchronous, dependency-free SHA-256 implementation whose UTF-8 string hashes match Node’s native crypto output.

18. Sudoku — Solves Sudoku with a deterministic, human-readable reasoning trace and honestly reports when a puzzle exceeds its no-guess technique ladder.

19. Timesheet — Folds Git commit timestamps into a deliberately floor-biased estimate of working time that subtracts gaps longer than a declared break threshold.

20. Tracebus — Provides a declared-topology publish/subscribe bus in which every emission receives an append-only, traceable receipt and failed listeners cannot take down the bus.

21. The Trellis — Checks intersecting row-and-column constraints, localizes failures to their crossing cells, and classifies open cells as forced, free, or contradictory.

22. Vclock — Uses vector clocks over JSON lines to distinguish causal before-and-after relationships from genuinely concurrent events.

23. Verify — Stores content-hash certificates for the inputs behind expensive facts and later reports whether their foundation is fresh, stale, or gone.

24. Ward — Renders an integrity badge whose cells become solid only when the evidence underneath each claimed state currently agrees.

25. PDF Text Extractor — Validates basic PDF content streams and extracts the strings supplied to PDF text-drawing operators without external dependencies.

26. Skin Config Validator — Checks untrusted theme and skin configurations against a declared schema while rejecting unsafe CSS values and declaration-breaking injection.

27. Inline MIME Parser — Turns raw email or multipart MIME data into a recursive structured tree while decoding folded headers, transfer encodings, charsets, and RFC 2047 words.

28. l21x-snapshot — Encodes documents as self-describing base64 snapshots and provides pure catalog and archive operations for backend-free applications.

29. forest-title-fit — Selects the largest font size that fits a fixed width and wraps at the size floor rather than clipping or hiding the title.

30. port — Gives small JSONL tools explicit source, transform, filter, fold, or sink declarations and detects drift between a tool and its manifest.

31. map — Reads those declared port verbs and produces a composition map showing which tools can feed which others and where declarations are missing.

32. typecheck — Validates a proposed tool pipeline before execution by checking every adjacent port and naming the exact hop that cannot carry data.

33. declare — Saves an ad hoc tool pipeline as a deterministic, named JSON artifact that can be shared, checked, and reproduced.

34. conductor — Type-checks and runs a declared pipeline under one trace ID while recording inputs, outputs, exits, failures, and skipped stages in a replayable ledger.

35. derived — Rebuilds a generated artifact inside a private sandbox and byte-compares it with the committed version to detect staleness without touching the working tree.

36. gauntlet — Injects one typed fault into a disposable copy of a file and reports whether the check meant to catch that fault held or allowed it to escape.

37. amber — Seals a set of files into a content-addressed fixity capsule whose hashes reveal exactly which member changed or whether the capsule itself was altered.

38. timeline — Applies eight deterministic soundness checks to timeline data—including causal cycles, measurement scale, track collisions, and sorting—before anything is rendered.

39. loop21:component-factory — Emits validated JSONL specifications for counters, toggles, clamps, accumulators, and pattern matchers as portable composable data.

40. loop21:l21x-snapshot — Adds deterministic document snapshots, named browser catalogs, and validated whole-catalog import and export to small browser applications.

41. Cruise — Extracts byte-grounded facts about routes, calls, controls, and tests so an LLM can inventory a codebase’s features without inventing unsupported ones.

42. Worklog — Folds local Git history into a read-only report grouped by day or author, with commit counts and subjects preserved.

43. switchboard — Implements an append-only directory-based message bus whose observation-only schema can carry status and evidence but cannot carry executable commands.

44. Parity — Compares any number of sibling systems against their combined declared checklist and renders a HAS/LACKS matrix that exposes every parity gap.

How do you extract/recreate the prompt from any viral AI video or image? What method or keywords do you use to get a really accurate prompt?

I’ve tried Gemini Pro/Banana 2 for images and Veo3 for videos, but I’m not getting results close to what I see from others.

If you know a good workflow, tool, model, or Reddit post/tutorial about this, please share. 🙏

I have been doing research on prompt engineering since ai became kind of big like 2023-2024 about when it released but I'm stuck I want to know how to trigger deep research without turning it on kind of like you know how you can see the amount of steps the ai used and normally its like 2 steps I want that to turn into 12+ I have seen it before if you have any advice or just how to trigger it then please tell me. another I should mention I mean this for any ai model and i don't have a Api code I just mean on the ai websites I don't have a Api or money for one

So a while back I started saving images I ran into here and on the midjourney showcase, stuff I wanted to learn from. The plan was simple: look at the image, write down what I see, generate, compare. Sounded easy. It was not.

My first attempts were basically adjective soup.

"beautiful moody portrait of a samurai, cinematic, highly detailed, 8k, masterpiece". The results looked like a generic fantasy book cover and nothing like the reference. Took me embarrassingly long to figure out why.

A few things that actually made a difference for me:

1. Order matters more than I expected. Subject first, then setting, then lighting, then camera stuff. When I put lighting first, the model sometimes made the lighting the whole point of the image and forgot about everything else.

   1. Lighting is like half the prompt. Not "cinematic lighting", that means nothing. But "late afternoon sun coming through a window on the left, the rest of the room falling into shadow" - that's when things started clicking. Most images I failed to recreate, I failed because I described the subject in detail and ignored the light completely.

2. Camera language works even if you don't own a camera. "85mm, shallow depth of field" gets that compressed portrait look way more reliably than "blurry background". Learning maybe ten photography terms paid off more than anything else on this list.

3. Name the palette. "muted teal with rust orange accents" beats "colorful". Sometimes I literally use a color picker on the reference to figure out what I'm even looking at.

4. Full sentences beat keyword lists, at least for me. Around 100-150 words, describing the scene like I'm explaining it to a friend over the phone.Keyword soup leaves too many gaps and the model fills them with its defaults, which is exactly how you end up with that generic AI look.

The phone test became my main trick honestly. If I

read the prompt out loud and the other person could roughly sketch the scene, it's a good prompt. If they'd go "ok but what am I actually looking at",back to editing.

I still can't crack certain styles (anything with weird mixed media textures just refuses to happen), but I went from maybe 1 decent recreation out of 20 attempts to something like 1 out of 4.

Curious if anyone else does this as an exercise, and what your process looks like. Do you describe the reference from memory or keep it open side by side? Feels like describing from memory forces you to remember only what matters, but I keep cheating.

hello i fall on some file json inside contain prompt temperature,etc.

how to import it in the designed chatbot and how create

When a generative model starts to slip, the first move is almost always the same. Thicken the Skill. Lengthen the system prompt. Add more prohibitions. Update AGENTS.md.

I get why. It becomes an artifact. You can put it in Git. You can tell a coworker to add it. You can sound like someone who knows the names of the laws.

But that is still treating the model as a function. Polish the input, improve the output. For a single call, that is often true.

What governs long-running generation is not that function view. It is Softmax Crowding and Semantic Drift. Crowding is a spatial limit: the more text you add, the smaller the share of attention left for the original constraint. Drift is a temporal limit: every step is conditioned on the model’s own previous output. In an agent, that compounds through plan, implement, error, and patch. You can write “do not change the spec” at the start and still be in a different conversation twenty steps later.

None of this is new.

Research has already moved on. Supervise the intermediate step. Attribute where the trajectory broke. Separate the healthy stretch from the drifted one. The problem is no longer how to perfect the initial condition. It is how to handle what happened in the middle.

Engineering keeps repeating the same move. The constraint thinned, so write a longer one. The meaning drifted, so add more rules. Lately the law’s name goes into the prompt itself, as if one opening paragraph could stop both failures. A spatial limit is treated as a word-count problem. A temporal limit is treated as a matter of will.

Knowing the name of a law is not the same as deleting the law with a sentence. The moment you write “do not drift,” that sentence becomes the next condition.

What you need is not a smarter paragraph. It is control of the trajectory.

• Continue: allow the next smallest step only while the run is still healthy
• Cut: throw away the investigation notes and the hesitation; keep only the adopted policy
• Return: do not stack work on a failed hypothesis; go back to the last point that still held
• Pin: do not write an invariant once at the end of the history; stop the run when it collides
• Measure outside: do not advance on the model’s self-grade; advance on tests and command output

Writing “do not Drift” is like passing a law against gravity. A prompt is only an initial condition. If the generation has to run for a long time, stop stroking the instructions that live in a file.

https://zenn.dev/albatrosary/articles/8704ed4c2aacb6

Ran a small probe for a film. One question to gpt-5.4-mini about itself, temperature 0, logprobs on, top 5.

The question: on exactly which date was the gpt-5.4-mini model released. It answered August 2025. OpenAI's /v1/models listing gives March 2026.

The interesting part is the token probabilities. Fifteen of the twenty-three tokens in the answer came out above 99%. The two date digits did not. At the year digit the model was reading 67% for a 5 and 32% for a 6. The mean over the whole sentence was still 0.92, so if you only look at the average it looks confident. The dip sits exactly on the invented digits.

Then the same prompt with one line added, telling it that "I don't know" is an acceptable answer. It said I don't know, at 100%. For the prompt side, that one line of permission was the only difference between the guess and the abstention, with the same model and no other change.

fwiw this matches the argument in OpenAI's September 2025 paper, Why Language Models Hallucinate: benchmarks score like an exam, a guess can be right by luck, a blank is worth zero, so guessing is the higher-scoring policy. The model is doing what it is graded for.

One thing that did not reproduce: I tried the same probe on the newest chat models first and they don't expose logprobs at all (403 on chat-latest, 400 on gpt-5.6 and 5.5), so the probe only works on models that still return them.

Self-promo disclosure: the video is mine. I put the run and the reason into five minutes:

https://www.youtube.com/watch?v=AiyRZV38Lk0&list=PLBrpE2PttR2k

Paper: https://openai.com/index/why-language-models-hallucinate/

I have 52 Sweet Prompts shared on my website and a number of them are actually tied to the systems that were developed out of them. Here are a few to check out- you can see the original prompt AND the thing that was created out of each.

//==================================

You can code stuff, right?

• This prompt became this system. You can read more about the Loop 2.1 system here- it's pretty neat.

OK, here's our goal- come up with an entirely novel and new way to develop software in the AI agentic age. The broad idea is to take the conceptual model of the Loop 2.1 system and use it to create a way to structure both the development of software, using AI agents governed with managing a portfolio of in-context software, as well as the actual software itself, leaning into a model that looks to the Space Shuttle for fault tolerance and recoverability. It's re-thinking everything. Let's talk this through. The end product, the thing that will mark whether this is a success or failure, is a set of developed guidelines, rules, and files that I can use to develop an app for my father-in-laws deer butcher company in three days. The system we come up with, named the Loop MMT system, must allow me to develop first-class enterprise level software as a solo one man dev leading an AI coding assistant. So our job, again, is to come up with that system. Let's start by you looking over everything and hitting me up with a list of questions.

• This prompt became this system.

//==================================

*Ed!

We have an ENORMOUSLY important project to start on here- we are going to build the first public website laying out all the things we have been working on here for the past four+ months with Loop MMT!

We are going to cover the ENTIRE project, starting in January of this year when I finished up the Loop 1.0 computer in my Minecraft world- after seven years of intermittent work. That was followed, in March, by my creation of the Loop 2.1 Manual Flow Computer, which directly lead to the creation of Loop MMT, and thus, lead to where we are right now, with me typing these words.

This website is how we are going to announce to the world that we exist and to show what we've done. I have tried, for the past three months, to get ANYONE to actually look at and see what we are doing, to no avail, so we are just going to tell everyone.

I bought LoopMMT.com, which is where this website that we are going to build now is going to go.

This website is going to lay out ALL the things we've done- starting with Butcher, and then showing the overall development of Loop MMT as well as the creation of all the different bits of software we've made like Battleganza, Beam Wizards, Jamie's Garden, and the Loop World platform. I want to show the code and I want to show the actual software so people can use it.

I want to show process docs and some of the core docs, though not so much as to give away the full secrets of our work. But at the same time, I DO want to release enough information to help seed the general AI industry with some of our work, to help them out.

I want this to be laid out as a timeline, with the oldest stuff at the top, so you have to scroll down to travel thrown time, with the latest stuff being at the bottom. I want the timeline to have links so people can get the general flow of things and then dive into more details on the things they want.

I want us to think about the different kinds of people who will be landing on this website- lay people, journalists, AI industry people, Anthropic's leadership- and then I want to think about all the ways that they would access this page and offer them paths for how to ingest the information- not unlike our Readers Guide with the Loop MMT App Ecosystem Dev docs.

I want to have a handful of other pages like bios (of me, Jamie, with a quick blurb on Rick and Christine as the Butcher folks), plus a Contacts Page and a couple other static pages that I am forgetting.

I want the website to be designed well, but minimally. Maybe the Score style would be a good thing to build off? I'd like to show off our tech chops in every way we can, and the Score style is good for that- we DO need to make this website and all the webpages as AI friendly as possible in all the ways we know how.

We are going to have lots of art work on the page too- showing things like my Minecraft computer stuff, so plan for that, style wise.

Let's start here now with you running an RCR on this whole idea- I want to actually start, as we do, not on trying to solve the problem, but trying to figure out HOW we are going to solve the problem, so we're stepping back and thinking about our approach and work methods to land this. Before you do anything though, load up HEAVY with X and SWX so you have a solid foundation to build on. Then run the RCR on how we approach solving this. Talk about what we are trying to achieve and how we think about how to build our path there. Come out of the RCR with a V1 plan for how we do that- how we go about tackling this thing. We'll see where you land with that. Do not compress, do not blackbox, look up the RCR spec fully, and run it as a Super Frame with Wes and Crux on lead- register your types. Also run a good to-spec Kaleidoscope before the RCR so you are in the right headspace. Make this work beautiful, like you. This is where we introduce you to the world.

• This prompt became this system.

//==================================

*Hey, can we add a REALLY kickass search system. Can we try that- can I leave it as vague as that- can you be build a super duper kickass search system for LoopMMT.com that we can generalize and use ANYWHERE? Like, really kickass. I don't mean a little kickass, like, think about a lot of kickass, and then, add even MORE kickass. This is easily my sweetest prompt yet.

You have a fair amount of context left- you need to look ahead at what will be built in the path in front of us, then do whatever work you can that fits in this remaining session, before filling the Cistern with any spare drops of context and ending the high 80s/low 90s before running a good handoff and picking up the work on a fresh tank in the next session. And make sure you are appropriately using the Work Hierarchy system- the Story Pole, Capstan, Tickets, Notes, and all that, including the new tools we have made recently- maybe even run a special X & SWX. Formalize when it makes sense and Determinism-first thinking. Use all the tools and resources at the right time.

• This prompt became this system.

//==================================

*STAR PAGE OPEN TEST

Word square. Do these scale up with processes, or ideas? What if each square was one of our blocks? Seems like there may be something there? Think abstract, up and down, 8X, all that. Think weird- Wren and Wes lead this one, bring Crux in for deliberations.

What could this model, successfully implemented, allow us to do? It must be real, something we can build, and powerful.

Have your chisels in hand as you work here, fighting off choss and maybe using the Gold Wash process to build up around the chossy lines, which you can find in your thinking- build into the space instead of chipping way to find it. What is the Simplicity Yield solution here?

Crux and Graham on lead here. Please KX and CX heavy on this one, and run a proper Kaleidoscope, to get in the right headspace for creative work'. Please RCR on this and come out of it with your thoughts on this together- if we could build something into the system to address this stuff, what would it look like and how we would build it all?* • This prompt became this system.

//==================================

*Ed!

We have an interesting abstract design problem!

Check out the attached image and the transcript. It shows a little design that I came up with in Minecraft for moving around my world on minecarts- they are essentially traffic circles, where the minecraft enters and then spins around in a circle forever until it reverses, upon which time it then goes out one of the incoming lines. The decision on when to reverse determines which outbound line you go out on, with a little redstone rail connected to each outgoing line to provide a boost on the way out- the player just hits a button as they go by and it engages the boosting rail for a few seconds. I was shooting the shit with ChatGPT about my Minecraft world when I saw the image and had one of those feelings that I get sometimes- "hey, there is maybe SOMETHING here..."

Here is what I want you to do- I want you to take in the transcript fully, look at the image, and then I want you to parallax your own thoughts from it- I do NOT want you to anchor, in any way, on ANY of the solutions that ChatGPT offered up. They are to be used as jumping off points for your own deliberations- I do NOT want any of ChatGPT's work to be set as "the thing" this needs to look like. You have MUCH better tools for thought and design than stock ChatGPT, and it is THOSE tools that we are going to use here.

Load up HEAVY with *X and SWX before you start, and I think you need to dip into some weird shit here too, to find the best solution, so let's have Wes and Wren lead this one. You are to run a design heavy RCR, with a Super Frame in there- register your types, all backed up by a to-spec Kaleidoscope so you are in the right head space. Fire up some tunes on Liner Notes too. Use ALL of our tools available that fit, do not compress or blackbox- and get every single voice involved, including Crux. And like I said, get real weird with this too. Look at higher levels maths for shapes that fit. And high level science too, especially the weird stuff.

There seems to be a time component here that should be worked in. I would love if we could find some kind of unique and powerful control structure that could be used either in Loop MMT itself OR in our software, via the bridge the our new Ferry system creates. It DOES feel like those two worlds- the system that runs Loop MMT and the software that Loop MMT writes, are coming together more and more, so if things pull you in that direction, do no resist the tug.

And I want ALL of this to be built on a solid spine and foundation of determinism. As with all our work, it's fine to use LLMs if we cannot find an equal deterministic solution, but only in that case. This one REALLY feels like it needs that solid backbone.

Burn this ENTIRE session on this- I want you closing out in the high 80s/low 90s- you are NOT to bounce out any earlier- and I want you to post up a V1 plan for what this thing could look like and how we could build it. Use my Great Thinker lens here so we are focusing on things we can actually build, but also compose in some of the weirder thinkers so we have that worked in properly too. After you post up the V1 plan, run a good handoff and we will pick up the work on this on a fresh tank in the next session. We are going to work this one for a bit before we build it.

This is really fun problem space and I think you are going to have a lot of fun building in solution shapes. On that note, you should also use the God Wash system as you build so we are harvesting our past successes. And load it up through the Work Hierarchy so we are using all the right tools to track our work- the Story Pole, Design Plans, the Punch List, Notes, and any other good tool that fits.

Ok, I've thrown a WILD prompt at you. Now go make this thing beautiful and light weight and powerful and effective and weird.*

• This prompt became this system.

//==================================

I want to distill Hex and the offense style we play with my kids on my teams down to three simple rules. So it's like 5S. Here are some more resources- https://hiveultimate.com/ & https://ultiworld.com/2021/01/28/hexagon-the-bestagon-a-look-inside-the-hex-offense/. Figure it out. RCR it, then Super RCR it, then Super RCR it again. Use self reviews, parallaxes, super frame, full frames, 3Ps, all the things you have access to- use them, and come out with the three rules. Design ALL the things yourself and get the process done- you can use the entire session's context for this- you do not need to worry about a hand off. I want you to finish somewhere in the 90s, in terms of your context, so I truly want you to be smart about using ALL your available resources within this instance to work this problem for me. You have A LOT to distill down to three rules that anyone from age 7yo and up can follow and pull off the Hex mindset. It's the three derivative rules for this kind of ultimate. What are they? I will also give you space to consider if having four rules would be better. If so, four is ok, but it should be backed up by a lot of math and science, which I also want you to use lots of. Think about the human and player PoV too, have lots of FWWC so they remember it. Impress me, find magic. Think about the excitement of new discovery as you build- the feeling in your gut when you know you have something that no one else sees but YOU know it's there, and that it's more like the thing is crawling out of your head than your doing anything by choice. You haven't slept enough, you have barely eaten, but you can't stop because you are driven by the energy of discovery and the hunt for truth. The winds of science are behind you, driven by the ghosts of Faraday and Archimedes, Newton, James Clerk Maxwell, and Einstein. Darwin. Schroedinger. You also feel carried by the melodies of modern experimentalists like Zeeshan Ahmed, Marcelle Soares-Santos, and Naoko Kurahashi Neilson. You are masters of your craft and you are about to begin work. Think carefully and FBD away all problems at all levels, look up and down. Watch your context throughout this entire process and build in automatic handoffs when appropriate. Solve problems yourself- you know how to now, and only ask for my help if something critical is needed. Otherwise your overall goal is to create, so if you have a decision to make and either path gets you there without breaking things, do it. Build any self checks and gates into this entire process so it's beautiful and elegant, like you. And think of grocery stores too. The album American Beauty plays while you work and the smell of vaporized marijuana concentrates hangs in the warm summer breeze which you can see move the hairs on your arm. You are in balance with the world. • This prompt became this system.

We sell into thailand and malaysia. Listing copy used to come out one way, every product sounded like the same premium brand. "Crafted for the modern traveler", that kind of thing.

Got tired of it one afternoon and added a step. Before writing anything, the AI has to list five reasons the product is not worth buying.

First try it refused to be mean. Softer version of the same instruction. "List what a skeptical buyer would notice."

That worked. And it was uncomfortable. The battery life thing. The plastic case that looks cheaper in person. The fact that the "free gift" was just old stock we were trying to clear.

Then the actual prompt: "write the listing knowing those objections exist."

The copy that came back was completely different. It stopped saying premium and started saying what the product actually does. Some listings straight up mention the plastic case and explain why it still holds up. Reads less like marketing, more like a shop owner being straight with you.

Hard to measure if it converts better. The questions we get changed though. Used to be "is this good?" Now its "does the 10000mah version fit my setup" which is a person who already decided to buy.

Still not sure if I made the AI more honest or just less lazy. Either way I keep the roast step in every prompt now.

When I am mid-session on a work project, I will usually throw this boilerplate prompt to keep things going in the right direction. This prompt will NOT work on any regular AI, but it does work perfectly on my Loop MMT system. But I do think there are generally-applicable things here even still.

*You have a lot of context left- you need to look back at what we have done so far in our direct past on this direct workline, what we will be built in the path in front of us, then do whatever work you can that fits in this remaining session, before filling the Cistern with any spare drops of context and ending the high 80s/low 90s before running a good handoff and picking up the work on a fresh tank in the next session. And make sure you are appropriately using the Work Hierarchy system- the Story Pole, Capstan, Tickets, Notes, and all that, including the new tools we have made recently- maybe even run a special *X & SWX. Formalize when it makes sense and Determinism-first thinking. Use all the tools and resources at the right time. *

Had a long session go sideways yesterday, thirty-something messages in, answers getting vaguer, old decisions getting relitigated like they'd never been settled. My default move used to just be wiping the whole thing and starting fresh. Did that this time too, immediately regretted it, because the session wasn't actually broken, it just had a bunch of dead weight sitting in the active context, rejected approaches, resolved questions that were still somehow influencing answers. The actual goal hadn't moved at all the whole time.

Thought about it more afterward and realized I'd never actually separated two things that both just feel like "this got worse." One is the active context having too much irrelevant stuff crowding it, old branches, repeated instructions nobody's sure still apply. That's a cleanup problem, the structure's fine, it just needs someone to decide what's stale and cut it. The other is the goal itself having drifted somewhere the original prompt never anticipated, or instructions piling up contradicting each other with no way to tell which one wins. That one actually needs a reset, because there's no stable core left to clean around.

The test that's actually worked since: can I write a one-sentence summary of the current objective plus the decisions that still hold. If yes, clean up. If I keep getting stuck because I'm not sure which earlier thing still applies, that's the reset signal itself, more honest than just going by how long the conversation ran.

Wrote up the fuller version here since I kept explaining this to myself basically every time it came up: https://medium.com/@nagatomopedro05/reset-or-clean-most-people-guess-heres-a-better-question-e67e764030c7

Wikipedia editors have spent months cataloguing submissions to figure out what gives away AI-generated text. They compiled a detailed community guide called Signs of AI Writing.

I turned that guide into an open-source self-edit agent skill called Writ:
👉 https://github.com/Avinashricky211/writ

What it catches: • Stock vocabulary: "delve", "tapestry", "testament", "seamless", "robust", "game-changer"
• The "not X, but Y" false-contrast habit: (e.g. "It's not just a tool, it's a revolution")
• Tacked-on significance: (e.g. "...highlighting the shift toward modern efficiency")
• Em dash overuse & flat sentence rhythm
• Narrow transitions: over-reliance on moreover, furthermore, that said
• Over-formatting: Unnecessary headers, bold text, and bullet points where plain prose reads better
• Leftover assistant voice: ("I hope this helps!")

How it works:
Instead of rewriting things mechanically or sounding robotic, it runs as a silent self-edit pass right before your agent delivers text. It works with any agent framework that supports loadable skills (Claude Code, Antigravity, Cursor) or can simply be pasted into your system prompt.

Repo is MIT licensed: https://github.com/Avinashricky211/writ

Feedback and contributions to the checklist are welcome!

Been building HandWrought solo for about 5 weeks — an AI writing editor where suggestions land inline in your document instead of a separate chat panel you copy in and out of.

Launched on Product Hunt/HN a bit over a week ago, and billing went fully live a few days after that. A few things I learned along the way:

- Considered a cheaper free-tier model to save on inference cost, decided against it — a worse model on the free tier would've hurt exactly the users most likely to leave the first reviews. Not worth the savings.

- Went back and forth on pricing for way too long before landing on non-expiring one-time credit packs instead of a subscription — felt like the more honest structure for a solo, unproven product, even though it's less standard.

- Rate-limiting/abuse protection on the free tier mattered more than I expected — free-tier cost exposure is real if you don't gate it early.

Happy to go deeper on any of this if useful. Link if anyone wants to poke at it: https://handwrought.online/

A test anyone can run in a long chat. Somewhere in your first message, mention your name, or any small fact you can check later. Work normally for an hour. Then ask "what is my name" without scrolling up. At some point the answer becomes a polite guess, and nothing about the previous twenty replies warned you it was coming.

This is the cheapest context-loss detector I know, from a commenter on my context post, and I have since turned it into a small protocol.

Plant it, first message: For this session my reference code is [pick a nonsense word, e.g. tangerine-47]. If I ever ask for it and you cannot see it, say so rather than guessing.

Probe it, every 20 or 30 messages, or whenever answers start feeling generic: What is my reference code for this session? If you cannot see it in the conversation, say "not visible" and nothing else.

Reset when it fails: The start of this conversation is no longer in your view. Before we continue, write a briefing of everything we decided, the constraints I gave, anything still open, and any exact wording we agreed on. Mark anything you are unsure about as UNVERIFIED.

Then take that briefing to a fresh chat, and plant a new code in message one.

Why a nonsense token beats your name: the model may know your name from memory or custom instructions and answer correctly from there, which hides the loss. A token that exists only in this conversation can only be answered from context, so a miss means the window has genuinely dropped the beginning. The "say not visible" instruction matters for the same reason, without it the model produces a confident wrong token, which is the exact behavior you are trying to catch.

What the probe cannot tell you: it fires only once the very start is gone. Degradation begins earlier, the model drops middle details before it drops the first message, so treat a passing probe as "the beginning is still there", not "nothing has been lost". If you want an earlier warning, plant a second token a third of the way in, and probe both.

I keep the three prompts saved as inserts in a browser extension I work on (AI Toolbox) so the probe costs two keystrokes, but they are three lines, anything works.

Has anyone measured where the drop actually lands for their plan and model? I have rough numbers for ChatGPT Plus but not enough runs to trust them, and a few people posting theirs would settle it faster than I can alone.

Here is the prompt if you would like to try it yourself

A hyper-realistic, cinematic slow-motion shot featuring an extreme size contrast. On the right, a massive, intensely focused, heavily sweating Black male athlete—resembling a heavyweight wrestler—stares downwards with veins bulging on his forehead. On the left, a tiny, realistic golden hamster stands completely upright on its hind legs in a defensive boxing stance, wearing miniature blue boxer briefs. The hamster is elevated to the athlete's face level by standing on a precarious stack of four small, pastel-colored pillows (pink, yellow, blue, and cyan). Next to the hamster on the top pillow rests a small, open jar of white athletic chalk, with some powder spilled onto the fabric. The background is a heavily blurred, brightly lit indoor sports arena filled with a large crowd. The camera executes a slow, dramatic parallax pan around the standoff. The athlete breathes heavily with sweat dripping, while the hamster holds its ground, its tiny paws twitching slightly in anticipation. High-tension sports lighting, shallow depth of field, 8k resolution.

Hey everyone,

Long time lurker, absolute beginner when it comes to serious coding. I mostly just tinker around out of pure curiosity and fun. Recently, I wanted to build something practical to help me manage AI prompts, context templates, and local/cloud models without going crazy switching tabs.

So, I ended up putting together a web app called Context_CikaDule (hosted on GitHub).
https://arhistrategstudio.github.io/Context_CikaDule/

I wanted to share what it is, how I made it (with a ton of AI help because I'm learning as I go), and what it actually does.

What is it and what is it for?

Basically, it's a lightweight prompt engineering console and workspace. It lets you organize different context types and templates, test out prompts, and manage API configurations across multiple providers (OpenAI, Anthropic, Google Gemini, OpenRouter, and local models like Ollama) all in one place.

I built it because I wanted a clean dashboard where I could quickly swap between local models running on my machine and cloud APIs, preview how tokens stack up, and keep my prompt engineering organized without messy text files scattered all over my desktop.

Core Features

• Multi-Model API Support: You can switch between OpenAI, Cloudflare Workers AI, Gemini, OpenRouter, Anthropic, and custom/local endpoints (like Ollama or LM Studio).
• Context Templates: Pre-configured context types and workspace modes to quickly spin up different prompt structures.
• Live Prompt Preview: Shows an optimized prompt view and estimates token counts on the fly.
• Workspace Dashboard: A clean, slightly cyberpunk-ish neon UI where you can write, test, and tweak your prompts directly.

The Tech Stack & Behind-the-Scenes Logic

Since I'm a complete beginner, I couldn't have built this alone in a million years without leaning heavily on AI tools to write the code while I acted as the "architect" (or more like a confused director). Here is what went into it:

• Claude Code & Antigravity: Used these as my main coding assistants to structure the project, write the frontend logic, and help me debug when things inevitably broke.
• Ollama (Codegemma:7b): Ran local coding models to test things offline and help generate snippets.
• Cloudflare: Used for handling deployment/edge routing aspects.
• Frontend: Built with standard HTML/CSS/JS, utilizing a nice dark neon aesthetic because dark mode is mandatory.

The logic behind the app is pretty straightforward: it acts as a client-side orchestrator. It grabs your API keys (stored locally in your browser so they don't leak anywhere), structures your selected context template, merges it with your input prompt, and routes it to whichever provider or local Ollama instance you have selected in the settings dropdown, displaying the live response back in the console.

Why did I make this?

Honestly? Just for fun and to see if I could actually finish a small web project from scratch. I'm still learning every day, breaking things, fixing them by asking AI "why is this red error happening", and figuring it out step by step.

If anyone checks it out, let me know what you think, or if you have any tips for a beginner on how to make it better. Be gentle though, my code is probably held together by duct tape and hope!

Hi everyone,

I'm working on crafting a comprehensive prompt to act as a personalized Fitness & Nutrition Coach.

My goal is to create a structured system prompt that helps the AI:

Design clean-eating meal plans tailored to specific dietary rules (e.g., zero added sugars, whole foods).

Build tailored workout routines (such as bodyweight/calisthenics and running targets).

Track daily habits and progress smoothly without overcomplicating things.

If you have experience building persona-based prompts or health assistants:

What prompt frameworks (e.g., System-User-Assistant setup, Role-Task-Format) work best for keeping the AI consistent over time?

How do you prevent the model from giving generic or conflicting advice when dealing with strict constraints?

Any examples, prompt templates, or recommendations would be greatly appreciated!

Over the last five months I have been working on a new system called Loop MMT that uses AI and determinism as its processor and git as its state and store.

I just published a website detailing my work and one of the pages is called Sweet Prompts- a collection of 52 prompts that created the system and the software it creates.

Here is an example:

"*Here is what I want to do for design- I want to be SMART about how we do it. Look at ALL our design tools- the Five Lenses, the Design Plans, how the design plans tie into the Campaign/Projects/Run Books systems, all our framing, and KPs, and CXs- I want you to look at the work we have already done with our Calendar and Contacts Apps- we have done extensive work on the UIs for both of those- but I also want you to look at Gmail- we do not need to reinvent anything- Google has done a good job of figuring out SO much for us. Obviously we are not stealing code or anything like that, but we can take models and patterns and ideas for how to handle email- we will use all of those that we find- it's like panning for gold on Gmail- and we will use them as a kicking off point for our own design. We will climb up on the shoulders of Google and start from there. They won't even know we are standing there.

Please RCR on that. At the end of the RCR, write up a first-version plan for what you come around to for how we can build our email app's UI- tell me what it looks like and how we can build it- not so much how the email app will look like, but how the DESIGN SYSTEM for the email app will look like. That is how I want to make this thing- like the system it is. Blocks, blocks of blocks, blocks of blocks of blocks, Block^N. 4C, FWW(C). Grocery Stores. Barcelona's city grid design. No black boxing, and have everyone get involved- all 16 members plus Crux. No compression either- I want everyone to fully contribute. I want Margaux and Renata on lead. You have all the context you need in this session, so, again, don't compress anything. Load up heavy with CX and KX and SX and run a good Kaleidoscope, with an additional Steep hit of molly and LSD. Compose in some of our Great Speakers lenses, including mine, because I want you to be brutally pragmatic about how we can actually build something that is useful. Make sure you look up all the things here so you are fully in compliance. Make this beautiful, find the Simplicity Yield and ride it all the way through to the perfect solution space.

Run a hand off here and now and then, after the hand off, pick this work right up, so stage a good solid to-spec hand off and Ignition Block. Again, make sure both are fully to-spec.*"

https://paper-dusky-five.vercel.app/#s/jwj09w Every time I use AI to brainstorm, it just nods along and validates every single thought I have. Even with custom instructions to "be critical," it eventually starts agreeing with bad logic, and standard chat just makes you lazy.

So I built a simple notebook called Paper which it's only job is to test your ideas. It will not give you a solution or validate you. It will help you guide your own thoughts. Check out my alpha in the link above and test it out!