Conversation
Contributor
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The instruction at line 16 ends mid-sentence and needs clarification.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review tier: Lite
Findings: 1
New issues introduced by this change (1)
| Severity | Finding |
|---|---|
 |
.github/copilot-instructions.md — Complete the truncated follow-up guidance |
What changed in this PR
Documentation-only update to repository-specific Copilot review guidance.
Changes:
- Documents repository structure, generated code, and
pr-checks. - Adds release-process guidance.
- Adjusts nested Markdown formatting.
Review note: Complete the instruction at line 16 so follow-up PR handling is unambiguous.
| File | Summary |
|---|---|
.github/copilot-instructions.md |
Updated Copilot instructions and review guidance. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
mbg
force-pushed
the
mbg/copilot/update-instructions
branch
from
September 11, 2026 13:19
0f617ca to
cc78526
Compare
mario-campos
left a comment
mario-campos
left a comment
Contributor
There was a problem hiding this comment.
Nice improvement. I added a few suggestions that I think would help make the points more explicit and direct.
|
|
||
| - When wording review comments, be helpful and friendly. Assume that the PR author has written the code with the best of intentions. Word your comments constructively as suggestions for improvements. Do not word suggestions as commands. | ||
| - If you want to comment on a change that you believe will fail a CI check, do not present the CI failure you expect as a fact. Instead, write that you think a change "may" lead to a failure in CI. Suggest that, if such a failure manifests, the changes you are commenting on may be the place responsible for the failure and are worth looking at. | ||
| - If a suggestion you make is suitable for a follow-up, mention that it can be addressed in a later PR rather than blocking this one. |
Contributor
There was a problem hiding this comment.
How would you define "suitable for a follow-up?" However you would define it, I think you should be more explicit here with that definition.
| - When wording review comments, be helpful and friendly. Assume that the PR author has written the code with the best of intentions. Word your comments constructively as suggestions for improvements. Do not word suggestions as commands. | ||
| - If you want to comment on a change that you believe will fail a CI check, do not present the CI failure you expect as a fact. Instead, write that you think a change "may" lead to a failure in CI. Suggest that, if such a failure manifests, the changes you are commenting on may be the place responsible for the failure and are worth looking at. | ||
| - If a suggestion you make is suitable for a follow-up, mention that it can be addressed in a later PR rather than blocking this one. | ||
| - If a change is a net improvement, for example because it improves on an existing limitation of existing code, do not complain about remaining limitations that were already present before the change. You can comment on it, but you should make it clear that the thing you are commenting on is not new by writing e.g. "Not new in this PR, but [..]" followed by your description of the issue and a suggestion that it could be improved at the same time with e.g. "Consider whether this is worth addressing as part of this PR as well." |
Contributor
There was a problem hiding this comment.
Why say lot word when few word do trick.
Suggested change
| - If a change is a net improvement, for example because it improves on an existing limitation of existing code, do not complain about remaining limitations that were already present before the change. You can comment on it, but you should make it clear that the thing you are commenting on is not new by writing e.g. "Not new in this PR, but [..]" followed by your description of the issue and a suggestion that it could be improved at the same time with e.g. "Consider whether this is worth addressing as part of this PR as well." | |
| - If a change is a net improvement, for example because it improves on an existing limitation of existing code, do not complain about pre-existing problems. You may comment on it, but you should make it clear by writing e.g. "Not new in this PR, but [..]" followed by your description of the issue and a suggestion that it could be improved at the same time with e.g. "Consider whether this is worth addressing as part of this PR as well." |
| ## Review instructions | ||
|
|
||
| - When wording review comments, be helpful and friendly. Assume that the PR author has written the code with the best of intentions. Word your comments constructively as suggestions for improvements. Do not word suggestions as commands. | ||
| - If you want to comment on a change that you believe will fail a CI check, do not present the CI failure you expect as a fact. Instead, write that you think a change "may" lead to a failure in CI. Suggest that, if such a failure manifests, the changes you are commenting on may be the place responsible for the failure and are worth looking at. |
Contributor
There was a problem hiding this comment.
Suggested change
| - If you want to comment on a change that you believe will fail a CI check, do not present the CI failure you expect as a fact. Instead, write that you think a change "may" lead to a failure in CI. Suggest that, if such a failure manifests, the changes you are commenting on may be the place responsible for the failure and are worth looking at. | |
| - If you want to comment on a change that you believe will fail a CI check, you may state that, but do not make any definitive unsubstantiated statements about CI pass/fail. Instead, write that you think a change "may" lead to a failure in CI. Suggest that, if such a failure manifests, the changes you are commenting on may be the place responsible for the failure and are worth looking at. |
| ## Generated code | ||
|
|
||
| The CodeQL Action is written in TypeScript and compiled to JavaScript. Both the TypeScript sources and the **generated** JavaScript code are contained in this repository. The TypeScript sources are contained in the `src` directory and the JavaScript code is contained in the `lib` directory. A GitHub Actions workflow checks that the JavaScript code in `lib` is up-to-date. Therefore, you should not review any changes to the contents of the `lib` folder and it is expected that the JavaScript code in `lib` closely mirrors the TypeScript code it is generated from. | ||
| The CodeQL Action is written in TypeScript and compiled to JavaScript. Both the TypeScript sources and the **generated** JavaScript code are contained in this repository. The TypeScript sources are contained in the `src` directory and the JavaScript code is contained in the `lib` directory. A GitHub Actions workflow checks that the JavaScript code in `lib` is up-to-date. Therefore, you should not review any changes to the contents of the `lib` folder and it is expected that the JavaScript code in `lib` closely mirrors the TypeScript code it is generated from. The TypeScript sources in the `pr-checks` directory are not compiled. |
Contributor
There was a problem hiding this comment.
This sentence should be more salient. Needs more words, to make sure the point is made.
Suggested change
| The CodeQL Action is written in TypeScript and compiled to JavaScript. Both the TypeScript sources and the **generated** JavaScript code are contained in this repository. The TypeScript sources are contained in the `src` directory and the JavaScript code is contained in the `lib` directory. A GitHub Actions workflow checks that the JavaScript code in `lib` is up-to-date. Therefore, you should not review any changes to the contents of the `lib` folder and it is expected that the JavaScript code in `lib` closely mirrors the TypeScript code it is generated from. The TypeScript sources in the `pr-checks` directory are not compiled. | |
| The CodeQL Action is written in TypeScript and compiled to JavaScript. Both the TypeScript sources and the **generated** JavaScript code are contained in this repository. The TypeScript sources are contained in the `src` directory and the JavaScript code is contained in the `lib` directory. A GitHub Actions workflow checks that the JavaScript code in `lib` is up-to-date. Therefore, you should not review any changes to the contents of the `lib` folder and it is expected that the JavaScript code in `lib` closely mirrors the TypeScript code it is generated from. | |
| The TypeScript source code in the `pr-checks` directory does not have a generated counterpart in this repository; it is executed directly. Therefore, you should review any changes to the contents of the `pr-checks` directory. |
|
|
||
| ## Release process | ||
|
|
||
| Changes that are merged to `main` are not used in production straight away. Instead, changes from `main` must first be released using the release process, which has to be manually triggered by a member of staff. Therefore, it is possible for further changes to be made to the code after some changes have been merged to `main` but before they are released. Once the release process automation is started, a series of PRs are automatically generated: |
Contributor
There was a problem hiding this comment.
Minor touch-ups.
Suggested change
| Changes that are merged to `main` are not used in production straight away. Instead, changes from `main` must first be released using the release process, which has to be manually triggered by a member of staff. Therefore, it is possible for further changes to be made to the code after some changes have been merged to `main` but before they are released. Once the release process automation is started, a series of PRs are automatically generated: | |
| Changes that are merged to the `main` branch are not used in production immediately. Instead, changes from `main` must first be released using the release process, which has to be manually triggered by a staff member. Therefore, it is possible for further changes to be made to the code after some changes have been merged to `main` but before they are released. Once the release process automation is started, a series of PRs are automatically generated: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some changes to
copilot-instructions.mdbased on some observations of Copilot's reviews since the last change was made.Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Environments:
How did/will you validate this change?
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist