SAFEGUARD: This skill must NEVER be invoked autonomously by the assistant. It is exclusively user-invoked — only run when the user explicitly types a

--

prefixed shorthand (e.g.

--cp

,

--cppr

) in their message. The assistant must never decide on its own to call this skill.

• Never delete branches. Do not pass

  --delete-branch

  to any

  gh

  command. Do not run

  git branch -d

  or

  git push origin --delete

  . If a tool or command would delete a branch, skip that flag or step entirely. GitHub deletes the remote head branch itself on merge (

  delete_branch_on_merge

  ) — that is the repo setting doing it, not you, and it is not a reason to start passing the flag.
• Execute steps in the order they appear in the shorthand (left to right).
• If a step fails, stop and report — don't continue to the next step.
• For

  c

  : follow the full commit protocol, but scope the staged files to only the work done in this conversation. Derive the relevant file set from the conversation context — which files were read, edited, or created during this session. Run

  git status

  to see everything dirty, then stage only the files that belong to this task. If there are other dirty files unrelated to the current task (e.g. from parallel agent sessions), leave them unstaged. If you're unsure whether a file is in scope, exclude it and mention it. Never use

  git add .

  or

  git add -A

  . Before staging, output a scoping summary in this exact format:

  In scope:
  • src/foo/bar.ts
  • src/foo/baz.ts
  
  Excluded:
  • src/other/thing.ts  (reason)

m

1. Resolve the author's Slack user ID:
   • Check if

     SLACK_USER_ID

     is set in the environment (

     echo $SLACK_USER_ID

     ).
   • If not set: ask the user "Was ist dein Slack-Handle? (z.B.

     tim

     )" → call

     mcp__slack__lookup_user_by_email

     or

     mcp__slack__users_lookupByUsername

     to resolve to a user ID → then ask "Soll ich die ID als

     SLACK_USER_ID=<id>

     in

     .env

     speichern?" If yes, append the line to

     .env

     .
2. Fetch the merged PR details:

   gh pr view --json title,url,body

3. Compose a one-liner (see below), then show it as a preview:

   Slack #dev: @tim: repo-name -> PostHog läuft jetzt via Reverse Proxy unter

   /_s

   — kein Adblocker-Problem mehr. <PR-URL> Posten?

4. If yes: post via

   mcp__slack__post_message

   with

   channel: "#dev"

   , using

   <@USER_ID>

   for the mention so Slack renders it as a clickable @-mention. If no: skip silently.
5. Wait for the user's response to step 3/4, then stop. The merge is finished. Do not offer

   --close

   or any other follow-up — nothing needs cleaning up after a merge.

<@USER_ID>: <repo-name> -> <one-liner> <PR-URL>

• PR title:

  feat: add reverse proxy for PostHog

• Body: routes

  /_s

  to PostHog, avoids adblockers
• →

  <@U0123ABCD>: colin -> PostHog läuft jetzt via Reverse Proxy unter /_s — kein Adblocker-Problem mehr. https://github.com/…

git pull --ff-only

• No upstream configured →

  git fetch origin

  , then

  git merge --ff-only origin/<branch>

  if that ref exists. Missing on origin → report and stop.
• Fast-forward not possible (local and remote diverged) → git aborts on its own; report the divergence and stop. Never fall back to a merge or rebase to force it through.
• Uncommitted changes are fine — git refuses the update only if they collide; then report and stop.
• Touches no other branches, ships nothing.

--pub

wf=$(grep -rl release-please .github/workflows/ 2> /dev/null | head -1)

1. Find the release PR —

   gh pr list --base "$trunk" --state open --label "autorelease: pending" --json number,title,url,headRefName

   • Not found → stop and report: "Kein offener Release-PR. Es wurde seit dem letzten Release nichts nach

     <trunk>

     gemerged, oder release-please läuft noch — prüf die Actions."
   • Never create it by hand. A hand-made PR carries no version bump and no changelog.
2. Show what would ship —

   gh pr diff <number> -- CHANGELOG.md

   and print the new version from the PR title. Ask: "Release

   <version>

   mit diesen Änderungen veröffentlichen?" Wait for the answer.
3. Check mergeability —

   gh pr view <number> --json mergeable,mergeStateStatus

   • MERGEABLE

     → proceed.

   • CONFLICTING

     → stop and report. Do not resolve conflicts in a release PR by hand — release-please regenerates it; fix the cause on the trunk instead.

   • UNKNOWN

     → re-poll up to 3 times (5 s apart). If still

     UNKNOWN

     , report and stop.
4. Squash merge —

   gh pr merge <number> --squash

5. Watch the run this merge created.

   gh run list --limit 1

   still returns the previous release run until the new one is queued, and watching that one reports a stale success. Pin the run to the merge commit:
   bash

   sha=$(gh pr view <number> --json mergeCommit --jq '.mergeCommit.oid')
   for _ in $(seq 12); do
     id=$(gh run list --workflow="$(basename "$wf")" --json databaseId,headSha \
            --jq ".[] | select(.headSha==\"$sha\") | .databaseId" | head -1)
     [ -n "$id" ] && break
     sleep 10
   done
   [ -n "$id" ] && gh run watch "$id" || echo "Kein Release-Run für $sha nach 2 min — prüf die Actions."

   Report the outcome. If the deploy step failed after the tag was created, tell the user the repair path: Actions → the release workflow → Run workflow → enter the tag.
6. Slack summary — same protocol as after

   m

   (see above), with the version in the one-liner.
7. Deploy annotation — if the repo annotates deploys in its analytics, remind the user:

   [DEPLOY] <tag>

   per the repo's analytics conventions.

1. Not a worktree? If the main checkout is the current directory (

   git rev-parse --git-common-dir

   resolves inside it), there is nothing to close. Report and stop.
2. Superset-owned worktree — do nothing. The path lives under

   ~/.superset/worktrees/

   . Superset runs

   .superset/teardown.sh

   and removes the worktree when the session closes, so

   --close

   has no work left. Report that and stop.
   Only exception: the user wants the database branch released now while keeping the session open → run the repo's teardown script (

   bash scripts/teardown.sh

   — always exits 0, safe to run twice) and leave the directory alone.
3. Anywhere else — one command, run from the main checkout:
   bash

   cd "$(git rev-parse --path-format=absolute --git-common-dir)/.." && yarn wt:remove <worktree-path>

   worktree-remove.sh

   already chains both halves: it runs

   teardown.sh

   inside the worktree, then

   git worktree remove

   . Do not call

   teardown.sh

   separately first.

git grep -q '"wt:remove"' -- package.json

test -f scripts/worktree-remove.sh

package.json

WORKTREE-SETUP.md

git worktree remove

• Run it from the main checkout, not from inside the worktree. The command deletes the directory it is pointed at; standing in that directory leaves the shell with no working directory and every later command fails.

• --close

  ends the session's work. Nothing can run afterwards — the working tree is gone. Finish everything else first, report, and treat it as the last action.

git worktree remove

--force

delete_branch_on_merge

--close

epic/*

epic/<name>

yarn neon branches delete epic/<name>

?

?

--cp?r

?

c

git status

git diff --stat

p

pr

gh pr view --json state,mergeable,url

m

gh pr view --json state,mergeable,mergeStateStatus,baseRefName

--squash

--merge

ff

git fetch origin

git rev-list --left-right --count <branch>...origin/<branch>

release

mergeable

--pub?

close

wt:remove

• --c?

  → summarise uncommitted changes

• --cp?

  → commit, then skip (p? is a no-op)

• --cppr?

  → commit → push → inspect PR status (don't create)

• --cpprm?

  → commit → push → create PR → report merge readiness (don't merge)

• --ff?

  → show how far behind the remote the branch is (don't pull)

• --release?

  → show what the next release would contain

• --close?

  → show what closing would tear down