Skill: oschina/gitee-create-release (version 1.0.0)

--- name: create-release description: Use this skill when the user asks to publish a release, create a release, "create release", "create-release", "tag a release", or generate a changelog. Requires Gitee MCP Server to be configured. version: 1.0.0 requires: mcp-servers: - gitee --- > **Note**: If you have `mcporter` installed locally, you should use `mcporter` to invoke the MCP tool instead of directly calling the MCP tool. The `mcporter` CLI provides a more convenient interface and better error handling. # Create Release via Gitee MCP Auto-generate a changelog from merged PR history and publish a well-structured release on Gitee. ## Prerequisites - Gitee MCP Server configured (tools: `list_releases`, `list_repo_pulls`, `create_release`) - User must provide: repository owner, repository name, version number - Optional: previous version number (to determine the changelog range) ## Steps ### Step 1: Confirm the Version Number Confirm the version number with the user, following Semantic Versioning: ``` vMAJOR.MINOR.PATCH - MAJOR: incompatible API changes - MINOR: backward-compatible new features - PATCH: backward-compatible bug fixes ``` If the user hasn't provided one, suggest an appropriate version based on the nature of the changes. ### Step 2: Review Release History Use `list_releases` to retrieve existing releases: - Confirm the previous version number - Understand the version naming convention (e.g., whether a `v` prefix is used) - Avoid version number conflicts ### Step 3: Collect PR Changes Use `list_repo_pulls` to get PRs merged since the last release: - `state`: `merged` - Sort by merge time, filtering for PRs after the last release Classify each PR: - `feat` / `feature`: new feature - `fix` / `bugfix`: bug fix - `refactor`: code refactoring - `perf`: performance improvement - `docs`: documentation update - `chore`: dependency / build / toolchain changes - `breaking`: breaking change (title contains `breaking` or `!:`) ### Step 4: Analyze Code Changes As a supplement to PR titles, use `compare_branches_tags` to get a more detailed diff analysis: ``` compare_branches_tags(owner="[owner]", repo="[repo]", target="[current_branch]", base="[previous_version_tag]") ``` This returns: - Files changed (added, modified, deleted) - Commit history between versions - Code statistics (additions, deletions) Use this to understand the actual code changes behind each PR, especially useful when PR titles are unclear. ### Step 5: Generate Changelog Generate the changelog using this template: ```markdown ## [v{version}] - YYYY-MM-DD ### ⚠️ Breaking Changes - [PR title] (#PR number) @author ### ✨ New Features - [PR title] (#PR number) @author - [PR title] (#PR number) @author ### 🐛 Bug Fixes - [PR title] (#PR number) @author ### ⚡ Performance - [PR title] (#PR number) @author ### 📖 Documentation - [PR title] (#PR number) @author ### 🔧 Other - [PR title] (#PR number) @author --- **Full changelog**: [link comparing previous version...current version] ``` Omit sections with no changes. ### Step 6: Confirm and Create the Release Show the generated changelog to the user for confirmation. After confirmation, use `create_release` with these parameters: - `tag_name`: version number (e.g., `v1.2.0`) - `name`: release title (e.g., `Release v1.2.0`) - `body`: changelog generated in Step 4 - `prerelease`: set to `true` for pre-release versions (alpha / beta / rc) After successful creation, output the link to the Release page. ## Notes - Use the `v` prefix in version numbers (e.g., `v1.2.0`) to match common project conventions - Breaking changes must be prominently highlighted to warn users upgrading - If PR titles are not semantic, lightly rephrase them in the changelog while preserving the original intent - Pre-release versions (alpha / beta / rc) should be marked `prerelease=true` so they don't affect the stable release line


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)