Your first hour

From signing in to a room with a project in it. About ten minutes of your attention; the rest is your CI working.

1. Sign in

DoneMark signs you in with GitHub. It asks for nothing else, and it stores no password of yours.

2. Start an organization

The first screen after signing in asks one question: what is it called.

Under the name you will see four seats — Author, Judge, Reader, Agents — and which of them are already yours. Being alone in the room is fine, and the screen says so: the record still carries your name on every verdict, and nothing you seal today changes when others join.

One field, one button.

Then one more question: Which hats do you wear? — Asker, Driver, Judge, Keeper, Owner, with I do everything ticked. Your hats decide what comes first in what waits for you, never what you may do, and you can change them any time from Your hats under your name. See What waits for you, and your hats.

3. Add a project

A project is one piece of software. DoneMark offers two ways in.

An app that exists. Point at its GitHub repository. DoneMark asks you to install a small read-only app on it, then reads what its CI already publishes. See Bring a project you already have.

A new app. Start from a template DoneMark can witness from its first commit, with CI, the runner and the first requirement already inside. See Start a new app.

The screen also prints, plainly, the stacks DoneMark cannot witness yet. If yours is on that list, it tells you now rather than after your first attempt.

From here the project page walks you through it — Setting up · step 2 of 6: Name and repository, Let DoneMark read it, Add DoneMark's files, Your agent's key, A test run, The first run. Going live comes later, and the page says Later, not now.

While you are there, give the project a brief: five short parts saying who it is for and what is being built now. Every attempt is handed it.

4. Let it read the repository

Whichever door you took, DoneMark now reads the repository and tells you one of three things.

Ready. Its CI already publishes what DoneMark needs. Nothing to do.

Something is missing. It names each missing piece in plain words — no script that runs the tests with a machine-readable report, no workflow publishing it — and offers one press, Add DoneMark's files, and let its runner open pull requests, in my name, or one line to run in a terminal. Either writes those files to a branch and opens a pull request in your name. You merge it. DoneMark notices the merge the next time it looks, and the page turns green on its own.

It cannot read the repository. Almost always the app is not installed on it yet. The page says so and links to where you fix it.

5. Add one secret

Your agents need a key, and it is yours, not DoneMark's. Paste your agent's key here and Seal it and store it on GitHub, in my name: the key is sealed in your browser before it leaves, with GitHub's own public key for the repository, so DoneMark's server never sees it. Or put it in GitHub yourself under the name the page prints.

DoneMark records the name and never the value. Then Test the key: your runner makes one real call with it and DoneMark records the answer — Works, Refused, or why it Could not test. Until the key has passed, dispatch waits and says Waits for the key's test.

6. Write your first requirement

One ask, in your words. Type what it should do in one line and press Draft the "done when" lines: DoneMark drafts the rules it will be judged by, and you change them until they say what you mean. Keep it to one screen or one behaviour; DoneMark's own experience is that a requirement too large for its envelope dies at the cap rather than being judged. Or start from a plan — A website people sign in to — and get five features at once.

Approve it. The words freeze.

7. Dispatch

Press Dispatch. DoneMark queues the work; the runner in your repository picks it up and runs your agent, on your CI, with your key.

When the evidence has settled, the door opens and you are told. Then you read what CI saw and decide.

From here on, the loop is the same every time.

This project is empty. What comes first?

Write one requirement: what you want, in a sentence, then the criteria you will judge it by, one per line, each saying how it will be seen. Approve it as its judge, and the queue starts the first attempt by itself. If the project has no judge yet, name one on the People page first.