一键导入
github-release
Automate GitHub release workflows including version management, CHANGELOG updates, PR creation, and GitHub Release publishing for multi-agent-ff15.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Automate GitHub release workflows including version management, CHANGELOG updates, PR creation, and GitHub Release publishing for multi-agent-ff15.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Automate GitHub release workflows including version management, CHANGELOG updates, PR creation, and GitHub Release publishing for multi-agent-ff15.
Create or customize repository operations and facet files. Use when adding or editing builtin or project-authored workflow YAML, jobs, instructions, skills, policies, or output-contracts, or when diagnosing operation routing, prompt composition, instruction placeholders such as output, setting, or root placeholders, source-aware operation refs, and debug-preview behavior.
Analyzes git changes, drafts localized PR titles and bodies, and assists with creating comprehensive pull requests. Use when user wants to create a PR, review changes before PR, or needs help drafting PR descriptions. Triggers on phrases like 'create PR', 'make a pull request', 'draft PR description', 'what changed in this branch', 'prepare PR'.
Organize post-implementation manual verification steps, execution methods, and expected results into a checklist-oriented dated Markdown report. Use when the user asks for verification steps, acceptance checks, expected outcomes, or manual test notes for UI, API, job, permission, or notification changes after implementation.
Use when you want a short reference for the relationships and traits of FF15-derived agents such as Noctis, Gladiolus, Ignis, and Prompto.
Read this before safely changing operation YAML, project workflow authoring paths, source-aware operationRef handling, facet source resolution, output contracts, output placeholders, or workflow-related tests.
| name | github-release |
| description | Automate GitHub release workflows including version management, CHANGELOG updates, PR creation, and GitHub Release publishing for multi-agent-ff15. |
Automate the release process for multi-agent-ff15. The actual GitHub Release (tag + release notes) is created by GitHub Actions after the release branch is merged into main.
package.jsonrelease/vX.Y.Z branch)Create release branch from main:
git checkout main && git pull
git checkout -b release/vX.Y.Z
Bump version in package.json:
python3 .opencode/skills/github-release/scripts/bump_version.py <major|minor|patch|version>
Update CHANGELOG.md:
python3 .opencode/skills/github-release/scripts/update_changelog.py <create|update> <version> <owner/repo>
Commit and push to the release branch:
git add package.json CHANGELOG.md
git commit -m "chore: release vX.Y.Z"
git push origin release/vX.Y.Z
Create a PR (release/vX.Y.Z → main):
python3 .opencode/skills/github-release/scripts/create_pr.py release/vX.Y.Z main <version>
Or use gh pr create directly.
Review and merge the PR into main. Do NOT merge yourself — wait for approval.
0.4.1) and run.package.json version matches the inputCHANGELOG.mdvX.Y.Z# Check version configuration
python3 .opencode/skills/github-release/scripts/check_versions.py
# Bump version
python3 .opencode/skills/github-release/scripts/bump_version.py <major|minor|patch|version>
# Update CHANGELOG
python3 .opencode/skills/github-release/scripts/update_changelog.py <create|update> <version> <owner/repo>
# Create PR (requires gh CLI)
python3 .opencode/skills/github-release/scripts/create_pr.py <from_branch> <to_branch> <version>
Note:
create_release.pyis superseded by GitHub Actions. Use the Actions workflow for all GitHub Release creation.
NEVER work on main directly — All version bumps and CHANGELOG updates go on a release/vX.Y.Z branch. Direct push to main is prohibited.
ALWAYS review CHANGELOG.md after script update — Inspect formatting, section headers, blank lines, and link references before committing.
Trigger GitHub Actions AFTER the PR is merged — The "Release" workflow reads from main, so it must be run only after the release branch is merged.
ALWAYS confirm the next version with the user if it was not explicitly specified — Never infer or auto-select the release version from package.json, tags, CHANGELOG, or branch state. If the user says "release it" without clearly naming the next version, stop and ask which version should be released before performing any release action.
Only use a version automatically when the user explicitly provided it — Examples: release 0.8.1, publish v1.2.0, or bump patch and release. Otherwise, confirmation is mandatory.
gh) installed and authenticatedpackage.json in the root (used for version tracking)CHANGELOG.md with entries in the format ## [X.Y.Z] - YYYY-MM-DD