Freeze outside-the-repo state into one snapshot. Use when the work depends on the current state of a service, database, queue, third party, or live logs.
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Build the snapshot, invoking each named skill with the Skill tool where its condition holds:
A hand-retrieved fact, a re-observation, or an amendment re-enters the snapshot, and the snapshot gets judged again. A fact's value is observed or it is a gap; there is no third kind.
One snapshot, in conversation, stateless: re-run the whole freezing to refresh it. Hand it back as two lists of short bullets — each observed fact on one line with where it lives and when it was read, each gap on one line named as a gap.
It stands when judge's verdict stands and the user locks it, or when the user stops with gaps standing. A snapshot with named open gaps is a valid lock; the gaps are what is open.
Every needed fact lives in the repo → read them where the work runs; no snapshot. The outside system is to be changed, not read → that is the work itself, not its grounding; proceed with the work.
saadshahd/moo.md
80ad1fe
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.