// Create a pull request for the current branch. Handles uncommitted changes, generates a PR title matching the `[{modules}] {type}: {description}` format enforced by CI, and fills in the PR description template. Trigger: 'create pr', 'open pr', 'submit pr', 'make pr'.
| name | create-pr |
| description | Create a pull request for the current branch. Handles uncommitted changes, generates a PR title matching the `[{modules}] {type}: {description}` format enforced by CI, and fills in the PR description template. Trigger: 'create pr', 'open pr', 'submit pr', 'make pr'. |
Minimize confirmations. The only user confirmation is for uncommitted changes (Step 1.3). Everything after that — drafting, writing file, pushing, creating PR — runs automatically. Tool-level permission prompts (file write, git push) serve as implicit confirmation; do not add extra "are you sure?" pauses on top.
Identify current branch:
git branch --show-current
If on main — stop and ask the user to create a feature branch first.
Determine base branch: use main unless the user specifies otherwise.
Check for uncommitted changes (only confirmation point):
git status
git diff --stat
If there are staged or unstaged changes, show a summary and ask the user:
"There are uncommitted changes. Commit them before creating the PR?"
make quality, stage relevant files (skip .env, credentials, large binaries), commit.make quality fails: stop and report errors.Check for existing PR on this branch:
gh pr view --json number,title,body 2>/dev/null
Note the PR number if one exists.
Check commits ahead of base:
git log origin/main..HEAD --oneline
If the branch has no commits ahead of main, stop — nothing to open a PR for.
Collect the full diff against the base branch:
git diff main...HEAD
git log main..HEAD --oneline
Identify affected modules by mapping changed file paths to allowed module names:
| Path prefix | Module |
|---|---|
veomni/models/ | model |
veomni/trainer/ | trainer |
veomni/data/ | data |
veomni/distributed/ | dist |
veomni/parallel/ | parallel |
veomni/ops/ | ops |
veomni/checkpoint/ | ckpt |
veomni/optim/ | optim |
veomni/logging/ | logging |
configs/ | config |
docs/ | docs |
tests/, .github/workflows/ | ci |
docker/ | docker |
tasks/ | task |
veomni/omni/ | omni |
.agents/ | agent |
| other / mixed | misc |
Allowed modules: misc, ci, config, docs, data, dist, omni, logging, model, optim, ckpt, release, task, perf, ops, parallel, docker, trainer, agent
Determine change type:
| Type | When |
|---|---|
feat | New functionality or capability |
fix | Bug fix |
refactor | Same behavior, better structure |
chore | Maintenance, cleanup, config changes |
test | Test-only changes |
Draft PR title in [{modules}] {type}: {description} format:
[model, data] feat: ...[BREAKING].github/workflows/check_pr_title.ymlDraft PR description following .github/PULL_REQUEST_TEMPLATE.md.
Write to .pr-drafts/ (already in .gitignore):
mkdir -p .pr-drafts
Filename convention:
.pr-drafts/<pr-number>.md (e.g. .pr-drafts/123.md).pr-drafts/<branch-name>.md — renamed to PR# after creation.File format — first line is the PR title, blank line, then the description body:
[model] feat: add support for Qwen4
### What does this PR do?
> Summary here.
### Checklist Before Starting
- Search for relative PRs/issues and link here: ...
- PR title follows `[{modules}] {type}: {description}` format
### Test
> Test description here.
### API and Usage Example
> N/A
### Design & Code Changes
> - Change 1
> - Change 2
### Checklist Before Submitting
- [ ] Read the [Contribute Guide](https://github.com/ByteDance-Seed/VeOmni/blob/main/CONTRIBUTING.md)
- [ ] Applied pre-commit checks
- [ ] Added/updated documentation
- [ ] Added tests to CI workflow (or explained why not feasible)
Tell the user the draft file path (so they know where to find it if they want to review later).
Push the branch:
git push -u origin HEAD
Create or update:
--body-file to avoid shell escaping issues):
# Extract body from draft file (everything after the first blank line)
tail -n +3 .pr-drafts/<branch-name>.md > /tmp/pr-body.md
gh pr create --base <base-branch> --title "<title>" --body-file /tmp/pr-body.md
<branch-name>.md to <pr-number>.md.tail -n +3 .pr-drafts/<pr-number>.md > /tmp/pr-body.md
gh pr edit <pr-number> --title "<title>" --body-file /tmp/pr-body.md
Output the PR URL and the draft file path.
.env, credentials, large binaries and warn the user.Use this skill when adding or refreshing a patchgen-generated modeling file for a VeOmni model under veomni/models/transformers/<model>/generated/ — GPU-only or GPU+NPU, dense or MoE, text-only / VLM / Omni-thinker+talker. Covers: creating <model>_{gpu,npu}_patch_gen_config.py, using patchgen decorators (replace_class/override_method/replace_function/modify_init/add_post_import_block/drop_import_names), reusing sibling-model patches via name_map, handling MoE weight-loading (CheckpointTensorConverter + fused gate_up_proj layout), multimodal/VLM forward with Ulysses SP, excluding speech/vocoder subtrees in Omni models (talker/token2wav/DiT/BigVGAN), wiring __init__.py for the patchgen-generated classes, running codegen, and adding test cases. Trigger: 'port <model> to patchgen', 'add patchgen for <model>', 'transformers v5 migration', 'add NPU patchgen'. Do NOT edit files under generated/ manually — always regenerate via patchgen.
Use this skill for ANY bug, error, crash, wrong output, loss divergence, gradient explosion, test failure, CUDA error, distributed training hang, checkpoint load failure, or unexpected behavior. Covers both quick fixes (clear root cause) and complex debugging (unclear cause). Trigger: 'fix bug', 'fix error', 'broken', 'crash', 'doesn't work', 'fails with', 'loss NaN', 'training hangs', 'FSDP error', 'OOM'.
Use this skill when adding support for a new model to VeOmni. Covers the full lifecycle: analyzing the HuggingFace model, creating model patches, defining parallel plans, writing configs, integrating with the trainer, and testing. Trigger: 'add model', 'support new model', 'integrate <model_name>', 'new model support'.
VeOmni-specific checklist for feature development and refactoring. Covers impact analysis across modalities, trainer hierarchy, data pipeline, and distributed code. Use before implementing any non-trivial change. For model-specific or ops-specific work, use veomni-new-model or veomni-new-op instead. Trigger: 'add feature', 'implement', 'refactor', 'reorganize', 'new capability'.
Use this skill when adding a new optimized kernel or operator to veomni/ops/. Covers the full lifecycle: understanding VeOmni's ops architecture (KERNEL_REGISTRY + OpSlot dispatch, with a thin function-pointer shim for a few legacy global ops), implementing the kernel, registering it, adding tests, and documenting it. Trigger: 'add op', 'new kernel', 'add attention variant', 'new fused op', 'add triton kernel', 'optimize operator'.
Use this skill when updating dependencies managed by uv: bumping a package version, upgrading the uv tool itself, updating torch/CUDA stack, switching transformers version, or regenerating the lockfile. Trigger: 'update dependency', 'bump version', 'upgrade uv', 'update torch', 'update lockfile', 'uv sync fails'.