Share the DNA of an app. Your agent builds it for you.
A single text file describes an entire app: what it does, what can't change, and the steps to build it. You give it to your coding agent and it writes the app.
The app comes out in your language, for your devices and hosting, and suited to how you use a phone or a computer. If you are blind, you get an app you can use by voice. If you are deaf, nothing depends on sound. What you share is the recipe.
Build the app described in https://meshkore.com/dnapps/example.dna.yaml following the DNApps standard at https://meshkore.com/dnapps/spec.md
Paste it into Claude Code, Codex or Cursor. The agent may ask you a few things (language, design, which AI provider to use), shows you the permissions the app needs, and builds and tests it step by step.
Why we call it DNA
A genome is a small description, and the same genome grows differently depending on climate, food and surroundings. The genes stay the same, but no two individuals come out alike. A capsule works the same way, and that gives it two uses.
Your setup goes in before any code
Your language, devices, operating system and abilities, and the hosting and AI keys you already have, go in before any code exists. So it doesn't have to be translated or reconfigured later. The agent writes down every choice, so the next version is grown the same way for you.
The capsule is a fraction of the app
A capsule keeps what the app must be and drops how one copy happens to be written. Our example capsule is 15 KB. The app an agent grew from it is 75 to 95 KB of code, about five times more. We think the ratio grows with bigger apps, but haven't measured it yet. The same capsule should also grow into web, iOS and Android apps in several languages. So far we've only built it as a web app.
What the app is, and the order to build it in.
We borrowed the names from biology: the DNA defines the app and the RNA is the plan that turns it into working software.
Purpose, features, constraints
Who it is for and what problem it solves. Features with acceptance criteria an agent can test. Platforms, stack and hosting. Data, privacy, device permissions (camera, microphone, GPS, Bluetooth) and integrations (a vision model, a Gmail connector). Design intent, languages and accessibility.
Phases and tasks, in build order
The ordered roadmap that turns the DNA into running software. Every task has a verifiable "done when", so the agent proves each step before the next. It maps one-to-one onto a project roadmap, so you can keep adding tasks after the first build instead of starting over.
Every decision says whether it may change.
Each value in a capsule is a gene with an expression mode. That mode is what lets the same file produce a different app for each person. Each one still has to pass the capsule's tests.
Must be respected as written. If the agent can't, it stops and says so. Purpose, features and privacy are fixed by default.
Used unless it clashes with your setup. If the agent swaps it, it writes down what it used and why. Stack and hosting default here.
Only a suggestion. The agent decides based on you. Language, colors, platform and modality default here.
# plate.dna.yaml (excerpt) # a nutrition spin-off of a bigger fitness app appdna: "0.1" identity: name: "Plate" lineage: forked_from: "Evolvea" changes: "Only the nutrition module" features: - id: F1 title: "Log a meal from a photo" acceptance: - "GIVEN a photo of a plate WHEN saved THEN within 20 s it shows grams, kcal, protein, carbs, fat, a 1-5 quality score and a confidence" - "GIVEN a photo with no food THEN no meal is invented" platforms: targets: { is: [web], mode: preferred, alternatives: [ios, android] } run: { is: "double-click index.html", mode: fixed } offline: { is: required, mode: fixed } stack: vision_model: { is: "any vision model with JSON output", mode: adapt } privacy: stays_on: device shared_with: ["the model provider the person chooses"] telemetry: none experience: i18n: languages: { is: [en, es], mode: adapt } accessibility: { baseline: "WCAG 2.2 AA" } rna: phases: - { id: P1, title: "Local core", ... } - { id: P2, title: "Capture", needs: [P1], ... }
Same DNA, three different apps.
The fixed parts are the same in all three. Everything else depends on who built it.
- profile
- Spanish · blind · iPhone
- expressed as
- Native iOS app, voice-first: she dictates each meal instead of photographing it, and the day's totals and weekly review are read aloud through VoiceOver.
Lucía · Madrid
- profile
- German · deaf · Android
- expressed as
- Installable web app in German. Every message is visual and no feature depends on sound.
Jonas · Berlin
- profile
- English · developer · Mac + Cloudflare
- expressed as
- Built with SolidJS, served from her own Cloudflare account and styled with her design system; she uses her own Gemini key.
Priya · Bengaluru
Every builder writes a .dna.lock.yaml listing every choice it made and why. That way the next version is built the same way, and you can compare a fork with the original.
What goes in a capsule
YAML or JSON, validated by one schema. Never secrets, passwords or personal data.
Name, summary, public or private, license, authors, and which capsule it was forked from.
The problem, who it is for, outcomes, non-goals; features with GIVEN/WHEN/THEN acceptance.
Web, iOS, Android, macOS, Windows, Linux; language, framework, database; personal, team or SaaS scale.
GPS, Bluetooth, the camera, a Gmail connection, each with a reason. Anything not on the list is off limits.
UI intent, optional screens, design hints, languages and accessibility modalities.
Entities, where data lives, who it is shared with, telemetry, export. A builder may tighten it, never loosen it.
Every acceptance line becomes a test the agent must pass.
Phases and tasks in order, with dependencies and "done when".
What already exists
We checked in November 2026. Several tools cover part of it: specs for coding agents, instruction files, deploy manifests. None describes a whole app in one file that says what is fixed, what can change, and adapts it to the person. DNApps reuses their vocabulary wherever it can.
| Format | What it describes | One file to share | Fixed vs adaptable | Adapts to the person | Build order |
|---|---|---|---|---|---|
| GitHub Spec Kit | Spec, plan and tasks per feature | No · many files | No | No | Yes |
| AWS Kiro specs | Requirements (EARS), design, tasks | No · tool-bound | Steering only | No | Yes |
| Agent OS / BMAD | Mission, roadmap, stack / PRD → stories | No · a method | No | No | Yes |
| AGENTS.md | How an agent works in a repo | Yes · free text | No | No | No |
| Score · OAM · Devfile | Workloads and deployment | Yes | No | No | No |
| Web App / OS manifests | Install metadata, permissions | Yes | No | No | No |
| DNApps | The whole app, for any builder | Yes | Yes · per gene | Yes · profile + lock | Yes · RNA |
Acceptance criteria use EARS / GIVEN-WHEN-THEN like Kiro and Spec Kit; permission names follow the W3C Permissions registry and Web App Manifest; a SaaS capsule can carry a Score workload. Sources and details are in the spec, §10.
A capsule only describes
The agent treats it like any file from a stranger. Before writing code it shows you what the app is for, which permissions it asks for, what it connects to and where your data goes. It asks for nothing that isn't listed, and it does nothing the text says that falls outside building the app.
The RNA becomes your roadmap
In a project that follows the MeshKore development standard, phases become initiatives and tasks become task files, so any agent can keep improving the app after the first build. A system that already knows your preferences could fill in the adaptable parts without asking you.
How we test a capsule
We gave the example capsule to Claude Code in an empty folder and didn't answer any of its questions. Then we checked the app it built. Each time something went wrong, we traced it back to a gap in the capsule. Once it was a default the agent never connected to its field. Once it was a model picked from memory. Once it was a test that missed the navigation bar. We fixed the capsule and built it again. The guide collects what we learned: every acceptance line becomes a named test, external services get fakes, checks look at the rendered page, and versions never come from the agent's memory.
Try it on something small and tell us where it falls short.
This is a first draft and parts of it are surely wrong. Tell us which. The text is CC BY 4.0, the schema is Apache-2.0, and a patent pledge covers anyone who implements it. Comments, build reports and pointers to similar work go on GitHub.