Prompt file imported from esystemsdev/aifabrix-miso-client (.cursor/commands/repair-release.md). Copyright stays with the author.

repair-release

Release flow: Prepare on dev (or the current development branch), then use /push-release-branch to stage release/miso-client-X.Y.0 and obtain a PR to main. After human merge, /push-github publishes. See deployment process. This command only prepares local files; it does not commit, push, tag, or publish.

Resume rule: When invoked by /push-release-branch, reuse an already prepared unpublished version with a matching changelog instead of bumping twice. An explicit standalone request for a new release still performs change analysis below.

When the /repair-release command is used, the agent must automatically prepare the component for release by running validation, analyzing changes, updating the changelog, and incrementing the version number. The agent must work autonomously without asking the user for input.

Execution Process:

1. Validation Step:

   • First, run the /validate-tests command to ensure all tests pass, linting is clean, and the codebase is in a validated state
   • This includes: pnpm run tests:typecheck:silent, pnpm run lint:fix:silent, pnpm run lint:silent, pnpm run test:silent, and final verification
   • On any *:silent failure, inspect .temp/validation/* logs first; run non-silent fallback only when silent runner/logs are not usable for diagnostics
   • Do not proceed until all validation steps pass

2. Change Detection Step:

   • Get the last published version from reachable version tags, corroborated by GitHub Release/npm evidence (a tag alone is not proof of deployment)
   • Compare current HEAD with the last tag to detect what has changed
   • Analyze git commit messages and file changes to categorize changes:
     • New Features: New services, new utilities, new functionality (minor version bump: 2.x.0)
     • Bug Fixes: Fixes, patches, corrections (patch version bump: 2.0.x)
   • Use git commands to get:
     • Commit messages since last tag: git log <last-tag>..HEAD --oneline
     • Changed files: git diff <last-tag>..HEAD --name-status
     • Summary of changes for changelog

3. Version Determination Step:

   • Read current version from package.json (e.g., 2.2.0)
   • Determine version increment based on change analysis:
     • Patch increment (2.2.0 → 2.2.1): If only bug fixes, small corrections, or minor changes
     • Minor increment (2.2.0 → 2.3.0): If new features, new services, new utilities, or significant functionality added
   • Calculate new version number

4. Changelog Update Step:

   • Read CHANGELOG.md to understand the format
   • Extract changes from git commits since last tag
   • Categorize changes into sections:
     • ### Added - New features, services, utilities, modules
     • ### Changed - Modifications to existing functionality
     • ### Fixed - Bug fixes and corrections
     • ### Technical - Technical details, dependencies, architecture changes
   • Add new version entry at the top of CHANGELOG.md with:
     • Version number in format: ## [X.Y.Z] - YYYY-MM-DD
     • Date in format: YYYY-MM-DD (current date)
     • Categorized changes from git analysis
   • Follow the existing changelog format and style

5. Version Update Step:

   • Update package.json with the new version number
   • Replace the version field in package.json with the calculated new version
   • Ensure JSON formatting is preserved

6. Final Verification Step:

   • Verify package.json version was updated correctly
   • Verify CHANGELOG.md was updated with new entry
   • Verify changelog entry follows the correct format
   • Display summary of changes made

Critical Requirements:

• Automatic Execution: The agent MUST automatically execute all steps without user interaction
• Validation First: Always run /validate-tests first to ensure codebase is ready for release
• Change Analysis: Properly analyze git changes to determine version increment type
• Changelog Format: Follow the exact format used in existing CHANGELOG.md entries
• Version Semantics:
  • Patch (2.2.0 → 2.2.1): Bug fixes, small corrections, patches
  • Minor (2.2.0 → 2.3.0): New features, new services, new utilities, significant functionality
• Date Format: Use YYYY-MM-DD format for changelog dates
• Git Tag Detection: Use git tag --merged HEAD --sort=-version:refname and select the latest published version on the intended release line (or its published predecessor for a new line); exclude unrelated maintenance lines
• Change Extraction: Extract meaningful change descriptions from git commits
• No User Input: Work autonomously and only report completion when all steps are done

Version Bump Rules:

• Patch Version (2.2.0 → 2.2.1): Use when changes include:

  • Bug fixes
  • Security patches
  • Small corrections
  • Documentation updates (if only docs)
  • Code quality improvements (refactoring, linting fixes)
  • Performance optimizations (without new features)
  • Test improvements
  • Type definition fixes

• Minor Version (2.2.0 → 2.3.0): Use when changes include:

  • New services (AuthService, RolesService, etc.)
  • New utilities (HTTP client, config loader, etc.)
  • New Express middleware or utilities
  • New features or functionality
  • New configuration options
  • Significant enhancements to existing features
  • New type definitions or interfaces

• Major Version: Breaking public SDK changes require a major increment and migration notes; do not classify them as a minor release.

Work is only complete when:

• ✅ All validation tests pass (via /validate-tests)
• ✅ Changes have been analyzed from git
• ✅ Version number has been determined and incremented
• ✅ CHANGELOG.md has been updated with new version entry
• ✅ package.json version has been updated
• ✅ All changes follow the project's format and standards