The Raycast command stack

Motivation

For five months I had been asking which of my tasks deserved to be automated. The better question turned out to be which of my prompts deserved a keyboard shortcut. The two look similar and cost very different amounts to answer.

• Does this task deserve automation? You have to know in advance that the task is worth the evening it will cost, and that judgment needs evidence you do not have until after you have built the thing.
• Does this prompt deserve a hotkey? About four minutes. If the answer turns out to be no, you have lost four minutes.

Four minutes is only the real number if there is somewhere cheap to put the thing, which makes the choice of container the first design decision rather than an implementation detail.

Script commands

Raycast is a launcher, the box that appears over everything when you hit a key combination. Most people use it to open applications. It also runs script commands: ordinary programs on your machine that the launcher executes by name, passes arguments to, and renders the output of straight back into the same box.

Three properties, and the container needs all three:

• a global launcher, so the thing is reachable from wherever you already are
• scripts that take arguments, so a command is a function rather than a fixed action
• output rendered in the same box, so there is nowhere else to go afterwards

The container I had been writing in for the previous five months was n8n. Authoring a Raycast command felt the same as writing an n8n workflow, and the whole difference sat in what fires it: I could trigger an entire LangChain flow at the speed of thought instead of scheduling it. Same authoring cost, and only one of the two makes you decide in advance that a task is worth building for.

The first dozen prompts came from Fabric, Daniel Miessler's collection, the ones like extract-wisdom and analyze-prose. Seeding from an existing library put the cost of first population near zero, and I picked those on the grounds that I knew the patterns were useful and was not using them. The ones I added were small cognitive utilities aimed at a specific moment in knowledge work, including one whose entire job was finding the exact word for something I could only describe.

Interaction instead of automation

The reframe changed my model of what AI was for.

	Automation	Hotkeys
Where the model runs	somewhere you are not	exactly where you already are
What fires it	a schedule or a trigger	you, mid-sentence or mid-problem
Design goal	you stop being involved	being involved gets better

The claim underneath is falsifiable, which is what makes it a claim rather than a preference.

• Automation was not the way out, interactivity was. I was getting far more value from enhancing what I could do than from having a model do things instead of me, and automation should serve to make life better rather than easier, which are not the same thing.
• Language model flows were centered on making the agent useful, on output and actions, rather than on making the interaction between the model and a person better. Nobody was solving the second problem.

The mechanism is fragility. An overeager automation is fragile, and the flexible part of the system is general human intelligence, which is why the preference for augmentation predates the tool that made it practical by about a month.

Admission criteria

The test came out of one app rather than out of theory.

Mochi, a spaced repetition tool, earned a place for three reasons:

• an API, so I could push things into it from a script
• good interfaces on desktop, web and phone
• a separation between notes and flashcards, so a page of material and a drill of that material are different objects

The third is what decided it, and it is a comparison on one axis.

• Anki merges them, so a fact you want to keep and a fact you want to be quizzed on have to be the same object. Anki's engine is the one everyone else's is measured against, and the merge is a design choice rather than an oversight.
• Mochi separates them, which is what lets you write a page first and decide afterwards which parts of it deserved drilling.

Those three reasons are not about Mochi. They generalise into a test for anything joining the stack:

"1. there's an app I can use, that is convenient -- the more accessible, the better. this is the human interface 2. there's an API -- the AI flows need to be able to manage resources / processes on it -- this facilitates the experience of it 3. it must be tied to a behavior or goal that I'm trying to accomplish -- it should be related to self-programming or self-improvement. usage of the app should be directly linked somehow with the human getting better."

• There has to be an app I can use, and the more accessible the better. This is the human interface. Without it the tool is something only I can operate, and the day my scripts break I lose the data and the habit with it.
• There has to be an API, so the AI flows can manage resources and processes on it. Without it the thing sits beside everything else rather than participating in it.
• It has to be tied to a behavior or goal I am actually trying to accomplish. Without it the arrangement is a toy that generates work.

Three tests and three different things that break, with one consequence in common. Each failure leaves a working tool sitting outside the system, and a tool outside the system is one I have to remember to go and use.

Spaced repetition as a primitive

Spaced repetition is an old and well-supported idea: review something just before you would have forgotten it, and let the interval grow, so a small daily budget maintains a large amount of material. The algorithm has never been the hard part. The hard part is that somebody has to turn what they read into cards, one at a time, and almost nobody sustains that, which is why the technique has a reputation for being excellent and for being abandoned.

The script took a piece of text and produced the cards. It broke the material into bite-sized pieces in increasing order of difficulty using the Feynman method, wrote quizzes aimed at mastery, and created notes in Mochi with cloze deletions and annotations alongside the flashcards. It sat behind a keyboard shortcut with several siblings. When I decided I should know something, I pushed it into the pipeline and stopped thinking about it, because the scheduling algorithm decided what I saw and when.

That changed what kind of thing learning was. Before, a block of time to defend on a calendar. After, a queue I fed, with the review happening in the fifteen minutes a day I spent in an app that told me what to look at.

Mochi's killer feature is its scheduling engine, and that engine became accessible to me because a model could do the data entry it required. Which is the general question: what other algorithms have been sitting there, good and unused, because the preprocessing they demanded was more work than anyone would do by hand.

Friction as the design variable

The friction has to be so low that the tool effectively becomes an extension of yourself. AI human augmentation cannot just be convenient tools.

That is a threshold claim, not a preference. A convenient tool is one you choose to use, and choosing has a cost paid every single time, so a merely convenient tool competes with doing nothing and frequently loses. Below some level of friction the choosing stops happening. The command fires because you thought of it, and by the time you would have weighed whether to bother, the output is already on the screen.

Capability was never the binding constraint that month, since the models could already do all of it in a browser tab. The constraint was the tab, which has to be found and focused and typed into before any of that capability is available, and every one of those steps is a place to decide not to bother.

Portability

None of the stack was shareable, and I did not attempt a fix, because the property is structural rather than a packaging problem.

Every command was:

• a Python file on my machine
• pointed at my API keys
• wired to my data
• shaped around habits I had spent months studying in myself

What makes a command worth a hotkey is that it fits a specific moment in my own routine, and finding that fit took continuous adaptation and deliberate attention rather than any of the work written in Python. The expensive part is discovering what is valuable rather than implementing it, so packaging the files would have shipped everything except the part that made them worth firing.