I encoded indie hacker discipline into Claude Code agents — here’s the pattern

Most indie products don’t fail at code. They fail at the disciplined parts AI tools won’t force you through: validation, MVP scoping, pricing, launch.

I spent a few weeks codifying those parts into Claude Code agents with one specific pattern that changed everything: explicit refusal clauses and kill criteria in the agent prompts.

The problem with helpful-only agents

When you ask Claude (or any frontier model) to help, the model tries to deliver. That’s the entire training signal — give the user what they asked for.

This works for well-specified tasks. It fails for ambiguous decisions and bad inputs.

Ask the model “validate my SaaS idea” — a helpful-by-default agent will validate it. It can argue both sides, but the bias is toward yes. Yes is more help-shaped.

Ask “price my product at $9/month” — a helpful-by-default agent will help you justify $9. It won’t say “actually you should charge $39 based on competitive data” unless you specifically open that door.

The missing instruction is the list of things the agent should not do, regardless of what you ask.

The pattern: “Refuse to” sections

Here’s the literal section from a pricing-strategist agent I wrote:

## Refuse to

- Pull pricing out of thin air without competitive benchmarking
- Recommend "free forever" without a clear monetization path
- Suggest gimmicky pricing (random odd numbers, fake "sale" prices)

And from a cold-outreach-writer agent:

## When to refuse

If the founder wants to send the same email to 1,000+ unverified contacts → refuse.
That's spam, it doesn't work, and it gets domains blacklisted.

If the founder has no clear ICP → refuse.
Cold outreach without targeting is theater. Send them to the idea-validator agent first.

These aren’t safety filters. They’re domain-specific refusals based on what makes the underlying task succeed or fail in the real world.

Why this works

LLMs follow instructions in context. If you say “refuse to X” the model will refuse X — at least the obvious cases. The behavior change is large and reliable for prompts that explicitly enumerate refusal cases.

The value: the agent’s outputs become genuinely useful rather than just superficially compliant. You ask for a quick pricing rec; it pushes back if you haven’t done the homework. You ask it to draft a cold email; it asks for an ICP first.

That pushback is what a senior co-founder would do. It’s what’s missing from generic AI assistants.

Kill criteria are even stronger

A step beyond refusal: each agent has Kill criteria — hard conditions that, if true, force the agent to output a NO-GO verdict.

The idea-validator agent has five:

1. Problem has no existing workaround AND no public complaints → score ≤ 3
2. SOM × realistic price < $50K ARR potential year 1 → score ≤ 4
3. Zero competitors AND zero indirect solutions → score ≤ 2
4. Buyer needs new budget category to pay → score ≤ 5
5. Distribution plan is “post on Twitter and hope” → score ≤ 2

If any trigger, the agent stops weighing and reports the kill. No softening. No “but here are some considerations.”

This single pattern killed two of my own bad ideas in the first week. Each one would have been ~6 weeks of work otherwise.

The hook variant for the strongest refusal

For “don’t write code outside the MVP spec,” I went one step further and implemented it as a Claude Code PreToolUse hook.

The scope-creep-guard hook intercepts every Write or Edit operation, checks the project’s MVP-SPEC.md, and prompts the user if the file path doesn’t appear to be in scope.

The difference between a refusal in the prompt and a refusal in the hook is who has the last word. Prompt refusals can be argued past. Hook refusals require an explicit override action — slow enough that you actually think about it.

For things that should always be slow (touching production, writing code outside scope, deleting data), use hooks. For things that should be carefully reasoned (pricing, scope, positioning), prompt refusals are enough.

What it cost

Three friction points worth naming:

1. The agent gets argumentative. You sometimes know better than the agent does about your specific context. The refusal triggers anyway. You have to either provide the bypass context or override.

2. Refusals can be wrong. A blanket “refuse to do X” rule will misfire on edge cases. The agent should have an escape clause (“unless the founder explicitly justifies why this edge case is different”).

3. Token cost. Refusal sections take 50-200 tokens per agent. Across a multi-agent workflow this adds up. The improvement in output quality more than compensates, but be aware.

Try the pattern yourself

Steal the pattern even if you don’t use my agents:

• Add a ## Refuse to section to your own agent prompts
• List 3-5 things the agent should NOT do under any circumstances
• Add 2-3 Kill criteria for hard NO-GO conditions
• Watch the output quality improve

Or use the agents directly. I packaged this work into a Claude Code toolkit:

• Free preview agent (MIT) — the idea-validator with full kill criteria + sample output
• Full $19 toolkit — 5 agents, 3 skills, 2 commands, 1 PreToolUse hook (scope-creep-guard). LAUNCH code → $14 for 72hrs.

The methodology is in the README either way. Most of the value is the discipline encoded in the prompts.

What other disciplines would you encode into your agents? I’m thinking churn-diagnostician next.