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 instructions/future-architect/uzomuzo-oss/coding-standardsgit clone --depth 1 https://github.com/future-architect/uzomuzo-ossWhat 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.01286 | $0.01286 |
| Opus 5 | $0.00643 | $0.00643 |
| Sonnet 5 | $0.00257 | $0.00257 |
| Haiku 4.5 | $0.00129 | $0.00129 |
Grade A, and why
uzomuzo-oss coding-standards.instructions.md 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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Coding Standards
Clean Code Principles
- YAGNI (You Aren't Gonna Need It): Do not implement functionality until it is actually needed.
- DRY (Don't Repeat Yourself): Avoid code duplication through proper abstraction and modularization.
- Single Responsibility Principle: Each function, struct, and package should have one clear purpose.
- Delete Unused Code: Always remove unused variables, functions, structs, and other dead code when making changes. This includes cleaning up imports that are no longer needed.
Function Organization and Ordering
- Public Functions First: Place all exported (public) functions at the top of the file, followed by internal (unexported) functions below.
- Logical Grouping: Within public and internal sections, group related functions together.
- Constructor Pattern: If present, place
New...constructor functions immediately after type definitions.
Abstraction and Interface Guidelines
- Value-Driven Abstraction: Only create abstractions when they provide clear value. Avoid over-engineering with unnecessary abstractions.
- Interface Creation Rules: Create interfaces only when:
- Multiple implementations exist or are planned
- Dependency inversion is genuinely required for testability or architectural reasons
- Polymorphic behavior is actually needed
- Pragmatic Design: Prefer concrete types over interfaces unless abstraction serves a specific, valuable purpose.
Leverage the Zero Value
A key tenet of idiomatic Go is to make the zero value of a type useful.
- Design for a Useful Zero Value: Strive to design structs where the zero value is a valid and ready-to-use default. This can often eliminate the need for
New...constructors. - Negative Naming for
boolFlags: If a feature should be enabled by default, name the flag with a negative sentiment (e.g.,DisableXxxinstead ofEnableXxx), so its zero value (false) corresponds to the desired default behavior.
Struct and Field Management
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 · 85 lines · 1,286 tokens per session scan A 8d9f9a2f092e
uzomuzo-oss coding-standards.instructions.md is an instructions file published in the GitHub repository future-architect/uzomuzo-oss (32 stars, last pushed yesterday), licensed Apache-2.0. It adds 1,286 tokens to every session, about $0.0064 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-09-01.
Other instructions, from other repositories
awesome-go AGENTS.md
AGENTS.md instructions for avelino/awesome-go, covering awesome-go · llm contribution guide, project snapshot, when modifying the awesome list, coding guidelines and testing & validation.
azure-sdk-for-go go-code.instructions.md
Instructions for Azure/azure-sdk-for-go: All code should follow the guidelines from the Azure Go SDK Guidelines. This document is a summary of the most important guidelines to follow when contributing to the Azure Go SDK.
neva AGENTS.md
AGENTS.md instructions for nevalang/neva, covering neva engineering guide, project model, repository map, documentation and ai engineering harness.
chatgpt-cli CLAUDE.md
Instructions for kardolus/chatgpt-cli, covering chatgpt-cli — release runbook, prerequisites, 1. cut the release, 2. publish the github release + binaries and 3. update the homebrew tap.
homebutler CLAUDE.md
Instructions for Higangssh/homebutler, covering homebutler, verify before claiming anything works, writing commits, prs, and comments, no tool attribution and commit subjects.
Sighthound AGENTS.md
Instructions for Corgea/Sighthound, covering claude, commands, python / django test naming and agent skill.