mcpField
R
release-notes-generation

release-notes-generation

github.com/happy-technologies-llcDevelopment4141 installsUpdated 2d ago
Repository

About release-notes-generation

This skill gathers ServiceNow change requests, user stories, and defects for a release window to produce stakeholder-ready release notes. It is intended for release teams that need categorized changes, impact details, and known issues, with an option to publish the notes as a knowledge base article.

Key features

  1. 01Aggregate and categorize release changes
  2. 02Collect stories and acceptance criteria
  3. 03Document defect fixes and root causes
  4. 04Identify known issues and workarounds
  5. 05Generate and publish release notes

Use cases

  1. 01Prepare notes for a software release or sprint
  2. 02Report fixes and changes to stakeholders
  3. 03Publish release notes as a knowledge base article

MCP support

It uses SN-Query-Table to gather release, change, story, and defect data. SN-Create-Record can publish a knowledge base article, and SN-Update-Record can update the release record.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/happy-technologies-llc/happy-platform-skills --skill release-notes-generation

After installing, type/release-notes-generationin Claude Code to confirm it loaded.

Details

From the project README

Release Notes Generation

Overview

This skill generates comprehensive release notes by aggregating data from change requests, user stories, and defect fixes associated with a given release window. It produces stakeholder-ready documentation with categorized changes, impact summaries, and known issues.

  • Query change requests within a release window and categorize by type
  • Aggregate user stories and their acceptance criteria for feature documentation
  • Collect defect fixes with root cause and impact descriptions
  • Identify known issues and workarounds carried into the release
  • Generate formatted release notes suitable for technical and non-technical audiences
  • Optionally publish release notes as a knowledge base article

When to use: When preparing for a software release, sprint delivery, or maintenance window and stakeholders need documentation of what changed, what was fixed, and what to watch for.

Prerequisites

  • Roles: itil, change_manager, release_manager, or scrum_master
  • Plugins: com.snc.change_management (Change Management), com.snc.sdlc.agile.2.0 (Agile Development 2.0, optional), com.glide.knowledge (Knowledge Management, optional)
  • Access: Read on change_request, rm_story, rm_defect, rm_release, kb_knowledge, incident
  • Knowledge: Understanding of your release cycle, change categories, and stakeholder audiences
  • Data: Change requests and/or stories/defects linked to the target release

Procedure

Step 1: Identify the Release Window

Determine the release scope by querying the release record or defining a date range.

Using MCP (Claude Code/Desktop):

Tool: SN-Query-Table
Parameters:
  table_name: rm_release
  query: number=[release_number]
  fields: sys_id,number,short_description,start_date,end_date,state,release_type,release_phase
  limit: 1

Using REST API:

GET /api/now/table/rm_release?sysparm_query=number=[release_number]&sysparm_fields=sys_id,number,short_description,start_date,end_date,state,release_type,release_phase&sysparm_limit=1

If no formal release record exists, define the window by date range:

  • Start date: Beginning of the sprint/release period
  • End date: Release deployment date
Step 2: Gather Change Requests

Query all change requests implemented within the release window.

Using MCP:

Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: stateINclosed,implemented,review^end_dateBETWEEN[start_date]@[end_date]
  fields: sys_id,number,short_description,description,type,category,risk,impact,cmdb_ci,assignment_group,close_notes,state
  limit: 100

Using REST API:

GET /api/now/table/change_request?sysparm_query=stateINclosed,implemented,review^end_dateBETWEEN[start_date]@[end_date]&sysparm_fields=sys_id,number,short_description,description,type,category,risk,impact,cmdb_ci,assignment_group,close_notes,state&sysparm_limit=100

Categorize changes:

CategoryCountDescription
New Feature5New capabilities added
Enhancement12Improvements to existing features
Bug Fix8Defect corrections
Infrastructure4Platform, server, or network changes
Security Patch3Security vulnerability remediation
Configuration6Settings or parameter changes
Step 3: Gather User Stories

If using Agile Development, retrieve completed stories for the release.

Using MCP:

Tool: SN-Query-Table
Parameters:
  table_name: rm_story
  query: release=[release_sys_id]^state=closed_complete
  fields: sys_id,number,short_description,description,acceptance_criteria,story_points,sprint,product,epic
  limit: 50

Using REST API:

GET /api/now/table/rm_story?sysparm_query=release=[release_sys_id]^state=closed_complete&sysparm_fields=sys_id,number,short_description,description,acceptance_criteria,story_points,sprint,product,epic&sysparm_limit=50
Step 4: Gather Defect Fixes

Retrieve defects fixed in this release.

Using MCP:

Tool: SN-Query-Table
Parameters:
  table_name: rm_defect
  query: release=[release_sys_id]^state=closed_complete
  fields: sys_id,number,short_description,description,severity,found_in,fixed_in,root_cause,affected_users
  limit: 50

Using REST API:

GET /api/now/table/rm_defect?sysparm_query=release=[release_sys_id]^state=closed_complete&sysparm_fields=sys_id,number,short_description,description,severity,found_in,fixed_in,root_cause,affected_users&sysparm_limit=50
Step 5: Identify Known Issues

Check for open defects or problems that persist into the release.

Using MCP:

Tool: SN-Query-Table
Parameters:
  table_name: rm_defect
  query: release=[release_sys_id]^stateNOT INclosed_complete,closed_skipped
  fields: sys_id,number,short_description,severity,workaround
  limit: 20

Also check for related incidents reported after similar past releases:

Using MCP:

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: active=true^short_descriptionLIKE[release_or_product_keyword]^sys_created_onONLast 7 days@javascript:gs.daysAgoStart(7)@javascript:gs.daysAgoEnd(0)
  fields: sys_id,number,short_description,priority,state
  limit: 10
Step 6: Generate the Release Notes Document

Compile all gathered data into a formatted release notes document:

================================================================
RELEASE NOTES
================================================================
Release: [release_number] - [release_short_description]
Date: [end_date]
Version: [version_number]
Environment: [Production / Staging / UAT]

================================================================
SUMMARY
================================================================
This release includes [X] new features, [Y] enhancements,
[Z] bug fixes, and [W] infrastructure changes.

Total Changes: [total]
Total Story Points Delivered: [points]
Risk Profile: [X] High, [Y] Moderate, [Z] Low risk changes

================================================================
NEW FEATURES
================================================================

[NFT-001] [CHG/STY number] - [Short Description]
  Description: [User-friendly description of the feature]
  Impact: [Who benefits and how]
  Configuration: [Any setup required by users/admins]
  Related KB: [KB article number if applicable]

[NFT-002] ...

================================================================
ENHANCEMENTS
================================================================

[ENH-001] [CHG/STY number] - [Short Description]
  Description: [What was improved and why]
  Before: [Previous behavior]
  After: [New behavior]

[ENH-002] ...

================================================================
BUG FIXES
================================================================

[BUG-001] [DEF number] - [Short Description]
  Severity: [Critical / High / Medium / Low]
  Symptom: [What users experienced]
  Root Cause: [What caused the defect]
  Fix: [What was changed to fix it]
  Affected Users: [Scope of impact]

[BUG-002] ...

================================================================
INFRASTRUCTURE CHANGES
================================================================

[INF-001] [CHG number] - [Short Description]
  Change Type: [Standard / Normal / Emergency]
  Impact: [Expected user impact during/after change]
  Downtime: [Any planned downtime window]

================================================================
SECURITY UPDATES
================================================================

[SEC-001] [CHG number] - [Short Description]
  Severity: [Critical / High / Medium / Low]
  CVE: [CVE number if applicable]
  Impact: [What was vulnerable and what was fixed]

================================================================
KNOWN ISSUES
================================================================

[KI-001] [DEF number] - [Short Description]
  Severity: [severity]
  Workaround: [Temporary workaround if available]
  Expected Fix: [Target release for fix]

================================================================
UPGRADE NOTES
================================================================
- [Any manual steps required after deployment]
- [Configuration changes needed]
- [Cache clears, restarts, or reindexing required]
- [Backward compatibility notes]

================================================================
ROLLBACK PLAN
================================================================
In case of critical issues:
- [Rollback procedure summary]
- Contact: [Release manager contact]
- Decision deadline: [Time by which rollback decision must be made]
Step 7: Publish Release Notes

Optionally publish the release notes as a knowledge base article.

Using MCP:

Tool: SN-Create-Record
Parameters:
  table_name: kb_knowledge
  data:
    short_description: "Release Notes - [release_number] - [date]"
    text: "[generated release notes]"
    kb_knowledge_base: [knowledge_base_sys_id]
    kb_category: Release Notes
    workflow_state: draft
    valid_to: ""

Using REST API:

POST /api/now/table/kb_knowledge
Content-Type: application/json

{
  "short_description": "Release Notes - [release_number] - [date]",
  "text": "[generated release notes]",
  "kb_knowledge_base": "[knowledge_base_sys_id]",
  "kb_category": "Release Notes",
  "workflow_state": "draft"
}
Step 8: Notify Stakeholders

Document the release notes distribution in the release record.

Using MCP:

Tool: SN-Update-Record
Parameters:
  table_name: rm_release
  sys_id: [release_sys_id]
  data:
    work_notes: "Release notes generated and published as KB article [KB_number]. Distribution: Technical teams, Change Advisory Board, Service Desk, End-user communications."

Tool Usage

ToolPurposeWhen to Use
SN-Query-TableRetrieve changes, stories, defects, release dataCore data gathering
SN-Natural-Language-SearchFind related items using natural languageSupplementary discovery
SN-Create-RecordPublish release notes as KB articleDocumentation
SN-Update-RecordUpdate release record with notes statusTracking and audit
SN-Add-Work-NotesDocument generation processAudit trail
SN-Get-Table-SchemaExplore table structuresSetup and field discovery

Best Practices

  1. Generate early, iterate often -- draft release notes as changes are implemented, not at the last minute
  2. Write for your audience -- technical details for engineering, business impact for stakeholders
  3. Group logically -- categorize by type (feature, fix, infrastructure) not by team or ticket number
  4. Always include known issues -- stakeholders trust transparency; hiding known issues erodes confidence
  5. Link to KB articles -- reference detailed documentation for features that need setup or training
  6. Version the notes -- if the release changes after notes are drafted, update and version them
  7. Include rollback information -- every release should have a documented rollback plan
  8. Automate the data gathering -- manual collection of change details is error-prone and time-consuming
  9. Validate with change owners -- have each change owner review their section for accuracy
  10. Archive consistently -- store release notes in a standard location (KB, release record) for historical reference

Troubleshooting

"No change requests found for the release window"

Cause: Changes may not have end_date populated, or they use a different date field Solution: Try querying by close_date or work_end instead. Also check if changes are linked to the release record via release field rather than date range.

"Stories have no release field populated"

Cause: Agile Development integration may not be configured to link stories to releases Solution: Query stories by sprint dates instead: sprint.end_date BETWEEN [start] AND [end]. Or query by product and state.

"Too many changes to include in release notes"

Cause: Large release window or very active environment Solution: Filter by risk level (exclude low-risk standard changes) or by application scope. Focus on customer-facing changes and summarize internal/infrastructure changes.

"Defect root_cause field is empty"

Cause: Developers did not populate root cause analysis during defect resolution Solution: Fall back to the defect description and close_notes for context. Flag empty root_cause as a process improvement item.

Examples

Example 1: Sprint Release Notes

Release: REL0023456 - Sprint 42 Delivery (2026-03-15 to 2026-03-29)

Generated Notes:

  • 3 New Features: Self-service portal redesign, Mobile app push notifications, SSO for vendor portal
  • 5 Enhancements: Improved search performance, Updated approval email templates, Dashboard load time optimization, Bulk import CSV validation, Report export to PDF
  • 4 Bug Fixes: Login timeout issue (Critical), Calendar date picker off-by-one (Medium), Report pagination error (Medium), Notification duplicate suppression (Low)
  • 1 Known Issue: PDF export occasionally truncates tables with >50 rows (workaround: export to CSV)
Example 2: Emergency Patch Release Notes

Release: REL0023457 - Emergency Security Patch (2026-03-18)

Generated Notes:

  • 1 Security Update: CVE-2026-1234 - Cross-site scripting vulnerability in form submission handler (Critical)
  • 0 New Features
  • 1 Infrastructure Change: WAF rule update to block exploit pattern pending patch deployment
  • Rollback Plan: Revert WAF rules and apply previous application version within 2-hour window
Example 3: Major Platform Upgrade Release Notes

Release: REL0023458 - Platform Upgrade v3.0 (2026-03-22)

Generated Notes:

  • 8 New Features spanning 3 modules
  • 15 Enhancements including performance and UX improvements
  • 12 Bug Fixes including 2 Critical severity
  • 3 Infrastructure Changes including database migration and cache architecture update
  • 5 Known Issues with documented workarounds
  • Upgrade Notes: 4-hour maintenance window, database backup required, cache clear after deployment, all users must re-authenticate

Related Skills

  • itsm/change-management - Change request lifecycle management
  • spm/agile-story-generation - Generate stories for next sprint
  • knowledge/article-generation - Create KB articles from release content
  • spm/acceptance-criteria - Define acceptance criteria for stories
  • itsm/suggested-steps - Resolution steps for incidents caused by releases
  • spm/planning-summarization - Sprint and release planning summaries

Comments

Markdown supported