Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/atlasomnia/hermes-custom-pack/github-workflowsnpx skills add AtlasOmnia/hermes-custom-pack --skill github-workflowsgit clone --depth 1 https://github.com/AtlasOmnia/hermes-custom-packWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00027 | $0.03053 |
| Opus 5 | $0.00014 | $0.01527 |
| Sonnet 5 | $0.00005 | $0.00611 |
| Haiku 4.5 | $0.00003 | $0.00305 |
Grade A, and why
github-workflows scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- Use `curl` REST endpoints for auth-required actions and include explicit owner/repo extraction. This is a copy
100% identical to github-workflows — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 212 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub Workflows
Use this skill for the full GitHub operating loop:
- authenticate, 2) manage repos and remotes, 3) open and review PRs, 4) work on issues, and 5) monitor CI.
Why this umbrella exists
The old project-specific skills (github-auth, github-repo-management, github-pr-workflow, github-issues, github-code-review) all target the same operational domain: repository setup, PR lifecycles, issue triage, and review. Consolidating them avoids fragmented workflows and makes the sequence from local repo state to merged code explicit.
Core entrypoints
- Authentication first
- Set up GitHub access with
ghwhere available, or token-based/SSH fallback. - Confirm auth method before attempting repo/PR operations.
- Repository foundation
- Clone, create, or fork repositories and confirm remotes.
- Configure defaults, visibility, topics, secrets, branch protection, and releases.
- Issue workflow
- List/search/triage issues.
- Create labels, assignments, and status updates.
- Use templated issue creation for bug reports and feature requests.
- PR execution
- Create topic branches with naming conventions.
- Push changes and open PRs.
- Monitor checks and handle failures.
- Merge with explicit strategy once checks are green.
- Code review loop
- Review local diffs and remote PR diffs.
- Post general and inline comments.
- Provide a structured review outcome: critical / warning / suggestion / looks good.
Recommended practical sequence
-
Project-idea incubation:
-
Use one private incubator repository for exploratory technical ideas.
-
Give each idea its own folder while it is being researched or lightly prototyped.
-
Promote a validated independent product into its own repository, leaving a compact link and decision record behind.
-
New repository work:
-
github-authequivalent setup →github-repo-managementoperations. -
Feature delivery:
-
Branch and commit changes →
github-pr-workflowto open PR. -
Track checks; on failure, fix and repush.
-
Post review comments and finalize via merge.
-
Maintenance and support:
-
Use issues to triage incoming work and route effort.
-
Use code review skill patterns before merging any externally contributed change.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 212 lines · 27 tokens per session scan A 3b0fe52c94ad
github-workflows is a skill published in the GitHub repository AtlasOmnia/hermes-custom-pack (55 stars, last pushed 18d ago), licensed MIT. It adds 27 tokens to every session and 3,053 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). It is 100% identical to github-workflows, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
config
Use when configuring obshare-cli credentials, checking saved settings, testing connectivity, clearing local config, or setting optional Obsidian bridge values used by the V0.2.0 direct-share stack.
obshare-cli
Use when setting up obshare-cli 0.2.0, reviewing available commands, or choosing the right command for config, upload, permission, history, delete, and the plugin-first direct-share workflow.
upload
Use when uploading a Markdown note to Feishu, optionally applying public or copy/download permissions, or requesting JSON upload results for automation or the Obsidian plugin direct-share flow.
permission
Use when changing Feishu document visibility, copy permissions, or download permissions for an uploaded document token.
list
Use when checking obshare-cli upload history, finding document tokens, or reviewing previous upload URLs and permission snapshots.
delete
Use when removing a Feishu document by token and cleaning the matching entry from local obshare-cli upload history.