Changelog To Jira

Changelog to Jira Skill

This skill reads CHANGELOG.md, identifies entries that don't have a DGW-* Jira ticket, groups similar entries together, creates them in the DGW project, infers the assignee from the commit author, transitions them to Done, and updates CHANGELOG.md with the new ticket links.

Scope

Only process entries for these components (text inside _italics_):

• dgw — Devolutions Gateway core
• installer — Devolutions Gateway installer
• agent — Devolutions Agent
• agent-installer — Agent installer

Skip entries for any other component (e.g., webapp, jetsocat, crates).

Always default to the latest release — the first ## VERSION (DATE) block in the file.

Audience

Ticket descriptions are for QA technicians, support technicians, and marketing people. Write them from a consumer perspective — what changed for the user, not how it was implemented. Avoid internal code references, crate names, and architecture notes.

Length: calibrate to the complexity of the change.

• A bug fix or minor improvement: 1–2 sentences is enough.
• A new feature that requires configuration or has non-obvious behaviour: write as much as needed. Include what the feature does, how to enable or configure it, and any relevant defaults or caveats. This gives QA and support enough context to test and explain it without needing to read the code.

Examples:

Bug fix (short):

Fixed a crash that could occur when the Gateway service was restarted while an active session was recording.

New feature needing configuration (longer):

Gateway and Agent now support outbound proxy configuration for all network traffic. The proxy mode is controlled by the Proxy.Mode field in the configuration file:

• System (default): auto-detects proxy settings from environment variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) or system settings (WinHTTP on Windows, /etc/sysconfig/proxy on RHEL/SUSE, system preferences on macOS).
• Manual: uses explicitly configured URLs. Set Proxy.Http, Proxy.Https, or Proxy.All to a proxy URL (e.g. http://proxy.corp:8080 or socks5://proxy.corp:1080).
• Off: disables proxy entirely.

HTTP, HTTPS, SOCKS4, and SOCKS5 proxies are supported.

Workflow

Step 1: Read and Parse CHANGELOG.md

Read CHANGELOG.md from the current working directory. Take the first ## VERSION (DATE) block.

Entry format:

## VERSION (DATE)

### Section (Features / Bug Fixes / Security / Performance / etc.)

- _component_: short description ([#PR](github-pr-url)) ([commit](commit-url)) ([TICKET-ID](jira-url))

  Optional multi-line body with more detail.

Parse each entry into:

• section: Features / Bug Fixes / Security / Performance / etc.
• component: text inside _italics_
• description: the short description text
• body: optional indented multi-line description
• github_pr: PR number if present (e.g., #1676)
• commit_hash: short hash from the commit URL if present
• existing_tickets: all Jira ticket IDs found (pattern: [A-Z]+-\d+ with atlassian.net/browse URL)

Filter to only entries whose component is one of: dgw, installer, agent, agent-installer.

Step 2: Classify and Group Entries

Classify each entry

Group similar entries into a single ticket

Before planning ticket creation, look for entries that describe the same underlying change and should be represented by one ticket rather than several. Group them when:

• They share the same PR number (most reliable signal — same code change, multiple components affected)
• They are clearly two sides of the same feature (e.g., both dgw and agent entries describe adding the same capability)
• The descriptions are semantically equivalent (same fix or feature, slightly different wording)

When grouping, create one ticket that:

• Lists all affected components in the summary: [dgw, agent] Feature description
• Has a description that covers all components
• Maps CHANGELOG.md lines for all grouped entries to this single ticket

Do not force groupings. When in doubt, create separate tickets.

Step 3: Show the Plan

Before creating anything, show a summary table and wait for confirmation:

Latest release: 2026.1.0 (2026-02-23)

Will CREATE (no ticket):
  [Features] dgw: Add CredSSP certificate configuration keys (#1676)
  [Bug Fixes] agent-installer: Specify ARM64 platform for ARM64 installer

Will CREATE (grouped — same change):
  [Features] dgw + agent: RDM pipe passthrough logic (#1701)
    • dgw: add pipe passthrough for RDM
    • agent: handle pipe passthrough messages from RDM

Will CREATE + LINK (cross-project ticket):
  [Features] agent: RDM messages and pipe passthrough logic → PI-651

Already have DGW tickets (skipping):
  DGW-341 — Improve real-time performance of session shadowing

Proceed?

Step 4: Infer Assignee from Commit Author

For every entry that needs a new ticket (missing or cross-project), infer the assignee by looking up the commit author in git and resolving them to a Jira account.

For entries with a commit hash:

git log --format="%ae %an" -1 <commit-hash>

This gives you the author's email and name. Then look up their Jira account:

mcp__claude_ai_Atlassian__lookupJiraAccountId  →  query = "<author email or name>"

Use the email first — it's the most reliable identifier. If no match, try the display name.

For cross-project entries: Also fetch the original ticket's assignee (getJiraIssue → assignee.accountId) as a fallback if the commit lookup yields no result. Prefer the commit author when both are available.

If no commit hash is available, or the author lookup returns no result, omit the assignee field — do not block ticket creation.

Cache the results — if two entries share the same commit author, reuse the resolved accountId without a second lookup.