GHA-281 Add a skill to set up release for DevEx repos.

[Krosovok]

A variation of skill to setup release for DevEx repos using ide-automated-release. Mostly reverse engineered from existing skill + ide-automated-release + existing implementation on SLCore.

Depends on #139

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[hashicorp-vault-sonar-prod]

GHA-281

[sonar-review-alpha]

Summary

This PR adds a new Claude Code skill (devex-release-setup) that guides users through setting up automated release workflows for SonarSource Development Experience projects (SonarLint Core, SonarLint for IntelliJ, etc.).

The skill is a comprehensive, interactive prompt template that:

• Auto-detects repository configuration (build system, workflow conventions, Slack channel, runners, etc.)
• Gathers required information (Jira project key, project name, version bump options)
• Updates the existing release.yml workflow to use workflow_dispatch inputs
• Creates a new full-release.yml workflow using the ide-automated-release reusable workflow
• Provides 5 workflow variants to handle different configurations (with/without version bump, Maven/Gradle/custom build systems)
• Confirms Jira prerequisites before the user proceeds

It is distinct from the existing automated-release-setup skill, which targets full SonarSource analyzer projects with releasability checks and external analyzer update PRs. This new skill is purpose-built for simpler DevEx projects that only need the ide-automated-release workflow.

What reviewers should know

Start with: The main skill file (.claude/skills/devex-release-setup/SKILL.md) is the core deliverable — 403 lines of step-by-step guidance. The README changes are just documentation.

Key sections to review:

1. Step 1 (Auto-detection): The skill proactively gathers repo config before asking questions — build system via pom.xml/gradle.properties, workflow style, Slack channel from existing workflows, and SHA pinning strategy for Renovate bot compatibility.
2. Variants A–E (Step 5): Five workflow templates handle different scenarios. Variant C (Maven + dry-run) and D (Gradle + dry-run) are most common. Note Variant E for custom build systems is less polished but provides escape hatch.
3. Jira integration: The skill explicitly states no Vault permission changes are needed (unlike the full analyzer setup) and prompts for Jira sandbox access if dry-run is enabled.
4. Workflow dispatch mechanics (Step 3): The skill is careful about removing the old release: published trigger — the new ide-automated-release workflow is invoked directly via workflow_dispatch by the publish-github-release action, not by a GitHub event.

Non-obvious decisions:

• The skill uses "check before acting" as a principle — at each file modification step, it verifies current state and asks for user confirmation before changing anything.
• SHA pinning format (@<sha> # <version>) is intentional for Renovate bot tracking.
• PM email defaults to the DevEx PM and is documented as a fallback.

Watch for:

• The skill relies entirely on Claude's ability to run interactive prompts (AskUserQuestion) and execute repo commands (git, bash). It does not make commits or push changes itself — that is deferred to the user.
• Variant E (custom build systems) requires the user to provide a shell command and the skill to hand-craft the bump-version job. This is inherently less robust than Variants C–D.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

There is one real bug that will cause every workflow generated by this skill to fail on its first run. The README and overall structure look good.

🗣️ Give feedback

[damien-urruty-sonarsource]

LGTM