agentleFS
Sign inStart free
mabykomabyko/AgentSkills/skills/github-workflow/SKILL.md

github-workflow

Skill0 starsChanged 33 days agoMITView on GitHub

Use when working with GitHub workflows: pull requests, stacked PRs and gh-stack, PR reviews, review threads, PR merges, auto-merge, GitHub Actions checks, CI annotations, branch protection, GitHub Releases, gh CLI commands, release publishing, or fork upstream-sync automation.

23 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use marketing-psychology, copywriting and 3 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.
  • SentrySkill

    marketing-psychology

    When the user wants to apply psychological principles, mental models, or behavioral science to marketing. Also use when the user mentions 'psychology,' 'mental models,' 'cognitive bias,' 'persuasion,' 'behavioral science,' 'why people buy,' 'decision-making,' or 'consumer behavior.' This skill provides 70+ mental models organized for marketing application.

    Also in 3 projects that use this

  • SupabaseSkill

    copywriting

    Write or audit UI copy (buttons, labels, empty states, error messages, tooltips, form text) anywhere in the monorepo. Load it before shipping or reviewing any user-facing text — including when copy is incidental to the task, like a new feature that adds buttons, toasts, dialogs, or validation messages.

    Also in 3 projects that use this

  • SentrySkill

    skill-creator

    Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, writing, registration, and verification.

    Also in 4 projects that use this

  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 3 projects that use this

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 7 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 5

    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. Very specific:

    Use for GitHub-hosted collaboration and publishing.

    line 8
  2. Very specific:

    Read repository-specific GitHub guidance first: .github/, PR templates, release workflows, branch protection notes, CONTRIBUTING.md, and …

    line 14
  3. Distinctive:

    Never claim GitHub status, checks, reviews, or release state unless you inspected them.

    line 15
  4. Distinctive:

    Do not merge, close, publish, mark latest, delete releases, or delete remote branches unless explicitly requested.

    line 16
  5. Distinctive:

    Treat green status as necessary but not sufficient: also check annotations, warnings, bot comments, and review state.

    line 17
  6. Distinctive:

    Follow the user's tool choice.

    line 23
  7. Very specific:

    If gh is missing, recommend installation once using the official GitHub CLI instructions.

    line 26
  8. Distinctive:

    If the user prefers no installation, continue with an available connected tool or browser and use Git for local branch work.

    line 28
  9. Distinctive:

    Read only the references needed for the requested task.

    line 35
  10. Very specific:

    Before merging, enabling auto-merge, publishing a release, changing release latest, or dismissing review/check state:

    line 46
  11. Very specific:

    Check worktree and branch state using git-workflow when local changes or branch history matter.

    line 48
  12. Distinctive:

    Read repository-specific GitHub guidance.

    line 56

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

Use for GitHub-hosted collaboration and publishing. Use git-workflow for local staging, commits, rebases, conflicts, branch cleanup, Git tag safety, or history rewrites.

For version changes, release candidate verification, and deployment handoff, use prepare-release-github when available. This skill handles the GitHub PR, check, and publishing operations within that process.

Rules

  1. Read repository-specific GitHub guidance first: .github/, PR templates, release workflows, branch protection notes, CONTRIBUTING.md, and README.md.
  2. Never claim GitHub status, checks, reviews, or release state unless you inspected them.
  3. Do not merge, close, publish, mark latest, delete releases, or delete remote branches unless explicitly requested.
  4. Treat green status as necessary but not sufficient: also check annotations, warnings, bot comments, and review state.
  5. For local Git history decisions, follow git-workflow.
  6. Default to a single PR for one cohesive change. Preserve the user's specified branch and PR counts. Use a stacked workflow for requested dependent PR layers, an existing stack, or repository guidance that calls for one. gh-stack availability or a native Stack's two-PR minimum is not a reason to split work into additional PRs.

Tool Availability and Installation

Follow the user's tool choice. Otherwise use an available GitHub CLI, connected GitHub tool, or browser that can access the target repository. CLI examples in the references describe operations, not mandatory dependencies; alternative tools must preserve the same targets, authorization, and verification.

  • Before using gh, check command -v gh unless availability is already known this session. For a CLI operation needing authentication, verify the target host with gh auth status unless already verified. Recheck when a failure or configuration change invalidates that evidence; distinguish missing commands from authentication, permission, or network failures.
  • If gh is missing, recommend installation once using the official GitHub CLI instructions. If only gh-stack is missing during stacked PR work, offer gh extension install github/gh-stack. Skip the offer when the user has chosen no installation. Ordinary PR work needs no gh-stack extension.
  • Installation is optional. Install only within an existing setup authorization or when requested, then verify the required command works. Do not install a separate upstream skill as a prerequisite for this skill.
  • If the user prefers no installation, continue with an available connected tool or browser and use Git for local branch work. Remember that choice for the session; offer installation again only if the user reopens it.
  • If no authorized GitHub access is available, finish local preparation and produce the PR title/body or other reviewable material. Explain which GitHub steps remain and give concrete manual instructions. Pause only steps needing unavailable access; do not claim remote state or completion that you could not verify.

For native stacks, preserve Stack membership when changing tools. The no-installation paths and ordinary PR-chain fallback are in references/stacked-prs.md.

Reference Routing

Read only the references needed for the requested task.

ReferenceUse For
references/pull-requests.mdCreating PRs, PR descriptions, review responses, merge readiness
references/stacked-prs.mdStack creation, lower-layer edits, gh-stack submit/sync, native Stack merges, no-installation paths, ordinary PR-chain landing
references/github-releases.mdGitHub Releases, release publishing, latest flag, published release recovery
references/upstream-sync.mdExplicit requests to create or review fork upstream-sync GitHub Actions workflows

GitHub Action Safety Checklist

Before merging, enabling auto-merge, publishing a release, changing release latest, or dismissing review/check state:

  • Check worktree and branch state using git-workflow when local changes or branch history matter.
  • Inspect the exact PR, release, check run, or review thread targeted by the request.
  • Confirm required checks, review state, branch protection, and requested merge/release mode.
  • Act only on the target named by the user or verified from repository metadata.
  • Report the command, URL, or API result used as evidence.

Default Workflow

  1. Read repository-specific GitHub guidance.
  2. Choose an available tool under Tool Availability and Installation; check worktree and branch state using git-workflow when needed.
  3. Inspect GitHub status, reviews, and templates relevant to the request.
  4. Make or recommend GitHub changes only within the user's requested scope.
  5. Report verification source, remaining blockers, and follow-up actions.

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