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/danielpodolsky/ownyourcode/documentationnpx skills add DanielPodolsky/ownyourcode --skill documentationgit clone --depth 1 https://github.com/DanielPodolsky/ownyourcodeWhat 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.00044 | $0.01685 |
| Opus 5 | $0.00022 | $0.00843 |
| Sonnet 5 | $0.00009 | $0.00337 |
| Haiku 4.5 | $0.00004 | $0.00169 |
Grade A, and why
documentation-fundamentals 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 — 335 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Documentation Fundamentals Review
"Code tells you HOW, comments tell you WHY. If you only explain what the code does, you're wasting everyone's time."
When to Apply
Activate this skill when:
- Reviewing or creating README files
- Writing JSDoc/docstring comments
- Inline code comments
- API documentation
- Architecture decision records
The Golden Rule: WHY, Not WHAT
// ❌ BAD: Explains what (code already says this)
// Increment counter by 1
counter++;
// ✅ GOOD: Explains why (context the code can't provide)
// Counter must be incremented before validation runs
// to account for the edge case where initial value is 0
counter++;
README Structure (The 5 Essentials)
Every README must answer these questions:
1. What Is This? (1 sentence)
"What problem does this solve in one sentence?"
## What
A CLI tool that converts Figma designs to React components.
2. Why Does It Exist?
"What pain point motivated this project?"
## Why
Manually converting designs to code takes hours and introduces inconsistencies.
This tool automates the process, ensuring pixel-perfect components.
3. How to Install
"Copy-paste instructions that work."
## Installation
npm install your-package
4. How to Use
"The simplest possible example that works."
## Quick Start
npx your-tool --input design.fig --output ./components
5. How to Contribute (Optional)
"For open source projects."
## Contributing
1. Fork the repo
2. Create your feature branch
3. Submit a pull request
Comment Types & When to Use Them
Function/Method Documentation (JSDoc)
/**
* Validates email format and checks domain against blocklist.
*
* @param email - The email address to validate
* @returns ValidationResult with success status and error message
*
* @example
* const result = validateEmail('[email protected]');
* if (!result.success) {
* showError(result.error);
* }
*
* Note: This uses the RFC 5322 regex pattern, which is intentionally
* strict to prevent disposable email addresses.
*/
function validateEmail(email: string): ValidationResult {
// Implementation
}
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 · 335 lines · 44 tokens per session scan A 2dfadc013534
documentation-fundamentals is a skill published in the GitHub repository DanielPodolsky/ownyourcode (276 stars, last pushed 2mo ago), licensed MIT. It adds 44 tokens to every session and 1,685 once invoked, about $0.0002 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-30.
Other skills, from other repositories
agent-release-swarm
Agent skill for release-swarm - invoke with $agent-release-swarm.
agent-code-analyzer
Agent skill for code-analyzer - invoke with $agent-code-analyzer.
agui-dotnet-streaming-chat
Get started with the AG-UI .NET SDK: bootstrap and run your first streaming-chat app (client + server) with the AG-UI .NET NuGet packages (AGUI.Client, AGUI.Server, AGUI.Formatting, AGUI.Abstractions). USE FOR: which packages to install and how to wire them; constructing an AGUIChatClient against an endpoint and…
agui-dotnet-sample-step
Add a GettingStarted sample Step (a Server/Client pair) to the AG-UI .NET SDK that demonstrates one protocol feature the way we want users to write it. USE FOR: adding a new samples/GettingStarted/StepNN Server+Client pair, wiring it into AGUI.slnx and the integration-test project, giving it a deterministic…
agui-dotnet-protobuf
Use the protobuf wire transport (instead of the default Server-Sent Events) for an AG-UI connection with the AG-UI .NET SDK — a compact binary event stream negotiated via the Accept header. USE FOR: making an AGUIChatClient prefer protobuf by wiring an AGUIEventStreamHandler with ProtobufEventStreamFormatter (then…
github-pr-description
Generate and create pull request descriptions automatically using GitHub CLI. Use when the user asks to create a PR, generate a PR description, make a pull request, or submit changes for review. Analyzes git diff and commit history to create comprehensive, meaningful PR descriptions that explain what changed, why it…