Changelog Deploy Mode

When to use

• 'deploy', 'deploy it', 'open the deploy PR', 'changelogfix', 'the deploy PR did not merge', 'reopen the PR'
• Korean triggers: 'deploy해줘', '배포해줘', 'deploy PR 올려줘', 'changelogfix', 'deploy 머지 안 됐어', 'PR 다시 열어줘'
• For a repo whose release goes straight into App Store / Play Store review (app review aware), show a review warning banner on the release notes and apply stricter cleanup.

⚠️ Model recommendation: the main job of this skill is writing release notes. Run it on a lite (haiku) model. It only analyzes commits and rewrites them in plain language, so a strong model is not needed.

A projectops-only skill. It works with the PROJECT-COMMON-RELEASE-CHANGELOG workflow: detect the release PR → if the body already has release notes, use them as is; otherwise generate them through the provider ladder (AI if a key exists → commit analysis) → finalize the version → update CHANGELOG → automerge. It does not wait for CodeRabbit (#566).

This skill does: push head → write release notes → open the release PR to base with the notes in the body → confirm automerge. On failure, fix mode closes the existing PR and re-triggers with a new PR. The notes use the Summary by CodeRabbit format. Only the format name says CodeRabbit; no bot is needed. The workflow respects that body and parses it and automerges right away.

Arguments: $ARGUMENTS

Talk to the user in their language (or the configured language preference). The message templates in this skill and its references give the meaning; say them in that language.

Do not use when

• Ordinary commit or PR work that is not a deploy
• The project has no release head branch on the remote (the development branch fixed in [Before you start §5], standard develop). This skill only handles a head → base release PR. The branch name itself is not fixed. Exception: if detect-release-context returns release_shape: deploy_branch (no development branch, main → deploy), follow its release_branches and release_steps. Do not use a missing develop as head
• The repository has no PROJECT-COMMON-RELEASE-CHANGELOG workflow

Core principles (safety rules — do not change their meaning)

• Never run git push --force
• Never close or open a PR without user confirmation (fix mode)
• Show the release-note body to the user before creating the PR (deploy 5.5 / fix 4.5). Only when auto mode is explicitly configured: show it and proceed at once
• App review repos (APP_RELEASE == true) need approval every time, even in auto mode. The release goes straight into store review, so a blanket delegation does not apply (#821)
• Before the release PR, merge the reverse difference base → head first (deploy 1-1). The release workflow leaves the version commit only on base. Skip this and the next deploy hits a version-file conflict
• Creating the PR is the last step, after the release notes are written (see the race note below)
• Never show config key names or file paths to the user. For the auto/manual toggle, take a plain-language answer and let the agent update the config
• Do not hard-code branches (#456). The source of truth for head/base branches and the provider is detect-release-context (version.yml) (#842). The config is only a per-repo record for repos without version.yml; branch and provider keys in the global config are not read. develop/main/commit are only fallbacks when no value can be read. Replace develop/main in the steps below with the resolved values
• The user never edits the config by hand. If you can decide, do not ask. Ask in plain language only when it is unclear, record the answer, and never ask again once recorded

What you want → command → details

Every command is PYTHONIOENCODING=utf-8 {PYTHON} {SCRIPTS}/changelog_cli.py <command>.

Before you start

1) Scripts · OWNER · REPO · PYTHON · PROJECT_ROOT (once)

If the fixed entry point exists, skip the search below (#942): ~/.projectops/bin/projectops_cli.py appears after the CLI runs at least once. On every call it finds the newest installed script and passes the arguments through. A plugin update during the session does not pin you to an old path. PYTHONIOENCODING=utf-8 python3 ~/.projectops/bin/projectops_cli.py changelog-deploy <subcommand> ... (if it is missing or returns scripts_not_found, use the search below). If the response has newer_installed, call again through this entry point.

⚠️ Do not store the command in a variable and call it (zsh). P="python3 …/changelog_cli.py"; $P deploy-status … does not word-split in zsh. The whole command is read as one file name and ends with exit 127 (command not found). To shorten it, wrap it in a function: cl() { PYTHONIOENCODING=utf-8 "$PYTHON" "$SCRIPTS/changelog_cli.py" "$@"; }; cl deploy-status …

Bash is stateless. Variables and export do not survive between calls. Remember the values printed below and write the real values into every later block (in the {PYTHON} slots and so on, or redeclare them on the first line of the block, like OWNER="..."; ...). Never assume a variable from an earlier call is still alive.

PROJECT_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
PYTHON=$(for _py in python3 python; do _path=$(command -v "$_py" 2>/dev/null) || continue; "$_path" -c "import sys; sys.exit(0)" 2>/dev/null && echo "$_path" && break; done)
[ -z "$PYTHON" ] && { echo "❌ Python not found."; exit 1; }
SKILL=pro-changelog-deploy; ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
[ -d "$ROOT/skills/$SKILL/scripts" ] || for B in ~/.claude/plugins/cache ~/.codex/plugins/cache ~/.gemini/extensions ~/.pi/agent/git; do
  H=$(find "$B" -maxdepth 8 -type d -path "*/projectops/*skills/$SKILL/scripts" 2>/dev/null | sort -V | tail -1)
  [ -n "$H" ] && { ROOT="${H%/skills/$SKILL/scripts}"; break; }
done
# Home-copied installs from npx projectops: GitHub Copilot and Cursor (#200)
[ -d "$ROOT/skills/$SKILL/scripts" ] || for B in ~/.copilot ~/.cursor; do [ -d "$B/skills/$SKILL/scripts" ] && { ROOT="$B"; break; }; done
SCRIPTS="$ROOT/skills/$SKILL/scripts"
[ -d "$SCRIPTS" ] || { echo "projectops skill scripts not found. Check the plugin installation."; exit 1; }
REMOTE_URL=$(git remote get-url origin 2>/dev/null || echo "")
OWNER=$(echo "$REMOTE_URL" | sed -E 's|.*github\.com[:/]([^/]+)/.*|\1|')
REPO=$(echo "$REMOTE_URL" | sed -E 's|.*github\.com[:/][^/]+/([^/.]+)(\.git)?$|\1|')
echo "PROJECT_ROOT=$PROJECT_ROOT PYTHON=$PYTHON SCRIPTS=$SCRIPTS OWNER=$OWNER REPO=$REPO"
PYTHONIOENCODING=utf-8 "$PYTHON" "$SCRIPTS/changelog_cli.py" detect-release-context --project-root "$PROJECT_ROOT"

From the detect-release-context output, remember branches (branches and provider), branches_source, conflict, signals and hint (app review signals), release_shape, and release_language (notes language, headings, store languages — step 5). If release_shape == deploy_branch (origin has no development branch but has deploy), set HEAD_BRANCH/BASE_BRANCH from release_branches (usually main → deploy) instead of branches, and follow release_steps. Confirm this pair with the user once. If it is standard, nothing changes. The CLI reads owner/repo from the origin URL and the config from its fixed path on its own (read-only). Only when you look at another repo, pass them explicitly: detect-release-context --project-root {PROJECT_ROOT} --owner {OWNER} --repo {REPO}.

2)~5) Resolve values from the config — details in references/config.md

Provider three-step rule (#821): branches.provider is the value the CLI already resolved. ① explicit changelog.provider in version.yml → ② unset + .coderabbit.yaml at the repo root → coderabbit → ③ neither → commit. The workflow uses the same rule, so the decisions never diverge. github-ai (service shut down) comes back from the CLI as commit. Never ask about the provider.

Choosing the mode

• deploy mode: "deploy it", "open the deploy PR" (Korean: "deploy해줘", "배포해줘", "PR 올려줘") → start at step 1
• fix mode: "it did not merge", "changelogfix", "do it again", "retry the PR" (Korean: "머지 안 됐어", "changelogfix", "다시 해줘", "PR 재시도") → start at fix step 1

deploy mode — steps and decisions (commands and messages in references/deploy-steps.md)

If the preferences have a template, use it as the release-note lead-in.

Step 1 Check commit state — run git status --short, git fetch origin, the current branch, git log origin/{BASE}..HEAD and git log origin/{HEAD}..HEAD each separately.

• If the uncommitted changes are yours (made in this task), stop and commit them first.
• If they are someone else's changes whose intent you do not know (another session), leave them alone, list them for the user and continue. A deploy only pushes commits. But if the 1-1 merge overlaps those files and fails, stop and hand it to the user.
• If the current branch is not HEAD_BRANCH, stop and tell the user. Do not switch branches on your own (another session may have moved it).
• Only when both logs are empty, say "nothing to deploy" and stop. If either has commits, go to 1-1.

Step 1-1 Bring base up to date (never skip) — the order is the contract:

1. git pull --rebase origin {HEAD} first, to align head with the remote (if you pull --rebase after making a merge commit, the merge gets undone). If the working tree has someone else's uncommitted changes and pull --rebase is refused, do not stash. Align with git fetch origin → git merge --ff-only origin/{HEAD} (this works on a dirty tree when no files overlap). If it cannot fast-forward (it diverged from your local commits), stop and ask. 2~3. PYTHONIOENCODING=utf-8 {PYTHON} {SCRIPTS}/changelog_cli.py sync-base --head {HEAD} --base {BASE} --project-root {PROJECT_ROOT} — fetch > check the reverse difference > merge it if there is one, all in one call. On in_sync (no difference) or merged, go to the next step. On merge_conflict, stop and agree on the resolution with the user. Do not run merge --abort, reset or drop one side on your own. On wrong_branch, tell the user without switching branches.
   • Before starting, look at branches_check from detect-release-context: if it has a warning (branch missing, 0 commits ahead), the configured head/base pair may differ from this repo's real release flow. Confirm with the user.

Step 1.5 Release context awareness — hint × APP_RELEASE:

Step 2 Confirm before push — show the list of commits to push and get approval. Step 3 Push — git push origin {HEAD}. Do not pull --rebase again here (it undoes the 1-1 merge). On non-fast-forward, never force push: run git pull --rebase=merges origin {HEAD} and push again (if someone else's uncommitted changes block it, stop and ask — no stash). The version does not change here (the release PR finalizes it).

⚠️ Step order (prevents a race condition — always follow it) RELEASE-CHANGELOG checks the body when the deploy PR is opened. If there is no Summary by CodeRabbit, it resets the body. If you create the PR with an empty body first, the workflow cuts in and the notes disappear. So the order is commit analysis (4) → write notes (5) → approval (5.5) → create the PR with the notes in the body (6), with PR creation last. (Do not change the workflow logic.)

Step 4 Commit analysis — git log origin/{BASE}..origin/{HEAD} (based on origin/{HEAD}, not HEAD — workflows such as the README version update can put the remote ahead). Classification and rewrite rules: references/release-notes.md.

Step 5 Write the release notes — branch on PROVIDER:

Writing up front is safe whatever the provider: the workflow respects a Summary by CodeRabbit that the skill put in first (already_found), regardless of provider. The only exception is commit "leave it". Write the notes to ~/.projectops/tmp/{OWNER}__{REPO}__release_notes.md with the skeleton below (create the tmp folder first if it does not exist). You may omit the marker comments and the ## Summary by CodeRabbit header; create-pr/update-pr add them when missing. Use only these five category names and delete empty categories. Open references/release-notes.md only when you need good/bad examples or the approval messages.

Write the notes in release_language.notes_language, and copy the heading values from release_language.headings character for character (#977). It is the same rule the workflow's generator uses (version.yml language), so one CHANGELOG.md never mixes two languages. If the user asks for a different language for this deploy only ("in English this time"), follow that.

## {headings.heading}

* **{headings.feat}**
  * (feat — a change the user can feel, one line, 40 characters or fewer)

* **{headings.fix}**
  * (fix)

* **{headings.improve}**
  * (refactor·perf·style)

* **{headings.docs}**
  * (docs)

* **{headings.etc}**
  * (the rest)

Rewrite rules: do not copy commit messages. Drop file, class and function names, prefixes like feat:, issue numbers and URLs, and internal details such as libraries and APIs. Write one line from the user's point of view. If APP_RELEASE == true, drop internal, CI/CD, test and build items entirely (the notes become the store release notes). After step 5 — per-language store translation drafts — if release_language.store.translation_targets is not empty, read references/store-translations.md and append translation drafts to the end of the notes file (translate them yourself, without calling an external AI). If it is empty, this step does not exist. If release_language.store.fixed_whats_new is set, that workflow uploads the fixed text to the store instead of the notes — say so in one line on the approval screen.

⚠️ AGENT MUST READ: after creating the notes file, always run through step 6 (PR creation). But do not jump there directly; go through step 5.5 first.

Step 5.5 Approval gate (messages in references/release-notes.md):

• 🔒 If APP_RELEASE == true, use B (manual) regardless of AUTO_APPROVE. Print the review warning banner above the body first and do not show C. Even for "leave it", ask right before step 6: "Leave the notes to automatic generation and create a deploy PR that leads into app review?"
• commit "leave it" (not app review) → skip 5.5 and go to step 6.
• A. Auto (AUTO_APPROVE == true AND APP_RELEASE != true) — only show the notes and go straight to step 6. If the user says "ask me first" ("확인받게 해줘"), update the config before step 6 and switch to B.
• B. Manual (AUTO_APPROVE == false OR APP_RELEASE == true) — show the notes and get approval. On an edit request, rewrite the notes and go back to the start of 5.5 (loop until approved).
• C. First-run automation offer — only when B was approved + CONFIG_HAS_KEY == false + APP_RELEASE != true, once, right before step 6.

Step 6 Create the deploy PR — first look for an open deploy PR with deploy-status --head. If one exists, do not close it; reuse it and update only the body with update-pr (opening a new one re-triggers the workflow and risks a body reset). If none exists, pass the absolute path of the notes file to create-pr as the body (an empty string for "leave it"). Delete the notes file when done. Always pass --project-root {PROJECT_ROOT} to create-pr. Action per rejection code:

Step 7 Verify automerge — decide with a single deploy-status --pr {N} --base {BASE} (no ad-hoc Python in /tmp). See the verdict table below.

Step 8 Report the result — push target, PR number, whether notes were written, Actions link.

deploy-status verdict → next action

fix mode — steps and decisions (commands and messages in references/fix-steps.md)

1. Check state — deploy-status --base {BASE} (without --pr it finds the open deploy PR on its own). no_pr → go to step 3 / merged → report and stop / otherwise → remember pr.number as EXISTING_PR and go to step 2.
2. Close the existing PR — only after the user confirms, update-pr ... "-" --state closed.
3. Commit analysis — same as deploy step 4. If you entered fix mode directly and APP_RELEASE == unset, run deploy step 1.5 once before this step.
4. Write the notes — same location and structure as deploy step 5 (including per-language store translation drafts — references/store-translations.md). Do not jump straight to step 5. 4.5. Approval gate — exactly the same branches as deploy step 5.5 (A/B/C; for app review, banner + manual approval).
5. Create the new PR — create-pr with the notes in the body (title 🚀 Deploy {YYYYMMDD} (재시도), where 재시도 means "retry"). In fix mode too, creating the PR is the last step.
6. Report the result, then verify with deploy-status --pr.

Notes

• Always verify with deploy-status after creating or retrying a PR. Do not write ad-hoc status-check Python into /tmp.
• Create the PR with the notes in the body. If you create it empty and fill it later, the race condition wipes the notes.
• Do not skip the approval gate. Only when auto mode is explicitly configured, show and proceed; app review repos need approval even in auto mode. Speak in plain language only and never surface config keys or paths.
• The only criteria for moving to fix mode are in the verdict table above (missing_coderabbit_summary twice in a row · workflow_failed · waiting_for_automerge over 10 minutes = stuck). waiting_for_workflow (queue delay) is not one of them — do not close and reopen.
• If a deploy PR already exists, reuse it instead of closing it.
• curl exit 35 (SSL error) on a Windows internal network: add --ssl-no-revoke to curl calls (../references/common-rules.md, Windows internal network section).

Customize

Your own language, tone and rules apply: see ../references/preferences.md. Read them once at the start: run the snippet in ../references/preferences.md with SKILL_ID=pro-changelog-deploy. Keys for this skill: template (release-note lead-in) plus the common tone, rules. The personal language preference does not change the release notes: they land in the team CHANGELOG.md, so their language is the repo's version.yml language (the key the workflow reads). Set that key to change it for the team; for one release, just ask. Preferences change presentation only; approval gates, secret protection and --dry-run stay in force.