API credits aren’t cheap. So you do what any reasonable developer does. You switch models when Claude disappoints you, start a fresh chat when the context fills up, close the tab and come back tomorrow.
And every single time, you spend the first ten minutes re-explaining your project from scratch. The architecture. The decisions you already made. The bug you fixed two sessions ago that the model just suggested reintroducing.
I got tired of it. So I built Dory.
What it is
Dory is a one-file convention. You drop a CHANGELOG.md in your repo root and write plain lines as you work. What you did, in your own words. No schema to memorise, no tooling to install.
# Project Changelog
<!-- Append-only. One line per entry. No headings or blank lines. -->
Refactored auth to JWT after session logic started breaking under multi-tenant load
Scaffolded the database schema
Fixed a rendering bug in the tree component
Enter fullscreen mode Exit fullscreen mode
At the start of a new session, drop the file into context. The model reads it and knows where you are. That’s genuinely the whole thing.
Why it works
LLMs are good at reading plain text and orienting themselves from it. You don’t need structured JSON or a special format. A flat list of what happened, in order, is enough.
The header comment does the instructional work:
<!-- Append-only. One line per entry. No headings or blank lines. -->
Enter fullscreen mode Exit fullscreen mode
Most models understand this on sight. Tell the model to update the changelog at the end of a session and it appends entries without needing further prompting.
The workflow
Starting a session: drop CHANGELOG.md into context.
Ending a session, just ask:
Update the changelog.
Switching models or coming back after a gap:
Read the changelog and tell me where we are.
If you’re on Claude, there’s a SKILL.md in the repo you can paste into your project instructions to make this permanent.
Why not just use git history?
Git history tracks code. Dory tracks decisions. A commit message tells you what changed. A changelog entry tells you why you went that direction and what state things were in when you left. They sit alongside each other fine.
If your project already has a CHANGELOG.md for user-facing releases, just name this one AI_CONTEXT.md or LLMLOG.md.
That’s it
No dependencies. No setup beyond creating a file. Works with Claude, GPT, Gemini, anything that reads text.
The repo has a SKILL.md, three real-world example changelogs from different project types, and a placeholder to copy straight into your project.
If you use it, open a PR with your own example. The more project types in there, the more useful it becomes.
답글 남기기