Get Started
In this section

What your agent reads

aDNA is Markdown instructions that an agent reads and acts on. That is the whole mechanism, and it is also the reason you might not want to run our install command on a stranger's say-so: the files are the program.

So read them first. Below is every file a fresh workspace hands your agent on its first run — all 4 of them, about 70 KB, shown exactly as they arrive. Nothing here is a paraphrase or a screenshot. If you would rather read them in the repository, or diff them against what you cloned, every file links to its source at the same commit.

The reading order

This is the order your agent meets them in, not a ranking. The first two are read on every session; the last two are procedures it follows only when you ask for a new project.

  1. The workspace router

    how/templates/template_workspace_claude.md · 150 lines

    The CLAUDE.md that sits at the root of your new workspace — the first file an agent reads.

    Why your agent reads it. An agent started anywhere in the workspace reads this to work out which project you mean before it does anything else. It is a map, and it is the reason the standard needs no index service and no daemon.

    What to look for. Read it as what it is: instructions addressed to an agent, in English. There is no code path here — nothing fetches, nothing installs, nothing phones home. The strongest check is the plainest one: if this file asked an agent to send your files somewhere, you would be able to read the sentence that said so.

    Read template_workspace_claude.md in full →

  2. The standard's own governance

    CLAUDE.md · 358 lines

    The CLAUDE.md inside the hidden .adna/ folder — the standard describing itself.

    Why your agent reads it. Your agent reads this to learn the conventions it is expected to follow: the triad, the entity types, the session and mission protocol. This is the file that makes the standard self-teaching rather than a PDF you have to remember.

    What to look for. Its frontmatter carries role: template. That single field is load-bearing — it is what tells an agent this directory is the standard itself and must never be edited, which is why updates arrive by git pull instead of by merge conflict.

    Read CLAUDE.md in full →

  3. The skill that actually runs first

    how/skills/skill_project_fork.md · 261 lines

    The procedure an agent follows to scaffold your first project.

    Why your agent reads it. This is the one that fires on a fresh clone. The workspace has no projects yet, so the router routes here — it creates <your_project>.aDNA/, its triad of what/ how/ who/, its governance files, and its own git history.

    What to look for. Follow it as a recipe and you can predict exactly what will appear on disk before you run anything. That predictability is the point of the tour: nothing below is a surprise. If you would rather do it by hand, you can — the skill is a description of file creation, not a binary.

    Read skill_project_fork.md in full →

  4. The interview that comes second

    how/skills/skill_onboarding.md · 266 lines

    The first-run interview that customises a project vault for your domain — after one exists.

    Why your agent reads it. It is real and you will probably meet it, but not first, and it is not what builds your project. It gates on a forked project directory, so a brand-new workspace cannot trigger it; the fork skill above creates the project and then offers this. The get-started page used to have the order the other way round.

    What to look for. Read its own first-run detection conditions and you can see the gate for yourself — it checks for an uncustomised project and explicitly refuses to run against the base template. We are showing you the file rather than asking you to take our word for the correction.

    Read skill_onboarding.md in full →

And what it builds

Those four files exist to produce one thing: a project that is legible to an agent without being explained to it. Here is a real one — the triad of this vault, the context graph that publishes the page you are reading:

what/

  • assets/
  • comparisons/
  • concepts/
  • context/
  • decisions/
  • design/
  • docs/
  • doctrine/
  • exemplars/
  • glossary/
  • inventory/
  • lattices/
  • measurement/
  • patterns/
  • specs/
  • tutorials/
  • use_cases/

how/

  • backlog/
  • campaigns/
  • configs/
  • federation/
  • gates/
  • migrations/
  • missions/
  • pipelines/
  • publishing/
  • quests/
  • sessions/
  • skills/
  • standard/
  • tasks/
  • templates/
  • workshops/

who/

  • adopters/
  • assets/
  • community/
  • coordination/
  • governance/
  • identity/
  • reviewers/
  • team/

Derived from this repository at build time, so it is the real directory listing rather than an illustration of one. Knowledge in what/, operations in how/, people in who/ — that split is the standard's one structural rule, and everything above is in service of it.

Then what

If the files look sane, the install page states what the command writes, what the agent does with it, and how to undo it. If they do not, you have lost a few minutes of reading instead of an evening — which was the point of putting them here.