We all hit the wall eventually: same model, same question, wildly different output quality.
One day Claude hands me a Terraform config my code review would actually approve. The next day it's hardcoded secrets and containers running as root. Same model. Same session, even. The only thing I changed was the prompt.
That was the realization — the model wasn't the variable. The prompt was. And when you treat an LLM as a generalist, you get generalist-quality output. "Revolutionize your workflow" landing pages. Five marketing emails that all say the same thing. A Dockerfile with latest pinned and a --privileged flag because it "just worked locally."
The fix: negative constraints over positive ones
The standard advice is to add more positive constraints: "be concise," "follow best practices," "be accurate." I tried this. It didn't move the needle consistently.
What actually worked was the opposite: hard negative constraints that eliminate entire failure modes.
Here's the real constraint block from the DevOps prompt pack:
NEVER use floating image versions; pin + reference immutable tags
NEVER hardcode secrets; read from environment only
NO local state; remote state with locking required
Least-privilege IAM only; no wildcard actions or roles
Output plan-first for review; never auto-apply to production
The difference is specificity. "Be secure" is vague — the model already "knows" to be secure and interprets it differently every run. "NEVER hardcode secrets" eliminates a concrete failure mode. The output space narrows.
Running this against Terraform generation tasks, the hardcoded-secrets failure dropped to near-zero. With a positive-only prompt, it appeared roughly 30% of the time.
What I built
I packaged this approach into 9 MIT-licensed tools:
Prompt packs (8 specialist system prompts each, plain Markdown):
- DevOps Prompt Pack ($29) — Terraform, K8s, CI/CD, cloud ops
- Marketing Prompt Pack ($29) — SEO, email, ads, landing pages
- Product Mgmt AI Prompt Pack ($49) — PRDs, user stories, sprint planning
- Prompt Template Library (free core / $35 full) — 32 fill-in-the-blank prompts + Node.js fill library
Code boilerplates (MIT, Docker, tests included):
- MCP Server Starter Kit (free core / $49 full) — TypeScript MCP server with rate limiting + Zod validation
- Claude Agent Boilerplate ($29) — tool-use loop with parallel calls, conversation memory, token tracking
- Multi-Agent Orchestration Kit ($79) — pipeline, fan-out, supervisor patterns
- MCP Vertical Server Bundle ($99) — GitHub, Slack, Notion MCP servers with Docker Compose
- FastMCP Python Boilerplate ($35) — Pydantic v2, token-bucket rate limiter, structlog to stderr
The MCP gotcha I keep seeing
If you're building MCP servers and hitting silent failures or parse errors, check your logging first.
MCP uses stdout for JSON-RPC frames. Any print() or console.log() that lands on stdout becomes part of the protocol framing — the client sees malformed JSON and either drops the message or errors out. All logging goes to stderr:
import structlog, sys
structlog.configure(logger_factory=structlog.PrintLoggerFactory(file=sys.stderr))
The FastMCP boilerplate has this wired by default. I've seen developers spend hours on this.
What's free
The free cores are genuinely free — not a page-trap:
- MCP Server Starter Kit (TypeScript + rate limiting + Docker)
- Prompt Template Library (32 prompts + Node.js library)
- Claude Agent Boilerplate (tool-use loop core)
- Multi-Agent Orchestration Kit (pipeline + fan-out patterns)
Clone them, use them in production, keep them if you never buy anything.
Honest limitations
These aren't magic. They're constraint-based prompts tested across Claude 3.5/4 and GPT-4o, mostly on codegen and infra tasks. The patterns may not transfer equally to every domain. The approach reduces variance — it doesn't eliminate it.
If you find a constraint that belongs in a pack, I want to know. The whole point is that these improve with real production feedback.
Full lineup with links: wireforge.fellwork.workers.dev
Top comments (0)