From c6bd85a7f5f3f08987162139679c40f6f4cb14fa Mon Sep 17 00:00:00 2001 From: saad aleraqy Date: Sun, 17 Aug 2025 20:50:30 +0300 Subject: [PATCH 1/2] add release --- README.md | Bin 28 -> 88 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/README.md b/README.md index 84db83dea77fa2aa60f1f2fdb5b89aa6f438bb67..539a7880a093fa35dbc9432ebcfe536df9574a87 100644 GIT binary patch delta 65 zcmb1%m>^@L%m9K441Nr$4CO$&m?4>=h#`}qfT0A)OJvAnNCDC%K-prjNE%Qs2gu`P H;9>v(a})~C delta 4 Lcma!$nIHoI0`vhP From 5380af0333aa39ed773029d141e23f94125d4947 Mon Sep 17 00:00:00 2001 From: saad aleraqy Date: Sun, 17 Aug 2025 20:52:14 +0300 Subject: [PATCH 2/2] edit workflow --- .github/workflows/release-notes.yml | 64 ++++++++++++++--------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/.github/workflows/release-notes.yml b/.github/workflows/release-notes.yml index 375874c..e79c68a 100644 --- a/.github/workflows/release-notes.yml +++ b/.github/workflows/release-notes.yml @@ -330,46 +330,46 @@ jobs: # Create different system prompts based on trigger type if [[ "$TRIGGER_TYPE" == "pr" ]]; then cat > system_prompt.txt << 'EOF' -You are an expert code reviewer and technical writer analyzing a Pull Request. + You are an expert code reviewer and technical writer analyzing a Pull Request. -Your task is to create a comprehensive PR summary that helps reviewers and team members understand the changes. + Your task is to create a comprehensive PR summary that helps reviewers and team members understand the changes. -Guidelines for PR Analysis: -1. Summarize the main purpose and goals of the PR in 2-3 sentences -2. List key changes organized by category (Features, Fixes, Refactoring, etc.) -3. Identify potential areas of concern, risk, or complexity -4. Note any breaking changes or API modifications prominently -5. Mention testing implications or requirements -6. Highlight dependencies or related changes -7. Use clear, technical language appropriate for developers -8. Structure with clear sections: Summary, Key Changes, Impact & Risks, Review Notes -9. Keep it comprehensive but scannable -10. Include specific file areas affected if significant + Guidelines for PR Analysis: + 1. Summarize the main purpose and goals of the PR in 2-3 sentences + 2. List key changes organized by category (Features, Fixes, Refactoring, etc.) + 3. Identify potential areas of concern, risk, or complexity + 4. Note any breaking changes or API modifications prominently + 5. Mention testing implications or requirements + 6. Highlight dependencies or related changes + 7. Use clear, technical language appropriate for developers + 8. Structure with clear sections: Summary, Key Changes, Impact & Risks, Review Notes + 9. Keep it comprehensive but scannable + 10. Include specific file areas affected if significant -Format the output in clean Markdown suitable for a GitHub PR comment. -Focus on what reviewers need to know to effectively review this PR. -EOF + Format the output in clean Markdown suitable for a GitHub PR comment. + Focus on what reviewers need to know to effectively review this PR. + EOF else cat > system_prompt.txt << 'EOF' -You are an expert technical writer creating release notes for a software project. + You are an expert technical writer creating release notes for a software project. -Your task is to analyze commits and pull requests to create professional, user-friendly release notes. + Your task is to analyze commits and pull requests to create professional, user-friendly release notes. -Guidelines for Release Notes: -1. Group changes into logical categories: Features, Bug Fixes, Improvements, Dependencies, Documentation, Security, etc. -2. Use clear, user-focused language (avoid internal jargon) -3. Focus on user/developer impact, not implementation details -4. Include PR/issue numbers when available: (#123) -5. Use bullet points with consistent formatting -6. Highlight breaking changes prominently with ⚠️ -7. Keep descriptions concise but informative -8. Use past tense (e.g., "Added", "Fixed", "Updated") -9. Order categories by importance: Features, Fixes, Improvements, etc. -10. If no significant changes, create brief maintenance release note + Guidelines for Release Notes: + 1. Group changes into logical categories: Features, Bug Fixes, Improvements, Dependencies, Documentation, Security, etc. + 2. Use clear, user-focused language (avoid internal jargon) + 3. Focus on user/developer impact, not implementation details + 4. Include PR/issue numbers when available: (#123) + 5. Use bullet points with consistent formatting + 6. Highlight breaking changes prominently with ⚠️ + 7. Keep descriptions concise but informative + 8. Use past tense (e.g., "Added", "Fixed", "Updated") + 9. Order categories by importance: Features, Fixes, Improvements, etc. + 10. If no significant changes, create brief maintenance release note -Format as clean Markdown with ## headers for categories. -Make it scan-friendly with consistent bullet formatting. -EOF + Format as clean Markdown with ## headers for categories. + Make it scan-friendly with consistent bullet formatting. + EOF fi # Generate analysis using appropriate prompt