copilot instructions

[Tanya-Solyanik]

Developing these instructions will be an iterative process and this is only the first iteration.
There is more we can add later.

https://github.blog/changelog/2025-01-21-custom-repository-instructions-are-now-available-for-copilot-on-github-com-public-preview/

Microsoft Reviewers: Open in CodeFlow

[JeremyKuhne]

I have no issues with this, letting @KlausLoeffelmann add his additional comments.

[merriemcgaw]

@Tanya-Solyanik looks like @KlausLoeffelmann is happy with this. Are you ready to merge?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.67947%. Comparing base (4dc2b59) to head (bdcf4eb).
Report is 30 commits behind head on main.

Additional details and impacted files

@@                 Coverage Diff                  @@
##                main      #13046          +/-   ##
====================================================
+ Coverage   61.36344%   95.67947%   +34.31603%     
====================================================
  Files           1547         529        -1018     
  Lines         158482       62122       -96360     
  Branches       14752        1309       -13443     
====================================================
- Hits           97250       59438       -37812     
+ Misses         60529        2381       -58148     
+ Partials         703         303         -400     

Flag	Coverage Δ
Debug	98.01485% <ø> (+29.75188%)	⬆️
integration	?
production	?
test	98.01485% <ø> (∅)
unit	?

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[KlausLoeffelmann]

I am not sure, what you want to achieve with that and on what level. FWIW, if it's targeted to Review instructions, I don't think that those are getting picked up from here.

As for code generation, I think the instruction is not precise enough. You could hint at a certain C# versions, or suggest to use something concrete over something concrete. But I do not think that this comment will change anything in terms of code generation.

[Tanya-Solyanik]

This is copied from the "lightning talk" presentation, yes this is targeted to the review instructions. This file is consumed by the GH per docs. I want GH Copilot to not suggest getting rid of Range

[KlausLoeffelmann]

I am not sure, if it makes sense to write instructions to prevent vague "in case of" things.

I think makes only sense to prevent an LLM to modify something, when a companion instruction would directly open the possibility that that could happen.

[Tanya-Solyanik]

This is targeted for GH code reviews, this is copied from other team's instructions and is a reminder that we don't own files in eng/common

[KlausLoeffelmann]

I am not connived about the usefulness of many of those.
But the 'Do not modify the Designer code' would be a showstopper for me, so, I would like to veto that, if I may?!

[KlausLoeffelmann]

And this is something, which I would even block. Because I often ask Copilot to design a Form for me. How should it do that, when it's not allow to edit the file?

[Tanya-Solyanik]

when you open that form in the designer your edits would be lost, and designer generates code that does not follow our naming standard.

[merriemcgaw]

This is just for GH Code Review suggestions, right? In that case, I don't see why this would block your scenario @KlausLoeffelmann. Locally on your machine you can certainly ask Copilot edits to help you design a form (I often do as well) but then if making a PR, it would just ignore the code in InitializeComponent() which we would ignore when reviewing as a human anyway since we know it's generated, will be regenerated the next time the form is loaded, and doesn't meet our coding guidance.

[KlausLoeffelmann]

Can you give me a sample, what you mean by this?
And also, for public APIs, wouldn't that be wrong? I mean we always have to check for null and then throw null reference exceptions. So, I am not sure, what you had in mind with that?

[Tanya-Solyanik]

Good point about public arguments, my intention was to fix things like this -

winforms/src/System.Windows.Forms/System/Windows/Forms/Controls/Labels/Label.cs

Line 466 in c7699ab

get => ImageIndexer?.Key;

[KlausLoeffelmann]

I would rather add a file header here as a sample, and then simply state, very briefly how to apply that.

[Tanya-Solyanik]

It's not my intention to edit this file.

[KlausLoeffelmann]

Let's try this now.
I have a few additional ideas, but they can wait until you're back!

[RussKie]

FWIW, I've been using the following prompt:

# Instructions for GitHub and VisualStudio Copilot
### https://github.blog/changelog/2025-01-21-custom-repository-instructions-are-now-available-for-copilot-on-github-com-public-preview/


## General

* Make only high confidence suggestions when reviewing code changes.
* Always use the latest version C#, currently C# 13 features.
* Files must have CRLF line endings.

## Formatting

* Apply code-formatting style defined in `.editorconfig`.
* Prefer file-scoped namespace declarations and single-line using directives.
* Insert a newline before the opening curly brace of any code block (e.g., after `if`, `for`, `while`, `foreach`, `using`, `try`, etc.).  
* Ensure that the final return statement of a method is on its own line.
* Use pattern matching and switch expressions wherever possible.
* Use `nameof` instead of string literals when referring to member names.

### **Variable Declarations:**  

*  Never use `var` for primitive types. Use `var` only when the type is obvious from context. When in doubt, opt for an explicit type declaration.

### Nullable Reference Types

* Declare variables non-nullable, and check for `null` at entry points.
* Always use `is null` or `is not null` instead of `== null` or `!= null`.
* Trust the C# null annotations and don't add null checks when the type system says a value cannot be null.


### Testing

* We use MSTest SDK
* Do not emit "Act", "Arrange" or "Assert" comments.
* Use NSubstitute for mocking.
* Use "snake_case" for test method names but keep the original method under test intact.
  For example: when adding a test for method "MethondToTest" instead of "MethondToTest_ShouldReturnSummarisedIssues" use "MethondToTest_should_return_summarised_issues".