Github Commit Push

Commit Push

Overview

Provide a repeatable commit-and-push workflow that runs lint/build checks first and optionally creates a PR with GitHub CLI.

Path Resolution (avoid missing-skill errors)

• Always open this skill using the absolute path from the active session skills list (for example <agent-skills-root>/github-commit-push/SKILL.md).
• Do not try guessed repo-relative skill paths unless the session explicitly lists that exact path.

Workflow

1. Preflight
   • Run git status -sb and git branch --show-current; confirm branch and scope.
   • Determine the issue number to auto-close in PR:
     • Detect issue number from branch name patterns such as issue-123, fix/123-*, gh-123, #123, 23-*.
     • If no issue can be derived automatically, ask the user for the issue number before creating the PR.
     • Keep the issue number only if a single, confirmed target exists.
   • If the user wants only specific files, confirm the file list before staging; otherwise default to all changes.
2. Verify
   • Run pnpm lint.
   • Run pnpm knip.
   • Run pnpm build. If repo policy restricts builds, ask the user to run it or explicitly approve running it.
   • If any command fails, stop and report the error.
3. Commit
   • Stage all changes: git add -A.
   • Summarize staged diff: git diff --stat --cached.
   • If no commit message is provided, generate a concise one based on the staged diff and proceed without asking.
   • Commit with git commit -m "message".
4. Push
   • Push the current branch with git push (default behavior when nothing else is specified).
   • If no upstream is set, use git push -u origin <branch>.
5. PR (optional)
   • Ask whether to create a PR.
   • If yes and gh is available/authenticated:
     • Include issue closure metadata in the PR body using Fixes #<issue-number> (or Closes #<issue-number>) so merge will auto-close the issue.
     • Build a detailed PR body that follows the repository template (create .github/pull_request_template.md if missing).
     • Fill the template sections (Summary, Why, What changed, How, Testing, Notes, Checklist).
     • Add an explicit heading in the PR body such as:
       • ## Related issue
       • Fixes #<issue-number>
     • Include test results and any warnings in Testing/Notes.
     • Never use inline --body "<...>" for multiline Markdown.
     • Write the PR body to a temp file with a quoted heredoc and use --body-file:
       • BODY_FILE=$(mktemp)
       • cat > "$BODY_FILE" <<'EOF' ... EOF
       • gh pr create --title "<branch>: <summary>" --body-file "$BODY_FILE" (add --draft if requested)
       • rm -f "$BODY_FILE"
     • Share the PR link.
     • Verify linkage is active before reporting success:
       • gh pr view <pr-number> --json closingIssuesReferences --jq '.closingIssuesReferences[].number'
       • Confirm <issue-number> is present.
   • If the issue must stay open, replace Fixes with Refs and clearly state why it is non-closing.
   • If gh is unavailable, explain how to proceed or skip PR creation.

Hard rules

• Never use unquoted heredocs (<<EOF) for Markdown payloads.
• Never place Markdown backticks inside double-quoted shell variables when composing PR text.