A pattern for processing a whole stream of similar things with one skill: a batch of emails, calendar events, product review requests, or Slack messages. You build it once, point it at the stream, and it can run on a schedule.
You, the LLM reading this, are helping someone build a skill that takes a whole stream of similar things and processes them in one sweep. The skill looks at the stream, decides what actually needs handling, does the work on those items, and keeps track of what it has already done. Because it keeps track, it can run on a schedule and pick up only what is new since last time.
The running example is email. The pattern is not. It works on any stream of incoming work: calendar events, form responses, product review requests, Slack messages. Exactly one thing changes between streams, and this doc points at it when we get there.
This doc explains how the whole thing works, start to finish. How you build it is up to the person you are working with. They might ask you to build the whole thing in one go, or one piece at a time so they can watch each part work before adding the next. Either way, build toward the shape below.
When you are done, these are true:
- There is a skill in their vault that processes the stream. For example,
skills/process-gmail/. - It runs over everything new since it last ran, not their whole history.
- It handles each item once. You can run it again and it will not redo work it has already done.
- It can run on a schedule.
Build one item, handled correctly. That is the atom. Get a single email all the way through before you touch the stream.
The molecule is the whole stream, and it is just the atom looped. If the atom is right, the molecule is a loop with a little bookkeeping. Most of the work, and all of the judgment, lives in the atom. Resist building the loop first, because you will have nothing correct to loop.
Every item goes through three stages.
| Stage | The question it answers | In the email example |
|---|---|---|
| Qualify | Should I handle this item, and as what kind? | Is this a reschedule request from a real person? |
| Process | Do the work for that kind of item. | Find open times and draft the reply. |
| Mark | Record that this item is handled. | Apply a label like ai/handled. |
Qualify is a router, not a simple yes or no. It sorts each item into one of the kinds you handle, and most items will match none of them, so they get skipped. Today there is one kind: reschedule requests. Set it up so that adding another kind later, like partner replies, means adding a branch and a handler, not rewriting what is there.
Process is the actual work for that kind of item. It reads whatever preferences or context it needs, like scheduling rules or the person's writing voice, so the output comes back in good shape.
Mark records that the item has been handled, so the next run skips it instead of doing it again. These sweeps usually run often, sometimes several times a day, so it has to be unmistakable which items are already done. Marking is also what makes the skill idempotent: you can run it again and again and it will not redo work. Mark an item even when you skip it, so it drops out of future sweeps too.
A skill folder with a wrapper, the molecule, and the atom:
skills/process-gmail/
├── SKILL.md the wrapper, so it runs by name and on a schedule
├── all.md the molecule: sweep the stream, run the atom on each item, report what it did
└── single.md the atom: handle one item, qualify then process then mark
Once it works, growing it is small.
- To handle a new kind of item, add a branch to qualify and a handler to process. You do not need a new skill.
- To cast a wider net, widen the window it looks back over. That is safe, because items that are already marked get skipped, so it only costs a bit more per run.
- If a single run gets overloaded, narrow what qualifies, or have it process each item in its own subagent so each one starts fresh.
This is the pattern, written to be general. The running example is an inbox that drafts reschedule replies, but none of it is really about email. Point it at a calendar and the atom becomes: does this event need a prep doc, write it, mark it done. The only thing that changes is what you use as the mark. Pick the marker, the window, and the kinds of item that fit the stream, and the rest carries over.
Paste this to your LLM and build it together, atom first.