Is this a prompt, or is it a skill?
The line isn't length or polish. It's whether the thing carries its own judgement about when to apply.
A prompt is an instruction you supply at the moment you need it. A skill is a package that knows when it applies, carries the references and scripts to do the job, and can be invoked without you restating the context. The practical test is whether it survives being handed to someone who was not in the conversation: if it needs your expla…
You have a prompt that works. It took a few attempts to get right, it produces good output, and you have started keeping it in a note so you can paste it again.
The question is whether that is worth turning into something more formal, and the answer is not about length or polish.
The distinction
A prompt is an instruction supplied at the moment of use. You are present. You know why you are asking, what the situation is, and what a good answer looks like. The prompt carries the request; you carry everything else.
A skill carries the everything else. It knows the conditions under which it applies. It brings its own reference material. It states the failure modes. It can be invoked by someone who was not in the conversation where it was written — including a version of you six weeks from now, which is functionally a different person.
The test that settles it
Hand it to a colleague with no explanation. If they need to ask when to use it, it is a prompt with formatting. If they can tell from the thing itself whether their situation is the one it was written for, it is a skill.
Almost everyone gets this wrong in the same direction: they expand the instructions and leave out the triggers. The result is a longer prompt that is no more portable, because the missing piece was never the instructions.
What actually needs writing down
Four things, roughly in order of how often they are omitted:
- When it applies. The symptoms. "Use this when X keeps happening" is worth more than a page of method, because it is the part that cannot be reconstructed from context.
- When it does not. The boundary is genuine information. A skill that claims to apply everywhere gets invoked everywhere and is right sometimes.
- What goes wrong. The failure modes you hit while working it out. This is the most valuable content and the first thing lost, because by the time you write it up you have stopped making those mistakes.
- The deterministic parts, as scripts. Anything with one right answer should be code, not instructions. A model asked to reproduce a calculation will occasionally produce a different one.
Why the triggers are the hard part
Because they were never explicit. You knew when to use the prompt — you were in the situation. Recovering that knowledge means asking what was true about the moment you reached for it, and that is a different question from what the prompt does.
The useful prompt: think of the last three times you used it, and write down what those three situations had in common. That commonality is the trigger, and it is usually more specific than expected.
When not to bother
Most prompts should stay prompts. Packaging costs an hour and pays back only on repetition or handoff. If you have used it twice and expect to use it twice more, keep pasting it.
The signals worth acting on are: you have explained it to someone more than once, you rewrote it from scratch because you could not find the old one, or it encodes something you learned the hard way and would rather not learn again.
Frequently asked questions
Isn't a good prompt enough?
What actually goes in a skill besides the instructions?
How long should one be?
Related skill
Turn this guide into a skill your agent can run
Stop re-explaining the same workflow. Loreto packages it as a Claude Code skill from any source.