pushlisted

# Publish the Current Work Treat invocation as approval to persist the work in scope from the current conversation. Preserve unrelated worktree changes. Honor any commit message, remote, base branch, or pull-request preference supplied by the user. ## 1. Establish the publication state Inspect: - `git status --short` - staged and unstaged diffs - the current branch and upstream - configured remotes and the remote default branch - commits ahead of the upstream A detached `HEAD` needs a user-selected branch before publication. For an active merge, rebase, or cherry-pick conflict, stop and recommend `/resolving-merge-conflicts`. This step is complete when the intended paths, branch, remote, upstream state, and existing local commits are known. ## 2. Gate on validation Reuse successful validation from the current session when it still covers the current diff. If the work changed afterward, run the smallest existing tests, checks, or build commands that cover it. Resolve failures before publication. This step is complete when the exact work being published has current passing validation, or consists only of documentation with no repository-specific docs check. ## 3. Stage exactly the intended change Stage explicit in-scope paths with `git add -- <paths>`. Use `git add -A` only when every dirty path belongs to this work. Inspect `git diff --cached` and `git status --short` after staging, including untracked files and accidental credentials. This step is complete when th