Why Prelude Isn’t Just a Skill
People often ask us: why can’t Prelude just be a skill that organizes your work?
The honest answer is that it could. If all Prelude did was wait for a request, read a few sources, and return a summary, a skill would be a perfectly reasonable way to build it.
That just is not the part of the problem we find most interesting.
Execution starts with a known task
A skill usually begins with a request:
Prepare me for Friday’s customer review.
Once the task is clear, a skill can gather context, identify unresolved questions, and prepare a useful brief. What it does not solve is noticing that the work needs attention in the first place.
Most work does not announce itself as a task. A meeting sits on the calendar. An email mentions a problem. A teammate raises a concern. A decision never becomes a next step. None of these things has to look urgent on its own, but together they may start to tell a different story.
Attention begins before the request
Take a customer review scheduled for Friday. By Wednesday, a new email says adoption has declined, a teammate has raised a renewal concern, and two requested improvements are still unresolved.
A task-oriented assistant waits for someone to say, “Prepare me for the review.”
Prelude should be able to ask:
- Do these signals belong to the same open thread?
- Has something changed enough to matter now?
- What context would make the next action easier?
The useful output is not another inbox summary. It might be a simple observation:
The customer review may need preparation. Adoption has declined, renewal risk was raised, and requested work remains open.
That may still lead to a familiar action: prepare a brief, draft a reply, or update a plan. The difference is that nobody had to turn the situation into a prompt first.
A summary is an output, not the product
A summary can tell you what is in an inbox or what happened in a meeting. By itself, it cannot tell you whether anything has changed enough to deserve your attention.
Prelude needs some continuity for that. It has to keep track of what was already open, what has been handled, what was dismissed, and what changed since the last time you looked. That is why we are designing it around open threads rather than isolated prompts.
The hard part is not producing more notifications. It is earning the right to interrupt less often—and being more useful when something does surface.
Skills still matter
Once Prelude has surfaced something worth doing, a skill may be exactly what should handle it. It can prepare a meeting brief, draft a reply, update a plan, or research an unresolved question.
Prelude does not need to rebuild every capability itself. It needs enough context to know when one might help and what information should go with it. The person should still be able to see why it happened and decide what comes next.
What we are trying to build
Separate pieces of work often start to add up before anyone has written down a task. We want Prelude to notice that shift, explain what changed, and make the next decision easier.
Sometimes the next step will use a skill. Sometimes there will be nothing to do at all. Knowing the difference is the point.