At ten to nine one Thursday morning I had a new skill working, built out of the strongest idea in somebody else's library. At three minutes past ten I deleted it.
Seventy-one minutes. Long enough to build the thing properly and find out it was wrong, which is not the same as looking at it and deciding I didn't fancy it.
Friction is the only thing that starts any of this
Nothing here gets replaced because I woke up wanting to replace it. Every single time, it's friction. Something rubs, and keeps rubbing, in a way I can't talk myself out of noticing.
That matters, because anyone with a repository full of their own modules gets accused of not-invented-here sooner or later, and it's a fair thing to accuse somebody of. So here is the order I actually work in.
One: use the thing
If a tool does what I need, I use it. Most of them do, and most of these decisions end right there, as one more line in a go.mod that nobody ever thinks about again. There's no post in that and nobody writes one, which is exactly right. But leave it out of the telling and you start to sound like a man who rebuilds everything on principle.
The ideas matter, always. The implementation is kinda incidental, and mostly somebody else's implementation is fine.
Two: try to fix it
When it nearly fits, the next move is upstream, and I've had both outcomes inside the same fortnight.
disgo, the Go Discord library, took a fix for RTP padding detection two days after I sent it. Then it didn't take the next one: I proposed returning an error rather than dereferencing a nil UDP connection, and eight comments later I'd been argued out of my own approach and came back with a different patch that's still open. That's rung two working exactly as advertised. Nobody owes me a merge, and being talked out of a fix by somebody who knows the codebase better than I do is a good afternoon's work as far as I'm concerned.
Losing an argument you started is fine. Losing it to someone who's right is better.
The other outcome looks like this. I sent releaser-pleaser a GitLab fix on the first of August, for release commits after an automatic rebase. It's still open, with no comment on it, on a repository that has merged fifteen commits since... all of them dependency bumps of the sort that merge themselves.
I'm not going to draw a conclusion from that and neither should you. Maintainers have lives, bots merge themselves, and a drive-by fix for one forge from a stranger who turns up out of nowhere is a genuinely awkward thing to land on somebody. Nobody did anything wrong here.
What it shows is that rung two has a failure mode you can't spot from the outside, and the only way you find out which one you've got is to wait. Which is a rotten thing to have to admit about a step you're recommending... and it's still the right step.
Three: build it
colophon exists because of exactly that. Not because I reckoned I could do release tooling better than the people already doing it, but because the fix I needed had nowhere to go and I still needed the fix.
Rung three is expensive and it is permanent. Everything you build is a thing you maintain until you die, and the estate is (quite typically) already stuffed with things I have signed myself up to maintain until I die.
Nobody makes you do that. You just keep doing it.
The seventy-one minutes
Back to that Thursday, because it's the case where all of this is visible.
I'd been putting a lot of hours into researching skills, watching people's videos, hunting for anything that would narrow the gaps in my own workflow. That led me to Matt Pocock's skills library, which is phenomenally good, and to wayfinder in particular, which decomposes work into a tree of forge tickets. Genuinely clever design. I built our version of it at ten to nine.
Three things killed it, and only two of them are defensible.
The first is a product argument rather than a taste one. Wayfinder assumes your issue tracker is yours. Mine aren't. They're a public front door, the place a stranger turns up to tell me something is broken, and filling that with hundreds of internal planning tickets wrecks it for the people it's actually there to serve.
The second is money, and I'd rather say so than dress it up. The whole value of the thing is what it calls the frontier: the handful of tickets you could genuinely pick up today, because nothing else is standing in front of them. To work that out, the tracker has to know which tickets block which. On GitLab Free it doesn't, because those blocking relationships come back 403 without a paid licence. So the most useful view in the tool is precisely the one my tier won't draw.
The third is that it didn't fit how I think about my own work. That's much harder to defend than the other two and I'm keeping it in, because a post that only gives you the defensible reasons is a post that's tidied itself up on the way out.
The question underneath all three, and it's the one worth stealing: will this improve my workflow, or just add to it? Four words, and the answer is more often "add to" than anybody wants to admit.
Turning something down is not the same as throwing it away
I didn't take wayfinder. I took five separate ideas out of it.
A Destination at the top of a spec, saying where the thing is meant to end up. A Not yet specified section for the parts you already know are missing, rather than leaving a reader to notice the hole themselves. The idea of fog, and the rather good test that tells fog apart from an ordinary open question: can you state the question precisely, right now? If you can, it isn't fog, it's a question, and you should go and answer it. Out of scope as a permanent verdict rather than a to-do, so something you have decided not to build stays decided instead of creeping back onto the list six weeks later.
And, best of all, naming a decision instead of numbering it, so a spec reads as words rather than a wall of D1 and 2c.2 and OQ1. When you're juggling a dozen projects and switching between them all day, an identifier you have to decode is a small tax you pay a few hundred times.
All of that went into our own spec skill and none of it is wayfinder. The marketplace's credits file lists twelve of these now, across two sources.
The bit I like best is what happened at 10:03. The revert and the replacement went in together. programme-tracker, one wiki page per project saying what's in flight, landed in the same batch as the deletion, and I did not have it in my back pocket beforehand. It only became obvious once I could say out loud precisely what hadn't fitted. Rung three isn't a plan you keep in your back pocket. It turns up after you've done the work of saying exactly what was wrong with the thing you turned down... which is another good reason not to jump straight to it.
And then it stops being about taste
I could have written all of the above as preference, and for a long time that's how I'd have defended it. Then I wrote the credits file and noticed the actual argument.
A skill file is not a library. It's instruction text that an agent reads and executes. Every one in our marketplace gets scanned for hidden characters and injection patterns before it lands, and a plugin installed from somewhere else walks straight past that gate, and then changes whenever its author changes a branch, with nothing in my repository recording that it moved.
Adopting the idea and owning the text keeps the whole trust boundary inside one place I control. That's not a preference. Shared skills are not one size fits all anyway, so you're going to be adapting them regardless; you may as well own what you're running.
The other half of that bargain is saying where it came from. Every derived skill carries an Adapted from line, and the credits file records the source, the author, the licence and the exact commit it was reviewed at. Pocock's work is MIT, so none of that is required of me. Which makes it matter more, not less.
Where it leaves me
Three rungs, in order, and I climb them slowly because skipping to the top is how an estate fills up with things nobody else will ever fix for you.
Wayfinder was a good tool that was wrong for me, and I only know that because I built it and lived with it for an hour rather than reading the README and having an opinion. Those seventy-one minutes were the cheapest thing in the whole exercise.
The rubbing stopped, anyway. That's the only test I've got.
Originally published at phpboyscout.uk on 7 September 2026.
Top comments (0)