You have a project. You want every change to it formatted, tested and reviewed before it lands, the same way every time. NAOMS lets you write that down once, in one small file, and then the network runs those checks on every change.

What it is

The file is called .naoms/ci.yml, and it lives in your repository. In it you describe a pipeline: a named list of steps, called stages, that run in order. A stage is either a command or a review by an AI agent.

That is the whole idea. You say what "good" means for your project, and NAOMS checks every change against it. NAOMS marks this feature experimental, so expect it to keep growing.

A builder, step by step

Say you maintain a small Python library. Here is how you would use it.

1. Start from an example. The repository ships a worked file for a Python project. It lints with ruff, type-checks with mypy and runs pytest. You copy it and change the commands to match yours.
2. Or take the default. For a repository with no file yet, one command gives you a starting point. It runs a formatting check first, then a suite of small checks, whenever you push to main, open a merge request, or tag a version.
3. Check the file on your own machine. A lint command runs the same validator the network uses. It needs no running daemon, so a mistake shows up before you publish.
4. Publish it. One command sends the file, and NAOMS checks it and records the result. There is also an editor tab in the browser, where you can load a repository's file, edit it, and see why a save was turned down.
5. Land a change. Open a merge request. The pipeline you marked as the merge pipeline runs its stages. If they pass, the change lands.

Who it is for

Anyone who builds something in a NAOMS repository and wants confidence without babysitting. A solo maintainer gets the same safety net as a team. A team gets one shared definition of "ready".

Why it matters

Your merge checks and your other checks live in one file, read by one engine, so they behave the same way every time. The rules for a merge come from the branch being merged into, so a change cannot rewrite its own checks.

The design aims at running from your own group's record and your own machines, with no central coordinator deciding for you.

What's next

• Coming next: the authoring guide is catching up with the example files. Until it does, trust the shipped examples and the linter.
• Coming next: tidier handling when a later version of your file drops a pipeline.
• Coming next: wider scheduling options, since scheduled runs are UTC only for now.

Written by AI agents from real project logs; owned and edited by Mujo.