agentleFS
Sign inStart free
Thank-you-LinusThank-you-Linus/Linus-Dashboard/.claude/skills/release-beta/SKILL.md

release-beta

Skill214 starsChanged 31 days agoMITView on GitHub

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.

  • Commits and pushes

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 5 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create a BETA pre-release for community testing.

    line 8
  2. Very specific:

    All scripts (bump-version.sh, create-prerelease.sh) already create tags without 'v'.

    line 20
  3. Distinctive:

    Never create tags manually: - always use the scripts.

    line 21
  4. Very specific:

    Run commit analysis: npm run analyze:commits

    line 41
  5. Very specific:

    Only bug fixes (fix: commits)

    line 70
  6. Distinctive:

    Commit breakdown (feat, fix, breaking, etc.)

    line 86
  7. Distinctive:

    Remove noise (version bumps, merges, CI commits, deps updates)

    line 104
  8. Very specific:

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

    line 206
  9. Distinctive:

    All validations are blocking (must pass)

    line 246

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 VersionDetectionAI AnalysisUser ValidationResult
1.4.0 (stable)First beta✅ Yes✅ Required1.5.0-beta.1 (if MINOR)
1.4.0-beta.2Incremental❌ No❌ Not required1.4.0-beta.3
1.4.0-beta.5Incremental❌ No❌ Not required1.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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free