# Use GitHub for a release note scope question

Example: A release issue lists three planned fixes. One remains open, but the draft release note includes all three.

By Righthand Team · 2026-10-19

Source: https://www.righthand.ai/blog/use-github-for-a-release-note-scope-question

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 release issue lists three planned fixes. One remains open, but the draft release note includes all three.

[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 issues and release note.
>
> Identify completed and planned work as different states.
>
> Send the unverified fix claim to the release owner.
>
> 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.

Issue closure alone does not establish deployed customer behavior.

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

> Two fixes have supplied completion evidence. The third remains open and cannot support a completed-fix claim.

The release owner removes the claim or supplies the required release evidence.

## 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).