mirror of
https://github.com/zoriya/v10.git
synced 2026-08-16 02:45:09 +00:00
3.5 KiB
3.5 KiB
name, description, allowed-tools, context
| name | description | allowed-tools | context |
|---|---|---|---|
| commit-pr | Commit all changes and create or update a PR following project conventions. Triggers: "commit and pr", "push changes", "create pull request". | Bash(git:*), Bash(gh:*), Glob, Grep, Read, question, mcp__github__* | fork |
Commit & PR
Stage all changes, create a conventional commit, and open a pull request (or push to an existing one).
Usage
/commit-pr [refs]
refs(optional): Issue/PR references (e.g.,#123,fixes #456,closes #789)
Examples
/commit-pr
/commit-pr #123
/commit-pr fixes #456
/commit-pr #123 closes #456
Arguments
$ARGUMENTS
Conventions
Load the git skill for:
- Commit message format (
references/commit.md) - Scope inference (
references/scope.md) - PR title and body template (
references/pr.md)
Your Tasks
Step 1: Load Conventions
Load the git skill to understand commit and PR conventions.
Step 2: Analyze Changes
- Run
git statusto identify changed files - Run
git diff --stagedandgit diffto understand what changed - Read modified files if needed for context
Step 3: Determine Commit Type and Scope
Based on the changes and git skill conventions:
- Type: What kind of change? (feat/fix/chore/refactor/docs/test/etc)
- Scope: Which package or area? (infer from file paths per
references/scope.md) - Breaking: Does it break existing behavior? (use
!suffix)
Step 4: Create Commit
- Stage all changes:
git add -A - Create commit with conventional message:
git commit -m "type(scope): description"
Step 5: Push and Create/Update PR
-
Push branch to remote:
git push -u origin HEAD -
Check if a PR already exists for this branch:
gh pr list --head "$(git branch --show-current)" --json number,url,title,body --jq '.[0]' -
If PR exists:
- Ask the user if they want to update the PR description (use the
questiontool) - If yes: Generate new body based on all commits in the PR, then update:
Note: Only update the body, never the title.
gh pr edit <number> --body "new body" - If no: Skip — the push already updated the PR code
- Ask the user if they want to update the PR description (use the
-
If no PR exists: Create one using
gh pr create:gh pr create --title "type(scope): description" --body "$(cat <<'EOF' ## Summary ... EOF )"Follow the PR body template from
references/pr.md.
Step 6: Report
- Existing PR (no update): "Pushed to PR #123: "
- Existing PR (updated): "Updated PR #123: "
- New PR: "Created PR #123: "
Writing Clear PR Descriptions
A reviewer should understand the PR in 30 seconds. Apply the same rigor as issue bodies:
- Why over what -- explain motivation, not mechanics. The diff shows what changed.
- Be concise -- cut filler. Every sentence should carry information.
- No file lists -- reviewers see the diff. Describe behavior changes.
- Collapse details -- use
<details>for implementation notes, tradeoffs, or architecture decisions that only some reviewers need. - Sections must earn their place -- omit Testing if covered by existing tests with nothing to add. Omit Changes if the summary says it all.
- Don't repeat the title in the summary.
Important
- Always stage ALL changes with
git add -A - Always check for existing PR before creating -- avoid duplicate PRs
- Prefer
ghCLI for GitHub operations; fallback to MCP tools ifghunavailable