Upd prompt

Signed-off-by: Reshma Abdul Rahim <reshmarahim.abdul@microsoft.com>

Author: Reshrahim

scripts/blog-prompt.md

@@ -11,14 +11,16 @@ Context for the blog post generation:
 - Style and formatting guidelines: https://github.com/radius-project/blog/blob/re/ab/radblog/guide/contribution-guide.md
 
 Requirements:
-- Target audience: experienced developers, platform engineers, DevOps practitioners
+- Target audience: Application developers, platform engineers, DevOps practitioners
 - Focus on concrete functionality and implementation details with technical reasoning
 - Technical depth over marketing fluff
 - Avoid marketing language like "we're excited", "with open arms", "happy building"
 - CRITICAL: Only include information that is explicitly stated in the release notes - do not expand, infer, or add details
-- Only include code examples, configuration snippets, or commands that are explicitly mentioned in the release notes or you can verify from the Radius code or documentation
-- Do NOT make up code examples following common industry patterns from similar projects if they are not specifically mentioned in the release notes or you cannot verify them from the Radius code or documentation
+- Only include code examples, configuration snippets, or commands that are explicitly mentioned in the release notes 
+-  Only include information and code samples that you can verify from the Radius code or documentation
+- Do NOT make up code examples following common industry patterns from similar projects if they are not specifically mentioned in the release notes or docs
 - Do NOT make up documentation links - only use links that are specifically mentioned in the release notes or that you can verify from the Radius documentation
+- When including code snippets, ensure they are spaced and formatted correctly for markdown
 - If you cannot verify information from the release notes, do not include it
 - 800-1000 words of substantive technical content
 - Professional, matter-of-fact tone
@@ -30,7 +32,7 @@ Structure:
 - Direct introduction stating what's new in this release and a link to the release
 - Key Features as the main sections, with subheadings for each feature if applicable
 - Technical summary of key features with implementation details and code examples demonstrating usage within the key features. 
-- Call out breaking changes within the feature summary if applicable and NOT in a separate section.
+- Mention breaking changes within the feature summary if applicable and DO NOT create a separate section for breaking changes.
 - Conclude with this standard "Learn more and Get Involved" section:
 
 ## Learn more and Get Involved