releasing

Generates a synchronized CHANGELOG entry and GPG-signed tag for dde releases.

47|9|Updated Jan 23, 2019
One-click install
npx skills add https://github.com/whatwedo/dde --skill releasing-whatwedo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: releasing
Source: https://github.com/whatwedo/dde/tree/main/.claude/skills/releasing
Command: npx skills add https://github.com/whatwedo/dde --skill releasing-whatwedo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you publish dde releases safely and consistently by ensuring the changelog and version tag stay in lockstep and are properly signed for the project’s release pipeline.

Core Features & Use Cases

  • Locks CHANGELOG and tags together: Updates CHANGELOG.md with a new top section and creates an annotated, GPG-signed tag pointing at the release commit.
  • Produces correct version behavior: Avoids editing src/Application.php so CI injects the right version from the tag or SHA during builds.
  • Builds user-facing release notes: Categorizes commits using conventional-commit semantics so only user-visible changes appear in the changelog section.
  • Minimizes accidental public releases: Requires explicit confirmation before pushing tags, since the tag triggers an expensive multi-platform release workflow.

Quick Start

Use this skill when you are preparing to create an official dde release and want to generate the signed changelog commit and version tag without bypassing CI.

Frequently Asked Questions about releasing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate a changelog entry and signed git tag together for a release?

To generate a changelog entry and signed git tag together, this skill updates CHANGELOG.md with a new top section and creates an annotated, GPG-signed tag pointing at the release commit. It requires conventional commit categorization for user-visible changes and strict GPG-signing for both commit and tag.

How do I automate GitHub releases using conventional commits?

Automating GitHub releases using conventional commits involves categorizing commit history to build user-facing release notes and creating a synchronized tag. This skill automates that workflow by generating the changelog content and updating GitHub Release descriptions based on conventional-commit semantics.

Do I need to manually update source code version numbers before creating a release tag?

No, you do not need to manually update source code version numbers before creating a release tag. This skill avoids editing source files like src/Application.php entirely, ensuring version injection is handled by CI from the tag or SHA during builds instead.

Can I use CI versioning to inject the correct version from a git tag?

Yes, you can use CI versioning to inject the correct version from a git tag. This skill specifically avoids manual source edits so that CI can inject the right version from the tag or SHA during the build process, keeping the release pipeline consistent.

Why does pushing a release tag require explicit confirmation?

Pushing a release tag requires explicit confirmation because the tag triggers an expensive multi-platform release workflow. This safety measure minimizes accidental public releases by demanding user confirmation before pushing tags to the remote repository.

Does generating a GitHub release support pre-release tags from conventional commit history?

Yes, generating a GitHub release supports pre-release tags from conventional commit history. This skill applies to producing both stable and pre-release tags, ensuring the changelog and annotated GPG-signed tag stay in lockstep for the release pipeline.