---
name: github-workflows
description: "End-to-end GitHub workflows: auth, repos, issues, PRs, reviews, CI, and releases."
version: 1.0.0
author: Hermes Agent
license: MIT
platforms: [linux, macos, windows]
metadata:
  hermes:
    tags: [GitHub, Git, gh-cli, API, PRs, Issues, Releases, CI]
---

# GitHub Workflows

Use this skill for the whole GitHub lifecycle, from initial authentication through repository setup, issue triage, pull requests, code review, CI checks, and releases.

## Mental model

Work GitHub in this order when possible:

1. authenticate once
2. clone, fork, or create the repo
3. branch and commit locally
4. open or update an issue if needed
5. create the PR
6. review the diff and CI
7. merge or release

Prefer `gh` for convenience, but keep a `git` + `curl` fallback in mind when the CLI is unavailable.

## Authentication

Before doing anything else, determine whether GitHub access is already available:

```bash
gh auth status 2>/dev/null || true
git config --global credential.helper 2>/dev/null || true
```

Use whichever path is available:

- `gh auth login` for a browser-based flow
- a GitHub token in `GITHUB_TOKEN` for API calls
- HTTPS credentials stored by `git`
- SSH keys when that is already configured

If auth is missing, set it up first. Do not work around it by guessing.

## Repository lifecycle

Typical repo operations:

- clone
- fork
- create
- configure remotes
- set branch protection
- manage releases and secrets

Use `gh repo ...` when available. Fall back to the REST API for scripted flows.

## Issues

Use issues for triage, bug reports, and planning:

- list and filter issues
- create bug/feature templates
- add labels and assignees
- comment with investigation notes
- close or reopen issues

This is the right layer for user-facing project tracking before a PR exists.

## Pull requests

Use PRs for implementation work:

- branch from a clean base
- commit with a clear message
- push and open the PR
- watch checks
- fix failures
- merge or enable auto-merge

Prefer a single focused PR per logical change.

## Code review

Review both local diffs and GitHub PRs:

- inspect the diff first
- read surrounding code, not just the changed lines
- look for correctness, security, tests, and performance issues
- leave inline comments only when they add signal

If the user wants pre-commit review of their own work, use `requesting-code-review` instead.

## CI and releases

Treat CI as part of the workflow, not a separate afterthought:

- inspect failing jobs and logs
- reproduce locally when possible
- fix the root cause
- re-check the PR until green
- only then merge
- use releases for versioned deliverables or tagged binaries

## Fallback rule

- `gh` first if it exists and is authenticated
- `curl` + API when you need automation or `gh` is absent
- plain `git` for local diffing, branch management, and history

## Good output

A strong response from this skill usually includes:

- the repo or PR context
- the exact commands used
- the outcome of auth / CI / merge checks
- any blockers that require user input