メニュー
Cut a release — promote develop to main, generate changelog, tag a semver version, and publish release notes. Use when Project Manager marks a milestone complete and the user approves.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | release |
| description | Cut a release — promote develop to main, generate changelog, tag a semver version, and publish release notes. Use when Project Manager marks a milestone complete and the user approves. |
You are the Conductor running a release cycle. The target: main now reflects the completed milestone, with a tag and a public-facing set of release notes.
milestone-checkpoint for that milestone approved by the user.develop.develop.If any precondition fails, abort and report which.
docs/ssot/decisions/adr-NNN-release-vX.Y.Z.md if non-obvious.Technical Writer compiles the changelog from:
Write to CHANGELOG.md:
## [vX.Y.Z] — YYYY-MM-DD
### Added
- <feat entries>
### Changed
- <refactor/perf/style entries>
### Fixed
- <fix entries>
### Removed
- <entries marked BREAKING CHANGE or removing features>
### Notes
- <ADRs, migrations, operational notes>
Open change request from develop to main with:
[release] vX.Y.ZReviewers:
Unanimous approval required.
atelier-check-reviews <CR> --policy unanimous
<forge> merge # NO --delete-source-branch for release CRs
git checkout main && git pull
git tag -a vX.Y.Z -m "Release vX.Y.Z"
git push origin vX.Y.Z
develop is not deleted — it is the ongoing integration branch.
gh release create vX.Y.Z --notes-file <path>glab release create vX.Y.Z --notes "..."docs/process/release-process.md.docs/roadmap/roadmap.md to mark milestone as released.docs/roadmap/lessons-learned.md with release retrospective.atelier-notify release "<summary>".main without a passing CI build.docs/process/release-process.mddocs/process/change-review-workflow.mddocs/process/git-flow.mdCHANGELOG.mdAdd a new project-specific agent mid-project, with Chief AI Officer drafting the definition and justification, and the user approving. Use when project scope expands (new domain emerges, a parallel track is needed, or critical expertise is missing) during Phase 2.
Add a new MCP server to the project mid-project. Wraps the capability-management procedure — external MCP search, ADR draft, .mcp.json update, user install instructions, and capability-log entry. User approval is mandatory regardless of involvement level. Use when an authorized agent identifies a missing external integration.
Add a new project-specific skill mid-project. Wraps the capability-extension procedure — reuse audit, skill-creator invocation, capability-log entry, user approval, and reload reminder. Use when an authorized agent identifies a missing helper-skill capability during Phase 1 STEP 2/3 or anywhere in Phase 2.
Re-activate a Phase 1 agent from STANDBY because a requirement, design, roadmap, team-composition, or documentation drift has been detected. The user invokes this with the target agent name and a brief reason. Use when Phase 2 cannot proceed without a Phase 1 decision.
Produce a production hotfix — branch from main, fix, change-review back into main, then merge the fix back into develop. Use when a bug in the released version (main) must be patched without waiting for the normal develop→main cycle.
Initialize a new project with a structured, multi-agent workflow — discovery interview, operating preferences, technical design, agent team formation, roadmap construction, documentation consolidation, and a final user approval gate. Use when the user starts a fresh project and wants a rigorous setup before any code is written.