0 added, 2 removed. Audit A to A.
---
name: release-init
description: Detect project type and generate a tailored project-level /release skill. Run once per project to set up releasing.
tags: [release, init, scaffold, meta]
---
# Release Init
## Protocol
### 1. Check for existing project skill
Look for `.claude/skills/release/SKILL.md` in the repo root.
If it exists, ask:
> Project release skill already exists. Overwrite with fresh detection? (y/n)
Stop if user declines.
### 2. Detect project type
Scan the working directory. First match wins:
| Marker | Type |
|---|---|
| `ProjectSettings/ProjectSettings.asset` (search recursively) | `unity` |
| `package.json` + `src-tauri/` directory | `tauri` |
| `package.json` | `node` |
| `*.xcodeproj` or `*.xcworkspace` (in root) | `ios-native` |
| `build.gradle` or `build.gradle.kts` (in root) | `android-native` |
| None of the above | `generic` |
### 3. Discover version files and current values
Read current version values from the detected files:
**unity:**
- Find `ProjectSettings/ProjectSettings.asset` (may be nested, e.g. `ProjectName/ProjectSettings/`)
- Read: `bundleVersion` (display version), `AndroidBundleVersionCode`, `buildNumber.iPhone`
- Report all three values
**tauri:**
- `package.json` → `version`
- `src-tauri/tauri.conf.json` → `version`
- `src-tauri/Cargo.toml` → `version`
**node:**
- `package.json` → `version`
**ios-native:**
- Find `Info.plist` → `CFBundleShortVersionString`, `CFBundleVersion`
**android-native:**
- `build.gradle` or `build.gradle.kts` → `versionName`, `versionCode`
**generic:**
- Ask user: "Where does your version live? (file path and field name)"
### 4. Detect platforms and recommend tagging approach
Determine if multi-platform based on project type and evidence:
| Type | Signal | Recommendation |
|---|---|---|
| `unity` | Has both Android + iOS build settings in ProjectSettings | Multi-platform: `android`, `ios` |
| `unity` | Only one platform target | Single platform, no platform tags |
| `tauri` | Desktop app | Single artifact, no platform tags |
| `node` | Web app / server | Single deploy, no platform tags |
| `ios-native` | iOS only | Single platform, no platform tags |
| `android-native` | Android only | Single platform, no platform tags |
Present the recommendation WITH reasoning.
Wait for confirmation. User may correct platforms (e.g., "also shipping to Steam") or remove some.
### 5. Handle greenfield / untracked repos
Check `git tag -l "v*"`:
- **Tags exist** — note the latest tag, continue.
- **No tags exist** — ask:
> No version tags found in git. Is this a first release, or has this project shipped before without tags?
- **First release** — suggest starting at `1.0.0` (user can override).
- **Previously shipped** — ask for current live versions:
> What are the current live versions? (e.g., "Android 4.0.5 build 41, iOS 1.2.9 build 12")
Create a baseline tag on the current commit so future releases have a reference point. For multi-platform, also create platform baseline tags.
### 6. Present full summary for confirmation
Show everything in one block:
```
Project type: unity
Version files:
- PuzzleSnake/ProjectSettings/ProjectSettings.asset
- bundleVersion (display version): 4.0.5
- AndroidBundleVersionCode: 40
- buildNumber.iPhone: 1
Platforms: android, ios
Tagging: v{version} + v{version}-android, v{version}-ios
Qualification: clean git, on master
Git baseline: v4.0.5 (to be created)
Generate .claude/skills/release/SKILL.md with these settings?
```
Wait for user approval.
### 7. Generate the project-level skill
Read `assets/template.md` (sibling to this SKILL.md) and fill all `{{placeholders}}` per the map in step 8 below, then write to `.claude/skills/release/SKILL.md`.
### 8. Fill the template
Replace all `{{placeholders}}` with detected values:
- `{{project_type}}` — detected type
- `{{version_files_list}}` — bullet list of file paths and field names with current values
- `{{platforms_or_none}}` — comma-separated platform list, or `none (single-platform)`
- `{{main_branch}}` — from `git branch --show-current` or detect default
- `{{bump_instructions}}` — project-specific Edit instructions for each version file. Format: one Edit call per file showing the old version string and new version string. Example:
```
Edit `package.json`: change `"version": "1.2.3"` → `"version": "{new_version}"`
Edit `src-tauri/tauri.conf.json`: change `"version": "1.2.3"` → `"version": "{new_version}"`
```
- `{{version_file_paths}}` — space-separated paths for `git add`
- `{{platform_build_number_instructions}}` — how to read each platform's build number. Format: one read instruction per platform file. Example:
```
Read `ProjectSettings/ProjectSettings.asset` → `AndroidBundleVersionCode` for android; `buildNumber.iPhone` for ios.
```
- Remove the `{{#if platforms}}...{{/if}}` block entirely if single-platform
The generated skill should be clean markdown with no template syntax remaining.
### 9. Commit
- Doc-sync scan first when the gate is installed: if `.claude/hooks/docsync-scan.sh` exists, run `bash .claude/hooks/docsync-scan.sh` as its own Bash call and resolve any staleness it surfaces — the scan self-stamps the token the gate consumes. Where the gate isn't installed the script is absent → skip the scan, commit directly. Scan and commit are separate calls.
-
```bash
git add .claude/skills/release/SKILL.md
git commit -m "chore: add project release skill"
```
### 10. Report
> Project release skill generated at `.claude/skills/release/SKILL.md`.
> From now on, just run `/release`.
Then offer to push this commit: **"Push now? (y / skip)"** — push only on yes, skip by default if silent.
## Rules
- Push only on explicit confirmation — offer after the commit, never force, never unannounced.
- Always confirm detection results before generating.
- Surface ambiguous detection with the candidate interpretations before proceeding.
- Verify all `{{placeholders}}` are replaced before writing the file.