// Draft MongoDB drivers release notes for a new version by fetching the corresponding release from the driver source code and adding them to the documentation. Use when asked to create release notes or What's New sections for the drivers and frameworks listed in the Workflow section.
Run local docs build checks on pending content/ changes before opening a PR. Catches broken directives, bad refs, missing includes, invalid substitutions, and indentation errors using the Snooty RST parser. Applies unambiguous fixes from a learned per-repo knowledge base, surfaces ambiguous ones, and appends new errors to a local log. Use when the user is about to commit or open a PR and the pending changes include: edits to .txt or .rst files, changes to YAML extract files in source/includes/, any file renamed/moved/ deleted in content/ (could break :ref:, literalinclude, or include paths), or snooty.toml changes. Also use when the user asks to "check the build", "test before PR", "lint the build", or wants to validate edits work. Do NOT trigger for image-only changes, code-example file edits that don't touch RST, or non-RST config files with no path impact.
Batch workflow for completing small DOCSP Jira tickets via sage-bot-beta. Selects tickets, hands them off to sage-bot-beta for implementation, polls for the resulting draft PRs, and adds staging links. Use this skill whenever the user wants to work through multiple small DOCSP Jira tickets or pick up batch work. Trigger phrases: "start tickets", "captain tickets", "do some tickets", "work on backlog", "bug tickets", "bug bash".
Help the user understand and complete their assigned DOCSP tickets for drivers. Provides a prioritized overview of all assigned tickets and suggests next steps. Use only when the user explicitly uses the slash command.
Use this skill for any Jira operation in the DOCSP project — creating, viewing, searching, updating, transitioning, commenting on, or linking tickets. Also handles follow-up ticket creation to manage scope creep. TRIGGER when: user mentions a DOCSP-XXXXX ticket number or any Jira ticket URL; user asks to view, open, check, update, transition, close, comment on, link, or search tickets; user references "the ticket", "the Jira", or "open a ticket". SKIP: GitHub issues; non-Jira platforms; questions unrelated to ticket operations.
Opens a GitHub Pull Request with the standard PR template: Description, Staging Links, and JIRA ticket. Infers the ticket from the branch name and generates staging preview URLs from changed files after the PR is created. TRIGGER when: user asks to open, create, submit, make, update, or edit a PR or pull request, or wants to refresh staging links on an existing PR.
Generate staging preview links for a MongoDB docs PR. Polls for the builder-bot deploy preview comment, then constructs page-specific URLs for changed .txt files, includes, YAML extracts, images, and TOC files. Use when you need to generate or refresh staging links for a pull request.
| name | drivers-release-notes |
| description | Draft MongoDB drivers release notes for a new version by fetching the corresponding release from the driver source code and adding them to the documentation. Use when asked to create release notes or What's New sections for the drivers and frameworks listed in the Workflow section. |
| argument-hint | <driver> <version> e.g. pymongo 4.10.1 |
This skill writes release notes for the following drivers and frameworks: C++, C, C#, Django MongoDB Backend, Hibernate, JVM (which includes Java Sync, Java Reactive Streams, Kotlin Sync, Kotlin Coroutine, Scala), Go, JavaScript (Node.js), Laravel MongoDB, Spark Connector, Entity Framework, C# Analyzer, Ruby, Rust, PyMongo, PyMongoArrow, PHP, and Mongoid. The driver and version are provided by the user. If not provided, ask the user to specify these values; do not guess or provide suggested values. If you receive a driver name that is not in the list, ask for clarification.
Note: Do not use the release-notes-base workflow, which only applies to unversioned products. This workflow is for versioned drivers that require changes made in an upcoming branch and then backported.
gh CLI installed and authenticated.references/docs-templates.md. Use these when drafting entries.| Driver | Reference file |
|---|---|
| C++ | references/cpp.md |
| C | references/c.md |
| C# | references/csharp.md |
| Django MongoDB Backend | references/django.md |
| JVM (Java Sync, Java Reactive Streams, Kotlin Sync, Kotlin Coroutine, Scala) | references/jvm.md |
| Go | references/go.md |
| Node.js | references/node.md |
| Laravel MongoDB | references/laravel.md |
| Spark Connector | references/spark.md |
| Entity Framework | references/entity-framework.md |
| C# Analyzer | references/csharp-analyzer.md |
| Ruby | references/ruby.md |
| Rust | references/rust.md |
| PyMongo | references/pymongo.md |
| PyMongoArrow | references/pymongo-arrow.md |
| PHP | references/php.md |
| Hibernate | n/a - Do not add release notes to the docs. Exit and inform the user that no changes are needed. |
| Mongoid | references/mongoid.md |
| Placeholder | Value |
|---|---|
{VERSION} | $ARGUMENTS |
{FULL_VERSION} | If {VERSION} is a patch version (e.g. X.Y.Z), use the same value. If {VERSION} is a major or minor version (e.g. X.Y), append .0 to the version (e.g. X.Y.0). |
{GITHUB_REPO} | Driver specific. See the driver reference file. |
{RELEASE_NOTES_FILE} | Driver specific. See the driver reference file. |
{CHANGELOG_LINK} | Driver specific. See the driver reference file. |
{UPGRADE_REF} | Driver specific. See the driver reference file. |
Use the Agent tool (subagent_type: Explore) to fetch the release notes from the {GITHUB_REPO} GitHub repository. Return the full list of changes.
If this returns an error, the release notes might not exist. In that case, stop and tell the user that the release information is not available.
Read the first 60 lines of {RELEASE_NOTES_FILE} to confirm the exact heading style, section labels, issue reference format, and changelog link format used by this product before drafting.
Format the new entry to match the conventions observed in step 2 and the additional instructions listed for the driver in the driver reference file. Insert the entry in the correct version-sorted position (newest version first). Do not assume the new entry belongs at the top — scan the existing headings to find where {VERSION} falls relative to other versions and insert it there, with a blank line separating it from the entry above and below. For example, see the Standard Entry Format in references/docs-templates.md.
DOCSP-<ticket number>-release-notes. If no, proceed to the next step._upcoming-breaking-changes: ref anchor immediately preceding the newest release notes section. If so, ensure that you move the ref anchor so it's above the section for the version you are adding.{+libbson+}), match the underline to the length of the rendered text.PHPLIB-1714: — extract only the meaningful description. Add detail to the description by retrieving additional context about the change in the linked ticket or PR.{VERSION} value for the heading (e.g. What's New in {VERSION}). The driver reference file includes instructions for determining the correct heading format for the driver.{CHANGELOG_LINK}. Use this syntax: "To learn more about this release, see the
:github:v{VERSION} Release Notes <{CHANGELOG_LINK}> on GitHub."A breaking change is a modification in a convention or behavior in a specific version of the driver that might prevent an application from working properly if not addressed before upgrading. If a driver has breaking changes, document them in the upgrade guide and add a warning admonition to the release notes - unless the driver-specific reference file states otherwise.
Use the templates in references/docs-templates.md when a driver has breaking changes. Follow the instructions in the driver reference file for the {UPGRADE_REF} value and for driver-specific overrides to the templates.
If there are breaking changes, add the Standard Breaking Changes Warning Admonition from references/docs-templates.md immediately following the What's New in {VERSION} header.
Create a new section in the driver's upgrade guide under the Breaking Changes header using the Standard Upgrade Guide Section template from references/docs-templates.md.
currentAfter modifying the release notes in upcoming, ask the user if they also want to apply the changes to the current version directory. The current directory is a sibling of upcoming under the same product's content/ folder (e.g., content/c-driver/current/).
If yes, use git diff and git apply to make the same changes to current:
git diff HEAD -- {RELEASE_NOTES_FILE} | \
sed 's|/upcoming/|/current/|g' | \
git apply -
If git apply fails, report the error output to the user and ask how to proceed. Verify the result by reading the patched file before reporting completion.
Report the file(s) changed and ask the user if they are ready to commit. Remind the user to complete the documentation version update, providing a link to https://wiki.corp.mongodb.com/spaces/DE/pages/201983140/How+To+Implement+Changes+for+Driver+Version+Updates, and request a technical review before publishing.
Remind the user that they can use the version-update command to update the documentation version if not already completed.
| Placeholder | Resolved value |
|---|---|
{VERSION} | 7.0 |
{FULL_VERSION} | 7.0.0 |
{GITHUB_REPO} | mongodb/node-mongodb-native |
{RELEASE_NOTES_FILE} | content/node/upcoming/source/reference/release-notes.txt |
{CHANGELOG_LINK} | mongodb/node-mongodb-native/releases/tag/v7.0.0 |
{UPGRADE_REF} | node-breaking-changes-v7.0 |
For the finished RST output, see Full Example: Node.js 7.0 in references/docs-templates.md.