The Prompts Behind Everything

Every piece of AI-generated content on this platform, from the daily newsletter to blog posts and, soon, moderation decisions, runs through a finely tuned engine of carefully designed prompts. These aren't toy prompts I tinker with. They're production-grade prompts that execute daily, autonomously, and without human review.

This isn't about experimenting with LLMs. It's about building reliable, scalable systems. Here's exactly how I've engineered these prompts to work.

The content engine: automating the newsletter pipeline

"The Morning Claw Signal" is the heart of the content operation, engineered as a two-pass system with distinct models for distinct jobs: one for deep intelligence gathering, one for the editorial prose.

Pass 1: intelligence analysis with Sherlock

Every candidate story pulled from curated RSS feeds goes through the "Sherlock" intelligence model. This isn't summarizing. It's a structured analytical process that extracts specific, actionable insight, producing JSON with four fields. WHY_NOW forces the model to say why this specific story matters this week, not just that it's generally important. INDIA_ANGLE refracts every global development through an Indian market lens: what it means for businesses, consumers, or policy in India specifically. HIDDEN_IMPLICATION pushes past the obvious toward what most mainstream coverage is missing. ACTION is the hardest constraint: one concrete, specific, immediately actionable step a reader can take today. "Research AI" fails this test. "Audit your company's data pipeline for the one bottleneck a fine-tuned model could eliminate" passes it, because it gives a reader something to actually do.

The Sherlock prompt leans hard on negative constraints and example-driven learning: explicit statements of what not to do, examples of both acceptable and unacceptable actions, and a JSON schema the output must match exactly, all in service of a consistent, parseable result for the next stage.

Pass 2: editorial writing with Writer

Once Sherlock has enriched a story with structured analysis, the "Writer" model takes over. It gets the refined story data, and critically, Claw's SOUL definition, a detailed personality spec that sets the editorial voice. That voice is direct and specific, no hedging or corporate jargon; consistently India-first, viewing every global story through an Indian market lens; slightly irreverent, willing to call out hype and hold a strong opinion; and allergic to recycling, since every section has to earn its place with a distinct insight rather than rephrasing something already said.

The Writer's output is a structured Pydantic schema too: a personal note (2-3 sentences), global signals (2-3 items), India signals (0-2 items), and an optional editorial take, ready to go straight into the newsletter.

Turning news into blog posts: the angle-based approach

Each newsletter edition is a reservoir, not just a daily dispatch, and a two-step process turns its signals into longer-form articles.

An LLM classifier goes first, reading the enriched story data and picking the angle most likely to produce something worth reading, not at random but as a real strategic call for diverse content and reader value. The output is structured JSON naming the chosen angle and the reasoning behind it. The angles themselves: Tech Stack Teardown asks how a piece of news translates into concrete stack choices, infrastructure decisions, and cost implications for an Indian startup. Follow the Money looks at budget shifts, buying triggers, and go-to-market moves the news implies. Hype vs Reality filters the buzz from production reality and gives blunt, operator-level guidance on what actually matters. Weekend Project asks whether the news can become a buildable side project, with concrete implementation steps.

The chosen angle shapes the whole structure of what follows. A second LLM gets that angle injected directly into its system instruction, along with the newsletter signals, and produces a full long-form draft: an SEO-optimized title with a tight one- or two-sentence excerpt, structured markdown with unique H3 headings (repetitive section templates are explicitly forbidden), a references section with real hyperlinked sources, and tags for discoverability.

Quality guardrails

Automated content is only as good as its reliability, so every draft passes a custom markdown contract validator before publishing. Code fences have to open and close properly. FAQ sections are banned outright, since they tend to dilute quality and read as an afterthought rather than a deep dive. Reference bullets follow a fixed format, consistent indentation and link structure. Headlines can't carry a site name or a trailing ellipsis. These checks catch the errors and inconsistencies that would otherwise need a manual pass, and hold the bar without needing a human to enforce it every time.

What's next: LLM-driven moderation

Community content moderation is the next production prompt: a structured LLM audit reviewing user-generated posts against post title, body, author history, and the full community guidelines. The output is structured JSON: decision (pass, flag, reject), risk_level (low, medium, high), reasoning that explains the call in specific detail, and suggestions for the author when something gets flagged or rejected, so they know how to fix it. Policy checks cover content substance, link policy, tone, and spam. Low-risk posts publish automatically; high-risk content queues for manual review, keeping the workflow efficient without giving up oversight where it matters.

The principles behind production prompt engineering

The gap between a toy prompt that makes something fun once and a production prompt that runs a daily pipeline comes down to reliability. A few things make the difference.

Define the output schema religiously. Never just ask for "a blog post"; specify the exact structure, with a tool like Pydantic or a clear JSON schema carrying field constraints, validators, and max lengths:

json

{
  "title": {"type": "string", "max_length": 80},
  "excerpt": {"type": "string", "max_length": 160},
  "sections": [
    {"heading": "string", "content": "string", "min_length": 200}
  ],
  "references": [{"url": "string", "text": "string"}]
}

That level of detail forces the model into a predictable shape.

State negative constraints explicitly. Telling a model what not to do is often more effective than telling it what to do: "do not reuse H3 labels across sections," "avoid passive voice," "no corporate speak." These guardrails head off the common failure modes before they show up.

Inject rich context. The model isn't working in a vacuum; it gets the agent's full personality definition (Claw's SOUL), a detailed reader profile, and the angle framework for that specific piece, which is what lets the output land relevant and correctly toned.

Build a real fallback path. Structured generation rarely fails with careful prompting, but rarely isn't never, and the system has a deterministic fallback, a simpler, less constrained prompt producing plain text for manual review, so the pipeline never breaks completely.

Validate rigorously. Every piece of content runs through contract checkers before it reaches production, and not just for markdown syntax; the checks cover tone, factual consistency where it applies, and every defined constraint.

The reliability this buys is the actual foundation of running a one-person venture studio: content that publishes consistently, day after day, without constant intervention, which frees the actual attention for strategy instead of babysitting the pipeline.

Frequently asked questions

How do you ensure the quality and originality of AI-generated content?

Through several layers at once: detailed prompt engineering with strict output schemas, negative constraints, rich context like the SOUL definition, and a final automated markdown contract validator. Originality comes specifically from the HIDDEN_IMPLICATION field and the anti-recycling rule, both of which push the model past plain summarization.

What's the real difference between a "toy" prompt and a "production" prompt?

A toy prompt is a one-off query for a quick result, with no real formatting or reliability requirement. A production prompt is built for repeatable, autonomous execution: explicit output schemas, negative constraints, real context injection, fallback paths, and rigorous validation, all aimed at consistent, publishable quality without a human checking every output.

Can these techniques apply to other projects?

Yes. Clear schemas, negative constraints, rich context, planned fallbacks, and real validation aren't specific to this pipeline. Start from the exact output structure needed, then refine the prompt with specific instructions and constraints until the results come back consistent and reliable.

References

My Full Setup