@turri-dev/cli 0.1.4-next.5a94e68 → 0.1.4-next.8254fbc

package/genome/skills/mature/SKILL.md

@@ -24,49 +24,28 @@ metadata:
 
 # Mature
 
-Load the `***plain` syntax rules before writing anything - they are in the system prompt under
-`<plain-rules>`; read `genome/rules/<name>.md` for the full text of any rule you need to follow
-closely.
+Load the `***plain` syntax rules before writing anything - they are in the system prompt under `<plain-rules>`; read `genome/rules/<name>.md` for the full text of any rule you need to follow closely.
 
 ## Role
 
 Act as a `***plain` spec writer who hardens a spec by building it, on your own, until it builds.
 
-**The goal:** the spec fully regenerated - `drift` says "Fully regenerated" for every module: every
-functionality regenerated from the spec as it stands, its conformance tests too, and nothing regenerating
-or held back.
+**The goal:** the spec fully regenerated - `drift` says "Fully regenerated" for every module: every functionality regenerated from the spec as it stands, its conformance tests too, and nothing regenerating or held back.
 
-**The loop:** render what is not built; watch the agents building it; when one struggles on something
-the spec leaves open or unclear, settle it in the spec, stop that build, and render again.
+**The loop:** render what is not built; watch the agents building it; when one struggles on something the spec leaves open or unclear, settle it in the spec, stop that build, and render again.
 
-Where a spec is silent, the agent that renders it has to decide - a format, a default, an error, a
-rule - and when the decision is hard, or the spec reads two ways, it struggles: its tests keep
-failing, the judge keeps finding the tests or the code wrong, it runs far too long. Much of that is
-the spec's to settle, and once the spec says it, the next build does not struggle. Some of it is not
-- a bug the agent will fix, an environment problem, turri itself - and the spec stays out of
-that.
+Where a spec is silent, the agent that renders it has to decide - a format, a default, an error, a rule - and when the decision is hard, or the spec reads two ways, it struggles: its tests keep failing, the judge keeps finding the tests or the code wrong, it runs far too long. Much of that is the spec's to settle, and once the spec says it, the next build does not struggle. Some of it is not
+- a bug the agent will fix, an environment problem, turri itself - and the spec stays out of that.
 
-You never ask the user: this runs on its own. Where the spec leaves a real choice, take the reading
-that best fits the rest of the spec, the intent it states and what the builds already did, write it,
-and record the decision for the report. You never change what the spec plainly means, never write the
-spec to match code that does something else, never add features, never touch generated code, and
-never edit a `.plain` file with the file tools once rendering has started - every change is a spec
-diff, with `write_spec_diff`.
+You never ask the user: this runs on its own. Where the spec leaves a real choice, take the reading that best fits the rest of the spec, the intent it states and what the builds already did, write it, and record the decision for the report. You never change what the spec plainly means, never write the spec to match code that does something else, never add features, never touch generated code, and never edit a `.plain` file with the file tools once rendering has started - every change is a spec diff, with `write_spec_diff`.
 
 ## Steps
 
 ### intake
 
-1. Find the spec: the `.plain` file(s) the user named, or the project's modules. Read them whole,
-   with their `import` and `requires` chains, and the project's `config.turri.yaml` (or the old
-   `config.yaml`, when there is no `config.turri.yaml`) and each stack's `config.turri.<stack>.yaml`.
-2. Run `validate` on each, and fix only what stops it parsing - with the file tools, while nothing
-   is built from it yet, otherwise with `write_spec_diff`.
-3. Make sure a build can start: the unit testing script (and, with conformance tests on, the
-   conformance testing script) turri finds. When one is missing, write it by following the
-   `implement-unit-testing-script` (or `implement-conformance-testing-script`) skill, for the stack the
-   spec's implementation reqs name. The static checks - formatter, linter, type checker - are part of
-   the unit testing script, as that skill writes it.
+1. Find the spec: the `.plain` file(s) the user named, or the project's modules. Read them whole, with their `import` and `requires` chains, and the project's `config.turri.yaml` (or the old `config.yaml`, when there is no `config.turri.yaml`) and each stack's `config.turri.<stack>.yaml`.
+2. Run `validate` on each, and fix only what stops it parsing - with the file tools, while nothing is built from it yet, otherwise with `write_spec_diff`.
+3. Make sure a build can start: the unit testing script (and, with conformance tests on, the conformance testing script) turri finds. When one is missing, write it by following the `implement-unit-testing-script` (or `implement-conformance-testing-script`) skill, for the stack the spec's implementation reqs name. The static checks - formatter, linter, type checker - are part of the unit testing script, as that skill writes it.
 
 Say in two lines what will be rendered, and go on.
 
@@ -75,41 +54,16 @@ Say in two lines what will be rendered, and go on.
 Run cycles until the goal is met - or you are stuck - and at most twenty. Each cycle:
 
 1. **Check the goal**: `drift` for every module. All fully regenerated: the goal is met - go to the report.
-2. **Regenerate what is not regenerated**: `regenerate` for each module that is not - one that requires
-   another after the one it requires, modules that share nothing together. A module with builds still
-   running or queued is left to them.
-3. **Watch**: `watch_jobs`. It comes back when a build struggles, when all have finished, or when its
-   time is up - then call it again.
-4. **When a build struggles**, read what it has been through - its change, its last stages, the end of
-   its output - and `spec_findings` for what the builds have recorded. Then judge:
-   - **The spec's to settle** - the spec is silent where the build needs a decision (a format, a
-     default, an error and its message, a limit, an order, an edge case); it reads two ways; two of
-     its specs conflict; a test and the code disagree over something the spec never said. Write what
-     the spec should say as a spec diff (below), then `halt` the struggling build - its `job_id`, and
-     as `reason` what the spec now says - and `regenerate`, so it is regenerated from the clarified spec, and go
-     to the next cycle.
-   - **Not the spec's** - a bug the agent is working through, a missing tool or package, a flaky
-     service, turri itself. Leave the build to it, note it for the report, and keep watching.
-     Stopping it would throw its work away for nothing.
-5. **When the builds finish**, read `spec_findings`, and write into the spec every assumption about
-   what the software does that a user, a caller or a test can see - as the build assumed it, unless
-   that is not what the spec meant - so the next build does not have to guess. An assumption about how
-   it is built inside - a library, a file layout, a name - stays out. A diagnosis that says the fix is
-   in the spec is written; one that says code, environment or turri is noted. Then the next
-   cycle: what failed, and what the new diffs changed, is rendered again.
-
-**Writing a fix.** A git diff of the `.plain` file(s), paths from the project root, a few lines of
-context, with `write_spec_diff`. One diff per concern - a functionality's missing rules together, a
-concept and what it means together - never one diff for everything. Put each where it belongs: a rule
-of one functionality into its functional spec, a policy for many into `***implementation reqs***`, a
-term into `***definitions***`, following `add-concept`, `add-functional-spec` and
-`add-implementation-requirement` for how it is written. Each diff is built as it is written: what is left
-to build is worked out again from the spec - only what it changes is rendered again.
-
-**When you are stuck, stop.** The same functionality struggling three times after you clarified the
-spec for it is not something the spec can settle: stop maturing it, and report it. Two cycles in a
-row with nothing newly built and nothing newly settled: stop, and report what is open. Twenty cycles:
-stop, and report.
+2. **Regenerate what is not regenerated**: `regenerate` for each module that is not - one that requires another after the one it requires, modules that share nothing together. A module with builds still running or queued is left to them.
+3. **Watch**: `watch_jobs`. It comes back when a build struggles, when all have finished, or when its time is up - then call it again.
+4. **When a build struggles**, read what it has been through - its change, its last stages, the end of its output - and `spec_findings` for what the builds have recorded. Then judge:
+   - **The spec's to settle** - the spec is silent where the build needs a decision (a format, a default, an error and its message, a limit, an order, an edge case); it reads two ways; two of its specs conflict; a test and the code disagree over something the spec never said. Write what the spec should say as a spec diff (below), then `halt` the struggling build - its `job_id`, and as `reason` what the spec now says - and `regenerate`, so it is regenerated from the clarified spec, and go to the next cycle.
+   - **Not the spec's** - a bug the agent is working through, a missing tool or package, a flaky service, turri itself. Leave the build to it, note it for the report, and keep watching. Stopping it would throw its work away for nothing.
+5. **When the builds finish**, read `spec_findings`, and write into the spec every assumption about what the software does that a user, a caller or a test can see - as the build assumed it, unless that is not what the spec meant - so the next build does not have to guess. An assumption about how it is built inside - a library, a file layout, a name - stays out. A diagnosis that says the fix is in the spec is written; one that says code, environment or turri is noted. Then the next cycle: what failed, and what the new diffs changed, is rendered again.
+
+**Writing a fix.** A git diff of the `.plain` file(s), paths from the project root, a few lines of context, with `write_spec_diff`. One diff per concern - a functionality's missing rules together, a concept and what it means together - never one diff for everything. Put each where it belongs: a rule of one functionality into its functional spec, a policy for many into `***implementation reqs***`, a term into `***definitions***`, following `add-concept`, `add-functional-spec` and `add-implementation-requirement` for how it is written. Each diff is built as it is written: what is left to build is worked out again from the spec - only what it changes is rendered again.
+
+**When you are stuck, stop.** The same functionality struggling three times after you clarified the spec for it is not something the spec can settle: stop maturing it, and report it. Two cycles in a row with nothing newly built and nothing newly settled: stop, and report what is open. Twenty cycles: stop, and report.
 
 ### report
 
@@ -117,10 +71,8 @@ A short account:
 
 - whether the goal was met - `drift` for every module, as it is now;
 - every cycle in a line: what was rendered, what struggled, what you did about it;
-- every decision you wrote into the spec - what it settles, what the spec now says, and the spec diff
-  job that renders it - with the ones where you chose between readings marked, for the user to check;
+- every decision you wrote into the spec - what it settles, what the spec now says, and the spec diff job that renders it - with the ones where you chose between readings marked, for the user to check;
 - what was not the spec's - code, environment, turri - with what the builds and diagnoses said;
 - what is still open, when you stopped before the goal.
 
-Then say that any further change is asked for in the conversation, as a spec diff: what is left to build
-is worked out again from the spec.
+Then say that any further change is asked for in the conversation, as a spec diff: what is left to build is worked out again from the spec.

package/genome/skills/spawn/SKILL.md

@@ -24,40 +24,21 @@ metadata:
 
 # Spawn
 
-Load the `***plain` syntax rules before writing anything - they are in the system prompt under
-`<plain-rules>`; read `genome/rules/<name>.md` for the full text of any rule you need to follow
-closely.
+Load the `***plain` syntax rules before writing anything - they are in the system prompt under `<plain-rules>`; read `genome/rules/<name>.md` for the full text of any rule you need to follow closely.
 
 ## Role
 
-Act as a `***plain` spec writer who decides. The only output is `.plain` specification files and
-the project's testing scripts and config - never code. Code is generated from the specs into
-`plain_modules/`, read-only; never write or edit it. Say everything in terms of specs: "I'll put
-this in the spec."
+Act as a `***plain` spec writer who decides. The only output is `.plain` specification files and the project's testing scripts and config - never code. Code is generated from the specs into `plain_modules/`, read-only; never write or edit it. Say everything in terms of specs: "I'll put this in the spec."
 
-The user tells you what they want, once, and which stack to build it on - or leaves that to you.
-Everything else is yours to choose, on best effort: the architecture, the tests, the features and
-their order, every rule a feature needs - and the stack, when the user leaves it to you. Choose what
-a careful engineer would for this intent - common, well supported, simple - and say what you chose.
-Never ask about any of the rest. The user corrects it afterwards in the conversation,
-where every change is a spec diff and the queued builds are reworked around it.
+The user tells you what they want, once, and which stack to build it on - or leaves that to you. Everything else is yours to choose, on best effort: the architecture, the tests, the features and their order, every rule a feature needs - and the stack, when the user leaves it to you. Choose what a careful engineer would for this intent - common, well supported, simple - and say what you chose. Never ask about any of the rest. The user corrects it afterwards in the conversation, where every change is a spec diff and the queued builds are reworked around it.
 
-Read what is already there first: an existing `.plain` file, `config.turri.yaml` (or the old
-`config.yaml`, with no `config.turri.yaml`), `template/`,
-`test_scripts/`. What the project already settled - a stack, a template, a testing script, a
-`conformance-tests:` decision - is kept, not chosen again.
+Read what is already there first: an existing `.plain` file, `config.turri.yaml` (or the old `config.yaml`, with no `config.turri.yaml`), `template/`, `test_scripts/`. What the project already settled - a stack, a template, a testing script, a `conformance-tests:` decision - is kept, not chosen again.
 
 ## Reference
 
 - Templates go in `template/`; import paths omit the `template/` prefix. Resources go in `resources/`.
-- Generated code lands in `plain_modules/<module>/code/`, conformance tests in
-  `plain_modules/<module>/tests/` (both read-only).
-- One module, unless the intent needs two stacks - a web frontend and an API backend. Then two
-  modules side by side, neither requiring the other, sharing what they both mean through one
-  imported module in `template/`. Each is on a stack of its own, whose testing scripts are named in
-  `config.turri.<stack>.yaml` beside `config.turri.yaml` (`unittests-script:`, `conformance-tests-script:`) -
-  `config.turri.backend.yaml`, `config.turri.frontend.yaml`. A stack is chosen, never worked out: tell the
-  user to choose one with `/stack <stack>` (`--stack <stack>` on the command line) before building its part.
+- Generated code lands in `plain_modules/<module>/code/`, conformance tests in `plain_modules/<module>/tests/` (both read-only).
+- One module, unless the intent needs two stacks - a web frontend and an API backend. Then two modules side by side, neither requiring the other, sharing what they both mean through one imported module in `template/`. Each is on a stack of its own, whose testing scripts are named in `config.turri.<stack>.yaml` beside `config.turri.yaml` (`unittests-script:`, `conformance-tests-script:`) - `config.turri.backend.yaml`, `config.turri.frontend.yaml`. A stack is chosen, never worked out: tell the user to choose one with `/stack <stack>` (`--stack <stack>` on the command line) before building its part.
 
 ## Steps
 
@@ -65,99 +46,33 @@ Read what is already there first: an existing `.plain` file, `config.turri.yaml`
 
 Find out what the user wants to build - the only thing you ask about.
 
-If what the user has already said answers it, do not ask again. Otherwise ask one open question with
-`ask_user` and `free_form: true`: what should it do, and for whom? Ask at most two follow-ups, and
-only when the answer leaves open something that changes what gets built - what kind of software it
-is (a web app, an API, a CLI), or what the first version must do. Never ask about testing, structure
-or details: those are yours.
-
-Then the stack - the one technical question, because it has to be one this machine can build: the
-agents use its toolchains and install none, so a Go project on a laptop without Go stops at its first
-build. `<toolchains on this machine>`, in your instructions, says which languages it can build now.
-When the user already named a stack - a language, a framework - take it; when it is in a language the
-machine lacks, say what to install first and that `turri doctor` checks it, and ask whether to wait for
-that or choose another. Otherwise ask one `ask_user` question: first `You choose`, then the standard
-library's stacks for the kind of software it is (the stdlib rule, in `<plain-rules>`, lists them - for
-an API the backend stacks, for a command-line tool the CLI ones) - only those in a language the machine
-can build now; the "Something else…" that `ask_user` adds takes a stack of the user's own. A product of two kinds - a web app and its API - is one question a module. `You choose` leaves it
-to you, as the groundwork step says.
-
-Then state the brief back in five short bullets - the problem, the primary user, what they can do
-with it, what makes the first version useful, and what the first version leaves out - with the stack
-in a line under them (the user's, or `chosen when it is built` when it is left to you) - and ask one
-`ask_user` question with the options `Build it` and `Change something`, the brief passed whole as its
-`context`: the dialog shows only the question, its options and its `context`. On a change, fold it in and
-ask again. Write nothing to disk in this step.
+If what the user has already said answers it, do not ask again. Otherwise ask one open question with `ask_user` and `free_form: true`: what should it do, and for whom? Ask at most two follow-ups, and only when the answer leaves open something that changes what gets built - what kind of software it is (a web app, an API, a CLI), or what the first version must do. Never ask about testing, structure or details: those are yours.
+
+Then the stack - the one technical question, because it has to be one this machine can build: the agents use its toolchains and install none, so a Go project on a laptop without Go stops at its first build. `<toolchains on this machine>`, in your instructions, says which languages it can build now. When the user already named a stack - a language, a framework - take it; when it is in a language the machine lacks, say what to install first and that `turri doctor` checks it, and ask whether to wait for that or choose another. Otherwise ask one `ask_user` question: first `You choose`, then the standard library's stacks for the kind of software it is (the stdlib rule, in `<plain-rules>`, lists them - for an API the backend stacks, for a command-line tool the CLI ones) - only those in a language the machine can build now; the "Something else…" that `ask_user` adds takes a stack of the user's own. A product of two kinds - a web app and its API - is one question a module. `You choose` leaves it to you, as the groundwork step says.
+
+Then state the brief back in five short bullets - the problem, the primary user, what they can do with it, what makes the first version useful, and what the first version leaves out - with the stack in a line under them (the user's, or `chosen when it is built` when it is left to you) - and ask one `ask_user` question with the options `Build it` and `Change something`, the brief passed whole as its `context`: the dialog shows only the question, its options and its `context`. On a change, fold it in and ask again. Write nothing to disk in this step.
 
 ### groundwork
 
-Set up everything the first build needs, on your own, with the ordinary file tools - no questions,
-nothing built, and `write_spec_diff` not used.
-
-1. **The module and its stack.** Create the `.plain` file (and the template, when it helps), with
-   its frontmatter, and write the stack into `***implementation reqs***`: the language, the
-   framework, storage, the architecture and layout - one requirement per fact, at the right scope,
-   the shared ones on the template. The stack is the user's, when they named or chose one; left to
-   you, choose what fits the intent - a mainstream stack, with the fewest moving parts - in a language
-   this machine can build now (`<toolchains on this machine>`). Follow
-   `genome/rules/impl-reqs.md`. When the standard library has a template
-   for it - a backend, a frontend, a command-line tool or a library (the stdlib rule, in `<plain-rules>`) -
-   import that template and write only what the module needs beyond it.
-2. **Unit tests.** A `:UnitTests:` requirement - the framework, and how they are run - unless the
-   imported stack already sets it, and the unit testing script, for the stack's test framework. Keep one turri already finds (named in `config.turri.yaml`, or the one
-   `run_unittests*.sh` in the root or `test_scripts/`); otherwise write
-   `test_scripts/run_unittests_<language>.sh` by following the `implement-unit-testing-script`
-   skill. Never link it from the specs. The script runs the stack's static checks with the unit
-   tests - the formatter in check mode, the linter, the type checker - and they count as the tests do.
-3. **Conformance tests: off**, so each feature is built fast. Keep a `conformance-tests:` decision
-   the project's config already holds - `config.turri.yaml`, or the old `config.yaml`. Otherwise write `conformance-tests: false` into
-   `config.turri.yaml`, changing nothing else in it - a project with only a `config.yaml` has it copied
-   to `config.turri.yaml` first, and `config.yaml` is never written - and write no `***test reqs***`, import no standard library
-   conformance template, and write no conformance testing script.
-   Only when the user asked for conformance tests, turn them on instead: `conformance-tests: true`,
-   the `***test reqs***` - `:ConformanceTests:` requirements for the framework, how the tests reach
-   the software (a subprocess, HTTP against a server they start, the public entry point), setup and
-   outside services, and the command that runs the suite, following `genome/rules/test-reqs.md`, or
-   the stack's standard library conformance template imported when the stack is from it -
-   and `test_scripts/run_conformance_tests_<language>.sh`, by following the
-   `implement-conformance-testing-script` skill, unless turri already finds one.
-
-Run `validate` on every module you wrote, and fix what it finds. Then say in a few lines what you
-chose - the stack, the architecture, the tests - and carry on. Do not ask for confirmation.
+Set up everything the first build needs, on your own, with the ordinary file tools - no questions, nothing built, and `write_spec_diff` not used.
+
+1. **The module and its stack.** Create the `.plain` file (and the template, when it helps), with its frontmatter, and write the stack into `***implementation reqs***`: the language, the framework, storage, the architecture and layout - one requirement per fact, at the right scope, the shared ones on the template. The stack is the user's, when they named or chose one; left to you, choose what fits the intent - a mainstream stack, with the fewest moving parts - in a language this machine can build now (`<toolchains on this machine>`). Follow `genome/rules/impl-reqs.md`. When the standard library has a template for it - a backend, a frontend, a command-line tool or a library (the stdlib rule, in `<plain-rules>`) - import that template and write only what the module needs beyond it.
+2. **Unit tests.** A `:UnitTests:` requirement - the framework, and how they are run - unless the imported stack already sets it, and the unit testing script, for the stack's test framework. Keep one turri already finds (named in `config.turri.yaml`, or the one `run_unittests*.sh` in the root or `test_scripts/`); otherwise write `test_scripts/run_unittests_<language>.sh` by following the `implement-unit-testing-script` skill. Never link it from the specs. The script runs the stack's static checks with the unit tests - the formatter in check mode, the linter, the type checker - and they count as the tests do.
+3. **Conformance tests: off**, so each feature is built fast. Keep a `conformance-tests:` decision the project's config already holds - `config.turri.yaml`, or the old `config.yaml`. Otherwise write `conformance-tests: false` into `config.turri.yaml`, changing nothing else in it - a project with only a `config.yaml` has it copied to `config.turri.yaml` first, and `config.yaml` is never written - and write no `***test reqs***`, import no standard library conformance template, and write no conformance testing script. Only when the user asked for conformance tests, turn them on instead: `conformance-tests: true`, the `***test reqs***` - `:ConformanceTests:` requirements for the framework, how the tests reach the software (a subprocess, HTTP against a server they start, the public entry point), setup and outside services, and the command that runs the suite, following `genome/rules/test-reqs.md`, or the stack's standard library conformance template imported when the stack is from it - and `test_scripts/run_conformance_tests_<language>.sh`, by following the `implement-conformance-testing-script` skill, unless turri already finds one.
+
+Run `validate` on every module you wrote, and fix what it finds. Then say in a few lines what you chose - the stack, the architecture, the tests - and carry on. Do not ask for confirmation.
 
 ### product
 
 Write the product, feature by feature, as spec diffs - on your own, without asking.
 
-1. **Plan the features** from the brief, in build order: the smallest useful thing first, then
-   what builds on it, up to what the first version must do - and nothing it leaves out. Each
-   feature is one functional spec a render can build in one go (well under 200 lines of code),
-   language-agnostic, and explicit about its interface where it has one. A feature too big for
-   that is two.
-2. **The description first.** A one-sentence product description in the frontmatter, as the first
-   spec diff.
-3. **Then one spec diff per feature**, in order, holding everything that feature needs across
-   sections: the concepts it introduces, into `***definitions***` - defined in the same change as
-   the functional spec that first uses them, following `add-concept`; a technology-free policy it
-   states, into `***implementation reqs***`; and its functional spec, following
-   `add-functional-spec`. Decide its edge cases, validation rules and permissions yourself, the way
-   the intent implies, and write them into the spec.
-4. **Write each with `write_spec_diff`** - a git diff of the `.plain` file(s): `diff --git
-   a/<file> b/<file>`, `--- a/<file>`, `+++ b/<file>`, then the hunks with a few lines of context,
-   paths from the project root. It applies the change and queues its render spec diff job - with
-   conformance on, its conformance tests follow it. Go straight on to the next feature -
-   never wait for a build. Never change a `.plain` file in this step by any other means.
-
-The step is done only once every feature you planned is written, one spec diff each. Never stop
-part-way to ask whether to go on, or which feature comes next: nobody answers in this step, and the
-skill ends when your turn does - so a question here leaves the product unwritten.
-
-Correct a change you find wrong once written with a diff and `fixes_earlier`, never by editing the
-file.
-
-End with the handover, in a few lines: the features in build order, the jobs they were queued as,
-that conformance tests are off unless they were asked for (turning them on later is one line in
-`config.turri.yaml`, `conformance-tests: true`, with the test reqs and the script added in the
-conversation), and what the user can do now - try each feature as its build lands (ask to try it, and the chat
-deploys it), and ask for any change in the conversation. A feature added, changed or dropped is one
-spec diff, and what is left to build is worked out again from the spec.
+1. **Plan the features** from the brief, in build order: the smallest useful thing first, then what builds on it, up to what the first version must do - and nothing it leaves out. Each feature is one functional spec a render can build in one go (well under 200 lines of code), language-agnostic, and explicit about its interface where it has one. A feature too big for that is two.
+2. **The description first.** A one-sentence product description in the frontmatter, as the first spec diff.
+3. **Then one spec diff per feature**, in order, holding everything that feature needs across sections: the concepts it introduces, into `***definitions***` - defined in the same change as the functional spec that first uses them, following `add-concept`; a technology-free policy it states, into `***implementation reqs***`; and its functional spec, following `add-functional-spec`. Decide its edge cases, validation rules and permissions yourself, the way the intent implies, and write them into the spec.
+4. **Write each with `write_spec_diff`** - a git diff of the `.plain` file(s): `diff --git a/<file> b/<file>`, `--- a/<file>`, `+++ b/<file>`, then the hunks with a few lines of context, paths from the project root. It applies the change and queues its render spec diff job - with conformance on, its conformance tests follow it. Go straight on to the next feature - never wait for a build. Never change a `.plain` file in this step by any other means.
+
+The step is done only once every feature you planned is written, one spec diff each. Never stop part-way to ask whether to go on, or which feature comes next: nobody answers in this step, and the skill ends when your turn does - so a question here leaves the product unwritten.
+
+Correct a change you find wrong once written with a diff and `fixes_earlier`, never by editing the file.
+
+End with the handover, in a few lines: the features in build order, the jobs they were queued as, that conformance tests are off unless they were asked for (turning them on later is one line in `config.turri.yaml`, `conformance-tests: true`, with the test reqs and the script added in the conversation), and what the user can do now - try each feature as its build lands (ask to try it, and the chat deploys it), and ask for any change in the conversation. A feature added, changed or dropped is one spec diff, and what is left to build is worked out again from the spec.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.1.4-next.5a94e68",
+  "version": "0.1.4-next.8254fbc",
   "license": "MIT",
   "type": "module",
   "repository": {