Skills That Remember Their Own History
Every skill in Piskes carries its own revision history, source, and trigger conditions — not just its current text — which matters the moment an edited skill starts behaving differently.
If you've already written a skill or two for your agent — a packaged, reusable set of instructions for a recurring kind of task — you've probably also already edited one. What you might not know is that Piskes keeps a real revision history of that editing, not just the current version you're looking at.
What's actually tracked
A skill isn't stored as a single block of text that gets silently overwritten every time you edit it. Revisions are tracked, so there's a record of how the skill has changed over time, not just its present state. Alongside that, skills record their own source and their trigger conditions as first-class facts — not just the instructions themselves, but where the skill came from and under what conditions it's meant to fire.
Why this matters once a skill starts misbehaving
The moment this becomes genuinely useful is the moment a skill that used to work well starts producing worse results after an edit. Without a revision history, your only options are to remember what the old version said, or to just live with the new behavior and hope it improves. With one, you can actually compare what changed — see the prior version side by side with the current one, and figure out whether the edit itself introduced the regression, or whether something else in the surrounding context shifted.
That's a meaningfully different experience than treating a skill as a black box that either works or doesn't. It turns "the skill got worse after I edited it" from a mystery into something you can actually diagnose, the same way version history on a document lets you find the exact edit that introduced a problem instead of guessing.
Source and triggers, not just instructions
Recording a skill's source and trigger conditions separately from its instructions matters for a related reason: a skill's behavior isn't only determined by what it says to do, it's also determined by when it decides to activate and where it came from in the first place. Two skills with near-identical instructions but different trigger conditions will behave very differently in practice, and being able to see those conditions explicitly — rather than inferring them from watching the skill run — makes skills something you can actually reason about and refine, rather than something you wrote once and hope keeps working.
The practical habit worth building
Treat a skill edit the way you'd treat any other change to something you rely on: make the change, watch how it behaves over its next few real uses, and if something feels off, go back and look at what the revision actually changed rather than assuming the skill is simply unreliable. The history is there specifically so you don't have to guess.