github-workflow
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: github-workflow
description: Use when working in a git repository hosted on GitHub and handling branch creation, commits, pus…
category: engineering
runtime: no special runtime
---
# github-workflow output preview
## PART A: Task fit
- Use case: Use when working in a git repository hosted on GitHub and handling branch creation, commits, pushes, pull requests, reviews, or merges with gh CLI available. Use a hybrid workflow: prefer gh for GitHub-aware tasks, and use git for local history editing, staging, and branch mechanics. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Overview / Quick Start Checks / Tool Choice Rules” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Use when working in a git repository hosted on GitHub and handling branch creation, commits, pushes, pull requests, reviews, or merges with gh CLI available. Use a hybrid workflow: prefer gh for GitHub-aware tasks, and use git for local history editing, staging, and branch mechanics. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Overview / Quick Start Checks / Tool Choice Rules” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Overview / Quick Start Checks / Tool Choice Rules”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: github-workflow
description: Use when working in a git repository hosted on GitHub and handling branch creation, commits, pus…
category: engineering
source: tomevault-io/skills-registry
---
# github-workflow
## When to use
- Use when working in a git repository hosted on GitHub and handling branch creation, commits, pushes, pull requests, re…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Overview / Quick Start Checks / Tool Choice Rules” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "github-workflow" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Overview / Quick Start Checks / Tool Choice Rules
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}GitHub Workflow
Overview
Use a hybrid workflow: prefer gh for GitHub-aware tasks, and use git for local history editing, staging, and branch mechanics.
Opinionated defaults:
- inspect repo state before making changes
- keep branches focused and short-lived
- use conventional-commit-style messages when possible
- open PRs with clear titles and summaries
- merge with explicit intent, not guesswork
Quick Start Checks
Run these before branching or opening a PR:
gh auth status
git remote -v
gh repo view --json nameWithOwner,defaultBranchRefConfirm:
ghis authenticated- the repo remote points to the expected GitHub repository
- you know the default branch, usually
mainormaster
If gh repo view fails because the current repo is not connected to GitHub, fall back to plain git and ask before attempting GitHub-specific actions.
Tool Choice Rules
Use gh for |
Use git for |
|---|---|
| auth and repo checks | staging files |
| PR create/view/checkout/review/merge | commit creation/amend/rebase |
| PR status and checks | switching branches |
| opening web pages for repo or PR context | inspecting local diffs and history |
Fallback rule: if gh has a clean command for the task, prefer it. If the task is fundamentally local source control, use git.
Branch Workflow
- Sync and inspect the default branch.
- Create a focused branch from the default branch.
- Keep the branch name descriptive.
Example:
git switch main
git pull --ff-only
git switch -c feat/add-github-workflow-skillRecommended prefixes:
feat/fix/docs/chore/refactor/test/
Avoid vague names like updates, stuff, or misc-fixes.
Commit Workflow
Use git for staging and committing. Keep commits small and readable.
git status
git add <paths>
git commit -m "feat: add github workflow skill"Prefer conventional-commit-style summaries:
feat: add github workflow skillfix: correct PR base branch detectiondocs: document packaged skillschore: clean up release notes
Before pushing, review what changed:
git diff --stagedIf a commit needs cleanup, use git commit --amend or interactive rebase deliberately. Do not use gh for local history surgery.
Push and PR Workflow
Push with git, then use gh to work with the PR.
git push -u origin HEAD
gh pr create --fill --base mainUseful gh commands:
gh pr status
gh pr view --web
gh pr checks
gh pr create --fill --base <default-branch>
gh pr checkout <number>PR hygiene:
- make sure the base branch is correct
- use a title that matches the change
- include a short summary of what changed and any risk areas
- mention tests run when relevant
If --fill produces a weak title/body, replace it instead of accepting low-quality PR text.
Review Workflow
Use gh to inspect and respond to review state.
gh pr view <number>
gh pr diff <number>
gh pr checks <number>
gh pr review <number> --comment -b "Looks good overall; left one suggestion."
gh pr review <number> --approve
gh pr review <number> --request-changes -b "Please address the failing tests and rename the branch."When reviewing your own work, check:
- PR targets the correct base branch
- branch is up to date enough for the repo's workflow
- checks are green or known failures are explained
- description matches the actual diff
Merge Workflow
Prefer gh pr merge so the merge action is tied to GitHub PR state.
gh pr merge <number> --squash --delete-branchCommon variants:
--squashfor small or iterative branches--mergewhen the repo prefers merge commits--rebasewhen the repo explicitly prefers rebased history
Before merging, confirm:
- approvals or review requirements are satisfied
- required checks passed
- the chosen merge strategy matches repo norms
After merge, sync local state:
git switch main
git pull --ff-onlyCommon Mistakes
- using
ghfor tasks that are really localgitoperations - forgetting to verify the default branch before creating the PR
- pushing a branch without
-uand then losing the upstream link - opening a PR with an unhelpful auto-filled title/body
- merging without checking CI or review status
- mixing unrelated changes into one branch or one commit
Red Flags
Stop and re-check before acting if you see any of these:
gh auth statusis not healthy- the remote is not the repo you expected
- you do not know the correct base branch
- the branch name does not describe the change
- the PR title says one thing but the diff shows another
- checks are failing and no reason is documented
When unsure, inspect first, then act.
Source: codersbrew/pi-tools — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review