Pr Description

PR Description Generator

When to use this skill

Use this skill when:

• The user asks to update the PR description
• Working with an active pull request that needs a description
• Creating documentation for code changes in a PR
• Following the repository's GitHub template standards

Workflow

1. Gather PR Context

First, get the active pull request details:

• Use github-pull-request_activePullRequest to retrieve PR information
• Analyze all file changes (additions, deletions, modifications)
• Identify related issues or Jira tickets (format: SMR-XXX)
• Note the target merge branch (usually main)

2. Analyze Changes

Categorize the changes by:

• Type: Use repository-defined PR types from lint-pr.yml
• Scope: Use repository-defined scopes from lint-pr.yml
• Technology stack: Java/Spring Boot, TypeScript/Angular, Python, etc.
• Breaking changes: API modifications, schema changes
• Configuration: build files, application properties
• Database: migrations, schema modifications

3. Generate Description

Create the PR description using this exact template structure:

## Description

[2-4 sentences explaining WHY these changes were made and the business/technical impact. Focus on the objective and benefits, not just what changed.]

## Related Issue

[If applicable, link to Jira ticket or GitHub issue]
Fixes [ISSUE-NUMBER](link-to-issue)

## Changelog

[CRITICAL: Use flat, single-level bullets with NO sub-items]
[Keep items high-level and coarse-grained - avoid excessive detail]
[Group related low-level changes into one high-level bullet]
[Aim for 3-7 bullet points total]

- [High-level change description]
- [High-level change description]
- [Continue for major changes only...]

## Preview

The [component/service/application] now has:

[CRITICAL: Use flat, single-level bullets with NO sub-items]
[Keep items high-level - focus on major outcomes and benefits]
[DO NOT use checkmark emojis (✅) or green checkboxes]
[Use simple bullet points with dashes (-)]

- [Major improvement or feature outcome]
- [Major improvement or feature outcome]
- [Continue for key accomplishments only...]

Content Guidelines

Description Section

• Start with the primary business or technical objective
• Explain the motivation behind changes
• Highlight main benefits or improvements
• Mention architectural or design decisions if significant
• Keep concise but comprehensive (2-4 sentences)

Related Issue Section

• Always search for related Jira tickets (SMR-XXX format)
• Include GitHub issue numbers if applicable
• Use proper linking format: [ISSUE-NUMBER](full-url)
• Omit this section if no related issue exists

Changelog Section

CRITICAL RULES:

• Use ONLY single-level flat bullets with NO nested items
• Keep items coarse-grained and high-level
• Avoid excessive technical detail or implementation specifics
• Group multiple related low-level changes into one bullet
• Use imperative form: "Add feature X", "Remove deprecated Y"
• Order from most to least important
• Aim for 3-7 bullet points total, not an exhaustive list
• DO NOT list individual file changes

Preview Section

CRITICAL RULES:

• Use ONLY single-level flat bullets with NO nested items
• Keep items coarse-grained - focus on major outcomes
• DO NOT use checkmark emojis (✅) or any emojis
• Use simple bullet points with dashes (-)
• Focus on end results and benefits from user/system perspective
• Highlight key improvements, features, or fixes
• Mention metrics if applicable (test coverage, performance)
• Aim for 3-5 bullet points describing major accomplishments

Technology-Specific Details

For Java/Spring Boot Changes

Include when relevant:

• JPA entity modifications
• Database schema changes
• Spring configuration updates
• Dependency updates (Gradle/Maven)
• Test infrastructure changes

For TypeScript/Angular Changes

Include when relevant:

• Component updates
• Service modifications
• Configuration changes (tsconfig, angular.json)
• Dependency updates
• Build system changes

For Python Changes

Include when relevant:

• Library/package updates
• Configuration changes (pyproject.toml)
• Dependency updates
• Test infrastructure

For Database Changes

Include when relevant:

• Migration files
• Schema modifications
• Index changes
• Constraint updates

Quality Checklist

Before finalizing:

• All major file changes are documented at high level
• Technical terminology is accurate
• Related issues are properly linked
• Changelog items are specific but coarse-grained
• Preview items highlight actual benefits
• NO checkmark emojis in Preview section
• NO nested bullets in Changelog or Preview
• Grammar and formatting are correct
• Description follows exact template structure
• Business value is clearly communicated
• Only 3-7 bullets in Changelog
• Only 3-5 bullets in Preview

Example Usage

When the user says:

• "Update the PR description"
• "Generate a PR description"
• "Create documentation for this PR"

Follow the workflow above and generate a comprehensive description using the template.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.