Tell your agent:
Every framework that exists was built by humans, for humans.
But more and more, agents are the ones writing the code.
What would it look like to design for that?
A TypeScript backend framework that runs on Bun. Routing, validation, auth, rate limiting, error handling, streaming — the things you need to build an API. About 1,400 lines of source code total.
The difference: the entire framework ships as source code inside your project. Not an npm package — actual .ts files your agent can read, understand, and modify. Every behavior is defined in a single file. No hidden middleware, no decorators, no magic. An agent reads one feature file and knows exactly what it does.
Route, inputs, auth, side effects, error cases, logic — all in one place. Your agent reads this and knows what to build on, what to test, and what might break.
A complete foundation for building APIs — all as readable source code in your project.
No dependencies to install. No docs to cross-reference. Your agent reads manifest/ once and understands the whole framework.
Copy and paste the prompt into your agent to get started.
Describe what you want to build. Spark handles the rest — cloning, setup, getting the server running.
The framework source code is now in your project at manifest/. Your features go in features/. Your agent already knows the conventions — it read them.
When you're ready to deploy, docker compose up --build works out of the box. No build pipeline to configure, no platform lock-in.
Your code. Your repo. Your infrastructure. Nothing opaque between you and what's running.
If your agent can read and build the code — can it also watch it run?
Spark is a sidekick agent that runs alongside your application during development. When something breaks — an error, a crash, an unhandled exception — Spark sees it with full context: the stack trace, the feature file, the request that caused it. It reads the code, diagnoses the issue, and fixes it — often before you even switch tabs.
Every request gets a JSON envelope with a trace ID. Every error becomes a structured event. Always inspectable — by you, by the agent, by anything.
This is the most experimental part of Manifest. It works remarkably well for some things. For others, it's still early. That's kind of the point.
Manifest comes with skills — structured workflows your agent loads and follows. Say what you want, and the agent handles the execution.
The agent reads the project conventions, scaffolds the feature following the patterns, writes tests, and verifies everything passes.
Because the framework is source code in your repo, the agent can also keep it up to date. When the upstream Manifest project improves, say "update from upstream" and the agent fetches changes, reads every commit, and walks you through what to pick — you decide what enters your app.
Features, commits, updates, conflict resolution — these are agent skills, not shell scripts. The agent handles the workflow. You handle the decisions.
However far agents go — writing code, monitoring systems, fixing what breaks — one thing doesn't change.
You decide what gets built.
The tools shift. The decisions don't. What matters, what ships, what it looks like, how it feels — those are still yours.
Manifest is one way to explore that relationship. The agent handles more of the how. You own the what and the why.
What you make of it is up to you.
Open source. MIT license. Ship something.