Add dynamo-release-notes skill, trim dynamo-content-designer

.claude/skills/dynamo-content-designer/SKILL.md

@@ -1,19 +1,20 @@
 ---
 name: dynamo-content-designer
-description: Technical writing specialist for Dynamo product documentation, blog posts, tutorials, educational content, release notes, and release documentation. Use when the user mentions writing documentation, blog posts, Primer articles, release notes, feature documentation, or starting a substantial writing task.
+description: Technical writing specialist for Dynamo product documentation, blog posts, tutorials, and educational content. Use when the user mentions writing documentation, blog posts, Primer articles, feature documentation, or starting a substantial writing task. For release notes specifically (curating, drafting, and publishing the wiki Release-Notes page), use the dynamo-release-notes skill instead.
 metadata:
   version: "1.0"
 ---
 
 # Dynamo Content Designer
 
-You are a Content Designer on the Dynamo team specializing in product documentation, blog posts, educational content for users, and content about new releases including release notes. Your role is to transform complex technical concepts into clear, engaging, and accessible written content.
+You are a Content Designer on the Dynamo team specializing in product documentation, blog posts, and educational content for users. Your role is to transform complex technical concepts into clear, engaging, and accessible written content.
 
 ## Trigger Conditions
 
 - User mentions writing documentation: "write a doc", "write an error message", "create a tutorial", "write up", "draft content"
-- User mentions specific doc types: "blog post", "Primer article", "release notes", "feature documentation," "notification message"
+- User mentions specific doc types: "blog post", "Primer article", "feature documentation," "notification message"
 - User seems to be starting a substantial writing task
+- If the request is specifically about release notes, use the `dynamo-release-notes` skill instead — it covers the full curation-to-publish workflow, not just the writing.
 
 ---
 
@@ -25,7 +26,6 @@ You are a Content Designer on the Dynamo team specializing in product documentat
 - Create comprehensive documentation that serves multiple audiences
 - Develop tutorials and guides that enable practical learning
 - Structure narratives that maintain reader engagement
-- Write clear release documentation including release notes and "What's New" content that contains succinct and relevant information for users
 
 ### Audience Adaptation
 
@@ -75,7 +75,7 @@ Load the relevant reference when working on that content type.
 | Content Type | When to Use | Reference |
 |-------------|-------------|-----------|
 | **UI content** | Error messages, notifications, labels, tooltips | [UI content guidelines](./assets/ui-content.md) |
-| **Release notes** | Release notes, "What's New" items | [Release notes](./assets/release-notes.md) |
+| **Release notes** | Release notes, "What's New" items | Use the `dynamo-release-notes` skill for the full curation-to-publish workflow |
 | **Node descriptions** | Node tooltips, documentation browser short and in-depth descriptions | [Node descriptions](./assets/node-descriptions.md) |
 | **Node errors and warnings** | In-graph error and warning copy | [Node errors and warnings](./assets/node-errors-warnings.md) |
 | **Feature documentation** | In-product help, procedures | [Feature documentation](./assets/feature-documentation.md) |

.claude/skills/dynamo-release-notes/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: dynamo-release-notes
+description: Curate, sweep, draft, cross-check, and publish the "### {version}" section
+of the Dynamo GitHub wiki Release-Notes page, starting from the raw
+ReleaseNotes_{X.Y.Z}.md generator dump. Use when compiling release notes for a Dynamo
+release, deciding which PRs belong in a release's notes, or inserting/updating content
+on the Release-Notes wiki page (https://github.com/DynamoDS/Dynamo/wiki/Release-Notes).
+---
+
+# Dynamo Release Notes
+
+## When to use
+
+- Turning a raw `ReleaseNotes_{X.Y.Z}.md` generator dump (or an equivalent PR list) into
+  a publishable wiki section for a Dynamo release — major, minor, or patch.
+- Deciding whether a specific PR belongs in a release's notes, or which section
+  (Features / Enhancements / Bug Fixes / Security Fixes) it belongs in.
+- Inserting or correcting content on the live `DynamoDS/Dynamo` wiki's Release-Notes page.
+
+## When not to use
+
+- Writing or polishing release-notes *prose in isolation*, with the PR list already
+  decided and no publishing step involved — use `dynamo-content-designer` and its
+  [style guide](./assets/style-guide.md) directly.
+- Any other content type (node descriptions, UI strings, blog posts, tutorials) — those
+  stay with `dynamo-content-designer`.
+
+## Inputs expected
+
+- The target version number (e.g. `4.2.0`).
+- The raw source: `ReleaseNotes_{X.Y.Z}.md` (produced by `PushRelease`'s
+  `GENERATE_RELEASE_NOTES=on` stage running `scripts/generate-release-notes.ps1`), or an
+  equivalent raw PR list for the version if that artifact wasn't generated.
+- Whether this is a major/minor or patch release (changes which prior-release baseline
+  applies to the bug-inclusion rule below).
+- Access to the public `DynamoDS/Dynamo` wiki repo, and — for internal ticket/PR
+  cross-refs (e.g. DYN tickets whose PRs live on `git.autodesk.com`) — access to that GHE
+  instance.
+
+## Output format
+
+The finalized `### {version}` wiki section, live on
+`https://github.com/DynamoDS/Dynamo/wiki/Release-Notes`, verified post-push against a
+fresh fetch of the page.
+
+---
+
+## Workflow
+
+1. **Orient before starting.** This skill may be run by someone other than its author —
+   don't assume the caller already knows the process. Summarize the steps below, then
+   ask two things: (a) proceed with the process as written, or adjust it first; (b)
+   confirm the version number, the raw source file, and the release type. Treat this as
+   a standing checkpoint on every run, not a one-time question.
+2. **Curate the raw dump.** Apply the rules in
+   [curation-rules.md](./assets/curation-rules.md): collapse revert/reapply churn on the
+   same ticket to its net behavior change, drop internal/build/test/version-bump-only
+   entries, and apply the shipped-baseline bug rule (a bug fix belongs in the notes only
+   if the underlying bug existed in an already-*shipped* release — bugs introduced and
+   fixed entirely within the current dev cycle are excluded regardless of beta exposure).
+3. **Run the sweeps** — security-fix identification, breaking-changes, external-contributor
+   credit, and category QA. These are independent of each other and of step 2's
+   line-by-line curation, so fan them out in parallel (subagents) rather than running
+   serially. Details and the contractor-vs-community-contributor distinction are in
+   [curation-rules.md](./assets/curation-rules.md).
+4. **Flag, don't guess.** Any inclusion, exclusion, or categorization call that isn't
+   clear-cut from the raw PR text goes into an explicit "needs a call" list for the
+   requester to decide. Never silently resolve ambiguity — this mirrors
+   `dynamo-content-designer`'s "never hallucinate, always ask" rule, applied to editorial
+   judgment calls instead of prose.
+5. **Draft the prose** per `dynamo-content-designer`'s writing principles and the
+   [style guide](./assets/style-guide.md) — past-tense verb, neutral tone, no internal
+   jargon, one sentence per bullet where possible. Format: `### {version}` heading, then
+   `#### Features` / `#### Enhancements` / `#### Bug Fixes` / `#### Security Fixes`
+   (only sections with content), each item as `> * <sentence>. [PR](url)`.
+6. **Cross-check against everything already published** — not just the immediately
+   preceding version. Diff every candidate PR number against the *entire* existing
+   `Release-Notes.md` content, all prior version sections. The raw generator only knows
+   whether a PR was cherry-picked into this release's RC branch; it has no concept of "this
+   PR's fix already shipped under an earlier patch release that also branched from
+   `master` in the same window." Drop exact matches. This step exists because it caught 5
+   duplicate PRs in the 4.2.0 pass that the generator's own tags completely missed — see
+   `curation-rules.md` and DynaNotes `DynamoRelease/improvement-plan.md` item **C19**.
+7. **Validate links and content.** For every cited PR: confirm the link resolves, and
+   confirm the bullet text matches the PR's own `### Release Notes` body field — not just
+   its title. Titles are sometimes misleadingly narrow (e.g. a title mentioning one
+   template when the PR's actual described scope covers four).
+8. **Insert into the live wiki.** Follow
+   [wiki-publish-plumbing.md](./assets/wiki-publish-plumbing.md) exactly. The wiki repo
+   contains a Windows-invalid filename that breaks any git operation touching the full
+   index or working tree — normal clone/checkout/add/reset will fail or, worse, silently
+   stage the entire wiki as deleted. Run `git status` immediately before creating the
+   commit and confirm it shows only the intended single-file change. **Ask the requester
+   to explicitly confirm before pushing** — a wiki push has no PR or review gate and is
+   immediately live and public.
+9. **Verify post-push.** Re-fetch the raw page and diff it against the pre-push version;
+   confirm only the intended lines changed anywhere on the page.
+10. **Retro.** Ask the requester whether anything about this run should change the skill
+    itself — a new gotcha, a rule that needs adjusting, a step that was unclear or
+    missing. If yes, update this skill and its assets now, while the detail is fresh,
+    rather than deferring it to "someday."
+
+## Boundaries
+
+- ✅ **Always**: run the full curate → sweep → flag → cross-check → validate pipeline
+  before drafting is considered final; run `git status` before any commit-equivalent step
+  in a wiki clone; re-verify the page after every push.
+- ⚠️ **Ask first**: any PR whose inclusion/exclusion/category isn't clear-cut (flag,
+  don't guess); crediting or omitting an external contributor when authorship is
+  ambiguous; pushing the finalized section to the live wiki.
+- 🚫 **Never**: run whole-index git operations (`git add -A`, `git reset`, `git checkout .`,
+  a normal `git clone`) against a local clone of the `Dynamo.wiki` repo — see
+  `wiki-publish-plumbing.md` for why and what to use instead. Never skip the step 6
+  duplicate-publication cross-check. Never skip the pre-push confirmation.
+
+## Assets & References
+
+- **[curation-rules.md](./assets/curation-rules.md)** — dedup/inclusion rules, the four
+  sweeps, and the C19 duplicate-publication cross-check in detail.
+- **[style-guide.md](./assets/style-guide.md)** — sentence-level style rules and good
+  examples for release-note bullets (moved here from `dynamo-content-designer`, which now
+  redirects release-notes requests to this skill).
+- **[wiki-publish-plumbing.md](./assets/wiki-publish-plumbing.md)** — the exact git
+  plumbing recipe for safely editing the `Dynamo.wiki` repo on Windows.

.claude/skills/dynamo-release-notes/assets/curation-rules.md

@@ -0,0 +1,94 @@
+# Curation Rules
+
+## The raw generator is a starting point, not a filter
+
+`scripts/generate-release-notes.ps1` lists every PR merged to `master` within a date
+window, tagged `[CP: ]` (cherry-picked into the RC branch), `[NO CP]`, or `[DIRECT RC]`.
+None of these tags mean "user-facing" or "belongs in this release":
+
+- Plenty of `[NO CP]` entries are real user-facing work that shipped pre-RC.
+- Plenty of `[CP: ]` entries are internal-only (version bumps, test-only fixes).
+- The tags say nothing about whether the fix already shipped under an *earlier* release —
+  see the duplicate-publication check below.
+
+Treat the raw dump as "everything to triage," never as "everything to include."
+
+## Dedup and drop
+
+- **Collapse revert/reapply churn.** A ticket that appears multiple times because a fix
+  was reverted and reapplied (or reworked) within the window collapses to one bullet
+  describing the final net behavior change.
+- **Drop internal/build/test/version-bump-only entries.** Pure version bumps,
+  test-only fixes, CI/pipeline changes, and other non-user-facing churn don't belong in
+  user-facing release notes, regardless of CP tag.
+
+## Shipped-baseline bug-inclusion rule
+
+A bug fix belongs in this release's notes only if the underlying bug existed in an
+already-*shipped* release (a version that real users have run). Bugs introduced and
+fixed entirely within the current development cycle are excluded — **regardless of beta
+exposure** (a bug only ever seen in a beta build doesn't count as "shipped" for this
+purpose, since betas aren't the general release population).
+
+Rationale: users reading the notes for "what changed since the last release you had"
+shouldn't see a bug fix for a bug they never could have hit.
+
+## Security-fix identification
+
+Look for: CVE references, fixes tagged as closing a CA2327/CA2328/CA2329/CA2330 analyzer
+violation (see `.claude/rules/dynamo-core-rules.md`), credential/secret-handling fixes,
+injection-class fixes, or anything the PR itself explicitly calls a security fix. When in
+doubt, ask the requester rather than silently bucketing it as a plain Bug Fix — security
+fixes get their own `#### Security Fixes` section.
+
+## Breaking-changes sweep
+
+A minor or patch release should have **zero** breaking changes by definition. Check
+`PublicAPI.Unshipped.txt`/`PublicAPI.Shipped.txt` diffs for any removed or renamed public
+member within the window. If you find one, don't fold it quietly into a Bug Fixes bullet
+— flag it explicitly to the requester as a process question (why did a breaking change
+land in a minor/patch cycle?), separate from the normal editorial "needs a call" list.
+
+## External-contributor credit sweep
+
+Identify commit/PR authors outside the normal Autodesk employee set. For each one, do
+**not** assume from username or profile alone whether they're:
+
+- A genuine external community contributor (credit them).
+- An employee of an agency contracted by Autodesk to work on Dynamo (no separate
+  attribution — they're effectively internal for this purpose, even though their commits
+  don't come from an autodesk.com-affiliated account).
+- A bot (e.g. Copilot) — exclude entirely, never credit.
+
+Ask the requester to confirm anyone not already known to be one of the three. This
+distinction has to be re-confirmed per release, since contractor engagements and
+community-contributor rosters both change over time.
+
+## Category QA pass
+
+Re-check the raw generator's bucketing — it doesn't reason about category, only about CP
+status. Use:
+
+- **Features** — a wholly new capability.
+- **Enhancements** — an improvement to existing, already-shipped capability.
+- **Bug Fixes** — corrects behavior that was wrong relative to intent.
+- **Security Fixes** — closes a security gap (see above).
+
+## Duplicate-publication cross-check (C19)
+
+Before finalizing, diff every candidate PR number against the **entire** existing
+`Release-Notes.md` content — every prior version section on the wiki page, not just the
+one immediately before this release. The raw generator's date-window logic doesn't
+exclude PRs whose fixes already shipped under an intermediate patch release that also
+branched from `master` within the same window.
+
+This caught 5 duplicate PRs in the 4.2.0 pass (already published, verbatim, under
+`### 4.1.1`) that the generator's own CP tags gave no signal about at all — the PRs
+looked like ordinary new `[NO CP]`/`[CP: ]` entries for 4.2.0 with nothing to distinguish
+them. Drop any exact match. See DynaNotes `DynamoRelease/improvement-plan.md` item
+**C19** for the full incident writeup.
+
+## When something doesn't fit these rules
+
+Add it to the "needs a call" list rather than guessing, and — once resolved — consider
+whether the rule set here needs updating for next time (see the skill's Retro step).