# Use GitHub to identify documentation work from a bug reply

Example: A completed issue shows that the product worked as designed. The reporter's confusion came from incomplete setup instructions.

By Righthand Team · 2026-10-19

Source: https://www.righthand.ai/blog/use-github-to-extract-documentation-work-from-a-bug-reply

Keep GitHub as the source for its records. A Righthand can use available information for the decision below.

This article is from Righthand. The example and result are illustrative. This guide has no executed integration test.

## The customer task

A completed issue shows that the product worked as designed. The reporter's confusion came from incomplete setup instructions.

[Provider documentation](https://docs.github.com/en/rest/issues/issues). The documentation gives information about issue read and write operations. Repository permissions are necessary for the selected endpoint.

## Make account access explicit

If GitHub is available in [Connections](https://docs.righthand.ai/guides/adding-your-first-connection), connect the intended account. Give the Righthand access to that connection.

Provider documentation does not establish installed Righthand operations. Examine the connection’s available tools before assigning direct account work.

For direct account work, the connection must have the necessary read or write operation and permission. If that operation is unavailable, supply the information in a message. The owner must make any account change in that case.

[Connection Permissions](https://docs.righthand.ai/guides/add-a-connection) gives information about account access and tool permissions. Give only the access necessary for the identified task.

## The request to the Righthand

> Read the supplied issue result.
>
> Prepare the specific documentation gap.
>
> Keep the product behavior finding outside the documentation task.
>
> Send a proposed documentation task to the maintainer.
>
> Send the owner the result before 3 PM Friday.
>
> Use Pacific time.

## Use the provider records for the result

Identify the repository and issue before using its content. Keep the reporter's evidence and the issue state. Treat code changes and issue communication as different tasks.

A documentation gap must not become an invented software defect.

For a permitted write, examine the resulting account record. A proposal does not establish a completed change.

For an external message, identify the recipient and permitted task. **Ask** uses an explicit instruction or approval. Connection tool permissions are another required control. [Communications Policy](https://docs.righthand.ai/security/external-communications).

## An illustrative result and next step

> The issue result identifies a missing setup step. No product code change is proposed.

The maintainer accepts a documentation task before the assistant creates an available issue record.

## Try one account task

1. Give the Righthand one identified source record.
2. Compare its result with that source.
3. Examine the account record after a permitted write.
4. Examine the work in [Activity](https://docs.righthand.ai/guides/working-with-your-righthand).

If a direct operation is unavailable, give the source information in a message. This does not establish a direct integration.

## When the account tools are sufficient

Use GitHub directly when its existing view gives the complete answer and no other conversation is necessary. A person can make the decision from that view.

[Compare plans](https://www.righthand.ai/pricing). [Get a Righthand](https://teams.righthand.ai).