Writing a post about one of my own projects involves a slightly ridiculous step: explaining the project, my writing style and my publishing boundaries to an agent all over again.
The code lives in a repository. So do plenty of product decisions. Yet writing two paragraphs can still involve collecting links, screenshots and old conversations as if I were packing for a move.
I have put the content side into a repo too. It holds voice guidelines, references, drafts and templates. I can open it with an agent, ask for a specific change and review the resulting files.
What goes into the repository
I keep materials with different jobs separate. Voice guidelines are not a calendar, and a draft is not a product fact sheet.
Here is a simplified version of that structure. It illustrates the arrangement; it is not a directory you need to reproduce in full:
content/
voice/
guidelines.md
projects/
product.md
drafts/
launch.md
templates/
video/
carousel/The guidelines hold decisions that affect the writing: language, expressions to avoid and boundaries around what can be shared. The project file holds verifiable facts. Drafts remain proposals, however convincing they sound.
Templates contain reusable visual decisions such as layout, type and output formats. Changing one piece should not require redesigning everything I publish.
A task I can actually review
For a post about SmoothUI, I would not ask an agent to “make something that performs well on social.” That hands over too many decisions we have not agreed on.
A more useful brief would be:
Read the voice guidelines and the current SmoothUI README. Propose a draft about one improvement you can verify. Identify the source for each claim. Do not add usage figures or publish anything. Suggest an interaction we could record to explain it.
The output might be a Markdown file and a proposed recording. I can review those independently. If the improvement needs a long explanation, a guide may be more appropriate than a twenty-second promo.
An agent can help identify the angle and write a first version. Whether that version deserves to go out is still a separate decision.
Git does more than keep old copies
I want to see what changed between proposals. If I remove a sentence because it promises too much, that correction should be easy to find later rather than buried in a conversation.
A diff also shows whether the agent changed the paragraph I asked for or enthusiastically rewrote the angle, headline and half the product description.
The repository is not automatically trustworthy, though. A README can become outdated. A draft can contain an invented number. Before describing a feature, I still need to check its current source.
What stays out
Credentials, private data and client material do not belong in this content workflow. I also separate generated media from template code. Versioning a composition is useful; filling Git with test renders is less appealing.
Storing content and authorizing publication are different operations. A file named launch.md is not permission to schedule it on a social platform.
This distinction matters when an agent has access to more than a text editor. Preparing a draft should not silently turn into publishing one.
Where I would start
I would start with a short voice guide, a fact sheet for one project and one draft. Then I would run a real task and see what information is missing.
I have already written about building AI skills for a workflow. This setup has a narrower purpose: preparing content about my products without reconstructing every previous conversation.
For now, I would rather have a small folder I can understand and review than a huge system that does everything except find the right draft.