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/hawkongz/github-format-standards/github-format-standardsnpx skills add hawkongz/github-format-standards --skill github-format-standardsgit clone --depth 1 https://github.com/hawkongz/github-format-standardsWhat 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.00156 | $0.04331 |
| Opus 5 | $0.00078 | $0.02166 |
| Sonnet 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 yesterday.
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 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.
- yesterday 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 (2 stars, last pushed 2mo ago), licensed MIT. It adds 156 tokens to every session and 4,331 once invoked, about $0.0008 per session on Opus 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
format-markdown
Formats Markdown files consistently using project-native tooling first (repo scripts/config), then safe fallback formatters, and verifies the result with lint/check commands. Invoked when the user asks to format markdown, tidy docs, normalize README files, or fix markdown style drift.
markdown-linter-fixer
Fix markdownlint errors in markdown files using markdownlint-cli2. Use when asked to "markdown linter fixer", "run markdownlint", "fix markdown lint errors", "fix MD029", or "resolve ordered list issues" across one or more .md files.
decided-capture
Capture a NEW decision or requirement from a conversation (an interview) into ONE valid RAC (requirements-as-code) artifact — you interview and propose, the human ratifies, decided validate closes, and promotion into the trusted corpus is by pull request reviewed by someone other than the author. Use when a user wants…
decided-import
Reformat ONE existing document (a decision, requirement, design, roadmap, or prompt) into ONE valid RAC (requirements-as-code) artifact, with a mandatory human-review step before any file is written and decided validate as the deterministic close. Use when a user wants to add or import a single existing decision or…
decided-review
Review and triage a RAC (requirements-as-code) corpus using the decided CLI — work prioritised findings worst-first until validation and relationship checks pass. Use when asked to review, triage, or fix findings across a project's AsDecided corpus (the decisions/ directory).
decided-artifacts
Author and maintain RAC (requirements-as-code) Markdown artifacts — requirements, decisions, roadmaps, prompts, designs — using the decided CLI. Use when asked to create, read, validate, update, or link AsDecided (RAC) artifacts in a project's decisions/ directory.