release-beta

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 Beta Pre-Release

Create a BETA pre-release for community testing.

Current version: Check package.json for current version.

⚠️ CRITICAL TAG FORMAT RULE

NEVER use 'v' prefix in git tags!

• ✅ CORRECT: 1.4.1-beta.1
• ❌ WRONG: v1.4.1-beta.1

The 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.

Intelligent Workflow

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

---

Phase 1: Version Detection & Analysis

Automatically detect release type:

1. Detect release type:

   • Current version: 1.4.0 → First beta (requires AI analysis)
   • Current version: 1.4.0-beta.2 → Incremental beta (auto-increment to beta.3)

2. For first beta after stable:

   • Run commit analysis: npm run analyze:commits
   • Analyze commit types (feat, fix, BREAKING CHANGE)
   • Count semantic changes
   • Determine version bump type (patch/minor/major)

3. For incremental beta:

   • Skip analysis (already determined)
   • Auto-increment beta counter

---

Phase 2: Version Type Decision (First Beta Only)

AI Semantic Analysis Rules:

MAJOR (X.0.0):

• Commits contain BREAKING CHANGE: in footer
• Commits use ! after type (e.g., feat!:, fix!:)
• API incompatible changes detected
• Database schema changes
• Major architecture refactoring

MINOR (X.Y.0):

• New features detected (feat: commits)
• Backward-compatible additions
• New components, views, cards
• Significant enhancements

PATCH (X.Y.Z):

• Only bug fixes (fix: commits)
• Documentation updates (docs:)
• Small improvements/refactoring
• Translation updates
• Dependency updates

AMBIGUOUS:

• Mixed signals (e.g., 5 feat + 1 BREAKING)
• Unclear impact
• → Ask user to decide manually

Present Validation Prompt:

Present detailed analysis with:

• Current version
• Proposed version
• Commit breakdown (feat, fix, breaking, etc.)
• AI reasoning with confidence level
• Key commits (most impactful)
• User decision options:
  • [1] APPROVE - Proceed with AI suggestion
  • [2] DOWNGRADE TO PATCH - Override AI
  • [3] UPGRADE TO MAJOR - Override AI
  • [4] VIEW COMMITS - Show full commit list
  • [5] 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)
   • Fill beta testing instructions
   • 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
• Beta testing filled
• 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

Present final approval with:

• Version and bump type
• Changes summary (features, bug fixes)
• Beta testing checklist
• Validation results
• What happens if approved

User options:

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

---

Phase 6: Publication (Only after approval)

For first beta with explicit version type:

1. Bump version (bash scripts/bump-version.sh beta <patch|minor|major>)
   • Example: bash scripts/bump-version.sh beta minor → 1.5.0-beta.1
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 monitoring links

For incremental beta:

1. Bump version (bash scripts/bump-version.sh beta)
   • Auto-increment: 1.5.0-beta.2 → 1.5.0-beta.3
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 monitoring links

GitHub Actions automatically:

• Builds project
• Runs smoke tests
• Creates ZIP
• Creates pre-release
• Sends Discord notification to @Beta Tester
• Cleans up RELEASE_NOTES.md

---

Quality Standards

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

---

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-beta.N

Skip Approval (Final approval only)

--skip-approval

Shows summary but auto-approves final publication. Still requires version decision validation if first beta. ⚠️ Use with caution.

---

Logs

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

Contains: timestamps, commit analysis, AI reasoning, 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-beta.N or re-run (auto-increments) Ambiguous commits → AI asks you to decide manually between patch/minor/major

---

Related Commands

After beta testing:

• ✅ Beta successful → Use release-stable skill (finalizes beta → stable)
• 🐛 Issues found → Fix, then use release-beta skill again (increments beta.N automatically)
• 🚨 Critical issue → Use release-rollback skill

---

Version Detection Logic Summary

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

---

Important

• First beta: AI analyzes commits, presents detailed reasoning, requires your validation
• Incremental beta: Automatic increment, no analysis, faster workflow
• All validations are blocking (must pass)
• Idempotent (safe to re-run)
• Logs everything
• Time: 5-10 min (first beta) or 3-5 min (incremental)

Scripts Used:

• scripts/analyze-commits.sh - Commit analysis (first beta only)
• scripts/bump-version.sh beta [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