// 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.
| name | release-beta |
| description | 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. |
Create a BETA pre-release for community testing.
Current version: Check package.json for current version.
NEVER use 'v' prefix in git tags!
1.4.1-beta.1v1.4.1-beta.1The GitHub workflows expect tags WITHOUT 'v' prefix. Using 'v' will cause workflow failures.
All scripts (bump-version.sh, create-prerelease.sh) already create tags without 'v'.
Never create tags manually - always use the scripts.
The workflow adapts automatically based on the current version:
First beta after stable release → AI analyzes commits and suggests version type (patch/minor/major) Incremental beta (beta.2 → beta.3) → Automatically increments without user validation
Automatically detect release type:
Detect release type:
1.4.0 → First beta (requires AI analysis)1.4.0-beta.2 → Incremental beta (auto-increment to beta.3)For first beta after stable:
npm run analyze:commitsFor incremental beta:
MAJOR (X.0.0):
BREAKING CHANGE: in footer! after type (e.g., feat!:, fix!:)MINOR (X.Y.0):
feat: commits)PATCH (X.Y.Z):
fix: commits)docs:)AMBIGUOUS:
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)
Present final approval with:
User options:
For first beta with explicit version type:
bash scripts/bump-version.sh beta <patch|minor|major>)
bash scripts/bump-version.sh beta minor → 1.5.0-beta.1git commit + git tag)git push && git push --tags)For incremental beta:
bash scripts/bump-version.sh beta)
git commit + git tag)git push && git push --tags)GitHub Actions automatically:
Release notes: EN+FR equal quality, no TODO, detailed explanations, specific beta testing, user-focused, clean
Code: 17 checks passed, 15 smoke tests passed, lint+type-check passed, build succeeded
Version decision: AI analyzes commits semantically, presents detailed justification, user validates when needed
--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-beta.N
--skip-approval
Shows summary but auto-approves final publication. Still requires version decision validation if first beta. ⚠️ Use with caution.
Every release logged to: .opencode/logs/release-beta-{timestamp}.log
Contains: timestamps, commit analysis, AI reasoning, 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-beta.N or re-run (auto-increments)
Ambiguous commits → AI asks you to decide manually between patch/minor/major
After beta testing:
| Current Version | Detection | AI Analysis | User Validation | Result |
|---|---|---|---|---|
1.4.0 (stable) | First beta | ✅ Yes | ✅ Required | 1.5.0-beta.1 (if MINOR) |
1.4.0-beta.2 | Incremental | ❌ No | ❌ Not required | 1.4.0-beta.3 |
1.4.0-beta.5 | Incremental | ❌ No | ❌ Not required | 1.4.0-beta.6 |
Scripts Used:
scripts/analyze-commits.sh - Commit analysis (first beta only)scripts/bump-version.sh beta [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 checksCreate a stable production release with intelligent detection (finalize beta or direct release). Use when publishing stable releases, finalizing beta versions, or creating production releases.
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.