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 skills add hawkongz/github-format-standards --skill github-format-standardsgit clone --depth 1 https://github.com/hawkongz/github-format-standardsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/hawkongz/github-format-standards/github-format-standards)<a href="https://agentmods.dev/skills/hawkongz/github-format-standards/github-format-standards"><img src="https://agentmods.dev/badge/skills/hawkongz/github-format-standards/github-format-standards/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/hawkongz/github-format-standards/github-format-standards"><img src="https://agentmods.dev/badge/skills/hawkongz/github-format-standards/github-format-standards.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00156 | $0.04331 |
| Opus 5.5 | $0.00062 | $0.01732 |
| Sonnet 5.5 | $0.00031 | $0.00866 |
| Haiku 4.5 | $0.00016 | $0.00433 |
Grade A, and why
github-format-standards 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 1mo 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.
`mkdir -p ... && curl -o ... raw.githubusercontent.com/...` How it starts
The opening of the file, as written. The whole thing — 289 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub Format Standards
When the user wants to share a project on GitHub, run the full pipeline. Take action directly — don't just recite rules.
Full Pipeline (7 Phases)
Phase 1: Root Directory Audit
Check the project root for cleanliness:
- Red flags: large files (>1MB), temp files (
*.tmp,*.bak,~*), build artifacts (dist/,build/,*.pyc), personal config (.env,credentials.*,*.pem), IDE cruft (.vscode/,.idea/) - If found: warn the user and add them to
.gitignore - Ensure
.gitignoreexists and covers at minimum:node_modules/,__pycache__/,*.pyc,.env,.DS_Store,dist/,build/, IDE dirs
Root audit:
⚠ node_modules/ found — added to .gitignore
✓ No large files, no secrets, no build artifacts
✓ .gitignore created with 12 rules
Phase 2: File Naming & Directory Structure
Naming rules:
- All lowercase, hyphens (
my-project) or underscores (my_project) — pick one style per project - No spaces, no Chinese characters in file/directory names (unless the project IS multilingual docs)
- Scripts:
scripts/, examples:examples/, docs:docs/, tests:tests/or__tests__/, source:src/orlib/ - Fix violations immediately — rename files, move things into proper directories
Structure enforcement:
project/
├── src/ # source code (or lib/)
├── tests/ # test files (or __tests__/)
├── docs/ # documentation (optional, may use README instead)
├── scripts/ # utility scripts
├── examples/ # example usage
├── README.md
├── LICENSE
├── .gitignore
└── CONTRIBUTING.md
If the project is small (single script), the flat structure is fine — don't over-engineer.
Phase 3: Document Audit & Fix
Go through every .md file and fix:
- Headings:
# Titlenot#Title, no level skipping (#→##→###) - Code blocks: every
```has a language tag - Tables: separator row has
:---alignment markers - Lists: consistent marker (
*preferred), 2-space sub-indent - Commands: every shell command has an explicit interpreter (
python script.pynot./script.py;bash script.shnot./script.sh;powershell ...for Windows-specific commands). The reader should never guess how to run a command. - Links: no bare URLs, every image has alt text
- Chinese spacing:
使用 GitHubnot使用GitHub;支持 10 个not支持10个 - Proper nouns:
GitHubnotgithub,JavaScriptnotJavascript - File endings: exactly one trailing blank line
- Image paths: relative or CDN, never absolute local paths
- No vague/informal expressions: replace "你懂的", "you know the drill", "just works" with precise instructions. Use clean
macOS / Linux:format for platform labels, never "you already know 😄"
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 289 lines · 156 tokens per session scan A 29fb58b01e47
github-format-standards is a skill published in the GitHub repository hawkongz/github-format-standards (3 stars, last pushed 4mo ago), licensed MIT. It adds 156 tokens to every session and 4,331 once invoked, about $0.0006 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
release-notes
Compare the repository with the team's Folio wiki and write release notes: read git log since the last tag, read the Roadmap table, create or update a Release notes page and add what the roadmap table is missing. Use when asked for release notes or to sync the wiki with the code.
surface-after-care
Regelmäßiger Pflegedurchlauf für ein bereits veröffentlichtes GitHub-Repository (Stufe 1, günstig und oft wiederholbar): zuerst alle Distributionsflächen des Projekts ermitteln (npm, PyPI, Registries, Marketplaces, Stores, Website) und Änderungen später dorthin spiegeln, dann Topics setzen, Privacy-Gate, Dokumente auf…
github-repo-care
Protocol for safely creating, publishing, releasing, auditing, and maintaining GitHub repositories: check local rules and locks, create .gitignore before the first add, run privacy checks, prepare README/i18n/banner/metadata, verify release tags and GitHub releases, and update organization profiles, llms.txt files…
launch-and-growth
Get an open-source project in front of the people who need it, and keep them. Use when preparing to announce a project, writing a Hacker News or Reddit or Product Hunt post, planning a launch, writing a blog post about a release, improving GitHub discoverability (topics, About, social preview), or when the user asks…
release-engineering
Version, changelog, tag, and publish a release. Use when cutting a release, setting up automated publishing to npm/PyPI/crates.io/Maven/Homebrew, deciding whether a change is major/minor/patch, writing release notes, adopting conventional commits or changesets, planning a 1.0, or handling a bad release that needs to…
changelog
Generate, update, review, and maintain changelogs using Keep a Changelog format, semantic-release, and conventional commits. Use this skill whenever the user wants to add a changelog entry, prepare release notes, document version changes, generate a changelog from git history, configure semantic-release, understand…