I have a small set of Python scripts I use all the time: a price monitor that watches product pages, a backtester for trading ideas, a Reddit searcher for freelance leads. They worked fine from the terminal. But every time I wanted Claude to use one, I re-explained the whole thing in a prompt. Then I packaged each one as a skill, and the re-explaining stopped.
What a skill actually is
A skill is just a folder with a SKILL.md file: a short description of when to use it, plus instructions for how. Claude reads the description automatically and loads the details only when a request matches. It is documentation with an activation trigger attached.
The anatomy is almost boring:
---
name: price-watcher
description: "Watch product prices on any webpage and alert when a price"
hits a target or drops by a set percentage. Use when the user wants to
track a product price or monitor for drops.
---
# Price Watcher
## When to use
- "Watch this product and tell me when it drops below $X"
## How to run a check
1. Collect the URL(s) and the rule from the user
2. Copy config.example.json to config.json, fill in urls/rules
3. Run: python monitor.py --config config.json
## Limits (be honest)
- JavaScript-rendered prices are not supported
The pattern, in four moves
First, make the script boring to run: one command, one config file, predictable output. If you need five flags to do anything, Claude will get it wrong, and so will you. My price monitor became one command with a config, and nothing else.
Second, write the description as the request, not the feature. "Watches prices" is a feature. "Use when the user wants to track a product price or get notified about drops" is a trigger. Skills fire on the overlap between what you say and what the description says.
Third, put the honesty inside the file. My backtester skill says, as part of its own instructions, that past performance does not predict returns and that parameters tuned until the curve looks good are memorization, not edge. Now Claude volunteers those caveats without being asked - they are part of the procedure, not an afterthought.
Fourth, bundle the boring parts: a config example, a tiny sample dataset, an offline test. The sample dataset matters more than you might think - it lets anyone, or any agent, verify the pipeline works before pointing it at real data.
What changed and what didn't
In practice: "watch this product and tell me when it drops ten percent" now just works. The skill collects the URL and the rule, writes the config, runs the script, reads the result back. Same for "backtest an SMA crossover on my CSV". The scripts did not change - the interface did.
The limits did not change either. A price monitor still cannot see JavaScript-rendered prices. A backtester still does not model fees and slippage. A skill is an interface layer, not a capability upgrade - if the script cannot do a thing, the skill will not make it happen.
Installation is deliberately unglamorous: copy the folder into ~/.claude/skills/, pip install once, start a new session. Two minutes. No accounts, no telemetry, nothing phones home - the skill is documentation, the script is yours.
The bigger pattern
Scripts are for machines; skills are for conversations. The same automation, packaged as a skill, stops being a tool you operate and becomes a capability you can ask for in a sentence.
If you want the whole thing assembled, I packaged my price watcher and backtester as a two-skill starter pack: the Claude Skill Pack.
The same store also has the underlying kits standalone, with longer READMEs: the Price Monitor Kit and the Python Backtest Toolkit.
Why $1? On purpose - collecting the first round of honest reviews. If the pack disappoints you, say so in the product Q&A; that is exactly what the price is for.
Happy packaging - and may your descriptions be written in the words people actually say.
Top comments (0)