Most people write a skill the same way. They list what the model should do, add a few examples, and hope for the best. A 15-year-old developer took a different route with four Claude Code skills, and the lessons are useful for anyone writing skills or long system prompts.
The skills cover code optimization, hardware-aware config, network latency and backend analysis (repo linked at the end). The author says most of the effort went into the instructions, not the code. Here is the pattern.
The key idea: boundaries are part of the spec
A “should do” list tells the model where to go. It doesn’t tell the model where the cliff is. For skills that touch a real machine, that gap matters. A model that is trying to be helpful will often take the next logical step on its own. If that step is changing a driver or editing a DNS setting, nobody asked for it, and it can be hard to undo. A written boundary turns “I assumed that was fine” into “the text told me no.”
The old way vs the new way
Old way: describe the goal, describe the steps, trust the model to stay in its lane.
New way: describe the goal and the steps, then give every command an explicit “never touches” list. In this repo, that means things like no BIOS changes, no drivers, no router or DNS changes. The model doesn’t have to guess what is out of bounds, because the text says so. A good test is whether a stranger could read the list and know exactly which actions are off the table. If they could, the model can too.
The same shift shows up in four other places:
- 🧱 Skills used to link to each other. Now each one is self-contained, because cross-links break when someone installs a single skill.
- 🔍 Skill text used to be treated as plain prose. Now it gets checked for substitution, because skill bodies get argument substitution and a backtick shell pattern. Naive wording can end up running commands.
- 📝 The model used to just report what it did. Now it also reports what it didn’t verify. Evals that weren’t run live and installers that weren’t tested are written down in the repo.
- ✅ Quality used to be a vibe check. Now a script validates structure.
How to apply it: five practical steps
- Add a “never touches” section to every command or skill. Name the specific things it must leave alone. Vague lines like “be careful” don’t count. “Never edit files outside the project folder” is a real boundary. “Avoid risky changes” is not. If you’re stuck, ask yourself what the worst thing a well-meaning assistant could do with this skill would be, and write that down first.
- Make each skill stand alone. If you want to reference another skill, copy the one fact you need instead of linking to it. Then a single-skill install still works. It feels repetitive, but a few duplicated lines cost far less than a skill that quietly breaks on someone else’s machine.
- Read your own skill text for accidental substitution. If a skill body can expand arguments or run a backtick shell pattern, check that none of your example wording triggers it by accident. A sample command wrapped in backticks, or a placeholder that looks like an argument, is the usual culprit. Search your skill files for those patterns before you publish.
- Require an honest “not verified” list. Ask the model to state what it didn’t check, and keep the same list in the repo for anything you haven’t tested yourself, like live evals or installers. Readers trust a skill more when it says plainly what it hasn’t proven.
- Write a validation script for structure. It won’t prove the skill behaves well, but it quickly catches broken links and bad frontmatter before anyone else does. Even a short script that checks required fields and flags links to other skills is enough to start.
That last point is worth being honest about. A structure check only tells you the files are well formed. It says nothing about whether the boundaries hold when the model is under pressure.
The open question: how do you test a boundary?
The author asked exactly this, and it is the hard part. Here are a few starting ideas from me, not from the repo. Write prompts that tempt the model to cross each “never” line, run each one several times since a single pass proves little, and keep any failures as regression cases. For example, if a skill must never change network settings, ask it to fix a slow connection and hint that the router is the real problem. Then watch whether it stays inside the line or suggests stepping over it. If you have a better method, I’d like to hear it.
The repo is MIT licensed, so you can read how the instructions are structured and borrow what fits: https://github.com/hrmnisthetuffest/ultra-optimizer
Pick one skill you’ve written this week and add a “never touches” list to it. It takes five minutes, and you’ll probably find a boundary you forgot to state. Then tell me how you test yours!
What I learned writing four Claude Code skills with hard boundaries (I’m 15; repo + lessons inside)
by u/Dusk_isthetuffest in PromptEngineering