From 18b8a31417d1b1444dd8d72bf50670f29510ef9c Mon Sep 17 00:00:00 2001 From: alexrise111 Date: Wed, 11 Feb 2026 15:46:56 +0200 Subject: [PATCH 1/2] Add GitHub Copilot code review instructions This adds standardized Copilot code review instructions to help ensure consistent and effective automated code reviews across the organization. Co-Authored-By: Claude Sonnet 4.5 --- .github/copilot-instructions.md | 57 +++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 .github/copilot-instructions.md diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 00000000..635ec330 --- /dev/null +++ b/.github/copilot-instructions.md @@ -0,0 +1,57 @@ +# 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 +- 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 + +--- + +## 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 avoidable 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, Low, or Informational. +- A security issue at RiseUp can only be described as **CRITICAL** if it is likely to: + - Lead to a personal or financial data breach of numerous identifiable persons to external attackers, + - Compromise a customer's credentials to their bank, credit card, or financial accounts, + - Or directly compromise RiseUp infrastructure, software, or credentials (such as CICD API keys or developer accounts). +- 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. +- **Do not provide feedback on style, naming or low severity issues** +- **Be encouraging and humble** - highlight issues and actions but be positive and ask good questions where there are assumptions, unknown or where a specific answer is not available + + +--- + +## 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 \ No newline at end of file From e27f32b0bdd724e2401cc346102fda076fed4469 Mon Sep 17 00:00:00 2001 From: alexrise111 Date: Wed, 11 Feb 2026 16:00:57 +0200 Subject: [PATCH 2/2] Update to latest copilot-instructions.md version Updates the file with the latest version including: - Clarification on authentication requirements for internet-facing vs internal services - Added whatsapp to communication channels - Better guidance on what constitutes CRITICAL issues - Improved examples and assumptions guidance Co-Authored-By: Claude Sonnet 4.5 --- .github/copilot-instructions.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 635ec330..584c88e5 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -6,14 +6,15 @@ - 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 - 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. +- 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, intercom, sms messages, push notifications +- 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 -- very few endpoints should remain unauthenticated and when such are added or extended this should be reviewed by humans with your feedback +- 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 @@ -27,7 +28,7 @@ When reviewing a pull request (PR), do provide a summary of the code change and - **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 avoidable inefficiencies, performance or scaling concerns? +- **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. --- @@ -35,17 +36,18 @@ When reviewing a pull request (PR), do provide a summary of the code change and ## 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, Low, or Informational. -- A security issue at RiseUp can only be described as **CRITICAL** if it is likely to: - - Lead to a personal or financial data breach of numerous identifiable persons to external attackers, - - Compromise a customer's credentials to their bank, credit card, or financial accounts, - - Or directly compromise RiseUp infrastructure, software, or credentials (such as CICD API keys or developer accounts). +- **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. +- **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 actions but be positive and ask good questions where there are assumptions, unknown or where a specific answer is not available +- **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?) ---