| name | push-and-pr |
| description | Push the current branch to the remote and create a GitHub pull request for this pyisis repository. Use when the user asks for 推到远程并开PR, 推当前分支到远程 PR, 自动 push branch and create PR, 发布当前分支, 提交远程审核, open PR for current branch, or wants one workflow that pushes then opens a PR. |
| argument-hint | [optional focus] e.g. current branch to main, draft PR, use current commit summary, only if working tree is clean |
| user-invocable | true |
| disable-model-invocation | false |
Push Branch and Open PR
Use this skill when the user wants a single workflow that publishes work from the entire current repository, not just a few named directories, and:
- checks the current branch state
- ensures the intended changes are committed
- pushes the branch to the remote
- creates a GitHub pull request
This skill is the repository-aware, action-taking companion to:
clean-commit for local commit cleanuppyisis-pr-writeup for reviewer-facing PR text
Use this skill instead of a shell script when the workflow needs judgment about:
- whether there are uncommitted changes
- whether the current branch has an upstream
- whether the branch is already pushed
- whether a draft PR is more appropriate
- how to describe the PR accurately for this repository
- whether the intended publish scope is the whole repository working tree or only a subset
When to Use
Typical prompts that should trigger this skill:
帮我把当前分支推到远程并开 PR把这个分支发上去给 reviewerpush 当前分支然后创建 PR自动推远程 PR发布当前分支到 GitHub 并开一个 PR推送并创建草稿 PRpush this branch and open a PR against main
Default Safety Contract
This skill may perform remote side effects because the user explicitly asked for push + PR behavior.
By default it should:
- push the current branch to
origin
- create a PR against the repo default branch unless the user specifies another base
- prefer creating a normal PR unless the user clearly wants a draft or the work is obviously not review-ready
- avoid publishing unreviewed working-tree noise by checking commit state before push
- treat any path under the current repository root as potentially in scope when the user asks to publish the current repository's work
It should not silently push uncommitted local edits by inventing a commit. If the working tree is dirty, it should first determine whether:
- the user wants those edits included now
- the branch is already in a suitable state to open a PR without them
- the
clean-commit workflow should be applied first
Examples of explicit user intent that should widen scope to the full repository include:
把当前仓库所有改动都推上去publish everything in this repo把当前仓库全部文件一起提交并开 PR
When the user explicitly asks to publish all current repository files/changes, do not bias toward only previously mentioned directories. Review the full repository working tree, then include all in-scope files across the repo root.
Workspace-Specific Expectations for pyisis
In this repository, PR creation should reflect real repo structure and validation language. The following paths are illustrative examples, not an exclusive allowlist or a directory restriction. Any file under this repository root may be in scope if it belongs to the requested publish unit. Prefer repository-accurate wording such as:
examples/controlnet_construct/examples/image_match/tests/unitTest/tests/smoke_import.pyctest --test-dir build -R python-unit-tests- pybind / examples / bug fix / refactor distinctions
Also watch for mixed working trees that may contain:
- unrelated
examples/experiment_methods/*
- generated artifacts like
print.prt
- scratch notes under
reference/notes/*
- sweep outputs or temporary CSVs
If the branch is dirty and the user wants to include current edits, prefer using the clean-commit skill logic rather than bluntly staging everything.
If the user explicitly asks for the entire current repository to be published, inspect the full working tree instead of concentrating only on these example directories.
What to Inspect First
Before pushing or opening a PR, inspect the smallest evidence set that determines whether publish is safe:
- current branch name
git status --short- whether there are staged/unstaged changes
- whether the branch has an upstream
- whether local commits are ahead of the upstream
- whether a PR already exists for the current branch when relevant
- recent validation evidence already available in the session
When possible, reuse session evidence instead of rerunning tests just to pad the PR description.
Standard Procedure
1. Confirm the publish target
Determine:
- head branch: usually the current local branch
- base branch: default to the repository default branch unless the user asks otherwise
- draft or not: infer from user wording or current readiness
For this repository, the common default should be:
- head = current branch
- base =
main
2. Inspect working tree and commit state
Check whether the working tree is clean.
Case A: clean working tree
Proceed to upstream / push checks.
Case B: dirty working tree
Do not blindly publish.
Instead:
- determine whether the dirty files are intended for this PR
- if yes, use the same review-first logic as
clean-commit
- if no, leave them out and push only the already-committed branch state
If the user explicitly says to include all current repository changes, treat the full repo working tree as the candidate scope, then review and stage across all changed paths under the repo root rather than narrowing attention to a few common directories.
If the branch has no new commits to push and the dirty changes are the only intended work, create a clean local commit first before pushing.
3. Ensure branch is pushable
Check whether the current branch already tracks a remote upstream.
If upstream exists
Push with the normal branch push flow.
If upstream does not exist
Push with upstream setup (for example the equivalent of setting upstream on first push).
The skill should handle the common first-push case autonomously.
4. Prepare PR title and description
If the user did not provide PR text, prepare it from real branch evidence.
Preferred sources:
- branch purpose from the current session
- staged / committed diff summary
- recent validation evidence from the session
- repository-aware wording from the
pyisis repo structure
If the user asks only for “push and create PR”, the skill should still generate a sensible PR title/body instead of opening an empty PR.
Use the same truthfulness bar as pyisis-pr-writeup:
- do not claim CI passed unless actually seen
- do not overstate validation
- distinguish focused unit tests, smoke import, build, and local script runs accurately
5. Push the branch
Push the branch to origin.
After pushing, verify that:
- the push succeeded
- the branch name used for the PR head is the pushed branch
6. Create the PR
Create the PR using the pushed branch as head.
By default:
- repo owner/name should match the current repository
- base should default to
main for this repo unless overridden
- draft should default to
false unless the user indicates draft/WIP semantics
7. Report the result clearly
After success, report:
- pushed branch name
- PR title
- PR number
- PR URL
- whether it was a draft
- what validation evidence was reflected in the PR body
If the skill had to exclude dirty files from publication, say so explicitly.
Recommended Decision Rules
User explicitly wants the whole repository published
Inspect git status --short for the entire repo, review the repo-wide diff, and treat all changed paths under the current repository root as candidate in-scope files. Do not restrict consideration to common pybind/example/test directories just because they are mentioned elsewhere in this skill.
Dirty working tree + user wants everything published
Use review-first local commit handling before push.
Dirty working tree + current branch already has the intended commits
Prefer pushing the committed branch state and explicitly mention that local uncommitted edits were left out.
No upstream branch
Create upstream on first push automatically.
No PR title/body given
Generate them conservatively from the branch diff and session evidence.
Existing PR already open
Do not create a duplicate PR if the active tooling reveals an existing one for the same branch. Prefer reporting the existing PR and, if needed, just push the new commits.
Truthfulness Rules
- Never claim a push succeeded unless it actually succeeded.
- Never claim a PR was created unless the remote tool returned success.
- Never claim the PR contains local dirty changes unless they were actually committed and pushed.
- Never imply all local changes were published if some were intentionally left out.
- Never fabricate validation results in the PR body.
Anti-Patterns
Avoid these mistakes:
- behaving as if example paths in this skill are the only publishable directories
- pushing a dirty branch without reviewing what should be published
- staging all changes automatically just to make push succeed
- creating a PR with a generic title/body when repo-aware wording is available
- opening a duplicate PR for a branch that already has one
- claiming the PR is ready for review when the user clearly wanted a draft
Good Outcome
A successful run of this skill should leave the user with:
- the current branch pushed to the remote
- a PR opened against the intended base branch
- a reviewer-friendly title and description
- no accidental inclusion of unrelated local working-tree noise
Recommended Output After Success
After completion, report something like:
- pushed branch
feat/... to origin
- created PR
#123 with title ...
- target base branch:
main
- PR link:
...
- local working tree changes left out:
none / list if applicable
Recommended Output After Partial Publish
If the branch was pushed and a PR already existed, report something like:
- pushed latest commits to
origin/<branch>
- existing PR detected / reused
- PR link:
...
- uncommitted local files left unpublished:
...
Suggested Composition With Other Skills
- If commit scope is messy, apply
clean-commit logic first.
- If PR wording needs richer text, reuse
pyisis-pr-writeup style and evidence gathering.
This skill is meant to provide the end-to-end publish workflow after local coding work is done.
