Describe the application in structured English. Let the LLM figure out the computing.
This repository contains an RSS client defined entirely in Markdown. The application is a collection of prose specifications, a command grammar, a state machine, execution primitives, error contracts, packaged as a skill that an agentic coding harness (Claude Code, Codex, or similar) can read and execute at runtime.
There is no compiled binary. No installed package. The Markdown is the application.
Programming has always been specification. We decompose a problem, define its boundaries, declare how inputs map to outputs and describe what happens when things go wrong. For decades, the only way to make a machine respect those specifications was to rewrite them in its language C, Java, Python, whatever the project demanded.
That constraint is dissolving. AI harnesses can read structured natural language, follow state transitions and execute operations against real I/O. If the specification is precise enough, the harness builds and runs the application at runtime. The human never touches syntax.
This project is a proof of concept for that paradigm. The RSS skill is modelled as:
- A command grammar with aliases, flags, positionals, and precedence rules
- A state machine with named states, typed transitions, and terminal exit codes
- Execution primitives that define every store, network, and output operation
- Error contracts that map failure classes to exit codes
The RSS client could work if every primitive were described in pure English. The LLM can parse XML, manage a JSON store, and format output without being handed a script. But each invocation could implement those operations differently, different variable names, different edge-case handling, etc.
The bash and python fragments in EXECUTION_PRIMITIVES.md exist to pin deterministic behaviour. They are not the application logic — they are disambiguation. They tell the LLM exactly how to resolve a feed reference, exactly what the atomic save looks like, exactly what the output envelope contains. The prose defines what the application does; the fragments remove the latitude in how it does it.
This is a deliberate point on a spectrum:
| Approach | Determinism | Flexibility |
|---|---|---|
| Pure prose specification | Lower — LLM chooses implementation each run | Higher — adapts to context |
| Prose with pinned code fragments | Higher — consistent behaviour across runs | Lower — fragments constrain the runtime |
| Traditional source code | Highest — compiled/interpreted exactly | Lowest — no runtime interpretation |
This project sits in the middle. The interesting question is how far toward pure prose you can push before the variance becomes unacceptable for your use case.
The proof of concept is a fully featured RSS client — feed management, fetching, reading, search, export, and LLM-powered analysis — defined across a set of Markdown specifications.
For the full technical details — command families, execution pipeline, state machine, output contracts, exit codes, and runtime spec references — see RSS/README.md.
This project requires an agentic coding harness with tool use (shell, file I/O, network).
Clone the repo first:
git clone https://github.com/IamCatoBot/text-is-code.gitThen copy the skill into your harness's skill directory:
| Scope | Path |
|---|---|
| Personal (all projects) | ~/.claude/skills/rss |
| Project-local | <project>/.claude/skills/rss |
# Personal
cp -r text-is-code/RSS ~/.claude/skills/rss
# Or project-local
cp -r text-is-code/RSS .claude/skills/rss| Scope | Path |
|---|---|
| Personal (all repos) | ~/.codex/skills/rss |
| Repo-local | <repo>/.codex/skills/rss |
# Personal
cp -r text-is-code/RSS ~/.codex/skills/rss
# Or repo-local
cp -r text-is-code/RSS .codex/skills/rssInvoke the skill using your harness's native syntax (/rss in Claude Code, $rss in Codex):
rss help me setup the rss skill
Or jump straight into commands:
rss feed add https://feeds.arstechnica.com/arstechnica/index -n "Ars Technica"
rss read --unread --limit 10
rss fetch
rss analyse --today
The harness reads the Markdown specifications and executes the operations directly — no build step, no binary.
This is a proof of concept and an open question. If you see where the approach holds, where it breaks, or what it means for how we build software. Open an issue or a pull request.
If you find this interesting, star the repo to follow updates and help others discover it.
