Claude Code Plugins

Community-maintained marketplace

Feedback

release-stable

@Thank-you-Linus/Linus-Dashboard
113
0

Create a stable production release with intelligent detection (finalize beta or direct release). Use when publishing stable releases, finalizing beta versions, or creating production releases.

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name release-stable
description Create a stable production release with intelligent detection (finalize beta or direct release). Use when publishing stable releases, finalizing beta versions, or creating production releases.

Create Stable Production Release

Create a STABLE release for production use.

Current version: Check package.json for current version.

⚠️ CRITICAL TAG FORMAT RULE

NEVER use 'v' prefix in git tags!

  • ✅ CORRECT: 1.5.0
  • ❌ WRONG: v1.5.0

The GitHub workflows expect tags WITHOUT 'v' prefix. Using 'v' will cause workflow failures. All scripts (bump-version.sh, create-release.sh) already create tags without 'v'. Never create tags manually - always use the scripts.

Intelligent Workflow

The workflow adapts automatically based on the current version:

From beta (1.5.0-beta.3 → 1.5.0) → Automatic finalization, no analysis needed Direct stable release (1.4.0 → 1.5.0) → AI analyzes commits and suggests version type with warning

Phase 1: Release Type Detection

Automatically detect release scenario:

  1. Detect release scenario:

    • Current version: 1.5.0-beta.3 → Finalize beta (automatic, no validation)
    • Current version: 1.4.0 (stable) → Direct release (requires AI analysis + warning)

  2. For finalize beta:

    • Strip -beta.N suffix automatically
    • Skip commit analysis (already done during beta)
    • Faster workflow (3-5 min)

  3. For direct stable release:

    • Show WARNING about skipping beta testing (risky)
    • Run commit analysis: npm run analyze:commits
    • Analyze commit types (feat, fix, BREAKING CHANGE)
    • Determine version bump type (patch/minor/major)
    • Present detailed validation with option to create beta instead

Phase 2A: Finalize Beta (Automatic)

Current: 1.5.0-beta.3 → Stable: 1.5.0

Present automatic finalization message:

  • Current version and target stable version
  • Note that version type was already determined during beta
  • No additional analysis or validation required
  • Proceed automatically to release notes and validation

No user validation required → Proceeds directly to Phase 3

Phase 2B: Direct Stable Release (Requires Validation)

Current: 1.4.0 → Proposed: 1.5.0

Beta Testing Warning

Present warning about direct stable release:

  • Risks: No community feedback, untested in real environments, bugs reach production, harder rollback
  • Recommendation: Create beta first
  • User options:
    • [1] YES - Continue with direct release (risky)
    • [2] CREATE BETA INSTEAD - Safer approach
    • [3] CANCEL - Abort

If user chooses [2] CREATE BETA: Stop and use release-beta skill

If user chooses [1] PROCEED: Show detailed AI analysis

AI Semantic Analysis (Direct Release Only)

Present detailed analysis with:

  • Current version and proposed version
  • Warning about skipping beta
  • Commit breakdown (feat, fix, breaking, etc.)
  • AI reasoning with confidence level
  • Recommendation to test as beta first
  • Key commits (most impactful)
  • User decision options:
    • [1] APPROVE - Proceed with AI suggestion (skipping beta)
    • [2] DOWNGRADE TO PATCH - Override AI (skipping beta)
    • [3] UPGRADE TO MAJOR - Override AI (skipping beta)
    • [4] CREATE BETA INSTEAD - Safer approach (recommended)
    • [5] VIEW COMMITS - Show full commit list
    • [6] CANCEL - Abort safely

Phase 3: Release Notes Generation & Editing

Automatically:

  1. Generate release notes (bash scripts/generate-release-notes.sh)
  2. AI-powered editing:
    • Remove noise (version bumps, merges, CI commits, deps updates)
    • Enhance features/fixes (bold title + detailed description)
    • Translate to French (same detail level)
    • Remove beta testing section (not needed for stable)
    • Add upgrade instructions if needed
    • Remove TODO markers
  3. Format for GitHub (bash scripts/format-release-notes.sh)

Phase 4: Quality Validation (BLOCKING)

All must pass:

A. Release notes validation (scripts/validate-release-notes.sh)

  • Required sections EN/FR
  • No TODO
  • No beta testing section
  • Bold features

B. Code quality (17 checks) (scripts/check-release-ready.sh)

  1. Git clean 2. Branch main 3. Up-to-date 4. Deps installed 5. Lint 6. Type-check 7. Build 8. Version consistency 9. No FIXME 10. CHANGELOG 11. manifest.json 12. hacs.json 13. No secrets 14. Python syntax 15. README 16. LICENSE 17. Smoke tests ready

C. Smoke tests (15 tests) (npm run test:smoke)

Phase 5: Final Approval & Publication

For finalize beta:

Present approval with:

  • Version and finalization info
  • Note that beta testing completed successfully
  • Changes summary (features, bug fixes) since last stable
  • Validation results
  • What happens if approved

User options:

  • [1] APPROVE - Publish stable release
  • [2] REQUEST CHANGES - Modify release notes
  • [3] VIEW FULL NOTES - See complete file
  • [4] CANCEL - Abort

For direct stable release:

Present approval with:

  • Version and bump type
  • Warning about skipping beta testing
  • Changes summary
  • Validation results
  • Reminder to monitor closely

User options:

  • [1] APPROVE - Publish stable release (skipping beta)
  • [2] CREATE BETA INSTEAD - Safer approach
  • [3] REQUEST CHANGES - Modify release notes
  • [4] VIEW FULL NOTES - See complete file
  • [5] CANCEL - Abort

Phase 6: Publication (Only after approval)

For finalize beta (automatic version):

  1. Bump version (bash scripts/bump-version.sh release)
    • Strips -beta.N: 1.5.0-beta.3 → 1.5.0
  2. Update release notes with final version
  3. Commit + tag (git commit + git tag)
  4. Push (git push && git push --tags)
  5. Report success with forum links

For direct stable release (explicit version type):

  1. Bump version (bash scripts/bump-version.sh release <patch|minor|major>)
    • Example: bash scripts/bump-version.sh release minor → 1.5.0
  2. Update release notes with final version
  3. Commit + tag (git commit + git tag)
  4. Push (git push && git push --tags)
  5. Report success with forum links

GitHub Actions automatically:

  • Builds project
  • Runs smoke tests
  • Creates ZIP
  • Creates stable release
  • Sends Discord notification (public announcement)
  • Cleans up RELEASE_NOTES.md

Manual step:

  • Open forum threads: npm run forums:open
  • Post release announcement (templates provided)

Quality Standards

Release notes: EN+FR equal quality, no TODO, detailed explanations, user-focused, clean, no beta testing section

Code: 17 checks passed, 15 smoke tests passed, lint+type-check passed, build succeeded

Version decision:

  • Finalize beta: Automatic, no validation
  • Direct release: AI analyzes commits, warns about skipping beta, requires user validation

Options

Dry Run

--dry-run

Runs everything, creates commit+tag locally, STOPS before push. Nothing published. To undo: git reset HEAD~1 && git tag -d X.Y.Z

Skip Approval (Final approval only)

--skip-approval

Shows summary but auto-approves final publication. Still shows warning and requires version decision for direct releases. ⚠️ Use with extreme caution.

Logs

Every release logged to: .opencode/logs/release-stable-{timestamp}.log

Contains: timestamps, detection logic, commit analysis (if direct), AI reasoning, warnings shown, user decisions, git hashes, URLs, duration

Common Errors

Validation fails → Fix issues, re-run command Smoke tests fail → Check npm run test:smoke, fix, re-run Build fails → Run npm run build, fix errors, re-run Push fails → git pull --rebase, re-run Tag exists → git tag -d X.Y.Z then re-run Ambiguous commits (direct release) → AI asks you to decide manually Beta recommended → Use release-beta skill first for safer release

Related Commands

Before stable release:

  • Recommended: Use release-beta skill (test first)
  • Check status: Use release-check skill

After stable release:

  • Hotfix needed → Use release-stable skill again (creates patch: 1.5.0 → 1.5.1)
  • Critical issue → Use release-rollback skill
  • Announce → npm run forums:open

Release Type Detection Logic

Current Version Detection AI Analysis Beta Warning User Validation Result
1.5.0-beta.3 Finalize ❌ No ❌ No ❌ Not required 1.5.0 (stable)
1.4.0 (stable) Direct ✅ Yes ✅ Yes ✅ Required 1.5.0 (if MINOR)

Important

  • Finalize beta: Automatic and fast (no validation, already tested)
  • Direct stable: Requires AI analysis + shows warning about skipping beta + requires your validation
  • Best practice: Always test with beta first (release-beta → test → release-stable)
  • All validations are blocking (must pass)
  • Idempotent (safe to re-run)
  • Logs everything
  • Time: 3-5 min (finalize) or 5-10 min (direct release)

Scripts Used:

  • scripts/analyze-commits.sh - Commit analysis (direct release only)
  • scripts/bump-version.sh release [patch|minor|major] - Version bumping
  • scripts/generate-release-notes.sh - Release notes generation
  • scripts/format-release-notes.sh - Formatting
  • scripts/validate-release-notes.sh - Validation
  • scripts/check-release-ready.sh - Code quality checks

Forum Announcement: After successful release, use npm run forums:open to announce on Home Assistant Community Forum and HACF.