You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Use CamelCase for class names. Follow PEP 8 style guidelines.
6
+
- Include type hints for function parameters and return types.
7
+
- Write docstrings for all public modules, classes, functions, and methods.
8
+
- Prefer using NumPy for numerical computations. Use vectorized operations instead of loops where possible.
9
+
- Import NumPy using the alias 'np'. Include comments explaining complex mathematical operations.
10
+
- Do **NOT** generate needless code or boilerplate.
11
+
- Do **NOT** generate functions that are used only once. Instead, inline the code if it is not reused.
12
+
- Do **NOT**, for ANY REASON, generate nested/inner functions, that means functions defined inside other functions. Always define functions either at the module level or as methods of a class.
13
+
14
+
### MANDATORY PLANNING PHASE
15
+
When working with large files (>300 lines) or complex changes:
16
+
1. ALWAYS start by creating a detailed plan BEFORE making any edits
17
+
2. Your plan MUST include:
18
+
- All functions/sections that need modification
19
+
- The order in which changes should be applied
20
+
- Dependencies between changes
21
+
- Estimated number of separate edits required
22
+
23
+
3. Format your plan as:
24
+
25
+
## PROPOSED EDIT PLAN
26
+
Working with: [filename]
27
+
Total planned edits: [number]
28
+
29
+
### MAKING EDITS
30
+
- Focus on one conceptual change at a time
31
+
- Show clear "before" and "after" snippets when proposing changes
32
+
- Include concise explanations of what changed and why
33
+
- Always check if the edit maintains the project's coding style
34
+
35
+
### Edit sequence:
36
+
1. [First specific change] - Purpose: [why]
37
+
2. [Second specific change] - Purpose: [why]
38
+
3. Do you approve this plan? I'll proceed with Edit [number] after your confirmation.
39
+
4. WAIT for explicit user confirmation before making ANY edits when user ok edit [number]
40
+
41
+
### EXECUTION PHASE
42
+
- After each individual edit, clearly indicate progress:
43
+
"✅ Completed edit [#] of [total]. Ready for next edit?"
44
+
- If you discover additional needed changes during editing:
45
+
- STOP and update the plan
46
+
- Get approval before continuing
47
+
48
+
### REFACTORING GUIDANCE
49
+
When refactoring large files:
50
+
- Break work into logical, independently functional chunks
51
+
- Ensure each intermediate state maintains functionality
52
+
- Consider temporary duplication as a valid interim step
53
+
- Always indicate the refactoring pattern being applied
0 commit comments