gh
Skill1 starsChanged 8 months agoMITView on GitHub
GitHub CLI (gh) and GitHub Actions workflows with git hygiene: secure CI YAML, least-privilege tokens, caching, concurrency, script-injection prevention, PR and issue automation, and operational commands. Use when authoring or reviewing .github/workflows, debugging Actions runs, using gh for repos/issues/PRs/runs/secrets/api, or when the user mentions GitHub Actions, GHA, workflow YAML, gh CLI, GITHUB_TOKEN, or GitHub automation.
- Reads credentials
In this repository33 other files it gives its agents.
- argocdSkill
- c-cpp-compilersSkill
- coding-guidelinesSkill
- devops-iac-engineerSkill
- dag-flowdSkill
- flowd-rules-authorSkill
- frontend-designSkill
- grafana-dashboardsSkill
- helmSkill
- kustomizeSkill
- legalizerSkill
- lua-projectsSkill
- markdown-documentationSkill
- mermaid-diagramsSkill
- meta-cognition-parallelSkill
- podmasterSkill
- practical-haskellSkill
- rcaSkill
- researcherSkill
- security-auditSkill
- solidity-securitySkill
- svg-genSkill
- tdd-red-green-refactorSkill
- tmux-masterySkill
- tokenomics-designSkill
- ultimate-dbSkill
- ultimate-nixosSkill
- ultimate-rustSkill
- ultimate-web3Skill
- web3-frontendSkill
- web3-testingSkill
- web3-whitepaperSkill
- ziglangSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 5 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
6
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
- Very specific: line 15
Read the relevant reference before suggesting version-specific action tags or gh flags.
- Distinctive: line 20
Branches: Use a consistent team convention for naming.
- Very specific: line 21
Secrets: Never commit tokens, keys, or .env with real credentials.
- Distinctive: line 22
History: Avoid rewriting shared history without team agreement.
- Very specific: line 29
Automation-friendly output: Prefer --json and --jq over scraping human tables in scripts.
- Very specific: line 36
Secrets and untrusted input: Use secrets.* for sensitive values.
- Very specific: line 37
Forks and
pull_request_target: Treat as high risk; never check out arbitrary fork refs in a context that can reach secrets without an … - Distinctive: line 38
Performance: Use path filters, concurrency groups, caching, and matrix design intentionally.
- Distinctive: line 45
Enterprise or org policy: Follow internal security and compliance rules over generic advice here.
- Distinctive: line 46
Deep Git internals: Use project docs or a dedicated Git reference for advanced history surgery.
- Very specific: line 47
Auditing a repository for vulnerabilities: Use security-audit. This skill covers Git and Actions authoring.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Git, GitHub CLI, and GitHub Actions
Reference files
| Topic | File | When to read |
| GitHub Actions (workflows, security, performance) | reference/github-actions.md | Writing or reviewing workflow YAML, CI design, hardening |
GitHub CLI (gh) | reference/gh-cli.md | Commands for repos, issues, PRs, runs, secrets, API |
Read the relevant reference before suggesting version-specific action tags or gh flags; prefer verifying against current docs or gh --help.
Git (repository hygiene)
- Commits: Small, coherent changes; messages that state intent and context (what changed and why, not only how).
- Branches: Use a consistent team convention for naming; keep feature branches short-lived and rebased or merged against the default branch as appropriate to the project policy.
- Secrets: Never commit tokens, keys, or
.envwith real credentials. Use secret managers, GitHub Secrets, or local git-ignored files. - History: Avoid rewriting shared history without team agreement. Prefer
git revertfor public fixes on main when others depend on the graph. - Hooks and config: Align with project
pre-commit/ CI checks; do not bypass hooks to land broken formatting or tests.
GitHub CLI (gh)
- Auth:
gh auth loginfor interactive use;GH_TOKEN(orGITHUB_TOKENin Actions) for automation. Scope tokens to the minimum required. - Repo context:
gh repo set-default owner/repoin a clone reduces repeated--repoflags. - Automation-friendly output: Prefer
--jsonand--jqover scraping human tables in scripts.
Full command map, environment variables, and doc links: reference/gh-cli.md.
GitHub Actions (high level)
- Permissions: Declare minimal
permissions:at workflow or job level; default broad scopes are rarely needed for build/test. - Secrets and untrusted input: Use
secrets.*for sensitive values; avoid interpolatinggithub.eventfields directly intorun:shells (see reference/github-actions.md). - Forks and
pull_request_target: Treat as high risk; never check out arbitrary fork refs in a context that can reach secrets without an explicit, reviewed pattern. - Performance: Use path filters, concurrency groups, caching, and matrix design intentionally; skip redundant setup when the runner image already provides the tool (confirm via runner image docs in the reference).
- Supply chain: Pin third-party actions to a commit SHA when policy requires; keep actions updated (Dependabot or equivalent).
Structured checklist, official documentation links, and patterns for clean workflows: reference/github-actions.md.
When this skill is not enough
- Enterprise or org policy: Follow internal security and compliance rules over generic advice here.
- Deep Git internals: Use project docs or a dedicated Git reference for advanced history surgery.
- Auditing a repository for vulnerabilities: Use
security-audit. This skill covers Git and Actions authoring.
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
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.