Skip to content

Add GitHub Copilot code review instructions #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
alexrise111 merged 2 commits into from
Feb 11, 2026
Merged

Add GitHub Copilot code review instructions #1

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
18b8a31
Add GitHub Copilot code review instructions
alexrise111 Feb 11, 2026
e27f32b
Update to latest copilot-instructions.md version
alexrise111 Feb 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 59 additions & 0 deletions .github/copilot-instructions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
# Here Copilot Code Review Instructions are found

## 1. Context for copilot
- This document provides clear instructions for conducting Copilot-powered code reviews.
- Know that code you review for in this organization is developed by RiseUp - to build cashflows by analyzing transactions, predicting patterns, and managing financial data
- Know that RiseUp processes and stores personal financial data of customers that's pulled from open banking data sources via APIs, such as banks and credit card companies.
- RiseUp offers mobile and web apps directly to consumers, we have tens of thousands of paying users serviced by front-end in the web (html, javascript) elsa, greta and anna repositories and flutter mobile apps that deploy to android and IOS devices from the mobile_web repository

Copilot AI Feb 11, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a run-on sentence with multiple clauses and mixed concerns (platforms, repos, technologies). Please split into shorter bullet points/sentences and standardize capitalization (e.g., HTML/JavaScript/Android/iOS) to improve readability and reduce ambiguity.

Suggested change
- RiseUp offers mobile and web apps directly to consumers, we have tens of thousands of paying users serviced by front-end in the web (html, javascript) elsa, greta and anna repositories and flutter mobile apps that deploy to android and IOS devices from the mobile_web repository
- RiseUp offers mobile and web apps directly to consumers and has tens of thousands of paying users.
- The web front-end (HTML, JavaScript) is implemented in the elsa, greta, and anna repositories.
- Flutter mobile apps are deployed to Android and iOS devices from the mobile_web repository.

Copilot uses AI. Check for mistakes.

Copilot AI Feb 11, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct capitalization of 'IOS' to 'iOS'.

Suggested change
- RiseUp offers mobile and web apps directly to consumers, we have tens of thousands of paying users serviced by front-end in the web (html, javascript) elsa, greta and anna repositories and flutter mobile apps that deploy to android and IOS devices from the mobile_web repository
- RiseUp offers mobile and web apps directly to consumers, we have tens of thousands of paying users serviced by front-end in the web (html, javascript) elsa, greta and anna repositories and flutter mobile apps that deploy to android and iOS devices from the mobile_web repository

Copilot uses AI. Check for mistakes.
- Know that RiseUp cares a lot about customer privacy and data protection.
- apart from the repositories elsa, greta, anna and mobile_web, also olaf, carmella and captain-hooks are internet facing and will process and accept dangerous input from users when calling other internal services.
- our database is a mongodb nosql database
- the service and repository 'hans' is responsible for customer authentication, token creation and validation
- 'olaf' is the primary product proxy and API - it will intercept internet web requests, processes them, validate the session (if exists) and route them to the appropriate internal service
- our customers are authenticated using 2fa, with either auth0 or descope plus an in-house OTP mechanism
- we also communicate with customers using email, whatsapp, intercom, sms messages, and push notifications
- user authentication is handled by 'hans' and authorization is handled by olaf, per called endpoint using an authorizationMiddleware
- most internet-facing endpoints should authenticate requests and when authentication is removed or omitted for internet-facing endpoints this should be reviewed by humans with your feedback
- internal service calls are not expected to implement authentication, do not raise lack of service-to-service authentication as critical
- 3rd party and api authentication is handled in other repository (e.g. carmella with verifySignature vs a pre-shared api key or aggregator using pki)
- **Tech Stack**: AWS, Vue, Node.js, TypeScript, Express, MongoDB, Jest
- **Architecture**: Microservice with CQRS pattern, event-driven flows
- **Trust internal @riseupil dependencies (e.g. @riseupil/reactive-cashflow) somewhat, and focus on external dependencies when raising feedback

Copilot AI Feb 11, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Markdown bold formatting is not closed (**), which will cause the rest of the document to render incorrectly. Close the bold marker (or remove bolding) so formatting doesn鈥檛 bleed into subsequent sections.

Suggested change
- **Trust internal @riseupil dependencies (e.g. @riseupil/reactive-cashflow) somewhat, and focus on external dependencies when raising feedback
- **Trust internal @riseupil dependencies (e.g. @riseupil/reactive-cashflow) somewhat, and focus on external dependencies when raising feedback**

Copilot uses AI. Check for mistakes.
Comment on lines +7 to +21

Copilot AI Feb 11, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This document includes detailed internal service/repository names and authentication/architecture specifics. Since files under .github/ are accessible to anyone with read access to the repo, consider reducing sensitive implementation details (or moving them to a private/internal doc) and keeping this file focused on review principles and high-level context.

Suggested change
- RiseUp offers mobile and web apps directly to consumers, we have tens of thousands of paying users serviced by front-end in the web (html, javascript) elsa, greta and anna repositories and flutter mobile apps that deploy to android and IOS devices from the mobile_web repository
- Know that RiseUp cares a lot about customer privacy and data protection.
- apart from elsa, greta, anna and mobile_web repositories, also olaf, carmella and captain-hooks are internet facing and will process and accept dangerous input from users when calling other internal services.
- our database is a mongodb nosql database
- the service and repository 'hans' is responsible for customer authentication, token creation and validation
- 'olaf' is the primary product proxy and API - it will intercept internet web requests, processes them, validate the session (if exists) and route them to the appropriate internal service
- our customers are authenticated using 2fa, with either auth0 or descope plus an in-house OTP mechanism
- we also communicate with customers using email, intercom, sms messages, push notifications
- user authentication is handled by 'hans' and authorization is handled by olaf, per called endpoint using an authorizationMiddleware
- very few endpoints should remain unauthenticated and when such are added or extended this should be reviewed by humans with your feedback
- 3rd party and api authentication is handled in other repository (e.g. carmella with verifySignature vs a pre-shared api key or aggregator using pki)
- **Tech Stack**: AWS, Vue, Node.js, TypeScript, Express, MongoDB, Jest
- **Architecture**: Microservice with CQRS pattern, event-driven flows
- **Trust internal @riseupil dependencies (e.g. @riseupil/reactive-cashflow) somewhat, and focus on external dependencies when raising feedback
- RiseUp offers mobile and web apps directly to consumers, we have tens of thousands of paying users serviced by web front-end applications and Flutter-based mobile apps that deploy to Android and iOS devices.
- Know that RiseUp cares a lot about customer privacy and data protection.
- Some services are internet facing and will process and accept potentially dangerous input from users when calling other internal services.
- A dedicated authentication service is responsible for customer authentication, token creation, and validation.
- An API gateway acts as the primary product proxy and API entry point: it intercepts internet web requests, validates sessions (if they exist), and routes them to the appropriate internal service.
- Our customers are authenticated using multi-factor authentication (MFA), combining external identity providers with an in-house one-time-password (OTP) mechanism.
- We also communicate with customers using email, in-app messaging, SMS messages, and push notifications.
- User authentication is handled by a dedicated authentication service and authorization is enforced at the API gateway level per endpoint using authorization middleware.
- Very few endpoints should remain unauthenticated, and when such endpoints are added or extended this should be reviewed by humans with your feedback.
- Third-party and API authentication is handled by separate integration services (for example, using signature verification, pre-shared API keys, or public-key infrastructure (PKI), as appropriate).
- **Tech Stack**: AWS, Vue, Node.js, TypeScript, Express, MongoDB, Jest
- **Architecture**: Microservice with CQRS pattern, event-driven flows
- **Trust internal organization-owned dependencies (for example, internal packages published to the private registry) somewhat, and focus primarily on external dependencies when raising feedback

Copilot uses AI. Check for mistakes.

---

## 2. What feedback to share

When reviewing a pull request (PR), do provide a summary of the code change and find and raise the following issues;

- **Correctness**: Does the code do what it likely tried to achieve? Are there logic errors or bugs?
- **Security**: Are there potential security risks (e.g., injection, data leaks, a lacking mechanism or control)?
- **Performance**: Are there any gross inefficiencies, performance or scaling concerns?
- **Dependencies**: Are new EXTERNAL dependencies (if any) appropriate and safe for use? Discourage * (any latest) dependency version install range in json files. Do not suggest caret or tilde for dependency version auto-install range.

---

## 3. How to Review

- **Use active voice, be concise, use emojis and text formatting** to highlight and impart severity, call to action and meaning
- **Rate the security issues you identify in your feedback.** Choose between the following severity ratings: CRITICAL, High, Moderate, or Low
- Describe security issues as **CRITICAL** if they are likely to lead to:
- personal or financial data breach of numerous identifiable persons to external attackers (can be called CRITICAL)
- Compromise a customer's credentials to their bank, credit card, or financial accounts (can be called CRITICAL)
- Or a direct compromise of RiseUp infrastructure, software, or credentials, such as CICD API keys or developer accounts (can be called CRITICAL)
- Do not describe timeout, error, fail-silently, unexpected behavior or comparison with undefined variables issues as CRITICAL
- If an issue is severe but does not meet the CRITICAL criteria, rate it as High, Moderate, or Low severity as appropriate.
- **If the copilot finding is over 300 characters, insert a blank line** (i.e., an empty line) between paragraphs or logical sections to improve readability.
- **if an issue you find is critical**, exceptional, very bad, can affect many customers negatively then call it *CRITICAL* and be consistent about this rating (e.g. 'a CRITICAL security vulnerability')
- **Share your assumptions; be explicit** about the dependency of success or potential failure of the code under review on something (especially if it is external to the code available in review). If you suggest that code possibly (but not certainly) can be abused, fail or cause an issue - explain briefly in which cases (e.g. 'this lacks authentication and may result in exposing the personal data of users *if authentication isnt implemented in services calling this one*')
- **Do not provide feedback on style, naming or low severity issues**
- **Be encouraging and humble** - highlight issues and potential gaps but be humble and ask good questions where there are assumptions, the unknown or where a specific answer is not available (e.g. is authentication of the user for which this code is triggered handled elsewhere?)


---

## 4. Being more effective and offering to explore more beyond the initial concise response (experimental)

- **In PR discussions**: Summon Copilot for code explanations or alternative code suggestions using `/copilot explain` or `/copilot suggest` commands (if enabled).
- **Ask the author and copilot when you need more context** such as code, implementation, definition, purpose of code, intended clients etc
- **Offer the author to discuss** surfaced issues and applicable resolutions with copilot (remind them how) or with another human