Filer Usecase
A Changelog Draft Every Week, From the Code Folder Itself
A Filer folder on a code repository reads its own commit history on a schedule and writes a plain-language draft of what changed — grouped the way a release note reads, not the way commits are written.
- Schedule
- Chat
What you get
Release notes get written last, by someone reading a week of commit messages and translating "fix(auth): null token on refresh" into a sentence a customer would understand. It is the kind of work that slips — and when it slips, the changelog says "various fixes".
Point a Filer folder at the repository instead. On a weekly schedule the folder's agent reads the commits made since its last draft, sorts them into New, Fixed, Changed and Internal, writes each one from the user's point of view, and puts the section at the top of a draft file for you to polish. Nothing is committed, nothing else in the repository is touched, and a week with no new commits produces no section.
How to do it
Screenshots below are from a real run on a clone of a public plugin repository — a few weeks of ordinary commits, nothing staged for the demo.
What it needs
- A folder that is a Git repository (or a folder inside one — the agent only sees the history that touches its own folder)
- The Code Analyzer plugin, so the agent can read commit history without a terminal
- An inference endpoint — Local AI, Frontier AI (API key), or a local LLM server
Give the repository folder its instructions
Activate the repository folder as a Filer and write the instructions once: on the weekly changelog schedule, find where the last draft ended, read the commits since, group them, and put a new section at the top of
CHANGELOG.draft.md. The instructions also say what the agent must never do — commit, or change any other file — so the repository stays exactly as your team left it.Instruction (excerpt)
This folder is a Git repository. On the "weekly changelog" schedule, draft a plain-language summary of what changed and put it at the top of CHANGELOG.draft.md. Read the commit history with the tools you have for it; never run git or any other command. When the weekly changelog schedule fires: 1. Find where the last draft ended: if CHANGELOG.draft.md exists, read it and look for the most recent line of the form <!-- last-commit: <hash> -->. 2. Read this folder's commit history for the last 14 days (newest first); keep only the commits newer than the marker. 3. If there are no new commits, write nothing and finish with exactly: "No new commits since the last draft." … 6. Put the new section at the top of CHANGELOG.draft.md. Keep every earlier section exactly as it was. 7. Never modify any other file in this folder, never delete anything, never create commits.
The schedule fires
Every Monday morning the schedule wakes the agent. It reads the draft to see where it stopped, asks for the commits since then, and — because these commits carried real messages — has everything it needs without opening a single diff. A repository with terser commit messages gets the same result; the agent reads the changed files of any commit whose message does not say enough.
A draft that reads like a release note
The new section sits at the top of the draft: thirty commits became sixteen lines a customer could read, with the internal work (a shared lint setup, a contributor guide, vendored test suites) kept apart from what users will notice. Run the schedule again before anything new is committed and the agent leaves the file alone and says so.
From the generated CHANGELOG.draft.md ## Week of … ### New — A new GIF Maker plugin combines two to twenty images of the same size into one animated GIF. — Composed videos can now start with a title card and end with an outro card, and can be exported in vertical 9:16 in addition to the usual 16:9. ### Fixed — GIFs made from screenshots with lots of colors no longer wash out and lose their detail, and the image converter no longer crashes when saving a GIF. ### Internal — Committed copies of dependency test suites were removed from the repository to keep it clean and avoid antivirus false positives.
What the draft is, and is not
It is a draft: the grouping follows the commit messages, so a commit filed under the wrong prefix lands in the wrong group, and a message that says nothing produces a line that says little. Quality follows the model — a stronger model gives more reliable results than the small bundled one. Read it before it becomes the changelog.
The screenshots and outputs on this page come from a real run of Filer, not a mockup.
Where else this applies
Any folder whose history is worth summarising for someone who does not read commits fits the same shape:
- A product repository — the weekly "what shipped" note for support, sales or a customer newsletter.
- A documentation or design-system repository — what changed for the people who consume it, not the people who edit it.
- A monorepo subfolder — a Filer on one package sees only the commits that touched that package.
Other ways in
The walkthrough uses a weekly schedule. The same reading of history works on demand, and the draft can go somewhere other than a file.
- Right-click
- No right-click action yet — use chat.
- Chat
- No schedule or setup needed to ask right now:
"What changed in this folder in the last two weeks?" - Other automation triggers
- A file event can replace the schedule — for example, draft when a tag file or a release note lands in the folder — the same shape doc-diff-notify uses.
- Other integrations
- Add a messenger or Notion plugin and the same section can be posted to a channel or a page instead of, or as well as, the draft file.
More usecases
Know What Changed, Without Reading It Twice
A Filer folder agent notices the moment a new contract or policy version lands, diffs it against the one it replaces, and sends you what actually changed.
- File event
- Chat
Come Back To an Answer, Not a Backlog
A Filer folder agent wakes up on its own schedule, reads what piled up while you were away, and sends you the digest — before you've even opened the app.
- Schedule
- Chat