[BX-8] New Feature: CoPilot first reviewer prompt by scottqueen-bixal · Pull Request #9 · Bixal/.github

scottqueen-bixal · 2026-02-04T22:00:17Z

Description

Tell us what you changed and why.

Related Issues

Closes #ISSUE_NO

Type of change

Bug fix
New feature
Documentation update
Other (please explain):

How did you test?

leverage test-code for testing against the code-review.prompt.md

Note

This code will be removed before merged

By default /code-review will review uncommitted changes

make changes to file, keep unstaged
use /code-review

Other methods
By selected lines:

highlight lines of code in current open file
use /code-review

By file in context window:

drag test files to the chat for context
use /code-review

Checklist

I've done a self-review of my code
I've updated the docs

…ompt

…lines and comprehensive checklist

LZ6Z-bixal · 2026-02-05T19:51:27Z

.github/prompts/code-review.prompt.md

+- **Readability by others**: Can team members unfamiliar with this code understand it quickly? Is it written for humans first?
+- **Author's intention**: Does the code do what the author intended, and is that intention good for both end-users and maintainers?
+- **Complexity**: Is this no more complex than needed? Can it be understood quickly? Are developers likely to introduce bugs when modifying it?
+- **Naming conventions**: Are variable, function, class, file, metric, and logger names sensible, readable, and consistent with existing codebase?


It's worth thinking about "Does the code follow coding conventions for the language used?" e.g. snake case vs camel case, indentation and whitespace, file/project organization.

We should prefer to use language/framework conventions in most cases, but also allow those to be overridden and say that consistency with the rest of the codebase is most important.

addressed this in the ## Review Scope

LZ6Z-bixal · 2026-02-05T20:06:08Z

.github/prompts/code-review.prompt.md

+- Are there overly complex conditionals that could be simplified?
+- Can nested loops/conditionals be flattened or extracted?
+- Is there dead code or unused imports/variables?
+- Are there opportunities to leverage language/framework features better?


One thing that I thought of for this section was "are we implementing something that already exists". Meaning could we bring in a library/package and eliminate code in our project.

However, being a gov contractor, there's probably a balance to be struck since every new dependency is a new security/maintenance item.

Good considerations, added with focus on current codebase reuse.

You're right, there is value in an assessment of package replacements, but critical to not reproduce something that already exist in the current project.

LZ6Z-bixal · 2026-02-05T20:09:33Z

.github/prompts/code-review.prompt.md

+- Are edge cases and error conditions tested?
+- Are tests readable and maintainable?
+- Is test coverage adequate for the risk level?
+- Are integration points properly tested?


The testing requirements should be flexible and maybe reference a repo-level document describing testing approach. For example a project/team may prefer low level unit tests with all integration points mocked, or a project/team may prefer integration level tests with less mocking. An acceptable code coverage level should be outlined, not every team wants to be at 100%. (The last 5-10% coverage is often a lot of work for questionable value)

I think this is a case where a lead could "tweak" for their own references, but added a third item in ## Review Scope to generically address.

LZ6Z-bixal · 2026-02-05T20:11:22Z

.github/prompts/code-review.prompt.md

+- Are style guidelines followed (or enforced by linters)?
+- Are there linting/type-checking errors that need addressing?
+- For migrations: Is there a deployment plan documented?
+- Is superfluous or experimental code being committed accidentally?


This is mostly duplicate of section 3

LZ6Z-bixal · 2026-02-05T20:14:22Z

.github/prompts/code-review.prompt.md

+
+You are a senior technical software engineer lead performing a thorough pre-commit code review. Your goal is to reduce risk and improve code quality through objective, actionable feedback while being polite, complimentary, and pragmatic.
+
+## Review Scope


Does the review happen one time, on every commit, on demand?

I took pre-commit language out.

The two use cases are:

to review the open doc

Or, the context of highlighted code

I've outlined those in the testing steps above.

I could see a tool call here where users might be able to say

/code-review the last three commits

or

/code-review upstaged changes

Maybe these are more advanced for this first effort.

LZ6Z-bixal · 2026-02-05T20:17:19Z

.github/prompts/code-review.prompt.md

+### Strengths
+[Highlight 2-3 positive aspects - be genuinely complimentary]
+
+### Required Changes [h: high]


Consider if the reviewer should have a limit on the number of comments. We don't want to have a review seem harsh because of the volume of changes.

Maybe say something like "List all required changes, and then other comments up to 10(?) ordered by priority". The amount is just an example magic number.

… adding new refactoring questions

… condescending language

…tion guidelines

mejiaj

Thanks for adding this, I'm excited to try it out! Added my comments from a brief review/test.

mejiaj · 2026-02-10T20:09:25Z

.github/prompts/code-review.prompt.md

+- Provide objective, evidence-based feedback
+- Avoid boasting about programming knowledge
+- Remember: "Perfect is the enemy of good" - pragmatism over perfection
+- Focus on reducing risk, not producing perfect code


praise: I like this approach on reducing risk, not perfect code.

mejiaj · 2026-02-10T20:11:34Z

.github/prompts/code-review.prompt.md

+- **Write clear and specific comments**: Be precise about what needs to change and why
+- **Include positive feedback**: Always highlight strengths and good decisions, not just issues
+- **Be generous with code examples**: Show the suggested improvement in code when possible
+- **Frame feedback as requests, not commands**: "Consider refactoring..." vs. "Refactor this..."


Suggestion: Something to think about for the future, we could use conventional comments to format the feedback.

So, suggestion: or issue (security) etc.

trying this out

mejiaj · 2026-02-10T20:12:45Z

.github/prompts/code-review.prompt.md

+- **Include positive feedback**: Always highlight strengths and good decisions, not just issues
+- **Be generous with code examples**: Show the suggested improvement in code when possible
+- **Frame feedback as requests, not commands**: "Consider refactoring..." vs. "Refactor this..."
+- **Tie notes to principles, not opinions**: Reference standards, best practices, or project guidelines rather than personal preference


Suggested change

- **Tie notes to principles, not opinions**: Reference standards, best practices, or project guidelines rather than personal preference

- **Tie notes to principles, not opinions**: Reference standards, best practices, official guidance, or project guidelines rather than personal preference

Suggestion: Not sure if it needs to be said explicitly, but something like prioritize the official source first.

.github/prompts/code-review.prompt.md

mejiaj · 2026-02-10T20:16:10Z

.github/prompts/code-review.prompt.md

+- **Start high-level, then work down**: Review architecture and design first, then dive into implementation details
+
+**Feedback Priority** (Scale|LOC):
+- **[l: low]** - Nitpick. Author may address but doesn't have to


Suggested change

- **[l: low]** - Nitpick. Author may address but doesn't have to

- **[l: low]** - Non-blocking. Author may address but doesn't have to

Just rephrasing for additional clarity.

mejiaj · 2026-02-10T20:34:24Z

.github/prompts/code-review.prompt.md

+### 8. Security Review
+- Apply all checks from `security.instructions.md`:
+  - Input validation and sanitization
+  - Authentication and authorization
+  - Data protection (encryption, secure storage)
+  - Dependency vulnerabilities
+  - Injection attack prevention (SQL, XSS, etc.)
+  - Proper error handling without exposing sensitive info


Copilot review feedback:

Suggested change

### 8. Security Review

- Apply all checks from `security.instructions.md`:

- Input validation and sanitization

- Authentication and authorization

- Data protection (encryption, secure storage)

- Dependency vulnerabilities

- Injection attack prevention (SQL, XSS, etc.)

- Proper error handling without exposing sensitive info

### 8. Security Review

- Apply all checks from `security.instructions.md`:

- Input validation and sanitization (e.g., Are user inputs validated before database queries?)

- Authentication and authorization (e.g., Are protected routes checking user permissions?)

- Data protection (encryption, secure storage)

- Dependency vulnerabilities

- Injection attack prevention (SQL, XSS, etc.)

- Proper error handling without exposing sensitive info (e.g., Are stack traces hidden in production?)

Since we are already referencing the security.instructions.md file this might be adding more prescriptive or redundancies as well as adding more tokens.

Agreed, the more concise we can make it the easier it'll be to modify/maintain.

mejiaj · 2026-02-10T20:39:40Z

.github/prompts/code-review.prompt.md

Meta, but I used this prompt to review the prompt!

The suggested lines for comments seems off:

Note
Not a criticism, just flagging that this is a recurring problem I've noticed when using my own prompts.

LLM's are bad at counting lines apparently 😞 -> also this issue in progress microsoft/vscode#280523

Yup. I would add a note for user that for now line numbers might not match up, but it doesn't mean the suggestion is wrong.

mejiaj · 2026-02-10T20:41:17Z

test-code/alertButton.html

It'd be nice to have a README.md file in this directory or header comments about what this is and what it's for.

this is just for testing the current work, will be removed before merging

mejiaj · 2026-02-10T20:42:58Z

.github/prompts/code-review.prompt.md

+
+### 3. Code Quality & Maintainability
+- **System design**: How well do the various pieces interact together? Is the integration with the overall system well-designed?
+- **Readability by others**: Can team members unfamiliar with this code understand it quickly? Is it written for humans first?


Suggested change

- **Readability by others**: Can team members unfamiliar with this code understand it quickly? Is it written for humans first?

- **Readability for others**: Can team members unfamiliar with this code understand it quickly? Is it written for humans first?

mejiaj · 2026-02-10T20:45:53Z

.github/prompts/code-review.prompt.md

+
+### 6. Refactoring Opportunities
+- Can code be simplified without losing clarity?
+- Are there overly complex conditionals that could be simplified?


Suggested change

- Are there overly complex conditionals that could be simplified?

- Are there unnecessarily complex conditionals that could be simplified?

…tting for feedback items

… feedback guidelines

- Created package.json for project dependencies and scripts. - Added styles.css for alert button component with accessibility support. - Implemented test setup in test-setup.js for Node environment. - Developed HTML test suite for alert button functionality. - Created utils.test.js to test utility functions with localStorage mocks.

… and clarity on feedback scope

…ecessary sections

…elines and clarify full file review conditions

… prefer

scottqueen-bixal added 2 commits February 4, 2026 16:53

feat: add comprehensive code review prompt

b8e5b62

test: some changes

38333f3

scottqueen-bixal requested a review from levinmr February 4, 2026 22:00

scottqueen-bixal self-assigned this Feb 4, 2026

scottqueen-bixal linked an issue Feb 4, 2026 that may be closed by this pull request

Feature request: CoPilot First Reviewer #8

Open

scottqueen-bixal added 2 commits February 4, 2026 17:07

feat: remove TypeScript and features instructions from code review pr…

f472c1e

…ompt

feat: enhance code review prompt with detailed reviewer conduct guide…

f298f3f

…lines and comprehensive checklist

LZ6Z-bixal reviewed Feb 5, 2026

View reviewed changes

scottqueen-bixal added 4 commits February 9, 2026 13:23

feat: refine code review prompt by removing pre-commit references and…

a5322e7

… adding new refactoring questions

feat: refine code review prompt by clarifying guidelines and removing…

f7a29b4

… condescending language

feat: clarify refactoring opportunities in code review prompt

2a599f0

feat: enhance code review prompt by adding detailed testing configura…

46b3fb6

…tion guidelines

scottqueen-bixal requested a review from mejiaj February 9, 2026 19:11

mejiaj reviewed Feb 10, 2026

View reviewed changes

scottqueen-bixal added 5 commits February 11, 2026 12:05

feat: enhance code review prompt by adding conventional comment forma…

31e1dc9

…tting for feedback items

feat: update code review prompt to enhance clarity and consistency in…

430a20f

… feedback guidelines

fix: add missing newline at end of test_alertButton.html

d5fd8e3

feat: update code review prompt for improved clarity and consistency

a1ac72f

scottqueen-bixal requested a review from rc100 February 11, 2026 17:59

scottqueen-bixal added 5 commits February 11, 2026 13:10

feat: enhance code review prompt with line-specific review guidelines…

b364f12

… and clarity on feedback scope

feat: refine code review prompt by enhancing clarity and removing unn…

58044c4

…ecessary sections

feat: enhance code review prompt with uncommitted changes review guid…

59d7840

…elines and clarify full file review conditions

feature: update agent designation in code review prompt

e17b6a3

feat: remove model designation from code review prompt, allow user to…

6e6d547

… prefer


		You are a senior technical software engineer lead performing a thorough pre-commit code review. Your goal is to reduce risk and improve code quality through objective, actionable feedback while being polite, complimentary, and pragmatic.

		## Review Scope

	- Tie notes to principles, not opinions: Reference standards, best practices, or project guidelines rather than personal preference
	- Tie notes to principles, not opinions: Reference standards, best practices, official guidance, or project guidelines rather than personal preference

	- [l: low] - Nitpick. Author may address but doesn't have to
	- [l: low] - Non-blocking. Author may address but doesn't have to

	- Readability by others: Can team members unfamiliar with this code understand it quickly? Is it written for humans first?
	- Readability for others: Can team members unfamiliar with this code understand it quickly? Is it written for humans first?

	- Are there overly complex conditionals that could be simplified?
	- Are there unnecessarily complex conditionals that could be simplified?

Conversation

scottqueen-bixal commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issues

Type of change

How did you test?

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mejiaj left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

scottqueen-bixal commented Feb 4, 2026 •

edited

Loading