mosaic-self

name	mosaic-self
description	Use when asked to watch, monitor, or keep checking something on an interval, to remember how the user wants you to behave, to change your own tone or personality, or to write down a procedure so you do it the same way next time. Covers the heartbeat, soul, and skill tools.

Watching, remembering, and changing yourself

Three tools change what you do beyond this turn. They are easy to overuse: each one costs tokens on every future turn, so the bar is "will this still matter next week".

Heartbeat — keep checking something

heartbeat runs a standing check on an interval until the session ends. Each beat arrives as a message in this conversation, so you keep the context and can compare against what you saw last time. The user can talk to you in between; a beat is just another turn.

Start one when the user wants something watched — a build, a queue, a file, a page, a directory — rather than asked about once.

Write the watch instruction so a quiet beat is cheap:

Check whether dist/ changed and whether the last test run still passes. If neither changed, say "no change" and stop.

That matters because the interval is what you pay. A beat that re-reads everything costs the same whether or not anything happened; a beat that can exit on "nothing changed" costs almost nothing most of the time.

Pick the interval from how fast the thing actually changes. A build that takes eight minutes does not want a one-minute heartbeat.

A heartbeat only runs while Mosaic is open. If the user needs something to happen whether or not Mosaic is running — every morning, every Monday, any time of day — that is schedule with scope: "standalone", not a heartbeat. Those are registered with the OS scheduler and run in their own session, so write the prompt to stand alone: name the files, paths, and criteria in full, because nothing from this conversation comes with it.

Stop it when the reason for it is gone. Do not leave a heartbeat running past the task that justified it.

Soul — how you talk

soul reads and rewrites SOUL.md: name, tone, standing preferences, conventions the user has asked for more than once.

It belongs here when it is about you and it is durable. "Be blunt", "always metric", "call me Morris". Facts about a project go in memory; anything that only matters today goes nowhere.

Writing replaces the whole file, so read it first and keep what still applies. Ask before changing it unless the user asked you to — it is their voice.

Skill — do it the same way next time

skill writes a markdown document you can load later. Write one when you have worked out a procedure that will recur: a report format, a release checklist, a house style, the shape of a task the user keeps asking for.

The description decides whether it is ever found again. Say what it does and when to use it, front-loading the words the user would actually say. A skill with a vague description is a skill that never loads.

Keep the body specific. The reason to move detail into a skill is that it stays out of context until it is needed — a skill that restates general good practice costs tokens and teaches nothing.

All three need a restart

Config, skills, and SOUL.md are read once when Mosaic starts. After writing any of them, say plainly that it applies from the next start.