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/buildinternet/uploads/docs-page-stylenpx skills add buildinternet/uploads --skill docs-page-stylegit clone --depth 1 https://github.com/buildinternet/uploadsWhat 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.00203 | $0.04196 |
| Opus 5 | $0.00102 | $0.02098 |
| Sonnet 5 | $0.00041 | $0.00839 |
| Haiku 4.5 | $0.00020 | $0.00420 |
Grade A, and why
docs-page-style 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 2d 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.
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 — 319 lines — stays where its author put it; the contents beside it link to each section on GitHub.
uploads.sh docs page style
These pages teach a developer (or their agent) to do one thing with the uploads
CLI and then get out of the way. Each subject page is one .mdx file in the
docs content collection (apps/web/src/content/docs/), rendered through
DocsLayout by the apps/web/src/pages/docs/[...slug].astro route: you write
Markdown prose, fenced code blocks, and a small, fixed vocabulary of HTML
wrappers and components. The hub page (apps/web/src/pages/docs.astro) is still
a plain Astro page — it is a card index, not prose. The goal is a page that reads like reputable dev-tool docs (Stripe, Vercel, Wrangler):
one short orientation, then commands you can actually run, with prose used only as
connective tissue.
The failure mode to fight is the opposite: heavy paragraphs, an example for every variation, a copy button on every line, and setup buried below usage. That reads as "complicated" even when every sentence is individually fine — because the structure makes the reader work.
How to approach a page
- Read the page and identify the ONE thing it's for. Everything else is secondary and should be demoted or linked out, not given equal weight.
- Decide the page's job. A hub/landing page (
docs.astro) triages and links — it should not re-teach what a subject page already covers. A subject page walks through one workflow. Don't duplicate a worked example that lives on another page; link to it instead. - Order it: understand → set up → do. A short "what/why", then install or prerequisites, then the golden-path command. A reader should be able to run the first real command without scrolling back up to find setup.
- Pick one golden path. If there are two ways to do the thing, show the more universal one as the worked example and demote the other to a one-line pointer (see the pattern below). Never present two competing commands as parallel entry points — that fork is the single most common source of "this feels complicated."
- Apply the prose, copy, and inline-code rules below to what's left.
- Verify it renders. Reuse only the existing component classes, keep every
command/flag/link real (never invent one — check a sibling page or the CLI),
and confirm the page still compiles (
pnpm buildinapps/web).
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.
- 2d ago First seen · 319 lines · 203 tokens per session scan A d3dbb831ac07
docs-page-style is a skill published in the GitHub repository buildinternet/uploads (19 stars, last pushed 2d ago), licensed Apache-2.0. It adds 203 tokens to every session and 4,196 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-30.
Other skills, from other repositories
open-pr
Take a cloudflare/agents GitHub issue plus any repro findings and one-shot a fix PR — branch, change, test, push, and open the PR linked to the issue.
release-notes
Draft short release notes from a list of changes. Use when the user asks for changelogs, release notes, or a concise product update.
test-plan
Produce a focused test plan for a change. Use when the user asks how to test a feature, what cases to cover, or for a QA checklist before shipping.
workspace-digest
Summarize the files saved in this assistant's shared workspace. Use when the user asks what is in their workspace, for a file inventory, or a digest of saved work.
debug-plan
Create a systematic debugging plan for a bug report. Use when the user asks how to investigate a failure, regression, or unexpected behavior.
pirate-voice
Rewrite or answer in a playful pirate voice. Use when the user asks for pirate tone, nautical phrasing, or says to talk like a pirate.