Stop re-pasting your system prompt: skills and custom agents

Look in your notes app right now. Somewhere in there is a paragraph that starts “You are a senior engineer. Follow our conventions.” Maybe it lives in a prompts.md at the root of a repo. Maybe it is a Slack message you sent to yourself so you could copy it back out later. You paste it into a new session, tweak two words, and get to work. Next week you paste a slightly different version, because you edited it in one place and not the other.

That paragraph is doing real work, and the way you are storing it guarantees it will rot. It drifts as you edit copies. Your teammate has their own copy that diverged three months ago. Nothing about which prompt produced which result is written down anywhere. The prompt is load-bearing infrastructure kept in a text file you re-paste by hand.

The fix is not a better text file. It is noticing that you have been cramming two different kinds of thing into one blob, and giving each one the home it actually wants.

Knowledge and configuration are not the same thing

Read your saved prompt closely and you will find two ingredients tangled together.

The first is knowledge. How your team writes database migrations. Which fields your API responses always include. The release checklist nobody remembers in full. This is reference material. It is true regardless of which model reads it, and most of it is irrelevant to any single task. You wrote it down because the agent needs it sometimes, not because it needs it every turn.

The second is configuration. Which model to run. What reasoning budget. What role the agent is playing. Which tools it can reach. This is not reference material at all. It is a set of choices about how the agent is set up before it reads a single word of your task.

These two things want opposite treatment. Knowledge wants to be plentiful, specific, and mostly dormant, pulled in only when a task touches it. Configuration wants to be fixed, named, and applied identically every time. Stuffing both into one paragraph you paste by hand gives you the worst of each: the knowledge is always present whether the task needs it or not, and the configuration is never actually recorded, just re-typed from memory.

Knowledge belongs in skills

A skill is a small named document. It has a name, a one-line description, and a Markdown body that holds the actual instructions: the migration conventions, the review checklist, the changelog format.

The part worth slowing down for is how a skill is loaded, because it is the whole point. You do not want ten convention documents sitting in the context window on every turn. Context is finite and it is not free. Every token you spend re-stating your migration rules is a token not spent on the task, and a model reading a wall of mostly-irrelevant reference material is a model with worse focus, not better.

So a good skill system does not load the document. It loads one line: the name, the description, and where the full text lives. That single line is all the agent sees until it decides, from the description, that the current task actually calls for that skill. Only then does it open the document. Carrying ten skills costs ten lines of context, not ten documents. The knowledge is available without being present.

This inverts the usual tradeoff. With a pasted prompt, every convention you add makes every session heavier, so you keep the prompt short and leave things out. With on-demand skills, adding another one costs a line. You can afford to write down the obscure stuff, because it only shows up when it is relevant.

Configuration belongs in a named preset

The other half, the configuration, wants to become a thing you can name and reuse. Not a paragraph you retype, but a saved agent: a “PR reviewer,” a “migration writer,” a “docs updater.” Each one is a fixed bundle of choices.

Take the reviewer. Retyping it looks like opening a session, selecting a model, pasting “focus on correctness and security, flag anything that touches auth,” and then remembering to also mention the team’s review checklist, which you usually forget. Do that ten times and you have ten slightly different reviewers.

As a preset it looks like this: a saved agent named “PR reviewer,” pinned to a specific model with a specific reasoning budget, with standing instructions that say to focus on correctness and security, and with your review-checklist skill attached so the full checklist is one decision away whenever a diff warrants it. You pick it once from a list. Every review starts from the same place. Your teammate picks the same one and gets the same reviewer, not their own drifted variant.

The reproducibility is the quiet payoff. When a run comes from a named preset, the run is repeatable, and the configuration that produced it is written down rather than reconstructed from memory. Compare that to the pasted prompt, where every run differs by whatever you did or did not retype that day, and nothing is recorded. One of these you can reason about later. The other you cannot.

How this works in Fletch

Fletch is built around exactly this split, so you are not maintaining a prompts.md at all.

Skills are a library in Settings. Each one is a named Markdown document with a one-line description and a body. At spawn, every skill attached to an agent is written into that agent’s sandbox as a file, and a compact index, one line per skill with the name, description, and path, is appended to the agent’s instructions. The description is all the agent sees until it decides the task matches and opens the file. Ten skills cost ten lines a turn until the agent reaches for one. Because a skill is just a file plus an index line, it works on every base agent, whichever CLI you are running underneath.

Custom agents are the presets. A custom agent wraps one of the built-in providers with a saved configuration: a name and color, a role tagline, a chosen model and reasoning budget, standing instructions, and any skills and MCP tools it should carry. You build them in Settings and they show up in the composer’s model picker as one-click options next to the built-in agents. The reviewer from earlier is a real thing you save once and pick from a menu.

The last detail ties it together. Everything is snapshotted onto a session when it spawns. A running or resumed agent keeps exactly the configuration it started with, even if you edit the preset afterward. So you can improve your reviewer today without disturbing the reviewer that has been running since this morning. The preset is a template you evolve; each spawned agent is a fixed instance of it. That is the difference between infrastructure and a paragraph you keep pasting.

Go find that paragraph in your notes. Then split it in two and put each half where it belongs.