yeet

name	yeet
description	Publish local changes to GitHub by confirming scope, committing intentionally, pushing the branch, and opening a draft PR through the configured GitHub integration, with `gh` used only as a fallback where connector coverage is insufficient.

GitHub Publish Changes

Overview

Use this skill only when the user explicitly wants the full publish flow from the local checkout: branch setup if needed, staging, commit, push, and opening a pull request.

This workflow is hybrid:

• Use local git for branch creation, staging, commit, and push.
• Prefer the configured GitHub integration for pull request creation after the branch is on the remote.
• Use gh as a fallback for current-branch PR discovery, auth checks, or PR creation when the connector path cannot infer the repository or head branch cleanly.

Prerequisites

• Require GitHub CLI gh. Check gh --version. If missing, ask the user to install gh and stop.
• Require authenticated gh session. Run gh auth status. If not authenticated, ask the user to run gh auth login (and re-run gh auth status) before continuing.
• Require a local git repository with a clean understanding of which changes belong in the PR.

Naming conventions

• Branch: semantic prefix plus short slug, for example feat/cloudflare-skills, fix/sentry-path, or chore/github-skill-cleanup.
• Commit: Conventional Commits, for example feat: add Cloudflare skills integration.
• PR title: semantic title matching the change intent, for example feat: add Cloudflare skills integration or fix: correct Sentry skill script path.

Workflow

1. Confirm intended scope.
   • Run git status -sb and inspect the diff before staging.
   • If the working tree contains unrelated changes, do not default to git add -A. Ask the user which files belong in the PR.
2. Determine the branch strategy.
   • If on main, master, or another default branch, create a semantic branch such as feat/{description}, fix/{description}, or chore/{description}.
   • Otherwise stay on the current branch.
3. Stage only the intended changes.
   • Prefer explicit file paths when the worktree is mixed.
   • Use git add -A only when the user has confirmed the whole worktree belongs in scope.
4. Commit with a Conventional Commit message aligned to the branch and PR intent.
5. Run the most relevant checks available if they have not already been run.
   • If checks fail due to missing dependencies or tools, install what is needed and rerun once.
6. Push with tracking: git push -u origin $(git branch --show-current).
7. Open a draft PR.
   • Prefer the configured GitHub integration for PR creation after the push succeeds.
   • Use a semantic PR title matching the Conventional Commit style used for the change.
   • Derive repository_full_name from the remote, for example by normalizing git remote get-url origin or by using gh repo view --json nameWithOwner.
   • Derive head_branch from git branch --show-current.
   • Derive base_branch from the user request when specified; otherwise use the remote default branch, for example via gh repo view --json defaultBranchRef.
   • If the branch is being pushed from a fork or the PR target differs from the remote that was just pushed, prefer gh pr create fallback because the connector PR creation flow expects one repository target and may not encode cross-repo head semantics cleanly.
   • If connector-based PR creation cannot infer the repository or branch cleanly, fall back to gh pr create --draft --fill --head $(git branch --show-current).
   • Write the PR body to a temp file with real newlines when using CLI fallback so the markdown renders cleanly.
8. Summarize the result with branch name, commit, PR target, validation, and anything the user still needs to confirm.

Write Safety

• Never stage unrelated user changes silently.
• Never push without confirming scope when the worktree is mixed.
• Default to a draft PR unless the user explicitly asks for a ready-for-review PR.
• If the repository does not appear to be connected to an accessible GitHub remote, stop and explain the blocker before making assumptions.

PR Body Expectations

The PR description should use real Markdown prose and cover:

• what changed
• why it changed
• the user or developer impact
• the root cause when the PR is a fix
• the checks used to validate it