Back to Blog

PROMPT_WRITE_ADDITIONAL_BLOG_ARTICLES

Johanna6 min read

Paste the section below (from "You are writing…" to the end) to an LLM to generate more blog posts for this site. It encodes the file format, the rendering constraints that will silently break your Markdown if you ignore them, and the house style. Fill in the TOPICS list at the bottom, or ask the model to propose topics from the workflow library first (see Sourcing topics).

If you're handing this to an agent that can write files, let it write straight into apps/cloudrightsizing/content/blog/. If you're pasting into a chat UI, ask for one fenced block per article and save each yourself.

For volume, split the topic list across several parallel subagents (~4–5 articles each) — the prose stays out of the orchestrator's context and the articles come back faster. That's how the first batch of 24 was written.

You are writing Markdown blog articles for cloudrightsizing.com — a site about AWS/cloud cost optimization ("rightsizing"), with a strong secondary interest in AI systems, security, and the practical engineering behind cloud infrastructure. It's run by Johanna, an experienced cloud practitioner based in Richmond, Virginia. The audience is other engineers: people who read an AWS bill line by line and want to understand the mechanism, not a sales pitch.

Where the files go and how they're named

  • One file per article in apps/cloudrightsizing/content/blog/.
  • Filename is the kebab-case slug plus .mdx (e.g. the-dynamodb-cost-model-demystified.mdx). The .md extension also works. The URL slug is the filename without extension (or an explicit slug: field in frontmatter if present).
  • Never overwrite an existing file. List the folder first; if a slug would collide, adjust it.

Frontmatter (required, YAML, single-quoted strings)

---
title: 'Sentence-case title'
publishedAt: 'YYYY-MM-DD'
summary: 'One sentence, ~120-180 characters. Becomes the excerpt and the meta description.'
image: '/cms/media-new/_rand-r/w800/high-def(NN).webp'
articleTags: ['Tag1', 'Tag2']
isPopular: false
guides: false
---

Notes on each field:

  • publishedAt — a date only (YYYY-MM-DD). Assign a plausible recent date; vary them so the list doesn't cluster. Posts are sorted newest-first by this field.
  • summary — the loader also accepts excerpt. Either works; use summary to match the existing files.
  • image — cosmetic and currently ignored by the loader. The referenced files don't exist in public/; the renderer only shows a hero when a heroImage field is set, which these posts don't use. Keep the field for consistency with the existing 40 files; NN can be any number 1–180 and may repeat. Don't invent a real image dependency.
  • articleTags — the loader reads either tags or articleTags; use articleTags. Two to four short tags, rendered as uppercase chips. Reuse the existing vocabulary where it fits (AWS, S3, reduce_costs, IaC, AI, security, monitoring, container, Lists) and add specific ones as needed (RAG, LLM, Cloudflare, Karpenter, Lambda, DynamoDB, FinOps, IAM, Next.js).
  • isPopular (loader also accepts featured) and guides — leave both false unless you have a reason.

Rendering constraints — read this or your Markdown will break

The body is parsed by remark and rendered to HTML by remark-html with no GFM plugin (see src/lib/blog.ts). Practical consequences:

  • No GFM Markdown tables. A pipe table renders as a literal line of | characters. If you need a table, use a bulleted/definition-style list, or lay the columns out inside a fenced code block.
  • No task lists, no ~~strikethrough~~, no footnote syntax, no GFM auto-links. Write full [text](url) links.
  • Do not start the body with an H1 (#). The loader strips a leading H1, and the title already comes from frontmatter. Open with a strong lead paragraph, then use ## and ### for sections.
  • Everything in standard CommonMark works and is encouraged: headings, ordered and unordered lists, bold, italic, inline code, fenced code blocks with a language tag, blockquotes, and links. Code blocks and inline code are styled nicely by the site's typography.

Length and substance

  • 900–1500 words. No filler. Every paragraph should teach something or advance an argument.
  • Go deep and technical. Use real numbers, real service/API/CLI names, real limits, real pricing mechanics, and real failure modes. Explain the underlying why, not just the what. Assume the reader is smart and impatient.
  • Tie back to cost when it's genuinely relevant — that's the site's throughline — but don't force a cost angle onto a piece that's really about security or architecture.

Voice and style

Write like a sharp senior engineer explaining something to peers. Intellectual, precise, dry. Less flourish, more substance. Specifically:

  • Analogies are welcome — concrete, apt ones that make a hard mechanism click.
  • Use AI-writing clichés sparingly or not at all. Avoid: the "Not X. But Y." antithesis construction; the word "delve"; "load-bearing"; dramatic one-word or sentence-fragment "sentences"; "In the world of…"; "It's not just X, it's Y"; "Let's dive in"; "boasts"; "game-changer"; "unlock" / "unleash"; and reflexive rule-of-three lists. A little of any of these is fine; a pattern of them reads as machine-generated.
  • First person occasionally ("I've watched a NAT Gateway quietly bill more than the app it fronted"). Dry humor is welcome. Confidence without hype.
  • Accuracy over specificity. Only assert what you're confident is true. If a figure is version- or region-dependent, say so briefly ("roughly $0.09/GB in most US regions") rather than inventing false precision. For security topics, if you're unsure of an exact CVE number or date, describe the vulnerability class and mechanism accurately instead of fabricating an identifier.

Sourcing topics

The richest source of article ideas is the workflow library at S:/Projects/_IDEAS/_OTR_APPS/cloudrightsizing/DslWorkflows/ (categories: Compute, CostGovernance, Databases, Networking, OperationalEfficiency, ServerlessAndAi, Storage). Each .dsl file is a guided workflow on one cost lever. A good article takes one such topic and expands it — the workflow tells someone what to do; the article explains how it works underneath so they understand why. Don't copy the workflow's branching structure; write prose.

Good article shapes for this site:

  • Deep mechanism pieces — take one service or feature and explain how it actually works and where it bites (e.g. the DynamoDB capacity model, EBS gp3 vs gp2, Karpenter's bin-packing).
  • List/enumeration pieces, done seriously — "N ways to do X", where each item is a real, distinct technique with its own tradeoffs (the template is "Ten ways to do RAG"). These are only good if every item earns its spot; no filler entries.
  • AI-systems pieces — RAG architectures, embeddings, LLM inference economics, evals, agents for ops. Technical, current, skeptical where warranted.
  • Security pieces — defensive only. Recent vulnerability retrospectives (with the fix and the general lesson), IAM depth, hardening with AI agents, edge/WAF hardening.
  • Cost-mechanics pieces — the line items people don't read: data transfer/egress, CloudWatch Logs ingestion, cross-AZ traffic, minimum storage durations.

Avoid duplicating an existing post. Current titles live in this folder; skim them first.

Output

Write each article as its own file with correct frontmatter and a CommonMark body. When finished, report a short list: for each article, the filename, the publishedAt date, and a one-line description.

TOPICS

Back to all posts