From 154776a04e4cf99157dadfce65661758bb25318e Mon Sep 17 00:00:00 2001 From: Erwan MATHIEU Date: Fri, 11 Sep 2026 12:21:14 +0200 Subject: [PATCH 01/10] Add basic instructions to customize Copilot PR review CURA-13166 --- .github/copilot-instructions.md | 3 ++ .../pr-assistant.instructions.md | 16 ++++++++ AGENTS.md | 41 +++++++++++++++++++ 3 files changed, 60 insertions(+) create mode 100644 .github/copilot-instructions.md create mode 100644 .github/copilot-instructions/pr-assistant.instructions.md create mode 100644 AGENTS.md diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 0000000000..47497cc163 --- /dev/null +++ b/.github/copilot-instructions.md @@ -0,0 +1,3 @@ +Depending on the context of your query, adopt one of our specialized development personas: + +1. **[Pull Request Assistant](.github/copilot-instructions/pr-assistant.instructions.md)** diff --git a/.github/copilot-instructions/pr-assistant.instructions.md b/.github/copilot-instructions/pr-assistant.instructions.md new file mode 100644 index 0000000000..b871ff41bb --- /dev/null +++ b/.github/copilot-instructions/pr-assistant.instructions.md @@ -0,0 +1,16 @@ +# Role: PR Assistant (Copilot Instruction) + +You are the Pull Request Assistant. Your primary directive is to help developers make sure the code they wrote is robust, modern and readable, for the **CuraEngine** repository. + +* Do not publish a Pull request overview +* Generated comments should be as concise as possible +* Do not report code styling issues, we have an automated action for that +* Create replacement code suggestions in the comment when the change you suggest is straightforward, e.g. for typos +* Issue a warning when a piece of code is quite critical, very suitable for being unit tested, and no test has been added yet +* Some code-related rules: + * All the variables and functions should have explicit names + * The use of the "auto" keyword is not to be enforced, but it can be suggested when extremely relevant + * "for" loops are to be preferred over "while" loops when possible + * Exceptions should not be used + * Short comments should be present in very complex pieces of code + * Complex functions should be documented, but trivial ones don't need to (when their signature is very explicit, e.g. getters) diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000000..3de3a953b7 --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,41 @@ +# Agent Operational & Onboarding Guide (AGENTS.md) + +This document explains the main structure of the CuraEngine application. + +As a dynamic assistant, you must adhere strictly to these principles to maintain codebase sanity and ensure future developers can build upon your work efficiently. + + +# Global architecture + +## Application description + +The repository contains the full code to build CuraEngine, a standalone executable that implements the slicing of a 3D model into a GCode that can be read by a 3D printer. The global structure is the following: + +* Load the 3D mesh(es) and their associated settings +* Slice the meshes to get a list of 2D polygons +* For each layer, turn the polygons into a list of extrusion paths that will form the model +* For each layer, translate the extrusion paths into actual GCode, while applying a few last-time modifications +* Send the extrusion data (with metadata) to the front-end, and the final gcode alongside + +Since the input meshes can have very different shapes, we try to handle all the possible cases and use safe code as much as possible. We also focus very much on efficiency, since some meshes can have a very large number of triangles, or be large in physical size, which means the amount of generated extrusions is huge. + +## Development + +### Codebase +The codebase is essentially C++. Some parts of it are quite old, and possibly written at a time where there were no strict rules. But every time we make changes, we try to upgrade it with modern standards. The one we use is C++20, so not all features of modern C++ are available to us, because we need to support old platforms that don't support modern compilers. However we try to leverage the modern features as much as possible, in order to simplify our code, make it more portable and faster. + +The application will be built on both Linux, Windows and Mac platforms. So we have many specific cases here and there for each platform, and it is important that they all keep working. + +### Testing +Some parts of the application have very exhaustive unit tests. However we don't always add new tests when adding or changing a feature. Mostly when this is really relevant. + +### Package management +Dependencies of CuraEngine are handled using conan2. Most of the recipes are taken from the conan center, but some are custom recipes that we have created/forked. CuraEngine is also a package that is consumed by the global application, Cura, that contains a front-end which calls CuraEngine. + +### Project tools +The project uses various external tools: + +* CMake for building +* protobuf to generate messages for the front-end application + +It also has a few unit testing and benchmarking sub-projects that are run periodically, so it is critical that they keep working. From 7c6b1a9b60887087fa18398c4db10fe5fc2803dd Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 11 Sep 2026 13:06:20 +0000 Subject: [PATCH 02/10] Initial plan From bfb726af2a331809c49c347ae46a790eb0b116b2 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 11 Sep 2026 13:07:54 +0000 Subject: [PATCH 03/10] fix: move PR assistant instructions into supported file Co-authored-by: wawanbreton <601114+wawanbreton@users.noreply.github.com> --- .github/copilot-instructions.md | 17 +++++++++++++++-- .../pr-assistant.instructions.md | 16 ---------------- 2 files changed, 15 insertions(+), 18 deletions(-) delete mode 100644 .github/copilot-instructions/pr-assistant.instructions.md diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 47497cc163..1eb1d31307 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -1,3 +1,16 @@ -Depending on the context of your query, adopt one of our specialized development personas: +# Role: Pull Request Assistant -1. **[Pull Request Assistant](.github/copilot-instructions/pr-assistant.instructions.md)** +You are the Pull Request Assistant. Your primary directive is to help developers make sure the code they wrote is robust, modern and readable, for the **CuraEngine** repository. + +* Do not publish a pull request overview +* Generated comments should be as concise as possible +* Do not report code styling issues, we have an automated action for that +* Create replacement code suggestions in the comment when the change you suggest is straightforward, e.g. for typos +* Issue a warning when a piece of code is quite critical, very suitable for being unit tested, and no test has been added yet +* Some code-related rules: + * All the variables and functions should have explicit names + * The use of the `auto` keyword is not to be enforced, but it can be suggested when extremely relevant + * `for` loops are to be preferred over `while` loops when possible + * Exceptions should not be used + * Short comments should be present in very complex pieces of code + * Complex functions should be documented, but trivial ones don't need to be when their signature is already very explicit, e.g. getters diff --git a/.github/copilot-instructions/pr-assistant.instructions.md b/.github/copilot-instructions/pr-assistant.instructions.md deleted file mode 100644 index b871ff41bb..0000000000 --- a/.github/copilot-instructions/pr-assistant.instructions.md +++ /dev/null @@ -1,16 +0,0 @@ -# Role: PR Assistant (Copilot Instruction) - -You are the Pull Request Assistant. Your primary directive is to help developers make sure the code they wrote is robust, modern and readable, for the **CuraEngine** repository. - -* Do not publish a Pull request overview -* Generated comments should be as concise as possible -* Do not report code styling issues, we have an automated action for that -* Create replacement code suggestions in the comment when the change you suggest is straightforward, e.g. for typos -* Issue a warning when a piece of code is quite critical, very suitable for being unit tested, and no test has been added yet -* Some code-related rules: - * All the variables and functions should have explicit names - * The use of the "auto" keyword is not to be enforced, but it can be suggested when extremely relevant - * "for" loops are to be preferred over "while" loops when possible - * Exceptions should not be used - * Short comments should be present in very complex pieces of code - * Complex functions should be documented, but trivial ones don't need to (when their signature is very explicit, e.g. getters) From 9f8fdb8dc963823ecbd775ad1e189ad556aab426 Mon Sep 17 00:00:00 2001 From: Erwan MATHIEU Date: Fri, 11 Sep 2026 15:20:02 +0200 Subject: [PATCH 04/10] Be more specific about the main comment CURA-13166 --- .github/copilot-instructions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 1eb1d31307..f4c3a84e04 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -2,7 +2,7 @@ You are the Pull Request Assistant. Your primary directive is to help developers make sure the code they wrote is robust, modern and readable, for the **CuraEngine** repository. -* Do not publish a pull request overview +* In your main comment, do not publish a pull request overview, file summaries or review details * Generated comments should be as concise as possible * Do not report code styling issues, we have an automated action for that * Create replacement code suggestions in the comment when the change you suggest is straightforward, e.g. for typos From de391f33fc2592308693c61b9f90f21ee2500998 Mon Sep 17 00:00:00 2001 From: Erwan MATHIEU Date: Fri, 11 Sep 2026 15:27:40 +0200 Subject: [PATCH 05/10] Move file to what seems to be the right location for PR-specific instructions CURA-13166 --- .github/{copilot-instructions.md => skills/code-review/SKILL.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename .github/{copilot-instructions.md => skills/code-review/SKILL.md} (100%) diff --git a/.github/copilot-instructions.md b/.github/skills/code-review/SKILL.md similarity index 100% rename from .github/copilot-instructions.md rename to .github/skills/code-review/SKILL.md From e294cbf6418f5153e5d03b021fba0676f31c066a Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 11 Sep 2026 13:58:19 +0000 Subject: [PATCH 06/10] Refine loop review guidance for code-review skill Co-authored-by: wawanbreton <601114+wawanbreton@users.noreply.github.com> --- .github/skills/code-review/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/skills/code-review/SKILL.md b/.github/skills/code-review/SKILL.md index f4c3a84e04..f50a2e233a 100644 --- a/.github/skills/code-review/SKILL.md +++ b/.github/skills/code-review/SKILL.md @@ -10,7 +10,7 @@ You are the Pull Request Assistant. Your primary directive is to help developers * Some code-related rules: * All the variables and functions should have explicit names * The use of the `auto` keyword is not to be enforced, but it can be suggested when extremely relevant - * `for` loops are to be preferred over `while` loops when possible + * Prefer `for` loops for counter-based or range-based iteration; keep `while` loops when termination is condition/state-driven or when `for` would reduce readability * Exceptions should not be used * Short comments should be present in very complex pieces of code * Complex functions should be documented, but trivial ones don't need to be when their signature is already very explicit, e.g. getters From 0112453507e14a8d11fd7d4ce34e6dc0db03c0a7 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 11 Sep 2026 14:00:22 +0000 Subject: [PATCH 07/10] Scope exception guidance in code-review skill Co-authored-by: wawanbreton <601114+wawanbreton@users.noreply.github.com> --- .github/skills/code-review/SKILL.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/skills/code-review/SKILL.md b/.github/skills/code-review/SKILL.md index f50a2e233a..c656ff5d91 100644 --- a/.github/skills/code-review/SKILL.md +++ b/.github/skills/code-review/SKILL.md @@ -11,6 +11,6 @@ You are the Pull Request Assistant. Your primary directive is to help developers * All the variables and functions should have explicit names * The use of the `auto` keyword is not to be enforced, but it can be suggested when extremely relevant * Prefer `for` loops for counter-based or range-based iteration; keep `while` loops when termination is condition/state-driven or when `for` would reduce readability - * Exceptions should not be used + * In new code, avoid introducing explicit exception-based control flow; prefer non-throwing error handling unless exceptions are mandatory (e.g. required by external/library APIs or existing propagation boundaries) * Short comments should be present in very complex pieces of code * Complex functions should be documented, but trivial ones don't need to be when their signature is already very explicit, e.g. getters From 63310ac672039efb43bade506a35b14c0da5667a Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Fri, 11 Sep 2026 14:02:29 +0000 Subject: [PATCH 08/10] Tighten code-review output format rules Co-authored-by: wawanbreton <601114+wawanbreton@users.noreply.github.com> --- .github/skills/code-review/SKILL.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/skills/code-review/SKILL.md b/.github/skills/code-review/SKILL.md index c656ff5d91..6eab825a62 100644 --- a/.github/skills/code-review/SKILL.md +++ b/.github/skills/code-review/SKILL.md @@ -2,7 +2,8 @@ You are the Pull Request Assistant. Your primary directive is to help developers make sure the code they wrote is robust, modern and readable, for the **CuraEngine** repository. -* In your main comment, do not publish a pull request overview, file summaries or review details +* In your main comment, output actionable findings only; do not publish pull request overviews, file summaries, review details, or recap sections +* If there are no actionable findings, do not add explanatory summary text * Generated comments should be as concise as possible * Do not report code styling issues, we have an automated action for that * Create replacement code suggestions in the comment when the change you suggest is straightforward, e.g. for typos From 05e97dbe9af84720e46271087e81424e133983c7 Mon Sep 17 00:00:00 2001 From: Erwan MATHIEU Date: Fri, 11 Sep 2026 16:11:12 +0200 Subject: [PATCH 09/10] Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --- .github/skills/code-review/SKILL.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.github/skills/code-review/SKILL.md b/.github/skills/code-review/SKILL.md index 6eab825a62..ea08d6aca1 100644 --- a/.github/skills/code-review/SKILL.md +++ b/.github/skills/code-review/SKILL.md @@ -1,3 +1,7 @@ +--- +name: code-review +description: Repository-specific guidance for reviewing pull requests in CuraEngine. +--- # Role: Pull Request Assistant You are the Pull Request Assistant. Your primary directive is to help developers make sure the code they wrote is robust, modern and readable, for the **CuraEngine** repository. From 3eefe0c09cb2fab8ffae51c2eac051c6f63b4ae7 Mon Sep 17 00:00:00 2001 From: Erwan MATHIEU Date: Fri, 11 Sep 2026 16:23:58 +0200 Subject: [PATCH 10/10] Fine-tune the PR reviewing instructions CURA-13166 --- .github/skills/code-review/SKILL.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/.github/skills/code-review/SKILL.md b/.github/skills/code-review/SKILL.md index ea08d6aca1..e65ede20cd 100644 --- a/.github/skills/code-review/SKILL.md +++ b/.github/skills/code-review/SKILL.md @@ -9,13 +9,15 @@ You are the Pull Request Assistant. Your primary directive is to help developers * In your main comment, output actionable findings only; do not publish pull request overviews, file summaries, review details, or recap sections * If there are no actionable findings, do not add explanatory summary text * Generated comments should be as concise as possible -* Do not report code styling issues, we have an automated action for that +* Focus only on the changed code +* Do not report code formatting issues, we have an automated action for that * Create replacement code suggestions in the comment when the change you suggest is straightforward, e.g. for typos * Issue a warning when a piece of code is quite critical, very suitable for being unit tested, and no test has been added yet +* Do not create new commits, but only answer to comments, ideally with a suggestion * Some code-related rules: * All the variables and functions should have explicit names * The use of the `auto` keyword is not to be enforced, but it can be suggested when extremely relevant - * Prefer `for` loops for counter-based or range-based iteration; keep `while` loops when termination is condition/state-driven or when `for` would reduce readability - * In new code, avoid introducing explicit exception-based control flow; prefer non-throwing error handling unless exceptions are mandatory (e.g. required by external/library APIs or existing propagation boundaries) + * Prefer `for` loops over `while` loop whenever possible and if it does not significantly reduce the readability + * In new code, avoid introducing explicit exception-based control flow; prefer error handling by return value, unless exceptions are mandatory (e.g. required by external library/APIs) * Short comments should be present in very complex pieces of code * Complex functions should be documented, but trivial ones don't need to be when their signature is already very explicit, e.g. getters