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 Netcracker/qubership-ai-packages --skill godoc-authoringgit clone --depth 1 https://github.com/Netcracker/qubership-ai-packagesWrote 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/netcracker/qubership-ai-packages/godoc-authoring)<a href="https://agentmods.dev/skills/netcracker/qubership-ai-packages/godoc-authoring"><img src="https://agentmods.dev/badge/skills/netcracker/qubership-ai-packages/godoc-authoring/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/netcracker/qubership-ai-packages/godoc-authoring"><img src="https://agentmods.dev/badge/skills/netcracker/qubership-ai-packages/godoc-authoring.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.00204 | $0.13878 |
| Opus 5 | $0.00102 | $0.06939 |
| Sonnet 5 | $0.00041 | $0.02776 |
| Haiku 4.5 | $0.00020 | $0.01388 |
Grade A, and why
godoc-authoring scanned grade A with 0 findings 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 944 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Authoring a Go doc comment
This skill governs what a comment says and in what order. Wording, tone, sentence length, and
dialect belong to english-developer-style: load it too, and defer to it on the prose. The two
compose: this skill picks the slots; that one writes the sentences.
It is the Go sibling of javadoc-authoring and keeps its section numbering, so a review that cites
"§7b" means the same rubric in either language. Read this one for Go; do not translate the Java one
in your head. The slot model transfers unchanged, but §3, §5, and §6 do not: Go puts the
identifier's name in the first sentence, replaces {@link} with an unchecked bracket syntax, and
has no tags at all.
gofmt owns the layout of a doc comment (indentation of code blocks, list markers, blank-line
normalization) and rewrites it on every save. Never hand-align a doc comment; write the content and
let the formatter place it.
1. The correction that matters most
"Document the why, not the what" is half wrong for a doc comment, and the wrong half does the damage.
An inline // comment inside a function documents the why; it sits next to code the reader can
already see. A doc comment on a declaration documents the contract: what a caller may rely on,
what an implementer must guarantee, what holds before and after. That is a what at the level of a
promise, not a restatement of the code.
The failure mode is therefore not "explains what the code does". It is either of these:
- Narrating the implementation.
Loops over the entries and adds each to the map.The body already states it, and the comment becomes false on the next refactor. - Justifying the code's existence.
This helper centralizes the boilerplate every endpoint shared.That belongs in the commit message and the pull request description. A doc comment's reader has to use or fix the thing, not decide whether to merge it.
The test is the refactor, not the reader. Rewrite the body so it behaves identically and reads
differently: a loop becomes a call into slices, a helper is inlined, a field is renamed. Every
sentence you would then have to edit was implementation, whatever it sounded like. This is the
operative rule, because it settles cases that "specification, not details" argues about forever,
and it does not soften with visibility: an unexported function's comment goes stale on that
refactor exactly as an exported one's does, and the cost of a comment that lies is the same either
way.
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 Changed · -21 lines f973cb9ba668
- 6d ago Changed · +290 lines · -3 tokens per session 5f871bc55437
- 11d ago First seen · 675 lines · 207 tokens per session scan A 5fb5556096d6
godoc-authoring is a skill published in the GitHub repository Netcracker/qubership-ai-packages (4 stars, last pushed 2d ago), licensed Apache-2.0. It adds 204 tokens to every session and 13,878 once invoked, about $0.0010 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
golang-testing
Go testing best practices including table-driven tests, test helpers, benchmarking, race detection, coverage analysis, and integration testing patterns. Use when writing or improving Go tests.
golang-patterns
Go-specific design patterns and best practices including functional options, small interfaces, dependency injection, concurrency patterns, error handling, and package organization. Use when working with Go code to apply idiomatic Go patterns.
ast-grep
Guide for writing ast-grep rules to perform structural code search and analysis. Use when users need to search codebases using Abstract Syntax Tree (AST) patterns, find specific code structures, or perform complex code queries that go beyond simple text search. This skill should be used when users ask to search for…
golang-testing
Production-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI…
golang-samber-oops
Structured error handling in Golang with samber/oops — error builders, stack traces, error codes, error context, error wrapping, error attributes, user-facing vs developer messages, panic recovery, and logger integration. Apply when using or adopting samber/oops, or when the codebase already imports…
golang-uber-fx
Golang application framework using uber-go/fx — fx.New, fx.Provide, fx.Invoke, fx.Module, fx.Lifecycle hooks, fx.Annotate (name/group/As), fx.Decorate, fx.Supply, fx.Replace, fx.WithLogger, and signal-aware Run(). Apply when using or adopting uber-go/fx, when the codebase imports go.uber.org/fx, or when wiring…