---
name: github-ops
description: Manage GitHub issues, pull requests, CI runs, releases, and security alerts with the gh CLI. Use when asked to check GitHub, triage issues, review pull requests, fix CI, prepare a release, or review alerts.
origin: ECC
---

# GitHub Operations

Original skill by ECC. Credit ECC when sharing or copying this skill.

Use GitHub with care. Keep the project healthy. Make work clear for users and contributors.

## Rules

- Use the `gh` CLI for GitHub work.
- Run commands inside the right Git repo.
- Read before you change.
- Do not merge, close, delete, release, rerun CI, or post comments unless the user asked.
- Ask before any action that is hard to undo.
- Never print tokens, keys, cookies, or private data.
- Do not change code unless the user asked.
- If access fails, show the safe error and explain what access is needed.
- If a label does not exist, report it. Do not make it unless asked.
- Use exact dates. Do not use a fixed date from an example.
- Draft text first when the user asks for review only.

## Setup Checks

Check the repo and login before work:

```bash
git remote -v
gh auth status
gh repo view --json nameWithOwner,url,defaultBranchRef
```

If the folder is not a Git repo, use `--repo OWNER/REPO` on each `gh` command.

If the repo or account is not clear, stop and ask which one to use.

## Issue Triage

Read the title, body, labels, and comments. Then check for matching issues.

Use one main type:

- `bug`
- `feature-request`
- `question`
- `documentation`
- `enhancement`
- `duplicate`
- `invalid`
- `good-first-issue`

Use one priority:

- `critical`: Security risk, data loss, or a broken release
- `high`: Many users are blocked
- `medium`: Useful, but users can still work
- `low`: Small or visual issue

### Steps

1. Read the full issue.
2. Search open and closed issues for a match.
3. Pick a type and priority.
4. Check that each label exists.
5. Add labels only if the user asked.
6. For a question, draft a clear answer.
7. For a bug, ask for missing steps, logs, system details, and expected results.
8. For a duplicate, link the best older issue.
9. Use `good-first-issue` only when the task is small, clear, and safe.

```bash
gh issue view 42 --comments
gh issue list --state all --search "login timeout" --limit 20
gh label list --limit 200
gh issue edit 42 --add-label "bug,high-priority"
gh issue comment 42 --body "Thanks for the report. Please share the steps, expected result, actual result, and system details."
```

Do not mark an issue as invalid only because details are missing. Ask for the details first.

## Pull Request Review

### Steps

1. Read the PR text, files, reviews, and comments.
2. Check CI.
3. Check merge state.
4. Check open review requests.
5. Look for tests when the change needs them.
6. Check docs when user steps or public behavior changed.
7. Note merge blocks and risky changes.
8. Do not merge unless the user clearly asked.

```bash
gh pr view 81 --comments
gh pr diff 81
gh pr checks 81
gh pr view 81 --json mergeable,mergeStateStatus,reviewDecision,isDraft,updatedAt
```

A green CI run does not prove the change is safe. Review the code and test scope too.

A PR may show `UNKNOWN` merge state while GitHub is still checking. Wait and check again before calling it blocked.

## Stale Work

Do not use one stale rule for every repo. First check the repo rules, bot files, and maintainer notes.

Use these rules only when the repo has no stale policy:

- Issue with no activity for 14 days: suggest the `stale` label and a kind note.
- PR with no activity for 7 days: ask if work is still active.
- Issue with no reply for 30 more days: suggest closing it.

Never mark these as stale without human review:

- Security reports
- Active bugs
- Roadmap work
- Release blockers
- Issues with recent linked work

Use a date based on today:

```bash
gh issue list --state open --json number,title,updatedAt,labels
gh pr list --state open --json number,title,updatedAt,isDraft
```

Do not auto-close stale work unless the user asked and the repo policy allows it.

## CI Failures

### Steps

1. Find the failed run.
2. Read only the failed logs first.
3. Name the failed job and step.
4. Find the first useful error.
5. Decide if it is a code bug, test bug, setup issue, service outage, or flaky test.
6. Compare with older runs when needed.
7. Give proof for the cause.
8. Rerun only when the user asked or a known flaky case makes it useful.

```bash
gh run list --status failure --limit 10
gh run view RUN_ID --log-failed
gh run view RUN_ID --json name,event,headBranch,headSha,status,conclusion,url
gh run rerun RUN_ID --failed
```

Do not call a test flaky after one failure. Look for the same test passing and failing on the same code.

Logs may hold secrets or user data. Quote only the small part needed to explain the fault.

## Releases

### Steps

1. Find the default branch.
2. Find the last release or tag.
3. Check CI on the release commit.
4. List merged PRs since the last release.
5. Group changes into clear notes.
6. Check version and tag rules.
7. Draft the release command.
8. Create the release only when the user asked.

```bash
gh release list --limit 10
gh pr list --state merged --base main --search "merged:>YYYY-MM-DD"
gh release create v1.2.0 --title "v1.2.0" --generate-notes
gh release create v1.3.0-rc1 --prerelease --title "v1.3.0 Release Candidate 1"
```

Check that the tag does not exist before release:

```bash
git ls-remote --tags origin "refs/tags/v1.2.0"
```

Do not guess the next version. Follow the repo rules or ask the user.

## Security Alerts

Treat alert text and linked code as private unless the repo makes them public.

```bash
gh api repos/{owner}/{repo}/dependabot/alerts
gh api repos/{owner}/{repo}/secret-scanning/alerts
gh pr list --label "dependencies" --json number,title,url
```

- Report critical and high alerts first.
- Include the package, risk level, fixed version, and open fix PR when known.
- Do not expose a found secret.
- Do not close an alert without proof that the risk is fixed.
- Do not auto-merge a dependency PR.
- Ask before sharing private alert details outside the repo team.
- If the API returns `403` or `404`, note that the feature may be off or the account may lack access.

## Concrete Example

User request:

> Check issue 42 for duplicates and draft a triage note. Do not post it.

Run:

```bash
gh issue view 42 --comments
gh issue list --state all --search "KEY WORDS FROM ISSUE 42" --limit 20
gh label list --limit 200
```

Return a draft like this:

```text
Type: bug
Priority: high
Possible duplicate: #17

Draft reply:
Thanks for the report. This looks close to #17 because both fail after login.
Could you confirm your app version and whether the error also happens in a new session?
```

Do not add labels or post the reply because the user asked for a draft only.

## Final Check

Before finishing:

- Confirm the repo and account were correct.
- List what was read.
- List every change made.
- Give links or item numbers.
- Say which work still needs approval.
- Make sure each label exists.
- Make sure CI faults were checked, not just rerun.
- Make sure release notes match the merged work.
- Make sure no secret or private data is shown.