blog · Artikel auf Englisch

Snotra 1.12.1: skills that keep what they learn

A skill written for another agent now finds its own files in Snotra, and a skill you have loaded can write back to its folder — approved like any other write. Plus AGENTS.md where repositories keep it, and hidden files in the folder panel.

Snotra 1.12.1 is out. It is a small release with one theme: skills that were written for other agents should work in Snotra as they are, and a skill should be able to keep what it learns. Two smaller changes ride along — the project AGENTS.md now sits where repositories actually keep it, and the folder panel can show hidden files.

Skills that find their own files

A skill is more than its SKILL.md. Many put their actual knowledge next to it, in references/, assets/ or scripts/, and point there from the instructions. Snotra could always read those files, but only through its own addressing: skill:<name>/assets/rules.md.

Skills written for other agents do it differently. They look up their own folder and then read <that folder>/assets/rules.md by its absolute path. Snotra refused that as “outside the workspace”, and the model did what models do when a file is missing: it carried on from memory, with what it expected the file to say.

Both halves of that are fixed:

  • load_skill reports the folder. The result names the skill's directory and how to reach the files next to it, so the model doesn't have to go looking.
  • An absolute path into a skill folder counts as a skill path. Every read tool treats it like the skill: form. That includes a symlinked skills directory — ~/.agents/skills pointing at another agent's skills folder works in either spelling. The checks against .. and against symlinks leading out of the folder run unchanged.
  • No silent substitute. If a file a skill depends on can't be read, the model is now told to say so and name the file, rather than guess at its contents.

In the tool log, such a read shows up as a skill access — “File assets/rules.md (skill time-booking) read” — instead of a long absolute path that looks like it came from the project.

Skills that keep what they learn

Reading was half of it. Many skills also write to their own folder: a mapping table that grows with every correction, a template, a state file their scripts update. Until 1.12.1, every skill folder was read-only in every mode, so a skill could look up a rule but never add the one it had just been taught.

Now a skill that is loaded in the current reply can write to its own folder. Loaded means: called by you with /name, or fetched by the model with a successful load_skill. Switched on in the settings isn't enough.

  • File tools. write_file_text, edit_file and apply_patch accept skill:<name>/… and absolute paths inside the folder.
  • Scripts. With the sandbox on, shell_execute and run_python may also write to the folders of the loaded skills, and the card lists them under “Loaded skills”. shell_execute can run inside a skill folder with cwd: "skill:<name>", so a skill's own scripts find their files.
  • Approved like any other write. “Smart” asks, “Always ask” asks, “Auto” writes. The card names the skill and says that the change applies wherever that skill is switched on.
  • Read-only otherwise. A skill that is switched on but not loaded stays read-only, and so do the skills that ship with the app. Every new reply starts with nothing loaded.

This deserves an honest word about risk. A global skill lives in your home directory and is used across projects. A skill that can write to itself is therefore a way for a prompt injection to outlast the conversation it came in with: a poisoned web page talks the model into “remembering” an instruction in a skill's rules file, and the next project reads it. What limits that: the skill has to be switched on and loaded in the same reply, the app's own skills are excluded, and in “Smart” and “Always ask” the card shows the change and how far it reaches before anything is written. In “Auto” there is no card — as for every other write in that mode. The security concept has the full reasoning.

Speaking of which: the permission model now has an infographic. It shows the two controls side by side — the mode decides whether Snotra asks, the sandbox decides how far a program it runs can reach — and what stays blocked in every mode. It sits at the top of the security notes in the README.

AGENTS.md at the root of the folder

The project-level AGENTS.md is now read from <folder>/AGENTS.md, where most repositories keep it, instead of <folder>/.agents/AGENTS.md. An existing AGENTS.md works as it is; open the folder, and Snotra follows the same project instructions as the other agents you use there.

If you had put yours under .agents/ after an earlier release: that location is no longer read, so move the file up one level. The global files (~/.snotra/AGENTS.md and ~/.agents/AGENTS.md), the memory file and the skills in .agents/ stay where they are.

Hidden files in the folder panel

An eye in the header of the folder panel shows and hides dot files. So does View › Show Hidden Files, and Cmd+Shift+. on macOS, Ctrl+Shift+. on Windows and Linux — the same shortcut as in the macOS Finder. Hidden entries sit in the normal order, dimmed, and the setting survives a restart. .git, .DS_Store, Thumbs.db and desktop.ini stay out either way.

The shortcut was more work than it looks. On a German keyboard, Shift+. types a colon, so a menu accelerator bound to the character never fires there. Snotra matches the physical key instead. And on the way, .env, .gitignore and friends stopped landing on the “binary file” card: a file name that starts with a dot has no extension, so the list of text extensions never matched them. They now open in the text preview.

What the model sees through its own tools is unchanged by the switch; it only changes what you see in the panel and in the @ menu.

If you skipped 1.12.0

1.12.0 came out two days earlier. In short: the file preview shows images and PDFs, each workspace remembers its own default permission mode, and before remembering something Snotra now asks where to store it — for this project or everywhere.

Getting it

Snotra checks for a newer version at startup and walks you through the update, one confirmed step at a time. Otherwise, download it for macOS, Windows or Linux, or read the release notes on GitHub. If a skill you use elsewhere still doesn't work in Snotra, I'd like to hear which one and where it stops — the Discussions are open for that.