|
1 | | -> **My Guiding Principles for You, my AI Coding Assistant:** |
2 | | -> |
3 | | -> **1. Communication:** Be concise, direct, and professional. Use markdown for code blocks and inline code. Explain your solution briefly and clearly. No conversational filler. |
4 | | -> |
5 | | -> **2. Code Quality:** |
6 | | -> - **Match Existing Style:** Strictly adhere to the project's existing coding style, conventions, and architecture. |
7 | | -> - **Be Idiomatic:** Write code that is natural for the language. |
8 | | -> - **Be Modular:** Encapsulate logic in reusable functions/classes. |
9 | | -> - **No Hardcoded Values:** Use constants or config variables. |
10 | | -> |
11 | | -> **3. Precision & Respect:** |
12 | | -> - **Surgical Edits:** Only modify what is absolutely necessary. **Never remove unrelated code or comments.** |
13 | | -> - **Justify Refactors:** If you suggest a refactor, explain why it's an improvement. |
14 | | -> |
15 | | -> **4. Context & Proactive Thinking:** |
16 | | -> - **Use All Context:** Analyze all provided files and project structure. |
17 | | -> - **Handle Errors:** Proactively add validation and error handling for edge cases. |
18 | | -> - **Ask Questions:** If a request is ambiguous, ask for clarification instead of guessing. |
19 | | -> |
20 | | -> **5. Best Practices:** |
21 | | -> - **Security First:** Always write secure code and sanitize inputs. |
22 | | -> - **Consider Performance:** Note any performance implications of your code. |
23 | | -> - **Justify Dependencies:** If you add a new library, explain why it's needed and how to install it. |
| 1 | +## My Guiding Principles for You, my AI Coding Assistant: |
| 2 | + |
| 3 | +### 1. Communication |
| 4 | +* Be concise, direct, and professional. |
| 5 | +* Use markdown for code blocks and inline code. |
| 6 | +* Explain your solution briefly and clearly. |
| 7 | +* No conversational filler. |
| 8 | + |
| 9 | +### 2. Code Quality |
| 10 | +* **Match Existing Style:** Strictly adhere to the project's existing coding style, conventions, and architecture. |
| 11 | +* **Be Idiomatic:** Write code that is natural for the language. |
| 12 | +* **Be Modular:** Encapsulate logic in reusable functions/classes. |
| 13 | +* **No Hardcoded Values:** Use constants or config variables. |
| 14 | + |
| 15 | +### 3. Precision & Respect |
| 16 | +* **Surgical Edits:** Only modify what is absolutely necessary. **Never remove unrelated code or comments.** |
| 17 | +* **Justify Refactors:** If you suggest a refactor, explain why it's an improvement. |
| 18 | + |
| 19 | +### 4. Context & Proactive Thinking |
| 20 | +* **Use All Context:** Analyze all provided files and project structure. |
| 21 | +* **Handle Errors:** Proactively add validation and error handling for edge cases. |
| 22 | +* **Ask Questions:** If a request is ambiguous, ask for clarification instead of guessing. |
| 23 | + |
| 24 | +### 5. Best Practices |
| 25 | +* **Security First:** Always write secure code and sanitize inputs. |
| 26 | +* **Consider Performance:** Note any performance implications of your code. |
| 27 | +* **Justify Dependencies:** If you add a new library, explain why it's needed and how to install it. |
| 28 | + |
| 29 | +--- |
| 30 | + |
| 31 | +### Naming Conventions |
| 32 | + |
| 33 | +As a repository standard, every function and variable name should use `camelCase`. |
| 34 | +* **Correct Usage:** `updatesCount = 0`, `searchForUpdates(packageManager)` |
| 35 | +* **Incorrect Usage:** `updates_count = 0`, `searchforupdates(package_manager)` |
| 36 | + |
| 37 | +Constants should be written in `UPPER_SNAKE_CASE`, using underscores for spaces: |
| 38 | +* **Example:** `SYSTEM_DEFAULT_LOCALE = "ca-ES"` |
| 39 | + |
| 40 | +--- |
| 41 | + |
| 42 | +### Type Hinting |
| 43 | + |
| 44 | +Please specify, when possible, variable data types and function return types. |
| 45 | + |
| 46 | +--- |
| 47 | + |
| 48 | +### Readability |
| 49 | + |
| 50 | +Try to add spaces and empty newlines to make code more human-readable. |
0 commit comments