A no-new-tools rule quietly becomes a no-new-ideas rule

You have a rule that stops your stack growing. Mine is blunt: nothing new gets installed unless it removes something bigger.

It is a good rule. It has saved me from a lot of half-maintained dependencies I would still be patching today.

Last week it nearly cost me the two best ideas I had all month.

The move that feels like discipline

Someone sends you a list. Eleven tools, a marketplace page, a “top ten skills” roundup.

You scan it for four seconds. You already know your answer. You reply “not for us” and feel efficient.

That four seconds is the bug.

You have collapsed two separate questions into one:

1. Should I take on this dependency?
2. Is there a good idea in here, independent of its packaging?

Question one is nearly always no. Question two is often yes.

Answering the first one fast means never asking the second. I call it dependency-shaped reading: judging a list by whether you would install it, so the ideas inside it are never assessed at all.

The tell is speed. If your verdict on a list of eleven things arrives faster than you could have read three of them, you did not evaluate anything. You applied a policy.

What happened when I read it properly

I opened a marketplace page of eleven design-focused agent skills. My reflex was the four-second scan.

Instead I wrote one line on each. Not a paragraph. A line, with the specific reason.

Nine were a no, and the reasons were not “we do not need it”:

• Two enforce their own aesthetic direction and ban certain fonts. I have locked design tokens read from live files. A tool with opinions about my typography would fight them on every run.
• One only runs on a coding agent I do not use.
• One assumes I design in Figma. I do not.
• One is 63 skills across 8 plugins. That is not a tool, that is a lifestyle.
• One generates token systems. I have tokens. Generating new ones is the exact opposite of reading them from the live file.
• One has no stated install method and links to a Medium post.
• Two duplicate something already wired in.

Specific reasons, not reflexes. That distinction is not pedantry. Writing the specific reason is the thing that surfaced the two yeses, because you cannot say “this would fight my locked tokens” without first thinking about what your tokens are and what you would actually want a tool to do to them.

The two I kept, and what I did with them

The first was a contrast checker. It computes WCAG contrast ratios and complains when text fails.

I did not install it. I took the idea and wrote it as about twenty lines inside my own renderer.

It computes the ratio for every text-on-background pair and refuses to render if any pair falls below AA. Not a warning at the end. It writes no file at all.

Twenty live pairs across four brands pass. It independently produced 2.50 for one brand’s bright orange on cream, which is exactly the figure written down in that brand’s identity file months ago. The rule and the code agree, which is how you know the code is measuring the right thing rather than confidently measuring the wrong one.

Then I did the part people skip. I put the failing orange back in and ran it.

It refused. No file.

That is the only evidence that a fail-closed check is actually fail-closed. Watching it close.

The second idea was screenshot diffing for visual regressions. I already run a headless browser, so the comparison is one command away. It would have caught both layout bugs I found by eye that same day: a headline overlapping the standfirst, and a dead band at the bottom of a frame. Not built yet. It is now a real item rather than a thing I have never considered.

The uncomfortable part

Here is the bit that stung.

That contrast rule already existed. It was written down, in a file, in plain English, months ago.

It was enforced by me remembering it.

A rule enforced by a person remembering is not a control. It is a hope with good documentation attached. It works right up until the day you are tired, or in a hurry, or the person who remembers is not the person doing the work.

Twenty lines turned a hope into a control. The marketplace did not give me that. It gave me the reminder that I could.

What to do with this

Next time a list of tools lands, run it in two columns instead of one pass.

Column one: would I take this dependency? Answer fast, answer no most of the time, and write the specific reason. The specific reason is the work. “Not for us” is not a reason.

Column two: is there a capability here I want, separate from the packaging? Ignore the install question entirely while you do this.

Then for anything in column two, ask how many lines the thin version is. Not the whole tool. The one behaviour you actually wanted.

If the answer is under fifty lines and it operates on values you already own, build it. You get the capability, you keep your surface area, and it fails in a way you can read at three in the morning.

And when you build a check that is supposed to refuse, break something on purpose and watch it refuse. An untested guard and no guard are the same object with different amounts of confidence attached.