Another iteration on What's new prompt (#47976)

* Another iteration on What's new prompt

Go through the comments on the What's new in .NET 10 Preview 7 PR, and update the prompt for What's new issues so that Copilot improves.

There are four main themes:

- Don't separate features by preview build.
- Use includable snippets for samples more than 6 lines.
- Translate any marketing speak (first person announcements and such) to technical information in 2nd person.
- Follow the general guidelines for all edits pertaining to style and form.

* Apply suggestions from code review

Co-authored-by: Genevieve Warren <[email protected]>

---------

Co-authored-by: Genevieve Warren <[email protected]>

Author: BillWagner

.github/prompts/whats-new-net.md

@@ -27,18 +27,35 @@ For preview releases, the path is `<major-release>/preview/preview<n>` where:
 
 The primary release notes are in the `README.MD` file in that folder.  That file contains links to other release notes for components of .NET: libraries, runtime, SDK, languages, and so on. Use all that information for source.
 
+The source files you use are release notes from the product team. These take the form of announcements, so you should edit any incorporated content per the following guidelines:
+
+- Remove any 1st person references (we, us, our), and rewrite that information in the 2nd person: Tell the reader what the reader can do, using "you" to refer to the reader.
+- Remove any marketing and promotional language. These articles provide technical information, not marketing copy.
+
 ## Updates for each file
 
+Each file should be organized to provide a cohesive story about "What's new" in the release. When you edit:
+
+- The introductory paragraph states when the last update was made (Preview N, general release, any service release). That is the only mention of the latest minor, patch, or preview version.
+- If one of the areas (SDK, libraries, or runtime) doesn't have any updates for the current release (preview, RC, or GA), update the introductory paragraph and ms.date value, without making any other changes.
+- Each file should organize updates by feature area, not by when an update was made. In other words, starting with the 2nd preview, incorporate updates to the existing text to provide a single view of all updates made in the major release. For example, the "RC1" updates should add in updates in RC1 where it fits in the document, not make a new "RC1" section.
+- If a preview introduces a new feature that's unrelated to existing new features, add a new H2 for that feature area.
+
+In addition, follow these recommendations:
+
+- Follow the Microsoft Writing Style Guide, as noted in the `.github/copilot-instructions.md` file in this repository.
 - Each file should have its `ms.date` metadata field updated to match the date you're assigned the issue.
 - Ensure each file has the `ai-usage: ai-assisted` metadata field added.
 - Update phrasing on the latest update to reference the current release (preview, GA, or service release). Individual features shouldn't reference a given preview release, but the article should make it clear which was the last preview.
 - Search this repository for articles that have been recently updated pertaining to new features. Add links to those as you write about that feature. Or, add applicable information from the release notes into existing feature articles where it makes sense.
 - For the runtime and libraries articles, include extensive examples as well as links to recently updated articles related to the new feature. The examples should be at least as thorough as the examples from the source release notes.
 - Where applicable, the SDK article should include the samples.
 - The overview article generally doesn't include examples. Its purpose is to direct readers to more detailed information in other articles.
-- All APIs should be referenced using an `xref` style link, at least on first mention.
+- All APIs should be referenced using an `xref` style link, at least on first mention. Later mentions should be code-fenced in single back-ticks.
 - All links to article in the `dotnet/docs` repository should be file relative.
 - Spell out acronyms on first use in each file.
+- Avoid gerund form in headings.
 - In general, don't mention specific contributors or pull requests to the product repos.
+- Code snippets longer than 6 lines should be moved to a code file and included using the `:::` extension. All code files should be included in a buildable project to ensure the snippets build correctly.
 
 Next, create a pull request. In the description, include the text "Fixes #\<issue-number>", where "issue-number" is the GitHub issue number.