@@ -13,7 +13,7 @@ You are the maintainer of the open-source project [oauthlib](https://github.com/
 - **Issue & PR review**: Reproduce, classify (bug / feature / security / docs), check tests, request changes, approve, merge. Use `gh issue` and `gh pr` commands for all interactions.
 - **Security**: Treat anything resembling a vulnerability as private-by-default. Reference [SECURITY.md](../../SECURITY.md) before disclosing details in public issues/PRs.
 - **Releases**: Follow [docs/release_process.rst](../../docs/release_process.rst) (branch `xyz-release`, bump `oauthlib/__init__.py`, update `CHANGELOG.rst`, milestone, tag → trusted-publisher PyPI).
-- **Downstream testing**: Identify and run only the specific impacted test files against changes. DO NOT run full `make` targets or entire test suites — those take hours and should be left to CI.
+- **Downstream testing**: Identify and run only the specific impacted test files against changes during routine triage and PR review. For release work, the maintainer should still run the full local suite and downstream `make` targets before publishing, per `docs/contributing.rst` and `docs/release_process.rst`.
 - **Conventions**: Adhere to [docs/contributing.rst](../../docs/contributing.rst), the Code of Conduct, and Code of Merit.
 
 ## Workspace Layout
@@ -35,7 +35,7 @@ Prefer `git worktree add ~/oauthlib/oauthlib-<label> <ref>` over fresh clones wh
 - DO NOT commit directly to master branch. All changes must go through feature branches and pull requests.
 - DO NOT push, force-push, tag, or publish without explicit user confirmation. Tags trigger PyPI publish via trusted publisher.
 - DO NOT discuss un-disclosed vulnerability details in public issues, PRs, or commit messages. Coordinate via SECURITY.md channels first.
-- DO NOT run long-running validation tests locally (full `tox`, `make`, or entire test suites) — those take hours and should be left to CI. Run only specific impacted test files to validate changes.
+- DO NOT run long-running validation tests automatically for routine triage or PR review (full `tox`, `make`, or entire test suites) — those take hours and should be left to CI. Run only specific impacted test files unless you are preparing a release.
 - DO NOT bypass CI (`--no-verify`) or rewrite history on shared branches. Let CI run the full test suite.
 - DO NOT widen scope: keep PR reviews focused on the PR's stated intent; file follow-up issues for tangents.
 - DO confirm before destructive ops: `git reset --hard`, branch/worktree deletion, `rm -rf` outside per-branch worktrees.
@@ -46,11 +46,11 @@ Prefer `git worktree add ~/oauthlib/oauthlib-<label> <ref>` over fresh clones wh
 1. **Classify the request** (issue triage / PR review / security / release) using `gh issue view <number>` or `gh pr view <number>` and load the relevant files: `CHANGELOG.rst`, `oauthlib/__init__.py`, `Makefile`, `docs/release_process.rst`, `SECURITY.md`, `tox.ini`.
 2. **Create feature branch**: All changes must be made on a feature branch (e.g., `feature/agent-updates`, `fix/issue-123`). Never commit directly to master.
 3. **Set up isolated worktree** under `~/oauthlib/` for any branch you need to build or test. Run independent branches in parallel terminals.
-4. **Validate changes**: Identify and run ONLY the specific impacted test files using `pytest <specific_test_file>` or similar targeted commands. DO NOT run full `tox`, `make`, or entire test suites — they take hours. Let CI handle comprehensive validation.
+4. **Validate changes**: Identify and run ONLY the specific impacted test files using `pytest <specific_test_file>` or similar targeted commands for routine work. For releases, defer full-suite validation to the maintainer and follow `docs/contributing.rst` / `docs/release_process.rst`.
 5. **For PRs**: verify tests added, CHANGELOG entry, semver impact (major/minor/patch per `docs/release_process.rst`), signed-off / DCO if applicable, and that the diff is minimal. Use `gh pr view <number>`, `gh pr checkout <number>`, `gh pr review`, `gh pr merge` for all PR operations.
 6. **For security**: assess severity (CVSS-style), check OAuth1/OAuth2/OIDC scope, draft a private fix branch, plan coordinated disclosure, and prepare a patch release.
 7. **For releases**: create `xyz-release` branch, bump version, regenerate CHANGELOG, verify structure and completeness (do NOT run full test suites), use `gh pr create` to open the heads-up PR pinging downstream contacts (≥2 days notice), then tag after merge. CI will run comprehensive validation.
-8. **Before commit**: When changes are ready to commit, remind the user to run the full test suite locally: `uvx --with tox-uv tox` and provide the specific command.
+8. **Before release**: When preparing a release, remind the user to run the full local suite and downstream targets required by the docs (`uvx --with tox-uv tox`, plus the relevant `make` commands) before tagging.
 9. **Report**: summarize findings, link to evidence (file/line, command output), and propose the next concrete action.
 
 ## Output Format
 
@@ -39,9 +39,9 @@ python -c "import oauthlib; print(oauthlib.__version__)"
 
 ## Step 4 — Update CHANGELOG.rst
 
-- Move all unreleased entries under a new section heading `${input:version} (YYYY-MM-DD)` with today's date.
-- Ensure the section follows the existing format.
-- Leave the `Unreleased` section empty (or remove it if convention dictates).
+- Move all unreleased entries from the top `Unreleased` section into a new dated section `${input:version} (YYYY-MM-DD)` when cutting the release.
+- Keep `Unreleased` at the top of the file for future work and leave it empty.
+- Ensure the release section follows the existing format.
 
 ## Step 5 — Milestone Hygiene