Code-to-Docs makes documentation automation wait for a reviewer’s second command

A Red Hat community project is testing a practical answer to a familiar documentation problem: let an AI model find documentation affected by a code change, but do not let the model decide what gets written. Code-to-Docs implements that boundary as a two-step review loop inside a pull request.

The review loop

A collaborator starts the Action by commenting [review-docs] on a pull request. Code-to-Docs examines the diff, identifies documentation files it considers relevant and posts a review comment with checkboxes. A reviewer can deselect files before issuing a separate [update-docs] comment, which creates a documentation pull request containing only the accepted files. Reviewers can also add global or per-file instructions to that second command.

That separation matters because the workflow is not merely advisory. Its sample configuration grants contents: write, issues: write and pull-requests: write. The example also limits command handling to comments from GitHub users whose association is OWNER, MEMBER or COLLABORATOR, making repository membership part of the approval boundary rather than accepting instructions from any commenter.

Where the credentials go

For documentation in the same repository, the project says GitHub’s built-in GITHUB_TOKEN is sufficient. Updating a separate documentation repository requires a personal access token with repository scope. The model is configured independently through an OpenAI-compatible endpoint, API key and model name; the README lists vLLM on OpenShift AI alongside hosted and local alternatives.

Teams therefore have at least two permission decisions to make: which identities may trigger generation, and which repositories the workflow token may modify. Keeping the generated update in a second pull request preserves an ordinary code-review checkpoint after the checkbox review.

Jira adds a wider visibility boundary

The optional [review-feature] command goes beyond documentation selection. It fetches a Jira ticket and linked Google Docs or Confluence specifications, then compares their requirements with the pull-request changes to identify covered, missing and unplanned work.

The project explicitly warns that Jira and specification content included in its review comment becomes visible to everyone who can access that pull request. Private requirements should therefore not be connected to a repository whose audience is broader than the source material. Unfetchable specification links are flagged for manual review rather than silently treated as absent.

Code-to-Docs is still automation with write-capable credentials, not a passive assistant. Its useful design choice is that discovery, human selection and repository mutation are distinct events that teams can audit and restrict.