pre-release-validation

# Pre-Release Validation

## Purpose

Performs comprehensive validation checks before finalizing a release for any project type. Validates version files, changelog, git state, and runs project-specific and custom validation checks. Returns both blocking errors (must be fixed) and non-blocking warnings (can proceed with caution).

## Input Context

Requires:
- **Project Configuration**: Output from `detect-project-type` skill
- **New Version**: Version to be released (e.g., "1.2.0")
- **Changelog Path**: Path to changelog file
- **Modified Files**: List of files that will be committed

## Workflow

### 1. Load Configuration

Use configuration from `detect-project-type`:
- `project_type` - Determines project-specific checks
- `version_files` - Files to validate
- `tag_pattern` - For checking tag conflicts
- `custom_validations` - Custom validation scripts
- `skip_validations` - Validations to skip

### 2. Version Tag Conflict Check

Check if a git tag already exists for this version:

```bash
# Build tag name from pattern
tag_pattern="v{version}"  # from config
tag_name="${tag_pattern//\{version\}/$new_version}"

# Check if tag exists
if git tag -l "$tag_name" | grep -q "$tag_name"; then
  error="Version $new_version already released (tag $tag_name exists)"
  suggestion="Choose a different version or delete existing tag with: git tag -d $tag_name"
fi
```

**Can skip with:** `skip_validations: ["version-tag-conflict"]`

### 3. Version Format Validation

Validate the version string follows semantic versioning:

```bash
# Semantic version pattern: X.Y.Z
if ! echo "$new_version" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+$'; then
  error="Invalid version format: $new_version (expected X.Y.Z)"
  suggestion="Use semantic versioning format like 1.2.3"
fi
```

**Can skip with:** `skip_validations: ["version-format"]`

### 4. Version Progression Check

Compare new version to current version:

```bash
# Parse versions
IFS='.' read -r curr_major curr_minor curr_patch <<< "$current_versi