Write and maintain documentation with the coding agent you already use

Writing documentation usually starts with good intentions and ends with a familiar problem: the code changes faster than the docs.

The difficult part is rarely Markdown. It is finding the right source file, checking what the product really does, turning implementation details into useful steps, and remembering which pages need to change after the next release.

Docloom makes that work much simpler. It gives the coding agent you already use—Codex, Claude Code, or Gemini—a project-local documentation skill. You ask for documentation in plain language, the agent researches the source code and tests, and it writes or updates the Markdown files in your repository.

You stay in the same editor, terminal, and Git workflow you already use.

Start in a few commands

Docloom is distributed through GitHub Packages. Sign in to the registry once with a GitHub token that can read packages:

npm login --scope=@pateladesh --auth-type=legacy \
  --registry=https://npm.pkg.github.com
npm install --global @pateladesh/docloom

For a new documentation project, run:

docloom init my-docs --source product=../my-product
cd my-docs

docloom init creates the local documentation project, connects the local product source, and installs the Docloom authoring skill for supported coding agents.

If you already have a Docloom project, add or refresh the agent skill with:

docloom agent setup

The same skill works with Codex, Claude Code, and Gemini. You do not need to learn a different documentation workflow for each agent.

The configured source path remains a local project setting. The agent knows where to research the product whenever you ask it to write or maintain documentation.

Ask for the first useful page

Open your preferred coding agent in the Docloom project and give it a direct request:

Use $docloom-authoring to create a clear getting-started guide for this product.
Read the source code and tests, keep all changes local, verify the examples,
and do not publish.

That is enough to begin. You do not need to prepare a large specification or explain the repository file by file.

The agent researches the product, identifies the intended first success, and turns the relevant implementation details into reader-focused instructions. It can also update navigation and record which source files support the page, making the documentation easier to maintain later.

For a new project, start small. A useful landing page and a working quickstart are more valuable than twenty shallow placeholder pages. You can add the next workflow once the first one is clear and verified.

Review everything locally

Preview the result before publishing:

docloom preview --open

This starts a local documentation preview. Read the page as a new user would:

1. Are the prerequisites clear?
2. Can you follow the steps without guessing?
3. Does the page show what success looks like?
4. Is there a sensible next step?

If something is unclear, ask the agent in ordinary language:

Make the setup steps shorter and add the expected result after each command.
Keep the existing tone and do not publish.

You can continue refining the page this way. The agent edits the local files, so every change remains visible in your normal Git diff and review process.

Before you finish, run the local documentation check:

docloom test

This catches common problems such as incomplete pages, missing navigation, stale evidence, and examples that could not be verified.

Keep documentation current as the code changes

Maintenance should be just as easy as the first draft. After changing product code, ask:

Use $docloom-authoring to update only the documentation affected by the current
code changes. Verify the result and do not publish.

The agent compares the current changes with the documentation and its saved evidence. It updates the pages that describe reader-visible behavior and leaves unrelated pages alone.

This is the important difference between generating documentation once and maintaining it well. The agent does not need to rediscover the entire product every time. The documentation brief, reader coverage, style choices, and source evidence stay with the project, so future sessions can continue from the same understanding.

If a code change is purely internal and does not affect users, the correct result may be no documentation change at all. Good maintenance is about keeping docs accurate, not creating edits for every commit.

A few prompts cover most everyday work

You do not need a library of complicated prompts. These are enough for most teams:

Document authentication for a developer using this product for the first time.
Use the source code and tests as evidence. Keep changes local and do not publish.

Improve the quickstart so a new user can reach a successful result without guessing.
Verify every command and do not publish.

Review the current documentation for outdated setup instructions.
Fix only issues supported by the current code and tests.

Update only the docs affected by my current code changes.
Run the local checks and tell me what changed.

Each request describes a reader outcome. The agent handles the repository research, page structure, evidence tracking, and local verification behind the scenes.

Publish your first documentation site for free

When the documentation is ready, you can publish your first public site on the Doxbrix Free plan. It costs $0 and does not require a credit card. The free plan includes one public documentation project, subject to the current Free plan limits.

Sign in from the CLI:

docloom login

Inspect the deployment without uploading:

docloom deploy --dry-run

When everything looks right, publish the site. Docloom creates or reuses the hosted project through Doxbrix's public API:

docloom deploy

The CLI validates the local pages before uploading them and asks for confirmation before publishing. Once the push completes, the documentation is live and its search and AI answers are updated from the same content.

Local-first authoring keeps you in control

The Docloom authoring skill lives inside your project. It reads configured local source directories, writes local Markdown or MDX, updates local navigation and evidence files, and runs local checks. Local authoring does not require a Doxbrix login or an MCP server, and the skill does not publish unless you explicitly ask it to.

That means you do not have to upload your repository to another documentation service just to produce a draft. You can inspect every changed file, review the Git diff, apply your normal repository permissions, and decide when anything is ready to leave your machine.

There is one important distinction: Codex, Claude Code, and Gemini are AI products, and their model-provider data controls still apply. Depending on the agent and your organization's configuration, selected context may be sent to that provider for processing. Use the provider plan and privacy settings approved by your organization, keep secrets out of prompts and source files, and retain normal sandbox and review controls. Local-first Docloom authoring removes an additional documentation-platform upload; it does not replace your AI provider's security policy.

Documentation becomes part of development

The simplest documentation workflow is the one your team will actually repeat:

1. Install the local authoring skill.
2. Ask for one useful reader outcome.
3. Preview and review the result locally.
4. Ask the agent to maintain affected pages when the code changes.
5. Publish the first public site on the Free plan when your team is ready.

You keep control of the source, the diff, and the release. The agent takes care of the time-consuming research and repetitive maintenance that usually lets documentation fall behind.

Start with one page. Ask your coding agent to make it useful. Then let the same workflow keep it useful as your product evolves.