How I Documented an Entire Product in 4 Days with an AI Agent

I had 95 pages of documentation to write, 64 screenshots to capture and a product that was still actively changing while I was documenting it. Features were shipping, parts of the UI were getting redesigned, the product itself was being rebranded and the release deadline was getting closer every day. Normally, a project like this takes weeks.

Not because writing documentation is technically difficult, but because documentation work contains an endless amount of hidden effort that most people underestimate until they actually do it. You are not only writing text. You are constantly switching contexts between source code, UI exploration, screenshot capture, formatting, cross-linking, image optimization, navigation testing and verification. Then the UI changes and suddenly half your screenshots become outdated.

I finished the entire thing in four days using an AI agent called Block Goose, an open-source AI agent project associated with the Linux Foundation ecosystem. But the interesting part is not simply that AI helped write documentation. The interesting part is how the workflow changed when the agent became more than just a chatbot and started behaving more like an actual collaborator that could read source code, automate screenshots, verify pages and improve itself through reusable skills.

This was not one of those AI did everything automatically stories people post on social media. It was messy, iterative, frustrating and surprisingly human. Things broke constantly. OCR failed. Navigation steps stopped working. Screenshots became outdated halfway through the sprint because the sidebar got redesigned. URLs generated by the preview system kept changing. The agent occasionally misunderstood things. I rewrote sections repeatedly. Some pages went through multiple editorial passes before they finally felt correct. But despite all of that, the workflow fundamentally changed how I think about documentation.

The biggest realization was this: AI becomes dramatically more useful when you stop treating it like a tool you repeatedly instruct and start treating it like a system you teach.

That distinction changed the entire project.

The Real Problem Was Never Just Writing Documentation

Most people think documentation work is primarily writing. It is not. Writing is only one small layer inside a much larger system of operational work.

The actual process usually looks something like this. First, you explore the feature manually because documentation is often written by people who did not build the feature themselves. Then you read source code to understand edge cases and implementation details. Then you verify behavior inside the running app because source code and UI behavior do not always perfectly match. Then you capture screenshots. Then you crop and optimize images. Then you insert them into the documentation. Then you cross-link related pages. Then you build the site and verify nothing broke. Then the UI changes and suddenly everything needs updating again.

Now multiply that by 86 pages. That is the real reason documentation becomes exhausting.

In my case, the challenge was even worse because the product itself was still evolving while I was documenting it. The AI Platform by Zephyr Cloud is a desktop collaboration application where teams work with AI specialists inside shared channels. The easiest way to describe it is Slack meets AI agents, but internally the system is much more complex than that. Features were actively shipping during the documentation sprint. Some parts of the product still felt fluid. The UI was changing. The branding changed during the sprint itself. And the existing documentation was not actually user documentation.

It was mostly developer-oriented material. Internal schemas, implementation references, workflow adapters and technical markdown files that made sense if you were building the product but were almost useless if you were simply trying to learn how to use it.

What we needed was true end-user documentation.

The kind where someone installs the application for the first time, opens the docs and immediately understands how to create channels, message specialists, manage workflows, configure settings and actually use the product effectively. That kind of documentation requires clarity, structure, consistency, screenshots and narrative flow. And those requirements turned out to be exactly where the AI agent became genuinely valuable.

Why I Chose an AI Agent Instead of Just Using ChatGPT Normally

I had already been using Goose for engineering tasks before this project started. Unlike a normal chatbot, Goose runs locally and can actually interact with the machine. It can read files, modify content, run commands, interact with tooling and execute workflows through reusable skills. That concept of skills became the foundation of the entire project.

A skill is essentially a persistent instruction system. Instead of repeatedly explaining conventions to the agent in every session, you encode the conventions once and let the agent reuse them forever. That sounds simple, but in practice it changes everything.

Without skills, AI sessions constantly reset context. Every conversation starts with re-explaining tone, formatting, conventions, structure and expectations. The agent may produce decent content, but consistency becomes difficult because every session behaves slightly differently. Skills solve that problem by turning conventions into reusable operational knowledge.

The more I worked on the documentation sprint, the more I realized I was not really prompting the AI anymore. I was gradually building an operational framework that taught the agent how documentation worked inside this specific product ecosystem. That is a very different mindset from casual AI usage.

Instead of repeatedly saying: Write docs like this. I started saying: Here are the permanent rules for how documentation works. And once those rules existed, the agent became dramatically more effective.

The Most Important Decision Was the Phased Plan

Before writing even a single page, I stopped and created a phased roadmap for the entire documentation system. That planning phase ended up being one of the smartest decisions of the entire sprint.

AI agents are powerful, but they still benefit enormously from structured workflows. Throwing a giant vague objective at an agent usually creates chaos. Write all the docs is not a real plan. It is just a large undefined task. So instead, I broke the project into phases with very clear scope boundaries.

• Phase 0 focused entirely on restructuring the documentation architecture itself. Developer-oriented content was separated from user-facing documentation. Directory structure was reorganized. Reference material was moved out of the onboarding flow.

• Phase 1 covered onboarding and first-use experiences. Installation, account creation, creating a channel, understanding the UI and basic navigation.

• Phase 2 documented daily workflows like messaging, channels, threads and specialist interaction.

• Phase 3 covered advanced features such as projects, workflows, tasks and the knowledge garden.

• Phase 4 documented settings pages, integrations, permissions, billing, browser extensions and sandbox configuration.

• Phase 5 focused entirely on screenshots, cross-linking, optimization, consistency and polish.

• Phase 6 became an audit phase where I intentionally searched for undocumented areas of the application.

That final phase was incredibly important because it uncovered features that had quietly escaped documentation entirely. The embedded browser, code editor panel and several settings sections simply had no user documentation before the audit pass.

The phased structure mattered because it gave the project momentum and checkpoints. After every phase I could review progress, adjust conventions, refine the skills and prevent problems from spreading across the entire documentation system. Without those boundaries, the sprint would have become overwhelming very quickly.

The Real Power Came From the Skills

The most interesting part of this workflow was not the AI writing documentation. It was the three reusable skills that gradually transformed the agent from a generic assistant into a specialized documentation system.

The first skill, write-docs, became the editorial brain of the project. It encoded writing style, formatting rules, heading structure, screenshot placement, cross-linking conventions and even validation checklists. The skill enforced a voice that felt direct, conversational and clear without sounding robotic or overly formal. It also solved one of the biggest problems with AI-generated writing: inconsistency.

Without fixed conventions, every session drifted slightly in tone and structure. Once those rules became part of the skill, the output stabilized dramatically. And whenever I noticed a recurring issue, I updated the skill once instead of correcting the same mistake across dozens of pages. Over time, the system itself kept improving because the operational knowledge was improving.

The second skill, doc-screenshots, became the most technically ambitious part of the sprint.

The product was a Tauri desktop app, which meant traditional browser automation tools were not enough. I needed OS-level automation that could interact with the actual application window, navigate screens, capture retina screenshots, run OCR, apply highlights and optimize images automatically. The biggest breakthrough was the screenshot manifest.

Instead of manually capturing screenshots one by one, every screenshot became a YAML definition describing:

• how to navigate there
• what text should appear
• how the image should be cropped
• what cleanup steps should happen afterward

That changed screenshots from static assets into reproducible outputs. Midway through the sprint, the sidebar UI got redesigned and dozens of screenshots instantly became outdated. Normally that would have meant hours of manual retakes. Instead, I updated the manifest rules, reran the pipeline and regenerated all 59 screenshots automatically.

The third skill, docs-preview, handled deployment and verification. Every time the agent updated documentation, the skill built the docs site, deployed it to a live preview URL and verified that the rendered pages actually worked correctly in the browser. This mattered because a successful build does not guarantee the page renders properly. Images can fail, navigation can break and layouts can render incorrectly even when markdown compiles successfully.

The skill also solved an annoying issue with dynamic preview URLs. Every deployment generated a unique hashed link and early in the sprint the agent occasionally reused outdated URLs or invented invalid ones entirely. I fixed that by forcing the skill to always extract the latest URL directly from build logs instead of relying on memory. By the end of the sprint, the three skills had evolved into separate operational layers:

• write-docs handled editorial consistency
• doc-screenshots handled visual automation
• docs-preview handled deployment and verification

Together, they changed the agent from a chatbot generating isolated responses into a continuously improving documentation system with reusable operational knowledge.

The Screenshot System Became an Entire Automation Pipeline.

The screenshot workflow ended up becoming far more sophisticated than I originally expected.

At first, I assumed screenshot capture would remain mostly manual because the application is a desktop app built with Tauri rather than a browser application. Traditional browser automation tools like Playwright work extremely well for web applications, but desktop applications introduce completely different constraints.

Tauri applications run inside native webviews rather than standard browser tabs. That means browser automation tools cannot easily attach to them in the same way they attach to Chrome or Chromium pages. So instead of browser-level automation, I needed OS-level automation.

That led me to Peekaboo, a macOS automation tool capable of interacting with applications through accessibility APIs and screen-level interactions. The resulting screenshot pipeline became surprisingly advanced.

The workflow looked something like this: Peekaboo would locate the application window and bring it into focus. It could navigate the UI by interacting with visible text elements rather than relying entirely on hardcoded coordinates. Once navigation reached the correct state, the system captured a high-resolution retina screenshot. Then a Swift OCR pipeline using Apple’s Vision framework scanned the image and extracted text with pixel-accurate coordinates. After that, Python tooling processed the image further, adding overlays, highlights, borders and optimization passes. Finally, image compression tooling reduced file sizes dramatically without visible quality loss.

The most important architectural decision, however, was the screenshot manifest. Instead of capturing screenshots manually one at a time, every screenshot became a declarative YAML entry that described:

• what screen to capture
• how to navigate there
• what text should exist on the page
• how the image should be cropped
• how cleanup should happen afterward

That design completely changed the nature of screenshot maintenance. Screenshots stopped becoming static artifacts and became reproducible outputs.

That distinction became critically important on Day 3 of the sprint when the application sidebar was redesigned in the middle of the documentation process. Text labels were replaced with icon-based navigation, instantly invalidating huge portions of the screenshots and navigation logic.

Normally, that situation would be catastrophic for a documentation sprint. But because the screenshots were driven through the manifest system, I only needed to update the navigation definitions and rerun the pipeline. Within minutes, all 59 screenshots were regenerated automatically. That single moment justified the entire engineering investment behind the screenshot system.

Working With the Agent Felt More Like Collaboration Than Automation

One thing I want to make very clear is that this was not a fully autonomous AI workflow. I was deeply involved the entire time.

Every page went through review. Every structural decision was debated. Every awkward sentence got revised. The AI generated strong first drafts because the skills provided strong operational context, but editorial judgment still mattered constantly.

Some pages needed major restructuring. The onboarding flow went through several iterations because sequence matters enormously in documentation. Should installation happen before the platform tour? Should channels be introduced before specialists? How should sidebar navigation be explained without overwhelming first-time users? Those are editorial decisions.

AI can assist with them, but it cannot fully own them. The most effective workflow turned out to be collaborative iteration. The agent handled the mechanical workload: reading source files, drafting content, generating structure, maintaining consistency, validating screenshots and checking formatting rules. I focused on narrative flow, clarity, prioritization, emphasis and overall coherence. That division of labor worked extremely well.

The AI accelerated execution dramatically, but human judgment still shaped the final experience. And honestly, I think that hybrid model is probably where AI workflows become most effective right now.

• Not AI replaces humans.

• Not humans ignore AI.

• But systems where AI removes operational friction while humans focus on higher-level reasoning and decision-making.

The Most Surprising Thing Was How Much the Skills Improved Mid-Sprint

One unexpected insight from the sprint was how quickly the skills evolved. The initial versions were relatively simple. But every time something failed, the fix became permanent operational knowledge.

• OCR misread text? Add substring fallback matching.

• Tooltips accidentally appeared in screenshots? Add automatic cursor repositioning before capture.

• Navigation failures left the app in unstable states? Add reset sequences before every capture.

• Preview URLs kept becoming stale? Add log parsing and URL extraction safeguards.

Each issue improved the system itself. And because the skills persisted across sessions, the improvements compounded over time rather than disappearing after each conversation. That was probably the biggest conceptual shift of the entire experience.

Traditional prompting feels temporary. Skills feel cumulative. And cumulative operational knowledge is where AI workflows start becoming genuinely powerful.

The Future of Documentation Is Probably Changing

The deeper I got into this sprint, the more I started questioning what documentation will even look like in an AI-first world. Right now, documentation still matters enormously because users need structured guidance. But increasingly, AI systems themselves are becoming interfaces to products.

If a product already contains intelligent assistants capable of guiding workflows interactively, the role of documentation changes. Instead of users constantly leaving the product to search documentation manually, agents can increasingly guide users contextually inside the application itself. That does not eliminate documentation.

It changes its role. Documentation becomes both a human reference layer and a machine-readable knowledge source that AI systems consume directly. That is why I added llms.txt and llms-full.txt support to the documentation system. Agents can now ingest the entire documentation corpus directly as structured markdown. Pages include Copy as Markdown and Open in Claude functionality specifically to support AI-assisted workflows.

That shift feels important. Documentation is no longer written only for humans.

Increasingly, documentation is also written for agents that help humans. And honestly, after spending four intense days building this system, I think that future is arriving much faster than most people realize. The interesting part is not whether AI will replace documentation. The interesting part is how documentation itself evolves once AI becomes part of the interface layer between users and software.