Can AI actually replace writing a PRD or post-mortem myself?

No — and you shouldn't want it to. AI is excellent at generating first drafts, restructuring notes, and filling in boilerplate. It's bad at making the actual judgment calls (what's in scope, who the user is, what the root cause was) that make a document valuable. Use AI to accelerate the mechanical work so you spend your time on the judgment.

Which AI tools work best with Markdown?

Any modern LLM handles Markdown natively in both input and output — ChatGPT, Claude, Gemini, local models via Ollama. Editor-integrated tools (Cursor, Zed, Copilot) give you Markdown generation in context, which matters more than the model choice for speed. For bulk work, use a CLI or API with prompt templates stored in your repo.

How do I avoid AI 'slop' — generic, filler content?

Three tactics. (1) Give the AI your template, not just a blank prompt — structure constrains output. (2) Feed it concrete inputs (real user quotes, real metrics, real code) — specifics are hard to fake. (3) Edit aggressively — the AI's first draft is raw material, not a finished product. If you ship AI output unedited, readers will notice.

Is it ethical to use AI for writing I publish under my name?

Disclose if you used AI substantially, especially for content that claims to represent your personal experience. For internal docs, PRDs, and technical documentation, disclosure is usually unnecessary — these are collaborative artifacts. For bylined articles, opinion pieces, or anything marketed as 'written by a human expert,' being transparent about AI involvement is the right call.

What's the risk of leaking sensitive data to AI?

Significant for public APIs (ChatGPT, Claude web). Minimal for enterprise contracts (ChatGPT Enterprise, Claude for Teams, Azure OpenAI) that include data isolation guarantees. Zero for local models (Ollama, LM Studio). For any proprietary code or unreleased product information, use enterprise plans or local models only — confirm your organization's policy before you paste.

How to Use AI + Markdown Templates to Ship Faster

AI assistants are good at Markdown. They understand the format, respect structure, and produce consistent output that renders cleanly. Combine that with a library of good templates and you have a force multiplier for any job that involves writing structured documents — PRDs, post-mortems, docs, technical specs, blog drafts, meeting notes.

This guide covers the patterns that actually work, the ones that don't, and how to keep quality high when you're shipping three times faster.

What AI is good at (for Markdown work)

Filling templates with content when you give it raw inputs (bullet points, transcripts, meeting notes).
Restructuring and summarizing — taking a brain-dump and organizing it into sections.
Generating boilerplate — FAQs, code examples, table structures.
Rewriting for clarity — trimming redundancy, fixing passive voice, shortening sentences.
Translating between formats — HTML to Markdown, CSV to Markdown table, bullets to prose.
Drafting first versions from a specification or outline.

What AI is bad at

Domain judgment. "Is this the right problem to solve?" "What's our actual root cause?" AI will produce confident-sounding answers without the context to be right.
Priorities and tradeoffs. Scope decisions, stakeholder navigation, timing calls — human work.
Knowing when to stop. AI will pad when you want terseness. You have to keep cutting.
Factual accuracy in narrow domains. AI hallucinates API method names, company policies, and citation details. Verify before shipping.
Your actual voice. Without heavy prompting or fine-tuning, AI defaults to a bland "professional blog" tone.

The division of labor: AI handles the mechanical work; you handle the judgment.

Pattern 1: Template + facts → draft

The highest-leverage use of AI in Markdown work. You provide:

The template (PRD skeleton, post-mortem structure, blog post outline)
Concrete facts (metrics, user quotes, timeline events, source material)

The AI fills in the structure. You edit.

Example prompt:

You are filling in a PRD for our product team. Use the exact template
below. Do not add sections. Do not change heading levels. Be concise —
1-3 sentences per bullet.

TEMPLATE:
[paste the PRD template here]

FACTS:
- Problem: 37% of users abandon the CSV export flow before completion.
  Survey data shows 68% cite "too many steps" as the reason.
- The flow currently has 6 clicks. Competitor analysis shows 2-3 is
  standard.
- Estimated revenue impact: $12K/month in lost conversions.
- We're targeting free-tier users in their first 30 days.
- Scope: redesign the export flow to 2 clicks maximum. Must work on
  mobile. Must preserve existing column-selection functionality.
- Out of scope: new export formats (XLSX, JSON), scheduled exports,
  API access to export history.
- Metrics: primary is export completion rate (target: 63% → 80%).
  Secondary is free-to-paid conversion (target: 4.2% → 5.5%).

Generate the PRD now.

The output is a first draft you can edit in 10 minutes instead of writing from scratch in 90.

Key prompt principles:

Show the template. The AI's default structure is almost always worse than yours.
Pre-digest facts. Bullet points of specifics, not a wall of context.
Constrain output length. "1-3 sentences per bullet" or "under 200 words per section."
Forbid additions. AI loves to add a "Conclusion" or "Summary" section you didn't ask for.

Pattern 2: Messy notes → structured doc

You took handwritten or transcribed notes during a meeting, interview, or incident. They're useful but unstructured. Feed them to AI with a target template.

Example prompt:

These are raw notes from the post-mortem meeting for incident INC-2026-042.
Convert them into the post-mortem template below. Preserve all facts.
Mark anything unclear with [VERIFY].

TEMPLATE:
[paste post-mortem template]

NOTES:
[paste raw notes — typos, half-sentences, all fine]

This is the most common real-world use. The AI is excellent at "I know what I meant, just organize it for me." The [VERIFY] marker catches ambiguity — if a note says "Alice fixed it around 3," the AI can't know the timezone; it should flag rather than guess.

Pattern 3: Generate cross-cutting artifacts

For a single project, you often need multiple related docs:

PRD (product)
Technical design (engineering)
Launch announcement (marketing)
FAQ (support)
Release notes (customer-facing)

Each is a different audience view of the same underlying effort. You can maintain a single source-of-truth facts file and generate the variants with AI:

Source file (project-facts.md):

# Q1 Export Redesign

## What
Redesigning CSV export to reduce clicks from 6 to 2.

## Why
37% abandonment in current flow; $12K/month revenue impact.

## When
Ships April 15. Announcement April 18.

## Who
Free-tier users, first 30 days after signup.

## Details
- New export dialog with smart defaults
- Mobile-optimized
- Preserves column selection
- Out of scope: XLSX, scheduled exports

Then for each variant, prompt:

"Using the template for a PRD, fill in using the facts below..."
"Using the template for release notes, summarize in 2 paragraphs..."
"Using the template for a support FAQ, write 5 questions customers will ask..."

One fact file, five downstream documents, each staying in sync as the facts evolve. For teams maintaining dozens of projects, this pattern alone saves days per month.

Pattern 4: Content fill-in

Some sections of Markdown documents are genuinely mechanical:

FAQ sections for blog posts
Example code snippets to accompany an explanation
"Related" cross-link suggestions
Table-of-contents generation from headings
Alt text for images (with vision models)

Each of these has a clear input-output relationship. Templates for each:

FAQ generation:

Based on the blog post draft below, generate 5 FAQ items:
- Questions a first-time reader would ask after reading the post
- Not questions already answered in the body
- Answers: 2-4 sentences each, specific and practical
- Format: Markdown with ### question followed by answer paragraph

[paste blog post]

Alt text:

You're writing alt text for images in a technical blog post.
For each image, write alt text that:
- Describes the image's purpose in the post (what it conveys)
- Is under 125 characters
- Does not start with "Image of" or "Picture of"

[attach image]
Context: the image appears in a section about [topic].

Pattern 5: Tone and style pass

Separately from drafting, AI can do a final editing pass:

Edit the Markdown below for these specific issues:
1. Remove passive voice where active voice is clearer.
2. Cut any adverb that doesn't add meaning (very, really, quite).
3. Split any sentence longer than 25 words.
4. Replace clichés ("at the end of the day," "in today's world").
5. Do NOT change headings, structure, code blocks, or factual claims.
6. Return the edited Markdown with all original structure.

[paste draft]

This kind of targeted editing outperforms general "make this better" prompts because it tells the AI specifically what to change and what to leave alone. You can run multiple targeted passes rather than one vague one.

Prompt templates for common artifacts

Save these as snippets or in a .prompts/ folder in your repo.

PRD from bullets

Fill in this PRD template using the facts provided. Stay within the
template structure. Be concise — 1-3 sentences per bullet. Mark
anything unclear with [VERIFY].

Template: [link to your PRD template]
Facts: [bullet points]

Post-mortem from timeline

Fill in the post-mortem template using the timeline and root cause
notes below. Use UTC timestamps exactly as given. Do not speculate
about causes beyond what's stated.

Template: [link]
Timeline: [entries]
Root causes: [notes]
Impact: [data]

Blog post from outline

Draft a blog post from the outline below.
- Voice: second person ("you"), present tense, active voice
- Length: 1200-1500 words
- Include 2-3 runnable code examples
- Every H2 section opens with why it matters
- Do NOT include "Introduction" or "Conclusion" headings
- End with a 3-5 question FAQ section

Outline: [headings and bullets]
Audience: [specific reader]

Release notes from PR list

Write user-facing release notes from this list of merged PRs.
- Group by: new features, improvements, bug fixes
- Customer-visible changes only — skip internal refactors
- Present tense, second person
- One sentence per item
- Start each item with a verb

PRs: [paste list]

README from project

Write a README for the project below. Follow this exact structure:
[name, one-liner, badges, installation, quick start, usage, configuration, contributing, license]

Only include sections for which you have information. Do NOT invent
examples or features. Mark missing sections with [TODO].

Project info: [paste package.json + brief description]

Verification patterns

AI-generated content needs verification before it ships. Built-in checks:

Cross-reference facts. Any number, name, or date the AI produced should be traceable to your source inputs. If you can't find it in what you gave the AI, assume it's wrong.
Read aloud. AI output has a distinct rhythm — too smooth, too balanced. Reading aloud surfaces the plastic parts so you can rewrite them.
Spot-check links and citations. AI fabricates URLs with high confidence. Click every link; verify every citation.
Check code. AI-generated code compiles more often than it's correct. Run it.
Have a human review for bylined content. Anything publicly attributed to a specific author should be read by that author before it ships.

Storing templates and prompts

Treat your templates and prompts as source code:

repo/
├── templates/
│   ├── prd.md
│   ├── post-mortem.md
│   ├── release-notes.md
│   ├── blog-post.md
│   └── readme.md
└── prompts/
    ├── prd-from-bullets.md
    ├── postmortem-from-timeline.md
    ├── tone-pass.md
    └── README.md

Version control them. Iterate on them. Share them across the team. A good prompt is reusable capital; a one-off prompt is wasted effort.

Anti-patterns

The blank prompt. "Write me a PRD about X." You'll get generic slop. Always pair a prompt with a template and facts.
Shipping raw output. The AI's first draft is 70% of a real doc, not 100%. The last 30% is the part that makes it worth reading.
Trusting confident-sounding details. AI writes "The service processes 10,000 requests per second" whether or not it's true. Verify numbers.
Using AI to decide. Don't ask AI "should we build this feature?" Ask yourself, using the document as a thinking aid.
Over-automation. If the doc is routine, automate it aggressively. If the doc is a judgment call (strategy, roadmap, narrative), do it by hand.

The workflow

Putting it all together, a typical AI-accelerated doc workflow:

Gather facts (10 min). Metrics, quotes, timeline, context — in bullet points.
Generate first draft (2 min). Template + facts + constraint prompt → AI output.
Review for accuracy (10 min). Fix hallucinations, verify numbers, remove generic sections.
Add judgment (20 min). The parts only you can write: specific insights, tradeoffs, recommendations.
Tone pass (5 min). Targeted AI edit for voice, passive voice, clichés.
Final read-through (5 min). Human reads, human ships.

Total: ~50 minutes for a doc that would have taken 3–4 hours to write cold. Scale that across a team and you're talking about days of throughput per week.

Closing

AI doesn't replace writing. It removes the friction between "I know what to write" and "it's on the page." Combined with a library of solid Markdown templates, it turns the bureaucratic parts of technical work — the PRDs, post-mortems, release notes, FAQs — from days of effort into an hour.

The templates are the boring part. The facts are the important part. The AI just glues them together. Your job is still the judgment — what problem to solve, what's in scope, what's the actual root cause, what's worth saying. That hasn't changed and won't.