I built a Claude Skill that tells me when to stop building. It's called Enough.

Here's the whole thing in three sentences. Enough is a Claude Skill I built because I'd been losing the same argument with myself for years, the one where every project I cared about kept growing one more "small thing" until it never shipped. It runs your idea or your half-built project through a structured cut test and returns a verdict, not a discussion. Below is what it actually does, why I bothered building it, and the moment I knew it was working.

The argument I kept losing with myself

Enough is a small, mean, opinionated Claude Skill that tells me when to stop. More discipline never worked — every new feature feels reasonable when you look at it alone, and the only way to see the cumulative cost is to weigh it against a hard line. So I built the hard line into a Skill and let it be the asshole instead of me. Here's the argument I kept having before I gave up and automated my way out of it.

I have a folder of projects that are forever "two weeks from done." I'd bet you do too. The pattern is always the same. You start small. You ship a piece. Then someone, often you, suggests "while we're at it, let's also add auth, settings, an admin view, a way to migrate users from the old version we don't have yet." The original idea was a fish. The thing you're now building is a submarine. And the submarine never launches, because submarines don't launch.

For a long time I thought the fix was more discipline. Write a tight PRD. Set a deadline. Don't add anything mid-build. It never held — because the discipline-based fix asks you to override your own judgement in the moment, and your judgement always wins.

What it actually does

Enough auto-detects which of three situations you're in based on how you describe your work to it. You don't pick the mode. It picks the mode.

Pre-build. You describe an idea or paste a PRD. Enough returns an Enough Spec, which is the smallest version of the idea that generates real evidence about your core hypothesis. Every cut comes with a one-line reason, and every deferred feature comes with the trigger condition that would justify building it later. The output is not a list of features. It's a fish, with everything that isn't a fish removed.

Mid-build. You describe what's done and what's left, and you ask if it's ready. Enough returns a Ship Verdict. The format is either SHIP NOW or SHIP AFTER. If it's SHIP AFTER, it names the true blockers in hours and caps the total work at forty-eight. The cap matters. If you have more than forty-eight hours of "blockers," they aren't blockers. They are the next version of the product, and they don't get to hold the current version hostage.

Post-launch. You describe a feature request you got from users, and Enough grades it on a four-tier ladder. Build when the evidence is strong and the cost is low. Do Manually when you can serve the next ten users by hand and learn whether the demand is real. Watch when you don't have enough evidence yet. No when the request is a vocal minority asking for the wrong thing.

Each verdict ends with a one-sentence Definition of Done, written in plain language. That sentence is the prize. It tells you what shipped looks like, in concrete terms a user can experience.

A real verdict, taken from the docs

Here's what a Ship Verdict actually looks like. This one is from the worked examples in the repo.

VERDICT: SHIP AFTER — 9 hours. True blockers: pricing page + payment link (4h) · import failure message (3h) · data deletion path (2h). Felt blockers, cut: Beehiiv API · tests · import rework. Definition of Done: a writer you've never spoken to uploads their export, sees their best send time, and pays — while you're asleep.

Look at the Definition of Done line. That's the part most "ship advice" leaves out. Not a checklist, not a Jira board. One sentence about what working looks like in the real world, written so you'd know it when you saw it. The rest of the verdict is in service of that one sentence.

The 18 cut patterns, in spirit

Enough ships with a library of eighteen patterns the model uses to recognise common forms of scope inflation. I won't list them all here, the repo does that, but the spirit is consistent. Each pattern flags a thing builders add early that almost never moves the core hypothesis, and pairs it with a cheaper substitute that does.

The classic example is auth. A real auth system, with password reset and email verification and session management, is a week of work that teaches you nothing about whether anyone wants your product. The substitute is a single shared link, or a magic-link sign-in, or no auth at all for the first version. Same with admin dashboards. You don't need an admin view. You need a SQL query and a bookmark. Same with multi-tenancy. Multi-tenancy is a feature for the third version of a product, not the first.

The pattern that hurts the most is "pre-launch rewrite." You finish v1, look at the code, decide it's ugly, and rewrite before launch. The rewrite always takes longer than the original build, and it doesn't test the hypothesis any better. Enough flags it hard.

The five uncuttables

Enough is not a license to ship broken work. The README is explicit about this. Five things never get cut.

Payment integrity. If you take money, the money has to flow correctly, refund correctly, and the receipts have to match.

Data integrity. If you store user data, you can't lose it, corrupt it, or mishandle it.

Honesty. You don't lie about what the product does, how it works, or what it costs.

The legal floor. You comply with the laws that apply to your category. This isn't optional.

Core-path accessibility. The thing the product is for has to be usable by the people you said it's for. Not perfectly. Not gold-standard. Usably.

Everything else is on the table. These five are not. That distinction is what keeps Enough from being a tool that helps you ship junk.

Why a Skill, not a prompt

You could try to get the same behaviour from a long prompt. People do. It works for one conversation and breaks the next. The reason a Skill works better is that the Skill is loaded with the same voice, the same library of patterns, the same definitions every time you invoke it. It doesn't drift. You don't have to remember which version of your prompt got you the good verdict last time.

There's a second reason that matters more for me. A Skill is the right shape for behaviour you want to invoke without thinking. I built Enough so I could say "run this through enough" inside any Claude conversation and get a verdict in one move. The mental cost of using it has to be near zero, or I won't use it. That's the test for any builder's tool, including the ones builders build for themselves.

I wrote more about why I keep shipping small things instead of waiting for the next model in my operator-mode post. Enough is part of that same instinct. Don't wait for a process. Build the process.

Who this is for

Enough is for solo builders, small teams, and indie founders who have a folder of projects that are almost done and don't ship. It's not for big-company PMs. It's not for someone whose problem is shipping too fast. It's not for a project where the spec is genuinely fixed by a client. It's for the kind of work where you're the only person deciding what's in, and that's the problem.

If you read the verdict format above and felt a small relief at the idea of a thing that just decides, this skill is for you. If you felt resistance at the idea of a tool telling you what to cut, also for you, but you'll fight it more. That's fine. The friction is the feature.

How to install

Two options. For Claude Code:

mkdir -p ~/.claude/skills
git clone https://github.com/tanujrajputdev/enough.git ~/.claude/skills/enough

For Claude.ai or Claude Desktop, upload via Settings → Capabilities → Skills. This requires a paid plan that supports Skills with code execution.

Trigger it naturally. You don't need a special command. Say "I'm building a tool where freelancers send clients a branded portal with proposals, contracts, invoices, and chat," and Enough will recognise pre-build mode and return an Enough Spec. Say "my side project has been two weeks from done for six weeks, here's what's left," and you'll get a Ship Verdict. Say "eleven users asked for a mobile app, should I build it," and you'll get Feature Triage.

If you want to force it, the explicit phrase is "run this through enough."

The first time it changed a decision for me

I'll close with the moment I knew this was working. I was about to start a four-day build on a feature for a client tool. Auth flow, settings page, the whole list. I ran it through Enough as a test, expecting to roll my eyes at the verdict. Enough cut the auth flow, the settings page, and a notification system, and proposed a single magic-link sign-in and a hardcoded settings file for v1.

The first thing I felt was annoyance. The second thing I felt was the realisation that the verdict was right, that the cuts didn't change what the user could do, and that I'd been about to spend four days on plumbing that didn't move the hypothesis. I shipped the cut version in a day. The client used it that night. Nothing the trimmed version was missing has come up since.

That's the test. Not whether the verdict feels good. Whether the verdict was right.

Try it

Enough is open source and free under MIT. The site lives at enough.tanujrajput.com. Install it once, point your next idea at it, and see what gets cut. The skill's tagline is the line I'd leave you with: if this skill kills a feature you loved, it worked.

If you want help running a real project through it, send me what you're building and where you're stuck. I'll run it through Enough on my end and send you the verdict. The verdict won't always be what you want. It will be what you need.