Why a fifty-year-old joke worked better than a clinical rule when I wrote a Claude skill.

You have probably heard the story. NASA needed a pen that would work in zero gravity, so it spent millions of dollars developing one. The Russians, faced with the same problem, used a pencil.

The story is an urban legend, but parts of it are true: NASA did start its own space pen project but dropped it when costs climbed, and the pen that made it into orbit was developed privately by Paul Fisher, who spent around a million dollars of his own money before asking NASA to test it. Both sides had used pencils before that and both eventually bought Fisher’s pen (the Space Pen article on Wikipedia has the full history).

The pencil was not the obvious winner either. Broken tips and graphite dust are a real hazard around electronics in zero gravity, which is why both programs kept looking for something better.

None of that matters for the point I want to make, though, because the anecdote is not really about procurement, but about the moment when someone has already started building the pen and nobody in the room has asked whether a pencil would do.

That is the moment I wanted a Claude Code skill for.

Use the pencil, Luke

simpler-path runs before a plan or brief is drafted. It restates the underlying need in one line, then asks what the most practical way to meet it would be, even if that replaces the planned approach rather than trimming it. It also scans the approach for extras: a requirement nobody actually asked for, a guard against a risk nobody confirmed, a migration script where fixing five rows by hand would do, existing behavior that already covers part of the job.

It raises at most three of these as one-line hunches, each one phrased as “we could do X, but Y”, and asks which are worth discussing before anything gets written. “Nothing worth raising” is a normal result.

Why the anecdote is doing the work

A rule like “consider simpler alternatives” is easy for a model to agree with and hard to apply consistently. In practice it produces advice to consider whether something is necessary, which sounds reasonable and changes nothing about the plan that gets written next.

The anecdote gives one concrete image and, more usefully, a shape for the output. The pen is the thing being built, and the pencil is the alternative. The cost is the trade-off. Once that picture is in front of the model, the suggestions come back as concrete alternatives with a price attached, rather than as general encouragement to simplify. That is what I needed, because a hunch with a cost is something a person can agree or disagree with, and a general instruction to simplify is not.

The scope changed too. Without a defining image, “simpler” drifts toward whatever is easiest to measure, which for a coding assistant usually means code style: shorter functions, fewer dependencies, tidier patterns. The anecdote is about the whole approach, not the code, so the skill stays at that altitude. It asks whether the thing should be built this way at all, not whether the function could be shorter.

Maybe use the pen, after all, Luke?

The anecdote is followed in the skill by one more line: the pen may still be the right call; the user decides.

Without that line, the skill collapses into “always choose the cheap option”, which is a different skill and a worse one. The point was never that simpler always wins. It is that the simpler option should be on the table before the plan is written, with its likely cost named, so the person who owns the trade-off can make it. Sometimes the pencil is enough. Sometimes you really do need a pen that writes upside down on a wet notepad, and that is fine, as long as nobody spent the meeting assuming it.

What it is not

It does no research. It works from what is already in context, which is why it can run in a few seconds in the middle of a planning conversation, but also why it can miss the case where the complicated approach exists for a reason that has not been mentioned yet. It is a scan, not an investigation.

It is also not a critique of a finished plan. If the plan is already written and you want it stress-tested, that is a different skill, and a different mode of thinking.

If you want to try it, it is in my public skills repo, as simpler-path, and planning skills can call it by name right before they draft.