Learn how to customize Copilot code review with custom coding guidelines.
Note
The custom coding guidelines feature is only available with the Copilot Enterprise plan, and is currently limited to selected customers.
This feature will be deprecated in favor of using Copilot custom instructions to customize Copilot code review. See Adding repository custom instructions for GitHub Copilot.
About coding guidelinesYou can provide Copilot with a set of coding guidelines, written in natural language, that will help it review your code in a way that aligns with your organization's coding style and best practices. For more information—including examples of coding guidelines—see About coding guidelines for GitHub Copilot code review.
Creating a coding guidelineOn GitHub, navigate to the main page of the repository.
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
In the "Code & automation" section of the sidebar, click Copilot, then Code review.
Click Create guideline.
Under "Name," give the coding guideline a name.
Under "Description," provide a description of the coding guideline up to 600 characters long. This will be used by Copilot to understand your coding style and to decide when to leave a comment.
How you write your description has a big impact on the quality of comments that Copilot will generate. For help with writing effective coding guidelines, see About coding guidelines for GitHub Copilot code review.
Optionally, limit the coding guideline to specific file types or paths by clicking Add file path and adding path patterns.
You can use fnmatch
syntax to define paths to target, with *
as a wildcard to match any string of characters.
Because GitHub uses the File::FNM_PATHNAME
flag for the File.fnmatch
syntax, the *
wildcard does not match directory separators (/
). For example, qa/*
will match all branches beginning with qa/
and containing a single slash, but will not match qa/foo/bar
. You can include any number of slashes after qa
with qa/**/*
, which would match, for example, qa/foo/bar/foobar/hello-world
. You can also extend the qa
string with qa**/**/*
to make the rule more inclusive.
For more information about syntax options, see the fnmatch documentation.
Test your coding guideline to make sure it works as expected.
Save your coding guideline, and turn it on, by clicking Save guideline.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4