I have a repository containing drafts, references and content rules. I also have agents that can work on those files. The awkward part is everything between them: opening the right project, finding the draft and following a task without losing track of what I am reviewing.
That is why I started Glim, a Mac app for working with agents on a content repo. The first prototype was called Moss. It became Glim on the same day, with several layout fixes already in the history. Apparently naming things is not free to delegate either.
The content stays in its files
I did not want trying a new interface to mean moving every draft into another database.
In Glim, the content project is a folder containing files and configuration. It can come from an existing repository. Text, instructions and references remain materials I can open outside the app.
That lets different tools work on the same underlying content. The app brings the work around the repo together rather than making its internal format the only place where that content exists.
The initial version focuses on macOS. I am not presenting it as a solution for every team or a replacement for their editorial tools.
Actual Glim navigation, recorded on November 14, 2026: template library, the “video” filter, opening a pilot’s details and returning to the list. Spanish interface, no audio; the initial and final waits have been trimmed. This is a current recording, not a historical capture from the article date.
What I need to see during a task
I want to request a change to a draft and follow what the agent is doing: what it reads, what it edits and whether it finishes or needs attention.
The project supports different installed agents, including Claude Code, Codex and Cursor Agent. It is not a new model. It provides an interface for assigning work to tools that can already operate on a folder.
A task might look like this:
Review this draft against the voice guidelines. Verify the project description in its README and propose corrections. Do not edit other drafts or publish anything.
Then I need to review the change, not simply receive a message saying it is ready. The conversation is useful, but I need to compare the modified files.
References belong in the workflow too
A screenshot can explain a visual direction better than a whole paragraph. The project includes a reference area for collecting links, images and videos and organizing material that can accompany a task.
That does not make every reference appropriate to copy. When using one to guide a piece, I still need to identify what matters: hierarchy, framing or timing, for example.
“Look at this reference” should not be interpreted as permission to reproduce an entire identity.
Publishing requires a separate decision
The app's repo includes a workflow for reviewing and pushing changes through Git and a PR. That is distinct from publishing content on a social platform.
The documented Buffer integration is read-only: it reflects scheduled and published content. It does not create or schedule posts there. Keeping that boundary prevents a file edit from turning into an external action I did not request.
Approving an editorial proposal and approving its publication therefore remain separate decisions.
It is an early project
Glim's history starts today. There is an app, a README and concrete implementation work behind it. That does not establish that every use case in the description works reliably from end to end.
I still need to test the complete journey: open a repo, assign a task, review the result and return to the work without mixing tasks up. I have no productivity measurements or comparison with other apps that would justify a bigger claim.
The problem I want to solve is specific enough. If the files and agents already exist, I do not want to spend half a session bringing them back together.
This follows my setup for keeping content in a repository. Glim is an interface I am building on top of it, with work still to review.