agentleFS
Sign inStart free
lyh843lyh843/AgentSkills/skills/yeet/SKILL.md

yeet

Skill1 starsChanged 5 months agoMITView on GitHub

Publish local changes to GitHub by confirming scope, committing intentionally, pushing the branch, and opening a draft PR through the GitHub app from this plugin, with `gh` used only as a fallback where connector coverage is insufficient.

  • Commits and pushes

We split this skill into the rules it gives an agent

20 rules. 0 are common, 16 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 14 edited versions we read keep these.

  • 16

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Use this skill only when the user explicitly wants the full publish flow from the local checkout: branch setup if needed, staging, commit, …

    line 10
  2. Distinctive:

    Use local git for branch creation, staging, commit, and push.

    line 14
  3. Distinctive:

    Prefer the GitHub app from this plugin for pull request creation after the branch is on the remote.

    line 15
  4. Very specific:

    Use gh as a fallback for current-branch PR discovery, auth checks, or PR creation when the connector path cannot infer the repository or …

    line 16
  5. Distinctive:

    Run git status -sb and inspect the diff before staging.

    line 33
  6. Distinctive:

    If the working tree contains unrelated changes, do not default to git add -A.

    line 34
  7. Very specific:

    If on main, master, or another default branch, create codex/{description}.

    line 36
  8. Distinctive:

    Prefer explicit file paths when the worktree is mixed.

    line 39
  9. Distinctive:

    Use git add -A only when the user has confirmed the whole worktree belongs in scope.

    line 40
  10. Distinctive:

    Commit tersely with the confirmed description.

    line 41
  11. Distinctive:

    Run the most relevant checks available if they have not already been run.

    line 42
  12. Distinctive:

    If checks fail due to missing dependencies or tools, install what is needed and rerun once.

    line 43
  13. Distinctive:

    Prefer the GitHub app from this plugin for PR creation after the push succeeds.

    line 46
  14. Very specific:

    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 …

    line 50
  15. Very specific:

    If connector-based PR creation cannot infer the repository or branch cleanly, fall back to gh pr create --draft --fill --head $(git branch …

    line 51
  16. Distinctive:

    Write the PR body to a temp file with real newlines when using CLI fallback so the markdown renders cleanly.

    line 52
  17. Distinctive:

    Never stage unrelated user changes silently.

    line 57
  18. Distinctive:

    Never push without confirming scope when the worktree is mixed.

    line 58
  19. Distinctive:

    Default to a draft PR unless the user explicitly asks for a ready-for-review PR.

    line 59
  20. Distinctive:

    If the repository does not appear to be connected to an accessible GitHub remote, stop and explain the blocker before making assumptions.

    line 60

“Common” is measured: kept by at least 6 in 10 of the 14 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 GitHub app from this plugin 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: codex/{description} when starting from main/master/default.
  • Commit: {description} (terse).
  • PR title: [codex] {description} summarizing the full diff.

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 codex/{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 tersely with the confirmed description.
  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 GitHub app from this plugin for PR creation after the push succeeds.
    • 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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free