diff --git a/action.yml b/action.yml index fec20964..c2fc4d76 100644 --- a/action.yml +++ b/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 diff --git a/src/prompts.ts b/src/prompts.ts index 7302cf80..32167d85 100644 --- a/src/prompts.ts +++ b/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