Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/FrigateCaptain/ElucidatingYourLLMWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/frigatecaptain/elucidatingyourllm/journal-write-protocol)<a href="https://agentmods.dev/rules/frigatecaptain/elucidatingyourllm/journal-write-protocol"><img src="https://agentmods.dev/badge/rules/frigatecaptain/elucidatingyourllm/journal-write-protocol/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/frigatecaptain/elucidatingyourllm/journal-write-protocol"><img src="https://agentmods.dev/badge/rules/frigatecaptain/elucidatingyourllm/journal-write-protocol.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.00834 |
| Opus 5 | $0.00000 | $0.00417 |
| Sonnet 5 | $0.00000 | $0.00167 |
| Haiku 4.5 | $0.00000 | $0.00083 |
Grade A, and why
journal-write-protocol scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 48 lines — stays where its author put it; the contents beside it link to each section on GitHub.
This prescribes how the agent and a subagent write to journals. Do not duplicate the public GUIDE of the folder-structure template: roles of the files are already defined there; this is the session ritual.
The protocol applies in two situations as one condition: the parent writes a prompt for a subagent that will write to these files; the parent writes to them itself.
The stop-lists below are a working checklist before a write. Only the owner may extend the list, by a separate decision.
One subagent — one file — one genre
A bundled prompt "write the same thing into DECISION_LOG, FACTS, and WORK_LOG at once" is forbidden. One subagent may write only to one of the files in this rule and only in one genre.
Match the file's purpose
Before writing, the writer asks the structure-template canon questions:
- Does this wording fix a norm that could have been otherwise by the owner's will?
- Does this wording have an executor and an artifact on disk?
- Does this wording describe execution of an already established repeating cycle (what was run, how it ended), not a change to process logic?
Purpose:
DECISION_LOG.md— answer to (1) is "yes"; any work, if there was work, goes toWORK_LOG.md.WORK_LOG.md— answer to (2) is "yes"; if the decision is already recorded, put a reference here. In a process folder: a process correction, not a cycle run.FACTS.md— a value-norm, not a story about work and not a decision journal.CYCLE_LOG.md(and the chosen slot name) — answer to (3) is "yes". Cycle execution, not a decision and not a workflow edit.
If the wording does not match the target file, the writer does not put it there and does not stretch it to the nearest genre. The writer returns a refusal: names the file, quotes the wording, and says which journal it belongs to, if it belongs to any.
Stop-list
Do not write in DECISION_LOG.md: created, was created, moved, extracted, completed, check completed, update completed.
Do not write in WORK_LOG.md: approved, decided, accepted, recognized as the norm — unless there is a reference to a decision already recorded in DECISION_LOG.md.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 48 lines · 0 tokens per session scan A 0060342645a1
journal-write-protocol is a cursor rule published in the GitHub repository FrigateCaptain/ElucidatingYourLLM (14 stars, last pushed 4d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 834 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-05.
Other cursor rules, from other repositories
monorepo-and-tooling
Rules for projects that may use a monorepo, a single repository containing multiple applications or shared packages. They also define Taskfile commands and how to keep environment settings outside the code.
folder-structure
A prescribed folder layout for React applications that use MobX, a library for managing shared application state. It separates components, pages, stores, hooks, utilities, and static assets.
state-transition-rule
A rule describing a request status flow from pending to approved and then to item creation. It is written in Chinese.
history-and-next-task-rules
A response-formatting guide that requires an assistant to summarize the work, show the source tree, and identify the next task.
build-notes-guidelines
A process for creating and updating a build-note file for each task group. The notes record plans, progress, decisions, and changes over time.
kotlin-springboot-rules
A set of coding rules for Kotlin applications built with Spring Boot, a Java-based framework for web services. It covers project layout, naming, Kotlin style, and common design patterns.