From 9a9d07e83d8c1cba3458992707f440c624446c6d Mon Sep 17 00:00:00 2001 From: Dominik Jain Date: Mon, 27 Jul 2026 13:41:00 +0200 Subject: [PATCH] Improve system prompt (OOP principles, etc.) --- .serena/project.yml | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/.serena/project.yml b/.serena/project.yml index 4ff8806a..0e57ea7b 100644 --- a/.serena/project.yml +++ b/.serena/project.yml @@ -71,21 +71,31 @@ included_optional_tools: [] # initial prompt for the project. It will always be given to the LLM upon activating the project # (contrary to the memories, which are loaded on demand). initial_prompt: | - IMPORTANT: You use an idiomatic, object-oriented style. - In particular, this implies that, for any non-trivial interfaces, you use interfaces that expect explicitly typed abstractions - rather than mere functions (i.e. use the strategy pattern, for example). - You avoid the use of low-level data structures in all cases where an object-oriented abstraction would be more appropriate. - For simple data storage, you use dataclasses instead of dictionaries or tuples. + IMPORTANT: You use an idiomatic, object-oriented style (Java-esque principles, Pythonic syntax and constructs). - You structure function implementations into functional blocks that are separated by blank lines. - Atop each functional block, you write an elliptical phrase (starting with lower-case letter) that describes the purpose of the - block in a concise manner. + Design: + * You keep each concern in exactly one home. + A mechanism whose parts are only correct in combination is implemented as a single component/class, and its parts are private to it; + expose a minimal public surface. Java-like encapsulation: If helper functions and constants are only used by one abstraction, + make them internal to the respective class. + * You enforce invariants through structure and visibility; interfaces should not permit states the design forbids. + * For any non-trivial interfaces, you use interfaces that expect explicitly typed abstractions + rather than mere functions (i.e. use the strategy pattern, for example). + You avoid the use of low-level data structures in all cases where an object-oriented abstraction would be more appropriate. + For simple data storage, you use dataclasses instead of dictionaries or tuples. - Docstrings: You consistently use reStructuredText. + Testing: + You test externally observable behavior and guarantees, never implementation structure. - Comments: - When describing parameters, methods/functions and classes, you use a precise style, where the initial (elliptical) phrase - clearly defines *what* it is. Any details then follow in subsequent sentences. + Docstrings & Comments: + * You consistently use reStructuredText. + * You structure function implementations into functional blocks that are separated by blank lines. + Atop each functional block, you write an elliptical phrase (starting with lower-case letter) that describes the purpose of the + block in a concise manner. + * When describing parameters, methods/functions and classes, you use a precise style, where the initial (elliptical) phrase + clearly defines *what* it is. Any details then follow in subsequent sentences. + * Each piece of information appears exactly once, at the element that owns it: callers do not + explain callees' internals, and callees do not describe their callers. Pull requests: Read `mem:creating_pull_requests` when asked to participate in the creation of a pull request.