Pick the word before you write the skill

Matt Pocock released a planning skill called wayfinder this week and gave Latent Space an interview about how he built it. The line everyone will quote is the fog of war: projects where you cannot decide everything at the start, so you make the decisions you can and the map opens a little further.

The part I keep rereading is duller and, I think, more useful. He says he has spent months obsessed with terminology. The skill has three nouns and only three. A map holds all the decisions already made. A ticket is one piece of work. A session is where the work happens. His warning is flat. Call everything a ticket, or refer to the same thing three different ways in three places, and you get strange behavior. He calls them leading words, and he built a whole dictionary of them so that every skill he owns runs off the same assumptions.

That is not a style preference. Between a person and a model there is a communication barrier, as he puts it, and the vocabulary is the interface across it.

The vault’s context notes make the structural version of the same argument. Structure is practical rather than ideological, and its job is separating instructions from examples from context from output. Durable material belongs in a scoped instruction surface, volatile task detail belongs in the current task packet. That is an argument about shape. Naming is what makes the shape legible to the thing reading it.

I will concede the obvious objection. Careful naming has been good advice since long before any of this, and dressing it up as an agent technique is a little cheap.

Still. Most people debugging a skill that misbehaves reach for more instructions. It is worth trying the other move first, which is finding the one word you have been using two ways.