agentleFS
Google CloudKnown publisherGoogleCloudPlatform/cloud-solutions/projects/build-with-gemini-demo/build-with-antigravity/.agents/skills/open-pr/SKILL.md

open-pr

Skill138 starsChanged 5 months agoApache-2.0View on GitHub

Commits local changes to a new Git branch and opens a GitHub pull request through the configured GitHub MCP server. Use when proposing code changes in a new pull request. Don't use for local-only commits without a remote GitHub repository.

  • Reads credentials
  • Commits and pushes

We split this skill into the rules it gives an agent

6 rules. 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 58 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Failure handling: If the directory is not a Git repository, has no remote configured, or the GitHub MCP server tools are unavailable, halt …

    line 33
  2. Very specific:

    Run git status and git remote -v to verify the working tree and target GitHub repository (owner/repo).

    line 42
  3. Very specific:

    Verify that .gitignore exclusions and secret hygiene comply with .agents/rules/dev-rules.md.

    line 44
  4. Distinctive:

    Check the current branch with git branch --show-current.

    line 60
  5. Very specific:

    Create a descriptive commit (git commit -m "<type>: <summary>") and push the feature branch to the origin remote (git push -u origin HEAD), …

    line 69
  6. Distinctive:

    Verify that the pull request is created and report the pull request number and URL to the user.

    line 78

“Common” is measured: kept by at least 6 in 10 of the 58 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

Open pull request

<!-- Disabling markdownlint MD029 to provide explicit ordering to avoid confusing the LLM. --><!-- markdownlint-disable MD029 --><!-- Disabling markdownlint MD030 to allow the list overflowing to numbers >=10. --><!-- markdownlint-disable MD030 -->

Prerequisites

  • Git repository and remote: Local Git repository initialized (git status) with a GitHub remote configured (git remote -v).
  • GitHub MCP server: Configured in .agents/mcp_config.json with a valid GITHUB_PERSONAL_ACCESS_TOKEN granted Contents (read/write), Pull requests (read/write), and Metadata (read-only) permissions.
  • Development standards: Workspace rules defined in .agents/rules/dev-rules.md.
  • Failure handling: If the directory is not a Git repository, has no remote configured, or the GitHub MCP server tools are unavailable, halt before pushing or creating the pull request and instruct the user on how to complete the missing setup.

Workflow

1. Inspect repository state and hygiene

  1. Run git status and git remote -v to verify the working tree and target GitHub repository (owner/repo).
  2. Verify that .gitignore exclusions and secret hygiene comply with .agents/rules/dev-rules.md. Never stage credentials, tokens, or .env files.

2. Analyze changes and draft pull request metadata

  1. Inspect staged and unstaged changes using git status and git diff.
  2. Draft a concise pull request title and a structured description containing:
    • Summary: High-level overview of the purpose of the changes.
    • Key changes: Bullet list of added or modified components, tests, and documentation.
    • Verification: Summary of unit tests, security checks, and local validation performed.

3. Create feature branch, commit, and push

  1. Check the current branch with git branch --show-current. If on main or master, create and switch to a descriptive feature branch:

    git switch -c feat/<short-description>
  2. Stage the relevant project files (git add <files>) and verify staged files with git status.
  3. Create a descriptive commit (git commit -m "<type>: <summary>") and push the feature branch to the origin remote (git push -u origin HEAD), or use the GitHub MCP server branch/commit tools if preferred.

4. Create pull request through GitHub MCP server

  1. Invoke the GitHub MCP server tool (such as create_pull_request) with the repository owner, repository name, head branch, base branch (main), title, and description.
  2. Verify that the pull request is created and report the pull request number and URL to the user.

Download now (ZIP)

  • Other versions59 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 59

    1. Significant-Gravitas/AutoGPT★ 188ksame name
    2. storybookjs/storybook★ 91ksame name
    3. pascalorg/editor★ 25ksame name
    4. dask/dask★ 14ksame name
    5. polarsource/polar★ 10ksame name
    6. cloudflare/agents★ 5.9ksame name
    7. Kiln-AI/Kiln★ 5.2ksame name
    8. analogjs/analog★ 3.2ksame name
    9. raine/workmux★ 2.9ksame name
    10. testcontainers/testcontainers-node★ 2.6ksame name

    49 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use address-review, commit-push and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • saffron-healthSkill

      address-review

      Address PR review comments systematically. Use when responding to code review feedback on a pull request.

      Also in 3 projects that use this

    • DataCoveySkill

      commit-push

      Commit and push the changes made on this chat session to the current branch. Use best practices from Conventional Commits.

      Also in 3 projects that use this

    • raineSkill

      rebase

      Rebase the current branch with smart conflict resolution.

      Also in 3 projects that use this

    • DockerSkill

      review-pr

      Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as "review PR 123", "is this PR correct?", "does this information belong here?", "validate this PR", or "help review backlog PRs". Do not use to maintain or fix a PR you own; use maintain-pr for that.

      Also in 9 projects that use this

    • MicrosoftSkill

      worktree

      Create, reuse or clean up a dedicated git worktree for working on a pull request or a private branch. Use from any PR-scoped workflow that needs an isolated checkout to keep current code and build output untouched.

      Also in 3 projects that use this

    • SentrySkill

      commit

      Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references.

      Also in 13 projects that use this

  • In this repository28 other files it gives its agents.

Does it work?

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

Reviews can't be read right now.

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.