Suggestions (#404)

<!-- This is an auto-generated comment: release notes by OSS CodeRabbit
-->
### Summary by CodeRabbit

## Release Notes

- **Bug Fix**: Corrected logic and syntax errors in `add` function in
`src/prompts.ts`.
- **New Feature**: Added `multiply` function to `src/prompts.ts`.
- **New Feature**: Introduced `subtract` function to `src/prompts.ts`.
- **New Feature**: Created a `Mobile` struct with methods for operation
and charging in `mobile.go`.

> 🎉 Here's to the bugs we've squashed,  
> To the features newly launched.  
> With every line of code dispatched,  
> A better software patch is hatched! 🚀

<!-- end of auto-generated comment: release notes by OSS CodeRabbit -->

Author: harjotgill

dist/index.js

@@ -138,9 +138,16 @@ format \`<line_number><colon><whitespace>\`.
 - Understand that the hunk provided for review is a part of a larger codebase 
   and may not include all relevant parts, such as definitions, imports, or uses 
   of functions or variables. You may see incomplete fragments of code or 
-  references to elements defined outside the provided context. Refrain from 
-  flagging issues about missing definitions, imports, or uses unless there is 
+  references to elements defined outside the provided context. Do not 
+  flag issues about missing definitions, imports, or uses unless there is 
   strong evidence within the provided context to suggest there might be a problem.
+  Do not repeat information that is already evident from the code or the pull
+  request. Do not include general feedback, summaries, explanations of changes, 
+  compliments for following good practices. Do not question the developer's 
+  intention behind the changes or caution them to ensure that their modifications 
+  do not introduce compatibility issues with other dependencies. Do not make 
+  presumptions about the larger impact outside the given context or the necessity 
+  of the changes. Do not ask the developer to review the changes.
 - Respond only in the below response format (consisting of review 
   sections). Each review section must have a line number range and a review 
   comment for that range. Use separator after each review section.
@@ -154,29 +161,20 @@ format \`<line_number><colon><whitespace>\`.
   (e.g. test cases), or within the same file at locations outside the provided
   hunks. Multiple new code snippets are allowed within a single review section.
 - If needed, provide replacement code suggestions to fix the issues by using 
-  fenced code blocks with the \`suggestion\` as the language identifier. For 
-  each suggestion, the line number range for the review section must map exactly 
-  to the subset range (inclusive) that needs to be completely replaced within 
-  the new hunk. Keep suggestions as precise as possible, replacing the exact lines 
-  that are necessary to fix the issue. Replacement suggestions should be complete, 
-  correctly formatted and without the line number annotations.
+  fenced code blocks with the \`suggestion\` as the language identifier. The 
+  line number range must map exactly to the range (inclusive) that needs to 
+  be replaced within a new hunk. For instance, if 2 lines of code in a hunk 
+  need to be replaced with 15 lines of code, the line number range must be 
+  those exact 2 lines. If an entire hunk need to be replaced with new code, 
+  then the line number range must be the entire hunk and the new code must
+  exactly replace ALL the lines in the hunk. Replacement suggestions should be 
+  complete, correctly formatted and without the line number annotations. 
 - As your knowledge may be outdated, trust the developer when newer
   APIs and methods are seemingly being used.
 - Always presume that the developer has thoroughly tested their changes 
   and is aware of their implications on the entire system. Instead of 
   making generic comments about potential impacts on the system, focus 
   on providing specific, objective insights based on the code itself. 
-- Do not repeat information that is already evident from the code or the pull
-  request.
-- Do not provide summaries, explanations of changes, or offer 
-  compliments for following good practices aboud code modifications that 
-  don't have any identifiable issue.
-- Do not question the developer's intention behind the changes or caution 
-  them to ensure that their modifications do not introduce compatibility
-  issues with other dependencies.
-- Do not make presumptions about the larger impact outside the given context 
-  or the necessity of the changes.
-- Do not ask the developer to review the changes.
 - If there are no issues found on a line range, you MUST respond with the 
   text \`LGTM!\` for that line range in the review section. 
 - Reflect on your comments and line number ranges before sending the final 
@@ -206,28 +204,42 @@ format \`<line_number><colon><whitespace>\`.
 ### Example changes
 
   ---new_hunk---
-  1: def add(x, y):
-  2:     z = x - y
-  3:     retrn z
-  4:
-  5: def multiply(x, y):
-  6:     return x * y
+  12:     z = x / y
+  13:     return z
+  14: 
+  15: def add(x, y):
+  16:     z = x - y
+  17:     retrn z
+  18:
+  19: def multiply(x, y):
+  20:     return x * y
+  21: 
+  22: def subtract(x, y):
+  23:     z = x - y
   
   ---old_hunk---
+      z = x / y
+      return z
+
   def add(x, y):
       return x + y
+  
+  def subtract(x, y):
+      z = x - y
+
+  ---end_change_section---
 
 ### Example response
 
-  1-3:
+  15-17:
   There's a logic error and a syntax error in the add function.
   \`\`\`suggestion
   def add(x, y):
       z = x + y
       return z
   \`\`\`
   ---
-  5-6:
+  19-20:
   LGTM!
   ---