Claude/ChatGPT Prompt to Write Technical Blog Posts

What this prompt does

This prompt enforces a rigid, opinionated structure that mirrors how high-ranking developer content actually performs. The fixed six-part skeleton — hook, sectioned body, code, pitfalls, security/performance, and actionable conclusion — isn't arbitrary. It maps directly to what developers scan for when they land on a post: "does this writer know the real problems, and will they show me working code?"

The [target_keyword] variable anchors every generation to a specific topic, which keeps the SEO layer coherent without the model drifting into adjacent territory. By explicitly requesting internal linking opportunities and a meta description as deliverables, the prompt produces content that's deployment-ready, not just draft-ready.

What separates this from generic blog-post prompts is the explicit pitfalls and security/performance sections. Those force the model to move past happy-path explanations and surface the nuance that distinguishes a tutorial from a reference post that developers actually bookmark.

When to use it

• Publishing a deep-dive on a framework feature (e.g., Laravel queue batching, React Server Components) that needs both SEO traction and technical credibility
• Writing comparison posts where the pitfalls section becomes a genuine differentiator over thin competitor content
• Producing content for a developer-facing product where security considerations in the post signal trust to the target buyer
• Building a consistent content cadence for a devtool audience where every post needs the same structural depth but the topics change weekly

Example output

For variables: length=2000, topic=Laravel job batching with Redis, audience=mid-level Laravel developers, tone=pragmatic, section_count=4, language=PHP, target_keyword=laravel job batching:

Meta description: Learn how Laravel job batching with Redis handles failures, retries,
and partial completions — with real PHP examples and gotchas most tutorials skip.

## The Problem Nobody Warns You About
You dispatched 500 jobs in a batch with allowFailures(). Three failed. Laravel marked
the batch "finished." Here's what actually happened and why your data is now
inconsistent — and why the default behavior (batch marked as failed) isn't always
better without a proper catch() strategy.

## H2: Setting Up a Job Batch
[PHP code block: Bus::batch([...]), ->then(), ->catch(), ->finally()]

## H2: Handling Partial Failures
## H2: Monitoring Batch State in Production
## H2: Batching Across Multiple Queues

### Common Pitfalls
- allowFailures() marks the batch as finished even when jobs fail — the catch() callback
  still fires per job, but the batch never transitions to a failed state. Log and alert
  inside catch(), not in then()
- Batch records persist in the job_batches table; schedule a pruning command or rows
  accumulate indefinitely

### Performance & Security
- Redis pipeline mode for batch dispatch at scale
- Never store PII in job payloads; reference IDs only

### Takeaways
[3 concrete action items]

Pro tips

• Set section_count to match your keyword's search intent depth. Informational queries rank well with 4-5 sections; comparison queries often need 6+.
• Use tone: pragmatic or tone: opinionated over tone: friendly — developer audiences distrust content that reads like it was written for a general audience.
• The "internal linking opportunities" output is only useful if you paste it into a second prompt alongside your existing sitemap or post list. Pair it with a linking prompt for real results.
• For the [language] variable, be specific: PHP 8.3 outperforms PHP because the model will use modern syntax, typed properties, and enums rather than defaulting to older patterns.
• After generation, gut-check the pitfalls section manually. If the pitfalls are ones you already know from experience, the post is good. If they surprise you, verify them — the model occasionally invents plausible-sounding but incorrect gotchas for niche topics.