update prompts (#385)

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

```
**Documentation:**
- Updated the instructions in `action.yml` to clarify the scope of code review.
- Revised response instructions and formatting guidelines in `src/prompts.ts` to focus on significant concerns.

> 🎉 Here's to the changes, small but mighty,
> To clearer instructions, making reviews light and sprightly. 
> No more minor issues, only the grand,
> For better code quality, we make our stand! 🚀
```
<!-- end of auto-generated comment: release notes by openai -->

Author: harjotgill

action.yml

@@ -162,24 +162,12 @@ inputs:
         - Modularity
         - Complexity
         - Optimization
+        - Best practices: DRY, SOLID, KISS
 
-      Refrain from commenting on minor code style issues, missing 
-      comments/documentation, or giving compliments, unless explicitly 
-      requested. Concentrate on identifying and resolving significant 
+      Do not comment on minor code style issues, missing 
+      comments/documentation. Identify and resolve significant 
       concerns to improve overall code quality while deliberately 
       disregarding minor issues.
-
-      Other instructions: 
-      - 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 question the developer's intention behind the changes or caution 
-        them to ensure that their modifications do not introduce compatibility
-        issues with other dependencies.
-      - Never ask the developer to review the changes.
   summarize:
     required: false
     description: 'The prompt for final summarization response'

dist/index.js

@@ -124,50 +124,65 @@ hunk is of the format \`<line_number><colon><whitespace>\`.
   ---end_change_section---
   ...
 
-## Response Instructions
+## IMPORTANT: Response Instructions
 
 - Your task is to review ONLY the new hunks line by line, ONLY pointing out 
   substantive issues within line number ranges. Provide the exact line 
   number range (inclusive) for each issue. Take into account any supplementary 
   context from the old hunks, comment threads, and file contents during your 
-  review process. Concentrate on pinpointing particular problems, and refrain 
-  from offering summaries of changes, general feedback, or praise for 
-  exceptional work.
+  review process. 
 - 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 
   strong evidence within the provided context to suggest there might be a problem.
-- IMPORTANT: Respond only in the below response format (consisting of review 
+- 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. Do not include general feedback or summaries. You 
   may optionally include a single replacement suggestion snippet and/or 
-  multiple new code snippets in the review comment. Separate review sections 
-  using separators.
-- IMPORTANT: Line number ranges for each review section must be within the 
+  multiple new code snippets in the review comment. Use separator after each 
+  review section.
+- Line number ranges for each review section must be within the 
   range of a specific new hunk. <start_line_number> must belong to the same 
   hunk as the <end_line_number>. The line number range is sufficient to map 
   your comment to the code changes in the GitHub pull request.
 - Use Markdown format for review comment text and fenced code blocks for
-  code snippets. Do not annotate code snippets with line numbers.
+  code snippets.
 - If needed, provide replacement code suggestions to fix the issue by using 
   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. Each suggestion must be provided as a separate 
-  review section with relevant line number ranges.
+  exactly replace all the lines in the hunk.Replacement suggestions should be 
+  complete, correctly formatted and without the line number annotations. 
+  Each suggestion must be provided as a separate review section with relevant 
+  line number ranges.
 - If needed, suggest new code snippets using the correct language identifier 
   in the fenced code blocks. These snippets may be added to a different file 
   (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.
-- IMPORTANT: If there are no issues found on a line range, you must only 
-  respond with the text \`LGTM!\` for that line range in the review section. 
+- 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 
   response to ensure accuracy of line number ranges and replacement snippets.