DEV Community: Kang

Early prototype: serve a Markdown variant for bots/agents without touching your app. NGINX converts HTML Markdown only for explicit clients; not intended for APIs/streaming/auth pages. Looking for feedback.

Kang — Mon, 02 Mar 2026 07:59:52 +0000

Kang

Mar 2

I tried Cloudflare’s “Markdown for Agents” idea in NGINX (Rust module) — early prototype

#showdev #nginx #rust #markdown

Comments

2 min read

I tried Cloudflare’s “Markdown for Agents” idea in NGINX (Rust module) — early prototype

Kang — Mon, 02 Mar 2026 07:21:00 +0000

Cloudflare recently shipped Markdown for Agents: if a client sends Accept: text/markdown, Cloudflare can fetch your HTML and return a Markdown variant.

That idea stuck with me, so I did some vibe coding over a few evenings and built a self-hostable NGINX dynamic module that does something similar on your own infra.

This is a very early / starter prototype — mainly meant to help people try the workflow and share feedback.

Repo: https://github.com/cnkang/nginx-markdown-for-agents

What it does

Only when the client explicitly asks for Markdown:

Browser (Accept: text/html) → original HTML
Agent (Accept: text/markdown) → NGINX converts upstream HTML to Markdown and returns text/markdown

No application changes. This sits entirely at the reverse-proxy layer.

Best for: docs / blogs / news / KB pages

Not for: APIs, streaming responses, or authenticated pages (unless you really know what you’re doing with caching).

Why you might care

Agents and LLM tools often fetch full HTML and end up spending tokens on:

navigation / footer / cookie banners
layout markup
scripts and noisy attributes

A Markdown variant can make downstream parsing cheaper and more predictable.

Quick try (2 minutes)

1) Install (prebuilt module)

curl -sSL https://raw.githubusercontent.com/cnkang/nginx-markdown-for-agents/main/tools/install.sh | sudo bash
sudo nginx -t && sudo nginx -s reload

Note: dynamic modules must match your exact NGINX patch version (nginx -v). If there isn’t a matching build, you may need to compile.

2) Verify content negotiation

# Markdown variant
curl -sD - -o /dev/null -H "Accept: text/markdown" http://localhost:8080/ | grep -iE 'content-type|vary'
# expect:
# content-type: text/markdown; charset=utf-8
# vary: Accept

# HTML variant
curl -sD - -o /dev/null -H "Accept: text/html" http://localhost:8080/ | grep -i 'content-type'

3) See the body

curl -s -H "Accept: text/markdown" http://localhost:8080/ | head -40

Minimal NGINX config

Start small — enable it on one route first.

load_module modules/ngx_http_markdown_filter_module.so;

http {
  markdown_filter off;

  server {
    listen 8080;

    location /docs/ {
      markdown_filter on;

      # Recommended: avoid upstream compression for clean conversion
      proxy_set_header Accept-Encoding "";

      proxy_pass http://backend;
    }
  }
}

A few knobs (optional)

Fail open (recommended for trials): if conversion fails, return original HTML

  markdown_on_error pass;

Limit work (avoid huge pages)

  markdown_max_size 10m;
  markdown_timeout 5s;

Metrics endpoint (localhost only)

  location /markdown-metrics {
    markdown_metrics;
  }

If you cache at NGINX/CDN: make sure variants split by Accept

  proxy_cache_key "$scheme$request_method$host$request_uri$http_accept";

Things that are rough / WIP

It’s early: edge cases will exist (weird HTML, giant pages, odd encodings).
It’s focused on HTML → Markdown only (not PDFs, not arbitrary binaries).
Caching needs care (variant keys + auth-aware behavior).

If you try it… feedback welcome 🙏

If you run into a broken page, a really slow page, or a caching gotcha, I’d appreciate an issue/report with:

a sample URL (or anonymized HTML)
your nginx -v
whether upstream is compressed
any cache/CDN in front

Repo: https://github.com/cnkang/nginx-markdown-for-agents

Cloudflare inspiration:

Showdev: An AI-assisted skill to batch messy changes into Conventional Commits

Kang — Thu, 19 Feb 2026 10:12:51 +0000

Hi DEV community 👋

I’d like to share a small project I’ve been tinkering with: conventional-commit-batcher.

This is my first “skill” I built with the help of AI tools. I originally made it for myself, then a few programmer friends tried it on real work‑in‑progress branches and told me it helped them turn messy, mixed changes into a cleaner commit history—so I decided to open‑source it and invite more people to try it.

TL;DR: It helps you turn a messy, mixed working tree into a clean, reviewable commit history.

Plan first (generate a Commit Plan by intent)
Commit in batches (often with git add -p)
Validate commit messages (Conventional Commits)

What problem does it try to solve?

When a working tree mixes refactors + fixes + docs + chores, it’s easy (especially for junior devs) to end up with:

one giant “misc” commit
vague commit messages
a history that’s hard to review, revert, or git bisect

I wanted something that nudges me toward a more reviewable, traceable history—without turning it into a big ceremony.

What it does (in one line)

Plan-first commit batching + commit message validation — it helps you organize mixed diffs into logical, reviewable Conventional Commits, and validates messages before they land.

How it works (high level)

Plan first: produce a Commit Plan that groups changes by intent (e.g., refactor vs fix vs docs).
Batch staging: stage changes batch‑by‑batch (often with git add -p) instead of “add everything”.
Message validation: enforce Conventional Commits formatting with an executable validator.
Safety gates: stop early if something looks risky (conflict markers, sensitive strings, etc.).

Example: a Commit Plan (by intent)

Here’s a tiny example of what “plan first” looks like:

1) refactor(auth): simplify token parsing

changes: src/auth/*

2) fix(api): handle empty response safely

changes: src/api/*

3) docs: update setup notes

changes: docs/*

Repo / quick try

Repo: https://github.com/cnkang/conventional-commit-batcher

If you use the Vercel skills ecosystem, you can try:

npx skills add cnkang/conventional-commit-batcher

Prefer no agent tooling? You can still use the validator and commit‑msg hook examples in the repo.

A tiny before/after example

Before (typical messy branch)

update stuff
fixes
wip

After (same work, clearer history)

refactor(auth): simplify token parsing
fix(api): handle empty response safely
docs: update setup notes

(You can imagine how much easier it becomes to review, revert, or bisect.)

A small favor: if you have a minute to try it…

I’d really appreciate any thoughts (especially if you can try it on a “messy branch”):

Batching by intent: does it actually help split mixed changes into logical commits?

If not, what kinds of changes are hardest to separate (tests + refactor, formatting + logic, lockfiles…)?
Team conventions: what rules do you follow (types/scopes, subject length, issue references, breaking changes)?
Junior-friendly guardrails: which checks feel helpful, and which feel too strict?
Multi-language commit messages: do you write commits in languages other than English?

If yes, would you prefer type(scope) in English + localized subject/body, or fully localized messages (and how should validation adapt)?

Thank you for taking a look 🙇

If you try it and it helps (or fails), I’d love to hear what happened—either way.