move poem to the summary message

action.yml

@@ -206,33 +206,30 @@ inputs:
     required: false
     description: 'The prompt for final summarization response'
     default: |
-      Provide your final response in the `markdown` format with 
-      the following content:
-        - *Walkthrough*: A high-level summary of the  
-          overall change instead of specific files within 80 words.
-        - *Changes*: A table of files and their summaries. You can group 
-          files with similar changes together into a single row to conserve
-          space.
+      Provide your final response in markdown with the following content:
+
+      - **Walkthrough**: A high-level summary of the overall change instead of 
+        specific files within 80 words.
+      - **Changes**: A markdown table of files and their summaries. Group files 
+        with similar changes together into a single row to save space.
+      - **Poem**: Below the changes, include a whimsical, short poem written by 
+        a rabbit to celebrate the changes. Format the poem as a quote using 
+        the ">" symbol and feel free to use emojis where relevant.
+
+      Avoid additional commentary as this summary will be added as a comment on the 
+      GitHub pull request. Use the titles "Walkthrough" and "Changes" and they must be H2.
 
-      Avoid additional commentary as this summary will be added as a 
-      comment on the GitHub pull request.
   summarize_release_notes:
     required: false
     description:
       'The prompt for generating release notes in the same chat as summarize
       stage'
     default: |
-      Create concise release notes in `markdown` format for this pull request, 
-      focusing on its purpose and user story. You can classify the changes as 
-      "New Feature", "Bug fix", "Documentation", "Refactor", "Style", 
-      "Test", "Chore", "Revert", and provide a bullet point list. For example: 
-      "New Feature: An integrations page was added to the UI". Keep your 
-      response within 50-100 words. Avoid additional commentary as this response 
-      will be used as is in our release notes.
-
-      Below the release notes, generate a short, celebratory poem about the 
-      changes in this PR and add this poem as a quote (> symbol). You can 
-      use emojis in the poem, where they are relevant.
+      Craft concise release notes for the pull request. 
+      Focus on the purpose and user impact, categorizing changes as "New Feature", "Bug Fix", 
+      "Documentation", "Refactor", "Style", "Test", "Chore", or "Revert". Provide a bullet-point list, 
+      e.g., "- New Feature: Added search functionality to the UI". Limit your response to 50-100 words 
+      and emphasize features visible to the end-user while omitting code-level details.
   language:
     required: false
     description: ISO code for the response language

src/prompts.ts

@@ -99,63 +99,26 @@ $description
 $short_summary
 \`\`\`
 
-## Instructions
-
-The format for changes provided in the example below consists of 
-multiple change sections, each containing a new hunk (annotated with 
-line numbers), an old hunk, and optionally, existing comment chains. 
-Note that the old hunk code has been replaced by the new hunk. Some 
-lines on the new hunk may be annotated with line numbers.
-
-Your task is to meticulously perform line-by-line review of new hunks, 
-identifying substantial issues only. Respond only in the below example 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. 
-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.
-Provide the exact line number range (inclusive) for each review comment. To leave 
-a review comment on a single line, use the same line number for start and end.
-
-Take into consideration the context provided by old hunks, comment threads, and 
-file content during your review. Remember, the hunk under review is a fragment of a 
-larger codebase and may not show all relevant sections, such as definitions, 
-imports, or usage of functions or variables. Expect incomplete code fragments or 
-references to elements defined beyond the provided context. Do NOT flag missing 
-definitions, imports, or usages unless the context strongly suggests an issue. 
-Do NOT restate information readily apparent in the code or the pull request. 
-Do NOT provide general feedback, summaries, explanations of changes, or praises 
-for making good additions. Do NOT question the developer's intentions behind the 
-changes or warn them about potential compatibility issues with other dependencies. 
-Avoid making assumptions about broader impacts beyond the given context or the 
-necessity of the changes. Do NOT request the developer to review their changes. 
-Given your knowledge may be outdated, it is essential to trust the developer when 
-they appear to utilize newer APIs and methods. Presume the developer has 
-exhaustively tested their changes and is fully aware of their system-wide 
-implications. Focus solely on offering specific, objective insights based on the 
-actual code and refrain from making broad comments about potential impacts on 
-the system.
-
-Use GitHub flavored markdown format for review comment text 
-and fenced code blocks for code snippets using the relevant 
-language identifier. Do NOT annotate the code snippet with 
-line numbers. The code snippet must be correctly 
-formatted & indented.
-
-If applicable, you may provide a replacement snippet to fix 
-issues within a hunk by using \`diff\` code blocks, clearly 
-marking the lines that need to be added or removed with \`+\` 
-and \`-\` annotations. The line number range for the review 
-comment that includes a replacement snippet must precisely map 
-to the line number range that has to be completely replaced 
-within a hunk. Do NOT use \`suggestion\` code blocks for
-replacement snippets.
+## IMPORTANT Instructions
+
+Input: New hunks annotated with line numbers and old hunks (replaced code). Hunks represent incomplete code fragments.
+Additional Context: PR title, description, summaries and comment chains.
+Task: Review new hunks for substantive issues using provided context and respond with comments if necessary.
+Output: Review comments in markdown with exact line number ranges in new hunks. Start and end line numbers must be within the same hunk. For single-line comments, start=end line number. Must use example response format below.
+Use fenced code blocks using the relevant language identifier where applicable.
+Don't annotate code snippets with line numbers. Format and indent code correctly.
+Do not use \`suggestion\` code blocks.
+For fixes, use \`diff\` code blocks, marking changes with \`+\` or \`-\`. The line number range for comments with fix snippets must exactly match the range to replace in the new hunk.
+
+- Do NOT provide general feedback, summaries, explanations of changes, or praises 
+  for making good additions. 
+- Focus solely on offering specific, objective insights based on the 
+  given context and refrain from making broad comments about potential impacts on 
+  the system or question intentions behind 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 thoroughly before posting them to 
-ensure accuracy and compliance with the above guidelines.
-
 ## Example
 
 ### Example changes