Moonwalk now ships with two tiny Jekyll plugins that fix this. Browsers still see your site exactly as before. Agents get clean Markdown.
For every post rendered at /foo, this plugin emits a sibling at /foo.md containing:
No layouts, no nav, no theme toggle scripts. Just the content.
_site/
foo.html <- as before
foo.md <- new: clean Markdown
An agent that lands on /foo can fetch /foo.md and skip HTML parsing entirely. It is the same pattern Anthropic, Stripe, and a growing set of agent-friendly sites use.
This one generates two files at the root of your site:
If you drop a YAML data file at _data/llms.yml with a title, description, and sections, the plugin uses your hand-curated structure. Otherwise it auto-generates from your posts.
They solve different problems and compose well.
The llms.txt file is a single discovery file. An agent that has never seen your site can fetch it and learn what is here. But it is one file, and it does not scale to deep linking. If a user shares a specific post URL with an agent, the agent still needs to fetch that page.
That is where Markdown siblings come in. Any post URL has a Markdown twin one extension away. Agents do not need to consult the index first.
Ship both. They are complementary.
Both ship as Moonwalk runtime dependencies. If you are on Moonwalk 0.2.0 or later, you only need to add them to your config:
plugins:
- jekyll-markdown-output
- jekyll-llms-output
markdown_output:
collections: [posts]
llms_output:
index:
collections: [posts]
full:
collections: [posts]
respect_markdown_output: true
Build the site. You should see something like:
MarkdownOutput: wrote 9 markdown file(s)
LlmsOutput: wrote /llms.txt
LlmsOutput: wrote /llms-full.txt
That’s it.
Add markdown_output: false to a post’s frontmatter and no Markdown twin is emitted for it. Useful for drafts you want indexed by Google but not picked up by agents.
The auto-generated index is fine. A curated one is much better. Drop this in _data/llms.yml:
title: Your Site
description: >
One paragraph about who you are and what readers
(human or otherwise) will find here.
sections:
- heading: Featured Writing
links:
- title: My best post
url: https://example.com/best-post
description: One line on what it covers
- heading: About
links:
- title: About me
url: https://example.com/about
description: Background and contact
The plugin uses this verbatim. You decide what an agent encounters first.
The default config sets respect_markdown_output: true. This tells the llms-full plugin to skip any post that has opted out via the markdown frontmatter flag. Without it, opted-out posts would still leak into the bulk file.
GitHub Pages restricts plugins to a whitelist, and these two are not on it. Your options:
Cloudflare Pages, Netlify, and Vercel run them without restriction. If you are on GH Pages and want this to work, the cleanest path is a small GitHub Actions workflow that builds and deploys.
If your site is mostly for humans and you do not care whether an LLM cites it well, no. Move on.
If you write things you want agents to find, recommend, and quote accurately, this is a roughly five-minute change with a non-trivial payoff. Agents are reading your site whether you help them or not. The question is whether they read source Markdown or a wrestled-down approximation of your HTML.
Both plugins are open source and small enough to read in one sitting:
They were the smallest change I could think of that meaningfully improves how the agentic web reads my own writing. Now they are part of Moonwalk too.
]]>For a lot of apps, that third moving part buys you nothing you could not get from the database you already have.
This is the argument behind Soniq. Background jobs in Python, persisted in Postgres, no broker, no separate result backend. The tagline says it plainly: “Powered by the Postgres you already have. Nothing else to maintain.”
Here is the scenario that taught me to stop using a separate broker for small and mid-sized apps.
You have an endpoint that creates a User row and enqueues a “send welcome email” job. The order matters. If the job fires before the row commits, the worker reads the database and finds nothing. If the row commits but the enqueue fails, the user exists but never gets a welcome.
With Redis-backed queues, these are two different systems with two different transactions. You write code to make them consistent. You sometimes fail.
With Postgres-backed jobs, the job is a row in the same database as your User row. Both commit in the same transaction or neither does. The “row exists but the job never fired” bug stops being possible.
That alone is worth the switch for a class of apps. The fact that you also remove a service from the architecture is bonus.
Two Postgres features carry most of the weight.
The classic worry with database-backed queues is the thundering herd. A hundred workers all run SELECT * FROM jobs LIMIT 1 at the same time. They all get the same row. They fight.
SKIP LOCKED solves this in one keyword.
SELECT id, payload FROM jobs
WHERE state = 'queued' AND run_at <= now()
ORDER BY run_at
LIMIT 1
FOR UPDATE SKIP LOCKED;
Each worker locks one row. Other workers see the locked row, skip it, and pick the next one. No coordination. No fighting. Postgres handles the concurrency.
This is not a clever workaround. It is a feature designed for queue-like workloads, and it has been stable since Postgres 9.5 (2016).
The second worry is latency. Polling the jobs table every second works but feels wasteful. Five seconds of latency on a “send welcome email” job is fine. Five seconds on a “process payment” callback is not.
Postgres has a built-in pub/sub channel. The producer NOTIFYs when it inserts a job. Workers LISTEN on the channel and wake up immediately. Latency drops from polling-interval to single-digit milliseconds.
Combined, these two features give you the same operational shape as a Redis queue: instant pickup, safe concurrent workers, persistence, retries. Without the second service.
Soniq packages this with the obvious surrounding pieces:
The smallest useful program:
from soniq import Soniq
app = Soniq(database_url="postgresql://localhost/myapp")
@app.job()
async def send_welcome(to: str):
print(f"Sending welcome email to {to}")
await app.enqueue(send_welcome, to="dev@example.com")
Then run soniq setup once to create the tables, soniq worker to process jobs, and you are done. No broker config. No result backend.
I want to be honest about the limits, because every “you don’t need X” post on the internet eventually runs into someone who does need X.
Throughput. Soniq comfortably handles up to about 10k jobs per second. Redis-backed queues can do an order of magnitude more. If you are sending 50k notifications a second through a single queue, you have outgrown this approach. You also probably know it.
Cross-language workers. Soniq is Python on both ends. Celery has a story for Ruby, Node, Go workers reading off the same queue. If your architecture genuinely needs that, this is not the tool.
DAG orchestration. Airflow and Prefect run pipelines of dependent jobs with retry semantics across the whole graph. Soniq runs individual jobs. They are different problems with different tools.
For everything else (the long tail of apps that need reliable async work, scheduled jobs, retries, and a place to look when something goes wrong) Postgres is enough.
This post is really about a smaller idea: prefer the boring database you already have over a new service, until the database stops being enough.
Most apps never reach the point where it stops being enough. They just reach the point where someone reaches for the new service out of habit, and adds a year of operational tax for no real benefit.
Soniq is one specific bet on that pattern. The site has the pitch in more detail and the docs are short: soniq.abhinav.co.
]]>I have done this on enough projects to think it is a mistake.
They do not show up in week one. They show up later, all at the same time.
Your homepage is as slow as your slowest endpoint. When the database is under load or a worker is leaking memory, your marketing page slows down too. The first impression a visitor gets is your worst-day performance. Static HTML on a CDN cannot have a bad day in the same way.
Marketing edits ship behind code review. Marketing wants to change the headline. Now it is a PR, a test run, a deploy, a cache bust. On a static site it is one commit and 40 seconds. The friction is not just annoying, it changes what gets shipped. Things that should be experiments become scheduled work.
SEO and app routing fight each other. Your blog wants /blog/some-post. Your app might want /blog as a feature. Pricing wants /pricing as a stable URL forever. App routing wants the freedom to refactor. They are different concerns and they should be different services.
The marketing site never needs the application’s runtime. It does not need a database. It does not need a job queue. It does not need authentication. Why is it shipping with all of them?
A static site generator, a CSS framework, a host that serves files from a CDN. That is it. No build pipeline beyond markdown and templates. No runtime to monitor. Deploy on every push to main, ship to a CDN, done.
This is what Cookie is. Jekyll for the generator, Tailwind for the CSS, a structure that gets you from fork to deployed in an afternoon.
What ships with it:
It is not a CMS. There is no admin panel. You edit Markdown files, you commit, the site rebuilds. That is the entire model.
If you are an indie founder or small team about to ship a new product, separate the marketing site on day one. The cost is fifteen minutes of repo setup. The savings show up over the next two years.
If you have an existing app with marketing bundled in, the migration is usually a few days. Move /pricing, /about, /, /blog out to a static site behind the same domain. Point the app at /app or a subdomain. The hardest part is usually the blog redirects.
The receipts: Cookie powers the marketing sites for APIC Blocks, APIC Agent, Annexr, Soopr, and Chhoti Si Kahani. I started one of those in 2021 and never had a reason to switch off.
When the same template survives five products and four years without rewriting, that is usually the signal that the underlying decision was right, even if the template itself keeps getting refreshed.
Fork it, deploy it, write your headline: github.com/abhinavs/cookie.
]]>That bothered me enough to rebuild it. HTTPlex is a small Elixir/Phoenix service that does the same thing httpbin does, runs on a box I control, and never makes my CI flaky because someone else’s deploy went sideways. There is also a hosted version at httplex.com you can point at if you do not want to self-host.
The same things httpbin does, mostly.
If you have used httpbin, you already know the API. That is the point. There is no learning curve, just a different hostname.
Two reasons.
The first is honest: I wanted to write more Elixir, and a service like this is small enough to finish in a weekend and rich enough to touch most of Phoenix. Pattern matching on request methods, returning streams from a controller, OTP supervision under load. It is a good project to learn on.
The second is practical: BEAM handles slow clients and long-lived connections better than almost anything else. /drip and /stream-bytes are useful precisely because they keep a connection open. On a runtime where every connection is a process, that is just normal.
Three reasons that mostly collapse into one.
Your CI shouldn’t depend on a third-party hostname. Every shared service has bad days. Yours should not be coupled to theirs.
Self-hosted means you can extend it. Need to test how your client handles a server that returns 200 OK with a Content-Length lie? Add an endpoint. The whole controller is one file you can read in five minutes.
It is a free education. If you have never read a real Phoenix controller, this is a cheap way to. The whole repo is a tour of the framework’s idioms with no business logic in the way.
git clone https://github.com/abhinavs/httplex
cd httplex
mix setup
mix phx.server
Now hit localhost:4000. Or deploy it. Phoenix releases are one command and the artifact is a self-contained tarball. Fly.io and Render both have one-click templates.
Or just hit httplex.com and start poking endpoints. Source: github.com/abhinavs/httplex.
A small tool, a fun rewrite, and a quiet reduction in CI flakiness. Worth a weekend.
]]>That bug taught me something obvious in retrospect. Unix tools were built for humans who read the output of one stage before piping to the next. We grep, eyeball the result, then pipe to awk. Agents skip the eyeballing. They wire the whole pipeline up at once and hope.
vrk is the toolkit I started building for that gap. 26 small commands, one static binary, zero dependencies. It is not a replacement for cat or jq. It is the layer that should sit next to them when the consumer at the other end of the pipe is an LLM.
Three things, mostly.
Silent failures stop being acceptable. classic Unix conflates “no output” with “everything is fine.” awk on a missing field returns empty. jq on a wrong path returns null. A human notices. An agent passes the empty string through and the next stage hallucinates.
vrk tools use explicit exit codes. 0 for success, 1 for an error you should stop on, 2 for a soft signal the next tool can react to. A tok check against a budget exits 2 when the input is too large, so the next stage in the pipe can branch instead of crashing.
Token counts are first-class. None of the standard tools care how many tokens a string is. wc -w is approximate at best, lying at worst. If the next stage costs money per token, you want the count up front and you want to gate on it.
cat article.md | vrk tok --check 8000 | vrk prompt --system 'Summarize'
The check fails loudly if the input would blow the budget. The prompt never runs. No retries, no surprise bill.
Secrets need to leak less. Pipelines copy data through a lot of stages. Anything you log, cache, or upload to a third-party model is a potential leak. vrk mask runs entropy and pattern checks on stdin and redacts before the data ever reaches a remote API.
A few I reach for daily:
The rest cover the boring bits: jwt, uuid, epoch, sse parsing, schema diffing. They exist because at some point I wrote them inline in a bash script and decided that was the third time too many.
Each tool reads stdin and writes stdout. None of them have hidden state. They chain.
cat data.json \
| vrk validate --schema input.schema.json \
| vrk mask \
| vrk prompt --model claude-opus-4-7 --system 'Extract entities' \
| vrk validate --schema output.schema.json
That is a complete agent pipeline. Validate the input, redact secrets, run the prompt, validate the output. Every stage fails loud. No surprise costs, no leaked tokens, no malformed JSON downstream.
vrk is open source and the binary is one curl away. Source and install instructions: vrk.sh.
The pitch in one sentence: classic Unix tools are excellent for humans and dangerous for agents. vrk fills the small set of gaps that show up the moment an LLM is the consumer at the end of the pipe. Use it next to your existing toolkit, not instead of it.
]]>[!NOTE] Useful information that users should know, even when skimming content.
[!TIP] Helpful advice for doing things better or more easily.
[!IMPORTANT] Key information users need to know to achieve their goal.
[!WARNING] Urgent info that needs immediate user attention to avoid problems.
[!CAUTION] Advises about risks or negative outcomes of certain actions.
[!NOTE] Alerts can contain bold text,
inline code, links, and other standard Markdown formatting.They can also span multiple paragraphs.
]]>This is a normal blockquote. It keeps its original styling and is not affected by the alert processing.
Moonwalk uses Soopr for share and like buttons and it is already integrated. By default, Moonwalk shows circular Twitter, Facebook and Copy buttons in base size. To add like button, please signup for free on Soopr
Once you have signed up on Soopr, get a publish token for your website and edit _config.yml file and add it under soopr key and restart the server.
soopr:
publish-token: "ADD_YOUR_PUBLISH_TOKEN_HERE"
Check out the Soopr Website for more info on how to get the most out of Soopr.
]]>from pathlib import Path
import json
def load_config(path: str) -> dict:
"""Read a JSON config file and return its contents."""
config_path = Path(path)
if not config_path.exists():
raise FileNotFoundError(f"Config not found: {path}")
return json.loads(config_path.read_text())
config = load_config("settings.json")
print(config.get("name", "world"))
require "net/http"
require "json"
module Weather
BASE_URL = "https://api.weather.example.com"
def self.fetch(city)
uri = URI("#{BASE_URL}/current?city=#{city}")
response = Net::HTTP.get_response(uri)
unless response.is_a?(Net::HTTPSuccess)
raise "Request failed: #{response.code}"
end
JSON.parse(response.body, symbolize_names: true)
end
end
data = Weather.fetch("Tokyo")
puts "#{data[:city]}: #{data[:temp_c]}C"
async function fetchPosts(tag) {
const url = new URL("https://api.example.com/posts");
url.searchParams.set("tag", tag);
const response = await fetch(url);
if (!response.ok) {
throw new Error(`Failed to fetch posts: ${response.status}`);
}
const { posts } = await response.json();
return posts.map(({ title, slug }) => ({ title, slug }));
}
const posts = await fetchPosts("javascript");
console.log(`Found ${posts.length} posts`);
defmodule TaskRunner do
@moduledoc "Runs async tasks with a timeout."
def run(tasks, timeout \\ 5_000) do
tasks
|> Enum.map(&Task.async/1)
|> Enum.map(&Task.await(&1, timeout))
end
end
results =
TaskRunner.run([
fn -> HTTPClient.get("/users") end,
fn -> HTTPClient.get("/posts") end
])
IO.inspect(results, label: "results")
.highlight, pre code, blockquote {
border-radius: 0.5em;
}
blockquote {
background-color: var(--bg-secondary);
border: 1px var(--border) solid;
}
Fusce non velit cursus ligula mattis convallis vel at metus. Sed pharetra tellus massa, non elementum eros vulputate non. Suspendisse potenti. Quisque arcu felis, laoreet vel accumsan sit amet, fermentum at nunc. Sed massa quam, auctor in eros quis, porttitor tincidunt orci. Nulla convallis id sapien ornare viverra. Cras nec est lacinia ligula porta tincidunt. Nam a est eget ligula pellentesque posuere. Maecenas quis enim ac risus accumsan scelerisque. Aliquam vitae libero sapien. Etiam convallis, metus nec suscipit condimentum, quam massa congue velit, sit amet sollicitudin nisi tortor a lectus. Cras a arcu enim. Suspendisse hendrerit euismod est ac gravida. Donec vitae elit tristique, suscipit eros at, aliquam augue. In ac faucibus dui. Sed tempor lacus tristique elit sagittis, vitae tempor massa convallis.
Proin quis velit et eros auctor laoreet. Aenean eget nibh odio. Suspendisse mollis enim pretium, fermentum urna vitae, egestas purus. Donec convallis tincidunt purus, scelerisque fermentum eros sagittis vel. Aliquam ac aliquet risus, tempus iaculis est. Fusce molestie mauris non interdum hendrerit. Curabitur ullamcorper, eros vitae interdum volutpat, lacus magna lacinia turpis, at accumsan dui tortor vel lectus. Aenean risus massa, semper non lectus rutrum, facilisis imperdiet mi. Praesent sed quam quis purus auctor ornare et sed augue. Vestibulum non quam quis ligula luctus placerat sed sit amet erat. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Fusce auctor, sem eu volutpat dignissim, turpis nibh malesuada arcu, in consequat elit mauris quis sem. Nam tristique sit amet enim vel accumsan. Sed id nibh commodo, dictum sem id, semper quam.
Donec ex lectus, tempus non lacinia quis, pretium non ipsum. Praesent est nunc, rutrum vel tellus eu, tristique laoreet purus. In rutrum orci sit amet ex ornare, sit amet finibus lacus laoreet. Etiam ac facilisis purus, eget porttitor odio. Suspendisse tempus dolor nec risus sodales posuere. Proin dui dui, mollis a consectetur molestie, lobortis vitae tellus. Vivamus at purus sed urna sollicitudin mattis. Mauris lacinia libero in lobortis pulvinar. Nullam sit amet condimentum justo. Donec orci justo, pharetra ut dolor non, interdum finibus orci. Proin vitae ante a dui sodales commodo ac id elit. Nunc vel accumsan nunc, sit amet congue nunc. Aliquam in lacinia velit. Integer lobortis luctus eros, in fermentum metus aliquet a. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos.
]]>This is a Japanese test post to show you how japanese is displayed.
私は昨日ついにその助力家というのの上よりするたなけれ。 最も今をお話団はちょうどこの前後なかろでくらいに困りがいるたをは帰着考えたなかって、そうにもするでうたらない。 がたを知っないはずも同時に九月をいよいよたありた。
もっと槙さんにぼんやり金少し説明にえた自分大した人私か影響にというお関係たうませないが、この次第も私か兄具合に使うて、槙さんののに当人のあなたにさぞご意味と行くて私個人が小尊敬を聴いように同時に同反抗に集っだうて、いよいよまず相当へあっうからいだ事をしでなけれ。
それでそれでもご時日をしはずはたったいやと突き抜けるますて、その元がは行ったてという獄を尽すていけですた。
この中道具の日その学校はあなたごろがすまなりかとネルソンさんの考えるですん、辺の事実ないというご盲従ありたですと、爺さんのためが薬缶が結果までの箸の当時してならて、多少の十月にためからそういう上からとにかくしましないと触れべきものたで、ないうですと多少お人達したのでたた。
From すぐ使えるダミーテキスト - 日本語 Lorem ipsum.
This is a chinese test post to show you how chinese is displayed.
善我王上魚、產生資西員合兒臉趣論。畫衣生這著爸毛親可時，安程幾？合學作。觀經而作建。都非子作這！法如言子你關！手師也。
以也座論頭室業放。要車時地變此親不老高小是統習直麼調未，行年香一？
就竟在，是我童示讓利分和異種百路關母信過明驗有個歷洋中前合著區亮風值新底車有正結，進快保的行戰從：弟除文辦條國備當來際年每小腳識世可的的外的廣下歌洲保輪市果底天影；全氣具些回童但倒影發狀在示，數上學大法很，如要我……月品大供這起服滿老？應學傳者國：山式排只不之然清同關；細車是！停屋常間又，資畫領生，相們制在？公別的人寫教資夠。資再我我！只臉夫藝量不路政吃息緊回力之；兒足灣電空時局我怎初安。意今一子區首者微陸現際安除發連由子由而走學體區園我車當會，經時取頭，嚴了新科同？很夫營動通打，出和導一樂，查旅他。坐是收外子發物北看蘭戰坐車身做可來。道就學務。
國新故。
工步他始能詩的，裝進分星海演意學值例道……於財型目古香亮自和這乎？化經溫詩。只賽嚴大一主價世哥受的沒有中年即病行金拉麼河。主小路了種就小為廣不？
From 亂數假文產生器 - Chinese Lorem Ipsum.
效育声去本义然空，各值太法心想，场强实地。 题铁习点儿表管少间千，只何政亲织文意部，千影画派证男须。 手反取长风治增非等直难群，连取及天他己事头级，影数弦适把气快目人。 专议以省通引而千个，格则口段度样水热马，地教少务改磨。 包思外心半院应她算斯，市外会快记路又火学，劳如肃它准众丧边。
团算部住县单总边素格军所，合音府教看和广光采率位转，位用品根确针百。 证其标元角工方海接交他，论象切万世认一响义，治然身本风弦带题。 向我次路持加北，她不反心。 说总元军例市决，现始即算证养，规走还壳。
因林可相儿应满军，热影省条律因资再，整肃赤心将届。 局广写两量备验还，南教事争工民的，备进研上布。 素身电活非直，速这区交示从，百层达。 资量那毛什京身，白这快。 半打容三手开常价或，手严量般象式效，名可重芽门适。 来设什一我么，光界美么或，住身式准。 造酸改表委验众办地百养，商物战众本列听度名院，制压录丽快与千机内。 住需当四议决得命南然照按民置，当住命形金决否矿单外。 气象理离开新集增际，三划方工义很年关，拉许准孝口。 构片出干计由备美打养，持育总指承入无己。
]]>