// 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.
| 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 a STABLE release for production use.
Current version: Check package.json for current version.
NEVER use 'v' prefix in git tags!
1.5.0v1.5.0The 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.
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
Automatically detect release scenario:
Detect release scenario:
1.5.0-beta.3 → Finalize beta (automatic, no validation)1.4.0 (stable) → Direct release (requires AI analysis + warning)For finalize beta:
-beta.N suffix automaticallyFor direct stable release:
npm run analyze:commitsCurrent: 1.5.0-beta.3 → Stable: 1.5.0
Present automatic finalization message:
No user validation required → Proceeds directly to Phase 3
Current: 1.4.0 → Proposed: 1.5.0
Present warning about direct stable release:
If user chooses [2] CREATE BETA: Stop and use release-beta skill
If user chooses [1] PROCEED: Show detailed AI analysis
Present detailed analysis with:
Automatically:
bash scripts/generate-release-notes.sh)bash scripts/format-release-notes.sh)All must pass:
A. Release notes validation (scripts/validate-release-notes.sh)
B. Code quality (17 checks) (scripts/check-release-ready.sh)
C. Smoke tests (15 tests) (npm run test:smoke)
For finalize beta:
Present approval with:
User options:
For direct stable release:
Present approval with:
User options:
For finalize beta (automatic version):
bash scripts/bump-version.sh release)
-beta.N: 1.5.0-beta.3 → 1.5.0git commit + git tag)git push && git push --tags)For direct stable release (explicit version type):
bash scripts/bump-version.sh release <patch|minor|major>)
bash scripts/bump-version.sh release minor → 1.5.0git commit + git tag)git push && git push --tags)GitHub Actions automatically:
Manual step:
npm run forums:openRelease 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:
--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
Shows summary but auto-approves final publication. Still shows warning and requires version decision for direct releases. ⚠️ Use with extreme caution.
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
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
Before stable release:
After stable release:
npm run forums:open| 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) |
Scripts Used:
scripts/analyze-commits.sh - Commit analysis (direct release only)scripts/bump-version.sh release [patch|minor|major] - Version bumpingscripts/generate-release-notes.sh - Release notes generationscripts/format-release-notes.sh - Formattingscripts/validate-release-notes.sh - Validationscripts/check-release-ready.sh - Code quality checksForum Announcement:
After successful release, use npm run forums:open to announce on Home Assistant Community Forum and HACF.
Create a beta pre-release for community testing with intelligent version detection. Use when creating beta releases, publishing pre-releases, or preparing versions for community testing.
Debug errors, bugs, and unexpected behavior systematically in Home Assistant integration. Use when investigating errors, analyzing stack traces, fixing bugs, or troubleshooting unexpected behavior.
Implement approved plans with precision and quality for Linus Dashboard Home Assistant integration. Use when implementing features, executing approved plans, writing code following standards, or developing new functionality.
Check if project is ready for release with comprehensive pre-release validation. Use when verifying release readiness, running validation checks, or checking project quality before publishing.
Rollback a failed release by deleting tags and reverting version changes. Use when a release fails, needs to be cancelled, or when reverting a problematic release.
Review code quality, security, and maintainability before committing. Use when reviewing code changes, checking code quality, performing security review, or validating changes before commit.