Update Docs
| This documentation was generated with the assistance of AI. Please report any inaccuracies. |
Bring an Antora-based documentation module’s .adoc pages (and its nav.adoc/antora.yml if structure or
version changed) up to date with changes already made to the codebase. This skill only edits documentation — it
never changes source code, and it never invents documented behavior that isn’t actually in the code.
Purpose
iru-update-docs closes the gap between a code change and a stale documentation site. It reads the actual diff, not
just file names, cross-checks every class/method/endpoint it plans to mention against the real current source,
and only touches the specific pages that diff actually concerns — leaving the rest of the site untouched. It
makes no assumption about a fixed docs path or a fixed set of page names; it discovers the real Antora module(s)
present and their real page map fresh each run, which is why it works the same way regardless of which
repository it’s invoked in. If a documentation MCP (e.g. Confluence, Notion) is connected, it extends the same
diff-driven understanding to that external system too — finding the relevant existing page(s) there first, then
showing the user the exact proposed change for approval before anything is written. Before drafting anything
against that connector, it checks what its own tools actually expose: if the connector is read-only (search/read
only, no create-page/update-page tool), it warns the user by name and skips the external-docs enrichment
entirely instead of drafting an update it could never send.
Inputs
| Argument | Required | Description | Default |
|---|---|---|---|
|
No |
A commit, ref, or range (e.g. a tag, |
None — defaults to uncommitted changes plus commits on the current branch not yet on the repository’s base
branch ( |
Outputs
-
Updated
.adocpages reflecting only what the scoped diff actually changed — new/removed/renamed public APIs, behavioral changes, new variants of an existing abstraction, or changed documented commands. -
nav.adoc/antora.ymlupdated only if a page was added, removed, or renamed, or the component version should track a source version bump. -
Mermaid diagrams (
[mermaid]) or MathJax equations added only where the Antora playbook already has the matching extension wired in, and only where they genuinely clarify a decision process, data flow, or formal definition better than prose. -
If no
antora.ymlexisted anywhere in the repository and the user agreed to bootstrap one: a newly scaffolded Antora module (viairu-setup-antora), then the rest of the run proceeds against it. -
If a documentation MCP (e.g. Confluence, Notion) is connected and exposes a write (create/update-page) tool: a proposed update to the relevant existing external page(s), sent only after the user reviews and approves the exact change shown to them.
-
If a documentation MCP is connected but only exposes read tools: an explicit warning naming the connector, and the external-docs enrichment skipped entirely for this run — never a drafted change that couldn’t be sent.
-
A report naming, per page: what changed in the source that drove the edit and what was updated in the docs — plus pages deliberately left unchanged, any doc gap noticed but left out of scope, and what was sent (or proposed-but-declined) to a connected documentation MCP.
-
No source code is ever modified.
Execution flow
Dependencies
Invokes
-
Setup Antora — Step 2, conditionally: only when no
antora.ymlis found anywhere in the repository, and only after asking the user whether to bootstrap Antora documentation now. Run via a sub-agent (the Agent tool) briefed with the actual code-change context, soiru-update-docsitself can resume once scaffolding finishes and continue with the rest of its run against the newly created module.
Invoked by
-
Code — Step 8, once per run (not per task), invoked directly (not via a sub-agent) once the build, quality, and security gates all pass, so the project’s documentation reflects everything the whole plan changed before the plan is archived.
-
Also meant to be run directly by a person (or potentially by another skill in a different repository) after code changes have already been made outside the
/iru-codeflow.
Related agents
None directly — iru-update-docs delegates the conditional iru-setup-antora call in Step 2 to a sub-agent (see
Agents), but that is calling a skill through a sub-agent wrapper rather than relying on an
agent’s own unique capability, so no agent is listed as a direct dependency here.
Source
SKILL.md on GitHub — the file this page was generated from.