docs: add PR issue closing syntax guidance

[joshsmithxrm]

Summary

• Add NEVER rule: Don't use comma-separated issues in Closes statement
• Clarify ALWAYS rule: Use separate Closes #N lines per issue

Background

PR #243 intended to close 7 issues (#152-158) but only #152 was auto-closed because GitHub's syntax Closes #152, #153, #154... only recognizes the first issue.

Issues #153-158 have been manually closed with comments referencing PR #243.

Changes

NEVER table:

| Use comma-separated issues in `Closes` | GitHub only auto-closes first; use separate `Closes #N` lines |

ALWAYS table (updated):

| Link related issues in PR body | Use separate `Closes #N` per issue; comma syntax only closes first |

Test plan

• Manually closed issues feat: Add ppds plugintraces get command #153-158 referencing PR feat: add plugin traces CLI commands #243
• Documentation update prevents future occurrences

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @joshsmithxrm, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request updates the documentation to provide clearer guidance on the correct syntax for closing multiple GitHub issues from a pull request. The changes aim to prevent a common mistake where only the first issue is automatically closed when using comma-separated issue numbers in Closes statements, ensuring that all intended issues are closed upon PR merge.

Highlights

• New 'NEVER' Rule: Added a new rule advising against using comma-separated issues in Closes statements, as GitHub only auto-closes the first issue in such cases.
• Clarified 'ALWAYS' Rule: Updated the guidance for linking related issues in PR bodies, emphasizing the use of separate Closes #N lines for each issue to ensure all are properly closed.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[Copilot]

Pull request overview

This PR adds documentation guidance to prevent incorrect usage of GitHub's issue closing syntax, specifically addressing the problem where comma-separated issue numbers in a Closes statement only auto-close the first issue.

• Added a NEVER rule prohibiting comma-separated issues in Closes statements
• Updated the ALWAYS rule to clarify that separate Closes #N lines must be used per issue

[gemini-code-assist]

Code Review

This pull request adds important guidance to the project's contribution documentation (CLAUDE.md) regarding the correct syntax for closing GitHub issues in pull request descriptions. The change correctly points out that comma-separated lists of issues in a Closes statement do not work as expected and that separate Closes #N lines should be used instead. My review includes one suggestion to refine the wording in the ALWAYS table to improve clarity, avoid redundancy with the new NEVER rule, and maintain the generality of the original rule, which aligns with the repository's guidelines for concise and directive documentation, especially for AI readers.

[gemini-code-assist]

The new NEVER rule on line 23 is a great addition and clearly explains the anti-pattern.

For this ALWAYS rule, the updated explanation becomes slightly redundant with the NEVER rule. It also loses the generality of the original guidance, which included non-closing keywords like Relates to.

To improve clarity and conciseness, I suggest a version that incorporates both aspects: general linking and the specific instruction for closing multiple issues. This approach keeps the detailed failure case (comma syntax only closes first) in the NEVER table, where it's most impactful, avoiding repetition.

Suggested change

	| Link related issues in PR body | Use separate `Closes #N` per issue; comma syntax only closes first |
	| Link related issues in PR body | Use `Closes #N` or `Relates to #N`. For multiple issues, use separate `Closes #N` lines. |

References

1. When documenting principles, prefer conciseness. Avoid adding redundant text if the existing wording already captures the essence of the principle, even if it's less explicit.
2. For documentation intended for an AI reader, prioritize concise, directive phrasing that is consistent with existing formats over separating patterns from their rationale.