chore: update pull request template and skills

Author: chenjiahan

.agents/skills/create-draft-release-notes/SKILL.md

@@ -9,7 +9,7 @@ metadata:
 
 ## Overview
 
-Create a GitHub draft release when possible, organize the generated notes by conventional commit type, and save the organized body back to the draft. If `gh` cannot create or edit the draft, return the organized Markdown in the conversation with manual creation steps. Preserve each release note item exactly; only split accidentally joined bullets, move bullets into sections, and adjust headings. Add a top `## Highlights` section only when the user explicitly asks for highlights.
+Create a GitHub draft release when possible, organize the generated notes by conventional commit type, and save the organized body back to the draft. If `gh` cannot create or edit the draft, return the organized Markdown in the conversation with manual creation steps. Preserve each release note item exactly except stale release PRs; otherwise only split accidentally joined bullets, move bullets into sections, and adjust headings. Add a top `## Highlights` section only when the user explicitly asks for highlights.
 
 ## Security Notes
 
@@ -138,7 +138,7 @@ Use this when the user provides generated release note Markdown and only wants i
 node .agents/skills/create-draft-release-notes/scripts/create-draft-release-notes.mjs release-notes.md
 ```
 
-Omit the file path to read from stdin. Review that every original item still appears once and non-item sections remain.
+Omit the file path to read from stdin. Review that every retained item appears once and non-item sections remain.
 
 ## Optional Highlights Workflow
 
@@ -154,7 +154,7 @@ Write highlights before `## What's Changed`:
 - Use one `###` heading per highlight.
 - Keep each highlight to a short paragraph plus an optional fenced code example.
 - Include examples only when the API/configuration is clear.
-- Do not rewrite or reorder changelog items below `## What's Changed`.
+- Do not rewrite or reorder retained changelog items below `## What's Changed`.
 - Replace an existing top `## Highlights` block instead of adding another one.
 
 Example shape:
@@ -203,6 +203,8 @@ Keep each category in generated top-to-bottom order.
 
 ## Preservation Rules
 
+- Remove bullets that clearly identify a release PR for `$previous_tag` or an older published version, such as `release: v1.0.0` in `v1.0.1` notes; keep current-version and ambiguous items.
+- If anything is removed, list the original bullets verbatim for the user outside the release note body.
 - Do not rewrite bullet text, authors, URLs, PR numbers, package names, scopes, punctuation, or casing.
 - Do not drop comments, `**Full Changelog**`, or other non-item sections.
 - Do not add commentary to the release note itself, except for a requested `## Highlights` section.

.agents/skills/pr-creator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pr-creator
-description: Use when asked to create a pull request for this repository. It helps the PR follow the repository's branch safety rules, title convention, pull request template, and concise English writing style.
+description: Create a pull request using repository branch rules, title conventions, templates, and concise English descriptions.
 metadata:
   internal: true
 ---
@@ -17,7 +17,7 @@ metadata:
    Do not revert unrelated user changes.
    Before creating the PR, ensure the intended changes are committed and never commit directly on the default branch.
 
-3. If `.github/PULL_REQUEST_TEMPLATE.md` exists, read it and follow its structure.
+3. Read the repository's PR template when available and follow its current headings and guidance.
 
 4. Draft the PR title in the repository's standard format. If the repository uses Conventional Commits, common patterns include:
    - `feat(core): add ...`
@@ -29,20 +29,13 @@ metadata:
    - `release: v1.2.0`
 
 5. Write the PR body in concise, clear English.
-   - In `Summary`, explain the change context first: the user-facing problem, maintenance goal, or compatibility constraint that makes the change necessary.
-   - Prioritize high-signal information: public API changes, behavior changes, breaking changes, migration notes, and important compatibility implications.
-   - Then describe the main implementation change only as much as needed to understand the review.
-   - Keep the PR body concise and review-oriented: use 1-4 short standalone sentences for typical changes, covering why it matters, what changed, and any reviewer-important impact.
-   - Avoid low-signal sections such as `Test plan` or `Validation`, routine verification commands, generated file lists, or obvious implementation details unless the repository template explicitly requires them or the change has unusual validation risk.
-   - Good background examples:
-     - `This PR adds support for custom logger injection so CLI output can be isolated per instance.`
-     - `This PR fixes incorrect padding in URL labels to keep terminal output aligned across different label lengths.`
-     - `This PR updates the English docs to clarify how the extraction option works and when to enable it.`
-
-6. Fill `Related Links` with issue links, design docs, related PRs, or discussion pages.
-   If the PR upgrades an npm dependency, add a link to the upgraded version's release notes or tag page when available.
-   Example: `https://github.com/web-infra-dev/rspack/releases/tag/v1.0.0`
-   If there is no relevant link, omit the entire `Related Links` section from the PR body.
+   - Explain the problem or motivation and why it matters, then describe the approach and resulting behavior.
+   - Include API, compatibility, or migration details when they help reviewers assess the change.
+   - Keep typical descriptions to a few short sentences. Focus on the key changes rather than a file-by-file summary.
+   - Mention tests, documentation, and validation only when required by the template, central to the change, or relevant to review risk.
+
+6. Include relevant issue, discussion, or design links alongside the context they support, following the template's guidance.
+   For dependency upgrades, link to the target version's release notes or tag when available.
 
 7. Push the branch only after re-checking the branch name. Never push the default branch directly.
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,7 @@
+## Motivation
+
+<!-- Explain the problem or motivation and why it matters. Include relevant context and links to issues or discussions. -->
+
+## Changes
+
+<!-- Describe how this PR addresses the motivation and what behavior changes. Focus on the key approach rather than a file-by-file summary. -->

skills-lock.json

@@ -5,13 +5,13 @@
       "source": "rstackjs/agent-skills",
       "sourceType": "github",
       "skillPath": ".agents/skills/create-draft-release-notes/SKILL.md",
-      "computedHash": "9fa7807d607c7fb7e02795ddee2560cc190d4af791320537a66ca8b2e429d858"
+      "computedHash": "1c07601e93b35361c92cd6f067ddba3c710c27e98fd42f7b11e74b446590d1a9"
     },
     "pr-creator": {
       "source": "rstackjs/agent-skills",
       "sourceType": "github",
       "skillPath": ".agents/skills/pr-creator/SKILL.md",
-      "computedHash": "c49fcbba72894d08a34d054a00720610d19a2e87e25942aee05da09e87b268df"
+      "computedHash": "ed4ca0b83b380c9a4a350047ef5f2616c0446b2830d59e3a06839cb827fd39b4"
     }
   }
 }