mergelisted

# Symphony Merge ## Overview Use this skill for the whole "get it into the real target and prove the relevant release settled" lifecycle. When work was started through `implementation-dispatch`, the dispatched worker thread owns this lifecycle by default. The parent/operator thread routes Pedro's merge approval back to that same worker thread; it does not execute the merge itself unless no worker thread exists or Pedro explicitly asks this thread to take over. This skill supersedes the old `merge-and-babysit` name. It also incorporates the publish step: if the work is local, first publish it on a branch and create a PR; then merge; then babysit the relevant rollout, deployment, preview, release, tracker, and worktree state. Use underlying skills as implementation modules when they fit: - For GitHub publishing, follow the installed `github:yeet` skill when available. - For legacy prompts or detailed rollout heuristics, the old `merge-and-babysit` path may redirect here. - For repo-local workflows, prefer a repo-local `merge` skill over this global skill when present. - For Azure DevOps repos, prefer `azure-publish-changes` and `azure-merge` when the repo matches their facts or has equivalent Azure DevOps conventions. ## Thread Ownership Use this routing before touching Git, GitHub, Linear, or deployment state: - If you are the parent/operator thread and the work has an implementation thread, PR, branch, or Linear issue produced by `implementation-dispatch`, fi