Meltemi

The method is a tool, not a toll

A specification is not paperwork you owe the process. It is the thing that lets one clear heading drive any number of agents, from any vendor, without you re-explaining your intent every session — and the thing that makes their output reviewable instead of merely plausible.

The loop

Every change moves through the same short arc. Trivial work takes the fast path — all artifacts at once — but never the null path.

1 · Propose

An idea becomes a change with a name: why it matters, what it touches and what it deliberately leaves out.

2 · Design

The decisions worth defending, each with the alternatives that were rejected and why. This is where an agent's suggestion earns or loses its place.

3 · Spec deltas

Requirements written as testable behaviour, expressed as deltas against the capabilities you already have — added, modified, removed — rather than a document rewritten in place.

4 · Tasks

A sequence small enough to review, each task pointing back at the requirement that justifies it.

5 · Verify

Each scenario is linked to a test or to a documented verification. Nothing is folded while a requirement is neither verified nor explicitly excepted with a reason.

6 · Archive

The deltas fold into the living truth and the change becomes history. The truth is what the code does now, not what someone once planned.

Requirements that can fail a build

Requirements are written in a constrained form — a trigger, a condition, a shall — so that a scenario reads the same way to a person and to a test name. A requirement whose scenarios cannot fail is a wish, and Meltemi treats it as one.

Traceability is mechanical rather than aspirational: one commit per task, the commit naming its change and task, and each line of code reachable back to the requirement that caused it.

Where the agents fit

The method is the same whether you write the change yourself or delegate it. Meltemi projects the constitution, the product heading and the active specification into the context the agent receives, so the agent argues inside your constraints instead of inventing its own. Then it holds the gates: permissions you decide, isolated worktrees per task, checkpoints before each turn, and a diff you review before anything lands.

Several agents can race the same task in separate worktrees, and you pick the result. That is the point of the heading: it does not care which sail catches the wind.

Read the sources in full

Nothing here replaces the primary documents, and this site does not paraphrase them into a second truth: