Editorial polish pass for Adobe GenStudio for Performance Marketing release notes: refines only newly added ### subsections under the current ## YYYY.MM {#latest} block in help/user-guide/release-notes.md. Copywriter tone (benefit-forward, energetic but accurate), 2–3 sentences per paragraph, no procedural how-to. Preserves ExL shortcodes and doc links.
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Editorial polish pass for Adobe GenStudio for Performance Marketing release notes: refines only newly added ### subsections under the current ## YYYY.MM {#latest} block in help/user-guide/release-notes.md. Copywriter tone (benefit-forward, energetic but accurate), 2–3 sentences per paragraph, no procedural how-to. Preserves ExL shortcodes and doc links.
Polish only content the user identifies as newly added this round:
In file:### subsections under the single heading ## YYYY.MM {#latest} in help/user-guide/release-notes.md.
Do not edit the page title, intro paragraph, frontmatter, or any text under Earlier release notes (collapsible +++ blocks).
Do not edit prior ## monthly blocks or pre-existing ### in the same {#latest} section unless the user explicitly asks.
If it is unclear which ### are new, ask or use git diff / edit context before changing prose.
Pasted content: only polish markdown the user pastes when they confirm it matches those same new subsections (do not treat unrelated paste as in-scope).
Keep diffs minimal: wording and paragraph breaks only—no drive-by refactors elsewhere in the file.
Voice and tone
Write as a copywriter for product release notes: concise, scannable, and energized about new value—lead with outcomes and “what’s in it for you,” use strong verbs and crisp benefit language.
Stay accurate: no claims beyond what the feature delivers; match Experience League / Adobe tone (confident and clear, not sensationalist).
Generate excitement with specific benefits and deltas (what marketers can do now, what friction is removed)—not empty hype or unsubstantiated superlatives.
Paragraph rules
Each paragraph: 2–3 sentences. Never more than three sentences in one paragraph—if you need more, start a new paragraph.
Optional: if a paragraph still runs longer than ~3 lines in rendered docs at typical line length, split further.
Do not add
Procedural “how to” content: numbered steps, “click [!UICONTROL …] then…”, full UI walkthroughs, or tutorial phrasing. Release notes summarize what shipped and why it matters, not hands-on lessons.
Content that violates Prohibited content on the generate skill (no Jira keys, internal-only URLs, wiki-as-proof, etc.).
Remove during polish (release scheduling)
Drafts sometimes include italicized lines (_…_ or *…*) about availability—for example limited release, Summit timing, GA, broader rollout, or Beta windows. That language belongs in release management, not in polished customer-facing notes for this page.
Remove entirely those italic lines or trailing italic clauses when their primary purpose is scheduling or rollout status (including GA, limited release, Summit, or similar).
Do not strip ordinary (non-italic) sentences that describe product behavior—only scheduling copy that was set in italics as a disclaimer.
Keep the [!BADGE Beta] block when the feature is Beta; the badge is the supported pattern for Beta, not a separate italic scheduling line.
After removal, tighten surrounding prose if a paragraph now starts or ends awkwardly; do not replace removed italics with new scheduling sentences unless the user explicitly asks.
Preserve (do not strip or rewrite structurally)
[!DNL …], [!UICONTROL …], [!BADGE …], and other ExL shortcodes.
Existing relative documentation links and anchor patterns: [phrase](/help/...) on meaningful anchor text.
Verify links and shortcodes still valid; run a quick scan for internal IDs or banned patterns per Quality checks.
Quality checks
Only the agreed new### blocks under {#latest} changed; archives and older months untouched.
No new Jira-style IDs, internal wiki URLs, or “see ticket” language.
No scheduling-only italic disclaimers (GA, limited release, Summit rollout, etc.) remain in polished {#latest} subsections—those were removed per Remove during polish (release scheduling); Beta badge blocks are fine where applicable.
Paragraphs are 2–3 sentences each (max three sentences per paragraph).
Copy stays factual and aligned with the described capability.
