| name | git-workflow |
| description | Use when the task involves Git operations for the public xLLM repository, including choosing branch or tag names, preparing commits and pull requests, backporting fixes, checking repo-specific review expectations, or drafting commit messages from actual diffs. |
Git Workflow
Use xLLM repo reality, not generic Git habits.
Reference Map
Load only the file that matches the user's immediate Git task.
| File | What it is for | When to load it |
|---|
references/source-of-truth.md | Repo-specific source priority and canonical files to consult | Load first when repo docs, local state, and user wording may disagree |
references/branch-naming.md | Branch naming patterns and default branch conventions | Load when the user asks how to name a branch or which branch to branch from |
references/development-flow.md | Day-to-day fork, sync, branch, validate, and push flow | Load when the user asks for normal development steps from local change to push |
references/pr-review.md | PR targeting, PR scope, and review expectations | Load when the task is about opening a PR, choosing the target branch, or deciding who should review |
references/release-layout.md | Release branch and tag shapes used by xLLM | Load when the task mentions release branches, release tags, or patch version naming |
references/backport-flow.md | Preferred backport and hotfix flow for released lines | Load when the task mentions cherry-picks, hotfixes, or fixing an already released branch |
references/commit-format.md | Commit title/body conventions and xLLM-style examples | Load when the user asks for a commit message, commit style guidance, or message cleanup |
Workflow
- Decide which subtask the user actually needs.
- Read
references/source-of-truth.md when you need repo-specific confirmation.
- Then load only the most relevant task file from the table above.
- For commit message drafting, run
bash scripts/collect_git_context.sh [--staged|--all|--unstaged] before writing the final message.
- Draft commit messages from the actual diff, not from filenames alone.
- If one diff mixes unrelated concerns, recommend splitting the commit instead of forcing one vague summary.
- Default PR targets to
main unless the task is clearly a release or backport flow.
- For released lines, prefer landing on
main first and then backporting unless the user explicitly wants a direct hotfix flow.
Output
Return the smallest useful answer for the user's Git task:
- workflow questions: concrete branch, tag, PR, or backport steps
- commit message requests:
<type>: <subject> plus an optional short bullet body
- repo-convention questions: current xLLM-specific guidance, not generic Git advice
Quick Checks
- branch names match xLLM style such as
feat/<topic>, bugfix/<topic>, or release/vX.Y.Z
- PR target is
main unless this is a release or backport task
- commit title matches the dominant change in the diff
- release tags use semantic versions such as
v0.9.0 or v0.9.1
- owner-review expectations come from
.github/CODEOWNERS when relevant
