Writing Claude Code Skills Like Functions
There's a repository on GitHub with a single star and no README. Its entire introduction is one line in the repo description: "Ming's skills to share for the up skill." Inside are eleven skills for Claude Code, created in September, last updated in late October.
Click in, and the first thing you see is a small gesture nobody else does: every skill opens with a table.
Signing the skill
The table looks like this: what file is input1, which skill processes it, what is output1. Even "updated input1"—which input a given output modifies—must be spelled out. Below it sits an encapsulation rule: a skill's body may only reference things listed in the input manifest; any file a skill writes must correspond to an output row. References outside the manifest count as a broken seal.
Anyone familiar with functions gets it instantly: this is a signature. Input types, side effects, return values—all posted at the door. Most people's skills are a blob of prompt text, written however they felt that day. This person's skills are small programs with an interface contract—when something breaks, you can point at the signature and say precisely which cell failed. Next to each SKILL.md sits a usage.md meant for humans: a one-line invocation plus a set of Before/After comparison images. What the model reads and what people read are kept in separate files.
The skill that manages this is called unit__skill__promote, with the goal that "when a friend gets it, they'll say: this is so useful, I need to save it." The library even turns "polishing a skill until it's worth saving" into a skill of its own, with its own vocabulary spec: three sets of terms—Scope, Level, Subject—never overlap; missing values must be registered into the schema before use. Per the author, readers can classify any tag without knowing the vocabulary contents.
Context is a prepaid cost
Another skill handles something every heavy user hits: contents of the default skills directory load once per session—the more you install, the more context you prepay. It offers three levers: move low-frequency skills into a neighboring on_demand directory, turning "prepaid every session" into "fetched by path when needed"—cost drops to zero; trim the remaining descriptions to a one-line relevance gate, no summaries; merge what can be merged into a single flow entry point—the author cites an example collapsing a hundred entries to ten.
The most interesting part is a hard rule: only the user may decide which skill counts as low-frequency. The agent must never move files on its own. A line is drawn between saving money and overstepping authority.
Filenames as enforcers
The most exacting skill in the repo governs how to write architecture decision documents. The rule: the document may only describe the "desired end state," and the filename must be desired__structure.md. The author's Q&A explains why not proposed or plan: proposed tempts you into writing comparisons, and comparisons rot first; plan is ambiguous—could be an endpoint or a sequence of steps. A file named desired refuses to hold history before you even start typing.
Writing it isn't enough—you must dry-run each rule against real cases: read the code, count things. "18 rules," "807 lines," "read by six units" are evidence; "it works" is not. One line worth copying: *a reasoning-based answer is just a guess wearing nice clothes.* Findings must be numbered; after changing one rule, rerun all cases—because passed cases share the same end-state document, a fix that saves one often gets caught by another. Last rule: once a change lands, delete the document. Documents that linger drift.
The rest
What remains are rules with personal fingerprints. The Python skill requires the same name to run through every layer—vocabulary term, class attribute, dictionary key, database column, enum value—differing only by casing convention; any other discrepancy is "explanation debt." Decisions and rationales don't go into code comments (saving tokens); they go into the skill's own _meta/decisions.md—that Q&A file is the gem of the library, each decision paired with a set of "why not that."
Some rules are pure taste: aiohttp over httpx for network requests, model_construct to skip validation for speed when building models—before adopting these, you need to know they're trade-offs, not truths. Outside the library there's a hook setup: statusline and post-write hooks hang on an npm package called graft, plus an MCP server; the published config hardcodes the author's local paths, though it's only one of several fallbacks, so forks won't be broken out of the box. One skill has nothing to do with engineering: low-poly-village, which teaches Claude to build a Dorfromantik-style browser game from scratch—even "a folder opened via index.html, no build step" is written up as a rule.
Eleven skills, one signature spec, one vocabulary, one context-cost algorithm—the repo's own unit of measurement is "skills in the default directory, times each session." Moving one low-frequency skill out permanently reduces that prepayment. One Q&A file. No stars, no audience, and the author kept pushing updates through October. The signature table sits at the door—that is probably the full extent of its ambition.
---
*Source: github.com/mingzilla/public_skills (full repo cloned and read directly, 11 skills; metadata via GitHub API: created 2026-09-04, last push 2026-10-22, 1 star, 34 followers). Quotes come from SKILL.md and _meta/decisions.md in the repository.*