# Plugin Release Preparation Skill

> **Purpose:** Preparing the plugin for submission to WordPress.org or production release
> **When to use:** Before submitting to WordPress.org, creating release tags, or deploying to production
> **Do NOT use:** During regular development, feature implementation, or bug fixes

---

## When This Skill Applies

**Use this skill ONLY when:**
- Preparing for WordPress.org submission (initial or update)
- Creating a release tag/version
- Building production distribution package
- Pre-release compliance audit
- User explicitly requests "prepare for release" or similar

**Do NOT use this skill when:**
- Writing new features
- Fixing bugs
- Refactoring code
- Making routine changes
- Building for development/testing

---

## Complete Pre-Release Workflow (Recommended)

This comprehensive workflow ensures zero regressions and complete quality assurance before release.

### Phase 1: Create Visual Checkpoint (Baseline)

**Purpose:** Capture the current state of all UI elements to verify no visual regressions after fixes.

**Steps:**
1. Create Playwright test script to capture baseline screenshots
2. Screenshot all UI screens:
   - Frontend comment list (default state)
   - Comment form (empty and with content)
   - Reply forms (at different nesting levels)
   - Comment actions (edit, delete, reply buttons)
   - Vote buttons (upvote/downvote states)
   - User avatars and meta information
3. Screenshot all modals:
   - Edit comment modal
   - Delete confirmation modal
   - Report comment modal
   - Login prompt modal (if applicable)
4. Screenshot all menus:
   - Comment action dropdown/menu
   - Admin settings pages (all tabs)
   - Admin moderation interface
5. Save screenshots to `tests/playwright/checkpoints/baseline/`
6. Record computed CSS values for critical elements (colors, spacing, fonts)

**Playwright Script Location:** `tests/playwright/checkpoint-baseline.spec.js`

### Phase 2: Comprehensive Audits

**Purpose:** Identify all issues before making fixes to ensure complete coverage.

Run all audits in parallel using Task tool with specialized agents:

#### 2.1 Code Review
- **Agent:** `.claude/agents-archive/plugin-reviewer.md`
- **Output:** `reports/code-review.md`
- **Checks:**
  - WordPress Coding Standards compliance
  - Code organization and structure
  - Performance issues
  - Database query optimization
  - Caching implementation
  - Error handling
  - Code documentation

#### 2.2 Security Audit
- **Agents:** 
  - `.claude/agents-archive/wordpress-plugin-security-audit.md`
  - `.claude/agents-archive/wordpress-security.md`
- **Output:** `reports/security-audit.md`
- **Checks:**
  - SQL injection vulnerabilities (all queries use `$wpdb->prepare()`)
  - XSS vulnerabilities (all output escaped)
  - CSRF vulnerabilities (nonce verification)
  - Authentication and authorization
  - Input sanitization
  - File upload security (if applicable)
  - Direct file access prevention
  - Capability checks

#### 2.3 Accessibility Audit
- **Agent:** `.claude/agents/expert.md` (with accessibility-skill)
- **Output:** `reports/accessibility-audit.md`
- **Checks:**
  - WCAG 2.1 Level AA compliance
  - Keyboard navigation
  - Screen reader compatibility
  - ARIA labels and roles
  - Focus management
  - Color contrast ratios
  - Form labels and error messages
  - Skip links
  - Reduced motion support

#### 2.4 Internationalization (i18n) Audit
- **Agent:** `.claude/agents/expert.md` (with php-skill)
- **Output:** `reports/i18n-audit.md`
- **Checks:**
  - All user-facing strings wrapped in translation functions
  - Correct text domain usage (`comments-press-zone`)
  - 🚨 **NO variables in gettext functions** (`__($var, 'text-domain')` FORBIDDEN)
  - User-configurable content NOT passed through translation functions
  - No hardcoded strings
  - Proper context for ambiguous strings
  - Pluralization handling (`_n()`)
  - JavaScript translation support
  - POT file completeness
  - sprintf() usage for dynamic strings
  - Translator comments for placeholders

**CRITICAL i18n Rule:**
```php
// ❌ REJECTION: Variables in gettext
__($variable, 'comments-press-zone')

// ✅ CORRECT: Static strings with printf
printf(esc_html__('Hello %s', 'comments-press-zone'), $name);
```

#### 2.5 Frontend Styling Audit
- **Agent:** `.claude/agents/frontend-styling-expert.md`
- **Output:** `reports/styling-audit.md`
- **Checks:**
  - CSS architecture and organization
  - SCSS variable usage (NO CSS custom properties)
  - BEM naming consistency
  - Responsive design breakpoints
  - Dark mode compatibility
  - Browser compatibility
  - CSS specificity issues
  - Unused styles
  - Print styles (if applicable)

**Commands to generate reports:**
```bash
# Create reports directory
mkdir -p reports

# Run all audits (example using Task tool)
# In practice, use Task tool to run agents in parallel
```

### Phase 3: Fix All Issues

**Purpose:** Resolve every issue found in audits, no matter how minor.

**Agent:** `.claude/agents/expert.md`

**Process:**
1. Read all audit reports
2. Categorize issues by severity: Critical → High → Medium → Low
3. Fix issues in priority order
4. For each fix:
   - Apply the fix
   - Document what was changed
   - Note file and line numbers
   - Run relevant build commands
5. Track progress in todo list

**Zero tolerance policy:** Fix ALL issues, including:
- Minor typos in comments
- Inconsistent spacing
- Missing PHPDoc blocks
- Suboptimal variable names
- Redundant code
- Potential edge cases

### Phase 4: Re-Run Audits (Iterative)

**Purpose:** Verify all issues are resolved and no new issues introduced.

**Process:**
1. Re-run ALL audits from Phase 2
2. Compare new reports with original reports
3. Verify issue count: `Critical: 0, High: 0, Medium: 0, Low: 0`
4. If any issues remain:
   - Return to Phase 3
   - Fix remaining issues
   - Re-run audits again
5. Repeat until ALL audits report ZERO issues

**Success criteria:**
- ✅ Code review: 0 issues
- ✅ Security audit: 0 vulnerabilities
- ✅ Accessibility audit: 0 WCAG violations
- ✅ i18n audit: 0 untranslated strings
- ✅ Styling audit: 0 CSS issues

### Phase 5: Visual Regression Testing

**Purpose:** Ensure fixes haven't broken any UI elements or functionality.

**Steps:**
1. Run Playwright verification script
2. Capture new screenshots of all UI elements (same as Phase 1)
3. Compare pixel-by-pixel with baseline screenshots
4. Check computed CSS values match baseline
5. Test all interactive functionality:
   - Comment submission
   - Reply functionality
   - Edit/delete actions
   - Voting system
   - Moderation actions
   - Modal open/close
   - Form validation
   - Error states
   - Loading states

**Playwright Script Location:** `tests/playwright/checkpoint-verify.spec.js`

**Verification criteria:**
- ✅ All screenshots match baseline (100% pixel perfect)
- ✅ All computed CSS values match baseline
- ✅ All interactive features work identically
- ✅ No console errors
- ✅ No visual glitches or layout shifts
- ✅ Animations/transitions work as before

**If verification fails:**
1. Identify which element(s) changed
2. Determine if change was caused by fixes
3. Fix the regression (restore original behavior)
4. Re-run verification
5. Repeat until 100% pixel perfect

### Phase 6: Final Build & Git Preparation

**Purpose:** Prepare clean release package and version control.

**Steps:**
1. Run production builds:
   ```bash
   cd admin && npm run build
   cd .. && npm run build:css
   ```
2. Update version numbers (if not already done):
   - `comments-press-zone.php` header
   - `PRESSZONE_COMMENTS_VERSION` constant
   - `readme.txt` stable tag
   - `package.json` version
3. Update CHANGELOG.md with all changes
4. Generate translation template:
   ```bash
   wp i18n make-pot . languages/comments-press-zone.pot
   ```
5. Verify no development artifacts:
   - No `console.log()` statements
   - No TODO comments
   - No debug code
   - No .map files in production build

### Phase 7: Git Commit & Push

**Purpose:** Create clean git history with release tag.

**Commands:**
```bash
# Stage all changes
git add .

# Create commit with detailed message
git commit -m "Release v1.0.5: Complete pre-release audit and fixes

- Security: Fixed all SQL injection and XSS vulnerabilities
- Accessibility: Achieved WCAG 2.1 Level AA compliance
- i18n: Wrapped all strings with translation functions
- Code quality: Resolved all coding standards violations
- Styling: Fixed CSS architecture and dark mode issues
- Visual verification: Confirmed 100% pixel-perfect UI preservation

Audits passed: Code Review ✓, Security ✓, Accessibility ✓, i18n ✓, Styling ✓
Visual regression tests: PASSED (100% match)"

# Create release tag
git tag -a v1.0.5 -m "Release version 1.0.5"

# Push to repository
git push origin main
git push origin v1.0.5
```

### Phase 8: Final Notification

**Purpose:** Provide comprehensive summary of release preparation.

**Report format:**
```markdown
# 🎉 Plugin Release Preparation Complete: v1.0.5

## ✅ All Audits Passed (0 Issues)

| Audit Type | Status | Issues Found | Issues Fixed |
|------------|--------|--------------|--------------|
| Code Review | ✅ PASS | 23 | 23 |
| Security | ✅ PASS | 8 | 8 |
| Accessibility | ✅ PASS | 15 | 15 |
| i18n | ✅ PASS | 47 | 47 |
| Styling | ✅ PASS | 12 | 12 |
| **TOTAL** | **✅ PASS** | **105** | **105** |

## ✅ Visual Regression Testing

- Screenshots compared: 24
- Pixel-perfect matches: 24/24 (100%)
- Interactive features tested: 18
- Console errors: 0
- **Result:** ✅ PASS (100% identical to baseline)

## 📦 Production Build

- Admin JS/CSS: ✅ Built successfully
- Frontend CSS: ✅ Built successfully
- Translation POT: ✅ Generated
- Version numbers: ✅ Synced

## 🔖 Git Release

- Commit: `abc123def456`
- Tag: `v1.0.5`
- Pushed to: `origin/main`
- Release notes: ✅ Updated

## 📋 Next Steps

1. Create GitHub release with CHANGELOG
2. Submit to WordPress.org (if applicable)
3. Monitor error logs post-release
4. Update documentation website

## 🐛 Issues Fixed (Summary)

### Critical (3)
- SQL injection in report query
- XSS in comment author display
- Missing nonce verification in delete action

### High (12)
- Missing ARIA labels on vote buttons
- Untranslated error messages
- CSS specificity issues in dark mode

### Medium (35)
- Inconsistent text domain usage
- Missing keyboard navigation
- Suboptimal database queries

### Low (55)
- Code formatting inconsistencies
- Missing PHPDoc blocks
- Redundant CSS rules

**All issues resolved. Plugin is ready for release.**
```

---

## Workflow Commands Summary

```bash
# Phase 1: Baseline checkpoint
npm run test:checkpoint:baseline

# Phase 2: Run all audits
npm run audit:all

# Phase 3-4: Fix issues and re-audit (manual with expert.md)

# Phase 5: Visual regression testing
npm run test:checkpoint:verify

# Phase 6: Production build
cd admin && npm run build && cd .. && npm run build:css

# Phase 7: Git release
git add . && git commit -m "Release v1.0.5" && git tag -a v1.0.5 -m "Release version 1.0.5" && git push origin main && git push origin v1.0.5
```

---

## Automated Workflow Script (Optional)

Create `scripts/prepare-release.sh` for automation:

```bash
#!/bin/bash
set -e

VERSION=$1
if [ -z "$VERSION" ]; then
  echo "Usage: ./scripts/prepare-release.sh <version>"
  exit 1
fi

echo "🚀 Starting release preparation for v$VERSION"

# Phase 1: Baseline
echo "📸 Creating visual checkpoint..."
npm run test:checkpoint:baseline

# Phase 2: Audits
echo "🔍 Running audits..."
npm run audit:all

# Wait for manual fixes (Phases 3-4)
echo "⚠️  Review audit reports in reports/ directory"
echo "Fix all issues, then press Enter to continue..."
read

# Phase 5: Visual verification
echo "✅ Running visual regression tests..."
npm run test:checkpoint:verify

if [ $? -ne 0 ]; then
  echo "❌ Visual regression tests failed. Fix issues and try again."
  exit 1
fi

# Phase 6: Build
echo "🔨 Building production assets..."
cd admin && npm run build && cd ..
npm run build:css

# Update version
echo "📝 Updating version numbers..."
sed -i "s/Version: .*/Version: $VERSION/" comments-press-zone.php
sed -i "s/PRESSZONE_COMMENTS_VERSION', '.*'/PRESSZONE_COMMENTS_VERSION', '$VERSION'/" comments-press-zone.php
sed -i "s/Stable tag: .*/Stable tag: $VERSION/" readme.txt

# Generate POT
echo "🌐 Generating translation template..."
wp i18n make-pot . languages/comments-press-zone.pot

# Phase 7: Git
echo "📦 Creating git release..."
git add .
git commit -m "Release v$VERSION"
git tag -a "v$VERSION" -m "Release version $VERSION"
git push origin main
git push origin "v$VERSION"

echo "✅ Release preparation complete!"
echo "📋 Next: Review reports/ directory and create GitHub release"
```

---

## WordPress.org Plugin Header Requirements

### Main Plugin File Header (MANDATORY)

**File:** `comments-press-zone.php` (plugin root file)

**CRITICAL:** WordPress.org parsers are STRICT about plugin header format. Follow this exact format:

```php
<?php
/**
 * Plugin Name: Comments Press Zone
 * Plugin URI: https://github.com/resite/comments-press-zone
 * Description: A modern, high-performance commenting system for WordPress with voting, moderation, and customizable design.
 * Version: 1.0.5
 * Requires at least: 6.0
 * Requires PHP: 7.4
 * Author: PressZone Developers
 * Author URI: https://press.zone
 * License: GPLv2 or later
 * License URI: https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain: comments-press-zone
 * Domain Path: /languages
 *
 * @package CommentsPressZone
 */

if (!defined('ABSPATH')) {
    exit;
}
```

### Required Headers (ZERO TOLERANCE)

These headers are **MANDATORY** for WordPress.org submission:

| Header | Purpose | Example |
|--------|---------|---------|
| `Plugin Name:` | Display name in admin | `Comments Press Zone` |
| `Description:` | Short description (max 150 chars) | `A modern commenting system...` |
| `Version:` | Semantic versioning (x.y.z) | `1.0.5` |
| `License:` | Must be GPL-compatible | `GPLv2 or later` |
| `License URI:` | Link to license text | `https://www.gnu.org/licenses/gpl-2.0.html` |

### Recommended Headers

These headers are **strongly recommended**:

| Header | Purpose | Example |
|--------|---------|---------|
| `Plugin URI:` | Homepage/repository | `https://github.com/resite/comments-press-zone` |
| `Author:` | Developer name | `PressZone Developers` |
| `Author URI:` | Developer website | `https://press.zone` |
| `Requires at least:` | Min WordPress version | `6.0` |
| `Requires PHP:` | Min PHP version | `7.4` |
| `Text Domain:` | Translation domain | `comments-press-zone` |
| `Domain Path:` | Translation files directory | `/languages` |

### Header Format Rules

**CRITICAL:** WordPress.org parsers are sensitive to formatting:

- ✅ **Use single space after colon:** `Plugin Name: Comments Press Zone`
- ❌ **NO extra spacing:** `Plugin Name:       Comments Press Zone` (causes parser errors)
- Each header on its own line
- Headers must be in the main plugin file's opening comment block
- Comment block must start within the first 8KB of the file
- No empty lines between headers

---

## Pre-Release Checklist

### 1. Version & Changelog

- [ ] Version number updated in main plugin file header
- [ ] Version constant updated: `PRESSZONE_COMMENTS_VERSION`
- [ ] `readme.txt` version updated
- [ ] `CHANGELOG.md` updated with release notes
- [ ] Git tag created: `git tag -a v1.0.5 -m "Release 1.0.5"`

### 2. Plugin Headers

- [ ] All required headers present (Plugin Name, Description, Version, License, License URI)
- [ ] Headers use single space after colon (no extra spacing)
- [ ] License is GPL-compatible (GPLv2 or later)
- [ ] Text Domain matches plugin slug (`comments-press-zone`)
- [ ] Domain Path points to translation directory (`/languages`)

### 3. README.txt (WordPress.org Format)

- [ ] `readme.txt` exists in plugin root
- [ ] Stable tag matches plugin version
- [ ] Tested up to latest WordPress version
- [ ] Requires at least version specified
- [ ] Screenshots documented
- [ ] Installation instructions clear
- [ ] FAQ section helpful

### 4. Build & Assets

- [ ] Production build completed: `npm run build` (admin)
- [ ] Production CSS compiled: `npm run build:css`
- [ ] Assets optimized (images compressed, JS minified)
- [ ] No development files in release (node_modules, .git, .DS_Store)
- [ ] Source maps removed or .map files excluded from release
- [ ] 🚨 **Build documentation exists (CONTRIBUTING.md or BUILD.md)** - REQUIRED if plugin has webpack/SCSS
  - [ ] Prerequisites listed (Node.js version, npm version)
  - [ ] Build commands documented (`npm install`, `npm run build`, `npm run build:css`)
  - [ ] Development workflow explained (watch mode)
  - [ ] Source-to-output file mapping provided

### 5. Translation

- [ ] POT file generated: `wp i18n make-pot . languages/comments-press-zone.pot`
- [ ] All translatable strings use correct text domain
- [ ] 🚨 **NO variables in gettext functions** (`__($var, ...)` is FORBIDDEN - causes rejection)
- [ ] User-configurable database values NOT passed through `__()`
- [ ] JavaScript translations extracted to JSON
- [ ] Translation files in `/languages/` directory

### 6. Security & Compliance

- [ ] No hardcoded credentials or API keys
- [ ] All SQL uses `$wpdb->prepare()`
- [ ] All output escaped
- [ ] All input sanitized
- [ ] Nonces verified
- [ ] Capabilities checked
- [ ] No direct file access (all files have `defined('ABSPATH')` check)

### 7. Code Quality

- [ ] No PHP errors/warnings: `php -l *.php`
- [ ] WordPress Coding Standards: `phpcs --standard=WordPress`
- [ ] No console.log() statements in production JS
- [ ] No TODO/FIXME comments in release code

### 8. Documentation

- [ ] README.md updated (GitHub)
- [ ] readme.txt updated (WordPress.org)
- [ ] Inline documentation complete
- [ ] API documentation current

### 9. Testing

- [ ] Fresh install tested
- [ ] Upgrade from previous version tested
- [ ] Uninstall cleanup tested
- [ ] Works with latest WordPress
- [ ] Works with minimum WordPress version
- [ ] No JavaScript console errors
- [ ] No PHP warnings/notices

### 10. Legal & Licensing

- [ ] LICENSE.txt file present (GPLv2 or later)
- [ ] All third-party libraries compatible with GPL
- [ ] Attribution for third-party code included
- [ ] No proprietary code included

---

## readme.txt Template

WordPress.org requires a specific `readme.txt` format:

```
=== Comments Press Zone ===
Contributors: presszonedev
Tags: comments, discussion, moderation, voting, engagement
Requires at least: 6.0
Tested up to: 6.4
Requires PHP: 7.4
Stable tag: 1.0.5
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

A modern, high-performance commenting system for WordPress with voting, moderation, and customizable design.

== Description ==

Detailed description here...

== Installation ==

1. Upload the plugin files to `/wp-content/plugins/comments-press-zone/`
2. Activate the plugin through the 'Plugins' screen in WordPress
3. Use the Settings -> Comments Press Zone screen to configure

== Frequently Asked Questions ==

= Question? =

Answer.

== Screenshots ==

1. Screenshot description
2. Another screenshot

== Changelog ==

= 1.0.5 =
* Feature: Added X
* Fix: Fixed Y
* Enhancement: Improved Z

== Upgrade Notice ==

= 1.0.5 =
Important update with security fixes.
```

---

## Release Package Structure

### Files to Include

```
comments-press-zone/
├── comments-press-zone.php     # Main plugin file
├── readme.txt                  # WordPress.org readme
├── README.md                   # GitHub readme
├── LICENSE.txt                 # GPL license
├── CHANGELOG.md               # Changelog
├── includes/                  # PHP source
├── admin/                     # Admin interface
│   └── build/                 # Built admin assets
├── assets/                    # Frontend assets
│   ├── js/                    # Compiled JS
│   └── css/                   # Compiled CSS
├── templates/                 # PHP templates
├── languages/                 # Translation files
└── uninstall.php             # Cleanup on uninstall
```

### Files to Exclude

Create `.distignore` for WordPress.org SVN:

```
# Development files
.git
.gitignore
.github
.vscode
.editorconfig
.eslintrc
.prettierrc
*.md

# Node/NPM
node_modules
package.json
package-lock.json
admin/src-vanilla
admin/node_modules

# Build tools
webpack.config.js
tsconfig.json
.babelrc

# SCSS source (include only compiled CSS)
assets/scss

# Tests
tests
phpunit.xml
.phpunit.result.cache

# System files
.DS_Store
Thumbs.db
*.log
```

---

## Build Commands for Release

```bash
# 1. Update version numbers
# Edit comments-press-zone.php, readme.txt, package.json

# 2. Build production assets
cd admin && npm run build
cd .. && npm run build:css

# 3. Generate translation template
wp i18n make-pot . languages/comments-press-zone.pot

# 4. Run tests
composer test
npm test

# 5. Create release package
./scripts/build-release.sh  # Custom script to package plugin

# 6. Create git tag
git tag -a v1.0.5 -m "Release version 1.0.5"
git push origin v1.0.5
```

---

## WordPress.org Submission Process

### Initial Submission

1. Zip plugin directory (excluding .distignore files)
2. Submit via https://wordpress.org/plugins/developers/add/
3. Wait for automated review (scans for common issues)
4. Wait for manual review (can take 2-4 weeks)
5. Address any feedback from reviewers
6. Receive SVN repository access

### Updating Existing Plugin

1. Update version in main plugin file
2. Update `Stable tag:` in readme.txt
3. Build production assets
4. Commit to SVN trunk: `svn co https://plugins.svn.wordpress.org/comments-press-zone/`
5. Copy files to trunk: `cp -r * ~/svn-repo/trunk/`
6. Add new files: `svn add trunk/*` (if any new files)
7. Commit: `svn ci -m "Update to version 1.0.5"`
8. Tag release: `svn cp trunk tags/1.0.5`
9. Commit tag: `svn ci -m "Tagging version 1.0.5"`

---

## Common Release Issues

| Issue | Cause | Fix |
|-------|-------|-----|
| **Header parsing fails** | Extra spacing after colons | Use single space: `Name: Value` |
| **Version mismatch** | Different versions in file vs readme | Sync all version numbers |
| **Undefined functions** | Missing WordPress core checks | Add `if (!defined('ABSPATH'))` |
| **Translation not working** | Wrong text domain | Use `comments-press-zone` everywhere |
| **Assets not loading** | Dev paths in production | Use `plugin_dir_url(__FILE__)` |
| **Database errors on activate** | Missing dbDelta | Use `dbDelta()` for schema changes |

---

## Automated Release Workflow (Optional)

Consider using GitHub Actions for automated releases:

```yaml
# .github/workflows/release.yml
name: Release Plugin
on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build assets
        run: |
          cd admin && npm ci && npm run build
          cd .. && npm ci && npm run build:css
      - name: WordPress.org Deploy
        uses: 10up/action-wordpress-plugin-deploy@stable
        with:
          generate-zip: true
        env:
          SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
          SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
```

---

## Post-Release Tasks

After successful release:

1. [ ] Monitor WordPress.org support forums
2. [ ] Update plugin homepage/documentation site
3. [ ] Announce release (blog, social media, newsletter)
4. [ ] Monitor error logs for new issues
5. [ ] Track download stats
6. [ ] Respond to user reviews
7. [ ] Plan next release cycle

---

## WordPress.org Guidelines Summary

**Must follow for approval:**

1. GPL-compatible license
2. No "powered by" links or affiliate links
3. No advertising in admin (without opt-in)
4. No phone-home or tracking (without consent)
5. Secure coding (prepared SQL, escaped output, nonces)
6. No obfuscated code
7. Proper namespacing (no globals conflicts)
8. Include uninstall.php for cleanup

**Full guidelines:** https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

---

## This Skill Applies To

**Release preparation tasks ONLY:**
- Preparing WordPress.org submission
- Creating release packages
- Version bumps and tagging
- Pre-release compliance audits
- Building distribution files

**This skill does NOT apply to:**
- Daily development work
- Feature implementation
- Bug fixes
- Code refactoring
- Development builds