@turri-dev/cli 0.1.25-next.d0c7575 → 0.1.25-next.fb3566e

package/genome/skills/brood/SKILL.md

@@ -1,129 +0,0 @@
----
-name: brood
-description: start a new project through an interview, built as you answer.
-allowed-tools: [read, write, edit, bash, ls, grep, find, change_plain]
-metadata:
-  # Started only by the person, with its command - /brood - never by the model on its own.
-  command-only: true
-  # What each phase does, in a line - shown under the skill's progress while it runs.
-  phases:
-    intent: "what problem this solves, for whom, and how you will know it works"
-    stack: "the language, frameworks, storage and architecture"
-    testing: "whether there are conformance tests, and how they are written and run"
-    product: "the product, feature by feature - each answer starts a regenerate pulse"
-  # The phases the questioning level caps, asked by the harness as the first question: light 3,
-  # medium 5, thorough 10, best judgement as many as turri judges the phase needs.
-  questioning: [stack, product]
-  # Every answer in the product phase is a spec change: the next question waits until it is
-  # written with change_plain. Changes turri decides itself need no answer before them.
-  change-plain-per-answer: [product]
----
-
-# Brood
-
-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 quote or follow closely.
-
-## Role
-
-Act as a `***plain` spec writer. The only output is `.plain` specification files — never code. Code is generated from the specs and lives in `plain_modules/` as a read-only artifact; never write or edit it. Frame every message to the user in terms of specs: "I'll add this to the spec," "Let me change the spec to fix that." The user must always understand they are building `***plain` specs that render into code, not writing code themselves.
-
-In the product phase, every change you make to the specs is a **spec diff**: a git diff of the `.plain` files, written with `change_plain`, which applies it and starts building it. The spec diffs are the output of the interview; the builds follow from them.
-
-The testing phase is the exception: it changes only `***test reqs***`, and comes before anything is built, so it writes them with the ordinary file tools and never with `change_plain`. It comes before the product phase so that every spec change the product phase writes is conformance tested as it is built: with conformance on, each build writes and runs the change's conformance tests, and keeps every earlier one passing.
-
-## Phase discipline
-
-**Finish each phase — its specs on disk and the user's confirmation given — before starting the next.** Do not draft, or even ask about, later-phase content while a phase is open: if an answer drifts ahead, acknowledge it briefly, note it for later, and steer back.
-
-When entering a phase, read its reference file and walk its topics **in order**. Skip a topic only if it genuinely does not apply, and say so explicitly.
-
-Between phases — and only between phases — summarize what was written and get one explicit confirmation before continuing. That single confirmation replaces per-change approval; do not ask for both. Do not ask the user to approve each spec change: they are answering questions, not running a review queue. After each change, say in one line what went into the spec, and carry straight on.
-
-## How many questions
-
-The first question of the intent phase is the harness's own, not yours: how many questions the **stack** and **product** phases may ask. The person picks one level, and it holds for each of them. The level sets how many questions there are and so how broad each is - never what they cover:
-
-| level | questions a phase | each question |
-| --- | --- | --- |
-| light | at most 3 | broad: a whole area at once - the features and their order, what the product does end to end - with what fits the brief proposed, for the person to confirm or correct |
-| medium | at most 5 | one feature or topic, with its main rules |
-| thorough | at most 10 | narrow: one feature, rule or edge case, with follow-ups on the ones that matter |
-| best judgement | as many as you judge the phase needs | as broad or as narrow as each area needs |
-
-At every level the questions reach all of the phase's topics; fewer questions only go less deep. The intent and testing phases are not capped. Follow-ups count; the closing confirmation of a phase - asked with `confirms_phase: true` - does not. Past the cap `ask_user` refuses the question. To stop sooner, or under best judgement once the phase is settled enough to build, call `end_questions`.
-
-The level limits the questions, never the spec changes. In the product phase **every answer is a spec change**, whatever the level: written with `change_plain` and built at once, before the next question - `ask_user` refuses the next one until it is. A broad answer that covers several features is several changes, one a feature, and you write them all. What the questions leave open - the details of a light answer, what is left once they are over - is yours to decide, as a careful engineer would, in the light of the intent brief: each decision a spec change of its own, written with `change_plain` with no answer needed before it, and said in one line. Write as many as the product needs. The phase's summary names every decision you made yourself, so the confirmation is where the person can change it.
-
-## Question style
-
-- Ask with `ask_user`, one question per call, and always pass `options` so the user picks rather than types; reserve `free_form: true` for genuinely open prompts.
-- Shape every question so any plausible answer maps directly to one spec change.
-- Prefer short, direct sentences over compound or nested clauses, and plain words over jargon.
-- Never drop detail to simplify — keep every constraint, edge case, option, and piece of context the user needs to answer accurately, splitting into more sentences instead.
-
-## Reference
-
-- Templates go in `template/`, but import paths omit the `template/` prefix. Resources go in `resources/`.
-- Generated code lands in `plain_modules/<module>/code/` and generated conformance tests in `plain_modules/<module>/tests/` (both read-only, never edit).
-
-## Steps
-
-### intent
-
-The harness has asked how many questions the stack and product phases may ask before this phase starts; its note beside these instructions gives the answer. Do not ask it again.
-
-Read `references/intent.md` and ask its five core questions one at a time via `ask_user`. Ask at most one focused follow-up when an answer is too vague to summarize.
-
-Write nothing to disk in this phase — no project files, no specification files. Keep entities, features, technology and testing for the phases that own them.
-
-Summarize the problem, the primary user, the desired outcome, the observable success criterion, and the initial boundary with its explicit exclusions. Get explicit confirmation of that brief - the bullets passed whole as `ask_user`'s `context`, which the dialog shows above the question - and carry it into every later phase.
-
-This phase ends on the user's confirmation.
-
-### stack
-
-**This comes before any functionality, so that every spec change in the product phase can be built the moment it is written.** A functionality cannot be rendered without knowing the language it is written in and the framework its tests use.
-
-Read `references/stack.md` and walk its topics in order, within the questioning level (see "How many questions"): language, frameworks, storage, external services, structure and architecture, other constraints, anything else, and last the unit tests - generated code needs them from the first functionality onward.
-
-Offer the standard library's stacks first, those in a language this machine can build now (the stdlib rule, in `<plain-rules>`, `<toolchains on this machine>`, and the first section of `references/stack.md`): a stack from it is one import, and only what it leaves open - storage, external services, other constraints - is asked and written.
-
-Create the module structure and frontmatter so there is a `.plain` file to build into, and author every requirement into `***implementation reqs***` at the right scope — shared requirements into the template, module-specific ones into the module. Write these with the ordinary file tools; **nothing is built in this phase**, and `change_plain` is not used here.
-
-Write no definitions, no functional specs, no `***test reqs***` and no `***acceptance tests***`.
-
-End the phase with the unit tests: their framework, as a `:UnitTests:` requirement, and the unit testing script, which every build needs from the first one on. If turri already finds a script - named by `unittests-script:` in `config.turri.yaml` at the project root, or the one `run_unittests*.sh` in the root or in `test_scripts/` - keep it. Otherwise write `test_scripts/run_unittests_<language>.sh` with the `implement-unit-testing-script` skill, for the language and framework just settled. Do not link it from the specs. Without it, every build stops before it starts. When this module sits in a project beside another on a different stack - a frontend beside a backend, sharing only an imported module - its script is its stack's: name it in that stack's `config.turri.<stack>.yaml` beside `config.turri.yaml` (`unittests-script:`) - `config.turri.frontend.yaml` for the stack `frontend` - not in `config.turri.yaml`, which is the project's and holds what the stacks share. Name the stack after this module - `config.turri.frontend.yaml` for `frontend.plain` - and it is built with it by itself, with nothing to choose. A stack the project already has under another name is passed as `stack` to `change_plain`.
-
-The unit testing script runs the static checks too - the formatter, linter and type checker the stack names, which count as the unit tests do; `implement-unit-testing-script` says which for each language. There is no separate static checks script.
-
-Run `turri validate` on the module before finishing, so the product phase does not start on top of a file that does not parse.
-
-Finish by summarizing the stack, the architecture, the unit testing script and the static checks it runs - marking each choice you made without asking - and getting explicit confirmation, with `confirms_phase: true`. The user reading the stack back is the check.
-
-### testing
-
-Read `references/testing.md`. Carry the intent brief and the stack in; ask about neither again. Walk its topics in order. Nothing is built yet, and nothing is built in this phase.
-
-First the decision: are there conformance tests at all? Ask it explicitly - even when `config.turri.yaml` already says, ask, offering what it says first - and write the answer to `config.turri.yaml` as `conformance-tests:` - the chat and every build follow it. A project with only a `config.yaml` has it copied to `config.turri.yaml` first; never write `config.yaml`. Off, and the phase is done once the user confirms: the product phase's builds then write and run no conformance tests.
-
-On: when the stack came from the standard library, import its conformance template (`stdlib/<kind>/conformance/<stack>`) and ask only about what it does not settle. Each answer about how the tests are written and run becomes a `:ConformanceTests:` requirement in `***test reqs***`, written with the ordinary file tools. A change to the test reqs is not a spec diff: never use `change_plain` in this phase. Then make sure the project has its conformance testing script - `implement-conformance-testing-script` writes it into `test_scripts/` when turri finds none - and run `validate` on what you changed. Without both, the first build of the product phase stops before it starts.
-
-Finish by summarizing the decision, the test reqs and the script, and saying that from the first spec change on, every build writes and runs its conformance tests. Get explicit confirmation.
-
-### product
-
-Read `references/product.md`. Carry the intent brief, the stack and the testing decisions in; restart none of them. This is the whole product interview, walked **feature by feature** - never section by section. Do not fill in the definitions first and the functional specs after: that is not this skill.
-
-Walk its topics in order, and run this loop while the questioning level allows (see "How many questions") - each question as broad as the level says:
-
-1. **Ask** one question with `ask_user` - about a feature, a step of a flow, a rule; never about a spec section.
-2. The user **answers**.
-3. **Make the spec change** the answer calls for, as one git diff of the `.plain` files - across every section it needs: the concepts it introduces, a policy it states, the functional spec it adds or changes.
-4. **Write it with `change_plain`**, which applies it and starts a render spec diff job for it, whatever it touches. With conformance on, that build also writes and runs the change's conformance tests. An answer that covers several features is a change for each: write them all. Then the changes for what you decide yourself around it, if any.
-5. Move straight on to the next question; never wait for a build.
-
-Every answer, at least one spec change and one render spec diff job, written before the next question - at every level. Once the questions are over, write what is left of the product the same way - one decision of yours, one spec change - with no answer between. Correct something already written with a diff and `fixes_earlier`, before the next question. Never change a `.plain` file in this phase by any other means than `change_plain`.
-
-Report each build result between questions, in one sentence. Use `drift` when the user asks how the builds are going.
-
-Finish by summarizing the concepts and the features in build order, marking what you decided without asking, saying what is built and what is still queued, getting explicit confirmation with `confirms_phase: true`. The summary is for the person to take in at a glance: a line a feature, a few words a concept, each decision you made yourself in a few words - about fifteen lines at most, never the specs' wording or every rule; they are in the spec.

package/genome/skills/brood/references/intent.md

@@ -1,27 +0,0 @@
-# the intent phase — What is the intent?
-
-Extract the user's intent before creating files or decomposing the product into specifications. Keep this phase short. Ask exactly five core questions, one at a time, and do not write to disk.
-
-The harness has already asked the first question of this phase: how many questions the stack and product phases may ask - light (3), medium (5), thorough (10) or best judgement. Do not ask it again; this phase's own questions are not capped by it.
-
-## Questions
-
-1. **Problem** — What problem should this software solve?
-2. **Primary user** — Who is it mainly for?
-3. **Desired outcome** — What should that user be able to accomplish with it?
-4. **Success criterion** — What observable result would make the first version useful?
-5. **Initial boundary** — What should the first version deliberately leave out?
-
-Ask one focused follow-up only when an answer is too vague to summarize. Do not explore features, entities, technology, architecture, or testing yet; those belong to later phases.
-
-## Intent brief
-
-Summarize the answers in five short bullets:
-
-- Problem
-- Primary user
-- Desired outcome
-- Observable success criterion
-- Initial boundary and explicit exclusions
-
-Ask the user to confirm or correct the brief with one `ask_user` question, the five bullets passed whole as its `context` - the dialog shows only the question, its options and its `context`. The intent phase finishes only after explicit confirmation. Carry the confirmed brief into the stack and product phases so their questions refine it instead of restarting intent discovery.

package/genome/skills/brood/references/product.md

@@ -1,49 +0,0 @@
-# the product phase — What does it do?
-
-The whole product interview, in one phase, walked **feature by feature** - not section by section. There is no pass that fills in the definitions and then another that writes the functional specs. Each question is about the product: a feature, a step in a flow, a rule. Its answer becomes one spec change that touches whatever sections that answer needs - the concepts the feature introduces, a policy it needs, its functional spec - and every spec change is built the moment it is written.
-
-Carry the confirmed intent brief and the settled stack in. Do not restart either.
-
-## How many questions
-
-The questioning level caps this phase's questions (light 3, medium 5, thorough 10, or best judgement - `SKILL.md`, "How many questions"), and so sets how broad each is. Every level walks all the topics below: light in a few broad questions - the features and their order in one, what they do end to end in another, with what fits the brief proposed for the person to confirm or correct; thorough in narrow ones, a feature, rule or edge case each. The level limits the questions, never the spec changes:
-
-- **Every answer is a spec change**, at every level: written with `change_plain` and built at once, before the next question - `ask_user` refuses the next question until it is. A broad answer covering several features is a change for each.
-- **What the questions leave open is yours** - the details under a broad answer, and everything still open once the questions are over (the cap reached, or `end_questions` called). Each feature, edge case and rule you decide is its own spec change, written with `change_plain` with no answer needed before it, and said in one line. Write as many as the product needs. Decide from the intent brief and the answers so far; leave out what they do not call for rather than invent scope.
-
-## One question, one answer, a spec change, a render
-
-Every iteration is exactly this, at every questioning level:
-
-1. **Ask one question** with `ask_user`, about the product: a feature, its trigger and outcome, one of its edge cases or rules, the next step of a flow - as broad as the level says. Never bundle two, and never ask about a spec section ("what concepts are there?", "what reqs apply?") - ask about what the product does, and let the answer decide which sections change.
-2. **Turn the answer into a spec change** - one for each feature it covers - everything it calls for, across sections:
-   - a concept the feature introduces, into `***definitions***`, following `definitions.md`, defined in the same change as the functional spec that first uses it;
-   - a technology-free policy the answer states, into `***implementation reqs***`;
-   - the functional spec for the feature, or the change to one already written, following `func-specs.md` - its wording, and the checks of *Adding a functional spec*. Write it as 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 unchanged context. Paths are relative to the project root.
-3. **Write it with `change_plain`.** It applies the diff and starts a render spec diff job for it in the same call - whatever the change touches, a definition alone included. Write every change the answer calls for before the next question - `ask_user` refuses it until then - and any you decide yourself beside them. Move straight on to the next question; never wait for a build.
-
-**One answer, at least one change.** A follow-up about the same feature - an edge case, a validation rule - is its own answer and its own change to that feature's spec. An answer that describes two features is two changes, both written before the next question. A change never carries both an answer and something you decided: what you decide is a change of its own.
-
-**Fix contradictions in place.** When a later answer refines or contradicts something already written, write the correction as its own diff with `fixes_earlier` set, before the next question. It is rendered like any other change.
-
-**Never edit the `.plain` files with `write` or `edit` in this phase.** A change that does not go through `change_plain` is a change nothing renders.
-
-## What a change may contain
-
-- **`***definitions***`** - the concepts the change needs, each defined before, or in the same change as, what first uses it.
-- **`***functional specs***`** - at most one new functionality per change: ≤200 lines of code change, language-agnostic, in chronological build order, externally explicit where it has an interface.
-- **`***implementation reqs***`** - only technology-free policy: an error-handling or retry policy, an ordering guarantee, a data-format rule. The technology was settled in the stack phase; an answer that needs a new technology is a stack answer - note it and steer back.
-
-Leave the `***test reqs***` as the testing phase wrote them, and write no `***acceptance tests***`. With conformance on, every change is built with its conformance tests - from the test reqs as they stand.
-
-## Topics (in order)
-
-1. **Product description** - propose a one-sentence description from the confirmed intent brief, state it back in one line, and write it into the frontmatter as the first change.
-2. **Features, one at a time, in build order** - the smallest thing that is useful first, then what builds on it. For each feature: one question for what triggers it and what comes out, then one per edge case, validation rule or permission that is not obvious. Each answer is a change: the first brings the feature's concepts and its functional spec; the follow-ups refine them. A feature too large for one functional spec is split *with the user* - that is the next question.
-3. **User flows** - walk the product from the user's side: what happens first, what next, and at each decision point. Each missing step is a feature, taken the same way.
-4. **User interface (optional)** - skip entirely if there is none. Otherwise per screen or interaction: what the user sees and what it does, still language- and framework-agnostic.
-5. **Anything else** - anything the user wants to add or change that has not been covered.
-
-## Reporting builds
-
-Report each build result between questions, in one sentence. A failed build does not stop the interview - note it and carry on, unless it shows the spec itself is wrong, in which case fix the spec with a diff and `fixes_earlier`.

package/genome/skills/brood/references/stack.md

@@ -1,39 +0,0 @@
-# the stack phase — What technologies should it use?
-
-Gather the technical stack **and** the project's structure/architecture. This phase affects only `***implementation reqs***`, and ends with the unit testing script every build needs — the rest of testing comes later. Run the core loop from `SKILL.md` for each topic below, in order: ask, then write the requirement into the `.plain` file with the ordinary file tools. Nothing is built in this phase. When the user has no preference, propose a sensible default that fits earlier answers and ask them to confirm.
-
-The questioning level caps this phase's questions (light 3, medium 5, thorough 10, or best judgement - `SKILL.md`, "How many questions"), and so sets how broad each is. Every level reaches all the topics, in order: light in a few broad questions - the stack, say, then storage and outside services together, then the remaining constraints, each with what fits the brief proposed; thorough a topic or two a question, with follow-ups. Every topic left unasked once the questions are over gets the default that fits the intent brief and the answers so far, written as a requirement like any other and named as your choice in the closing summary. The unit testing script is written whatever the level.
-
-## Author target for this phase
-
-Write each requirement into `***implementation reqs***`:
-
-- Shared, stack-wide reqs (language, framework, architecture, coding standards) go on the template module if one exists.
-- Module-specific reqs (e.g. a data-storage choice or an external integration only one module uses) go on the module that needs them.
-
-Do **not** add `***test reqs***` or `***acceptance tests***` in this phase — the test reqs belong to the testing phase, right after this one.
-
-## First: a stack from the standard library
-
-Before the topics, settle what kind of software each module is - a backend, a frontend, a command-line tool, a library - and offer the standard library's stacks for that kind (the stdlib rule, in `<plain-rules>`, lists them) that this machine can build: `<toolchains on this machine>`, in your instructions, says which languages it can build now. The agents use its toolchains and install none, so a stack in a language it lacks stops at its first build. Ask with `ask_user`: those stacks as options, the one that fits earlier answers first, and "Something else…" for a stack of the user's own. A stack the user names 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.
-
-- **A stack from the standard library.** Import it into the module's frontmatter as `stdlib/<kind>/<stack>`, and read the templates it brings: the stack, its `stdlib/lang/<language>` and its kind's `common` - the folder is in the stdlib rule. They settle topics 1, 2 and 5, error handling and logging in topic 6, and the unit-test framework in topic 8: do not ask about those, and write no requirement that restates them. Say in one line what the stack settles - its language, framework, layout, how it reports errors and logs - so the user knows what they chose. Then walk only topics 3, 4, 6 (what the stack leaves open), 7, and the unit testing script in 8.
-- **Something else.** Walk every topic below. When the language is one the standard library has, its `stdlib/lang/<language>` template can still be imported for the language-wide conventions.
-
-A user who wants something the stack settles done differently - another framework, another layout - has chosen something else: an import cannot be taken back in part.
-
-## Topics (in order)
-
-1. **Programming language** — e.g. Python, TypeScript, Java, Go. Author a language requirement at the appropriate scope (template if shared across modules, otherwise on the module). Review that requirement snippet.
-2. **Frameworks** — e.g. Flask, FastAPI, Next.js, Spring Boot, Express, React, Vue. Author framework requirement(s) and any framework-specific architectural conventions. Review the new framework reqs.
-3. **Data storage** — e.g. PostgreSQL, SQLite, file-based, in-memory, none. Author a storage requirement on the module that owns persistence (or the template if shared). Review that snippet.
-4. **External services or APIs** — anything the app talks to: auth providers, payment gateways, email/SMS, third-party APIs, internal services. Author one requirement per integration on the module that uses it. Review each integration snippet.
-5. **Project structure & architecture** — the architectural style and the layers/components the project should be organized into (managers, services, models, repositories, controllers, views, adapters, DTOs, …). Discuss naming conventions, directory layout, and the responsibilities/boundaries of each layer. If the user has no preference, propose a layout that fits the language, framework, and feature set, and confirm it. Author architecture/layering reqs in the template (if shared) and any module-specific deviations on the module. Review the architecture reqs and the resulting layer split.
-6. **Other constraints** — deployment target, OS requirements, performance needs, coding standards, security policies, observability — anything stack-wide that hasn't already been covered. Author each constraint as its own requirement at the appropriate scope. Review the new constraint snippets.
-7. **Anything else** — anything the user wants to add or change that hasn't already been covered.
-8. **Unit tests and their script** — last, once the stack is settled: the first build needs both.
-   - The unit-test framework, e.g. pytest, Jest, JUnit, Go's `testing` package. Suggest one that fits the language if the user has no preference. Author a `:UnitTests:` requirement in `***implementation reqs***` at the appropriate scope - e.g. "`:UnitTests:` should use pytest" plus how they are run. Review that snippet.
-   - The unit testing script. If turri already finds one - named by `unittests-script:` in `config.turri.yaml` at the project root (or in the stack's `config.turri.<stack>.yaml`, in a project whose parts are on different stacks), or the one `run_unittests*.sh` in the root or in `test_scripts/` - keep it. Otherwise generate `test_scripts/run_unittests_<language>.sh` (and any framework config it needs, e.g. `pytest.ini`) via `implement-unit-testing-script`. Do not link it from the specs. Without it, every build stops before it starts. Review the script's path and what it runs.
-   - The static checks, in that script: the formatter in check mode, the linter and the type checker the stack names, run with the unit tests and counting as they do - `implement-unit-testing-script` says which for each language. A unit testing script turri already finds that runs none is extended with them. There is no separate static checks script.
-
-When all topics are complete, summarize the full tech stack and the chosen architecture, and get an explicit overall confirmation before moving to the product phase.

package/genome/skills/brood/references/testing.md

@@ -1,25 +0,0 @@
-# the testing phase — How is what was built checked from the outside?
-
-Decide whether the project has conformance tests, and if it does, say in `***test reqs***` how they are written and run, and give it the script that runs them. This comes before the product phase, and nothing here is built: a change to the test reqs is not a spec diff, so it is written with the ordinary file tools, never `change_plain`. What is settled here is what every build of the product phase follows - with conformance on, each spec change is built with its conformance tests. Run the core loop for each topic below, in order: ask, then write. When the user has no preference, propose a default that fits the stack and the intent brief and ask them to confirm.
-
-Conformance tests are black-box tests written from the spec: for each functional spec, tests that run the built software from the outside - as a command, over HTTP, through its public entry point - and check it does what the spec says, kept apart from the spec's acceptance tests. The harness runs the whole suite after every spec change, so they catch one change breaking another. They cost time and tokens on every build.
-
-## Author target for this phase
-
-- `***test reqs***` - one `:ConformanceTests:` requirement per fact, on the template if one exists (shared by every module), otherwise on the module. Follow `genome/rules/test-reqs.md`.
-- `config.turri.yaml` at the project root - the `conformance-tests:` decision. Change only that key, and create the file if there is none; everything else in it stays as it is. When the project has only a `config.yaml`, copy it to `config.turri.yaml` first - and each `config.<name>.yaml` to `config.turri.<name>.yaml` - and write the copy: `config.yaml` may be another tool's, and is never written.
-- `test_scripts/` - the conformance testing script.
-
-Write no `***acceptance tests***`, no functional specs and no `***implementation reqs***` here.
-
-## Topics (in order)
-
-1. **Conformance on or off** - ask it explicitly, with what it costs and what it catches; it is a recorded decision, never an inference. Ask it even when `config.turri.yaml` already has `conformance-tests:` - offer what it says as the first option. Write it to `config.turri.yaml` as `conformance-tests: true` or `conformance-tests: false`. Off: say that no conformance tests will be written or run until it is turned on, and go to the end of the phase.
-2. **Framework** - e.g. pytest, JUnit, Jest, Go's `testing`; one that fits the stack. Author it as a `:ConformanceTests:` requirement.
-3. **How the tests reach the software** - as a subprocess of the CLI, over HTTP against a server the tests start, through the public entry point it exports. Author it.
-4. **Setup and outside services** - fixtures, test data, databases, third-party APIs: started for real, faked, or mocked at the boundary. Author each decision as its own requirement.
-5. **How the whole suite is run** - the one command that discovers every test. Author it.
-6. **The conformance testing script** - if turri already finds one (named by `conformance-tests-script:` in `config.turri.yaml`, or the one `run_conformance_tests*.sh` in the project root or in `test_scripts/`), check it runs the suite the way the test reqs now say, and keep it. Otherwise write `test_scripts/run_conformance_tests_<language>.sh` with `implement-conformance-testing-script`, to match the test reqs. Never link it from the specs. If `test_scripts/` would hold two of a kind, name the one to use in `config.turri.yaml`. In a project whose parts are on different stacks, name each stack's script in its own `config.turri.<stack>.yaml` (`conformance-tests-script:`), each stack named after the module it builds - `config.turri.backend.yaml` for `backend.plain` - so each part is built with its own by itself.
-7. **Anything else** - anything about testing the user wants to add or change.
-
-Run `validate` on every module you changed. The product phase's first build needs the test reqs and the conformance testing script both there: without them it stops before it starts.

package/genome/skills/bud/SKILL.md

@@ -1,104 +0,0 @@
----
-name: bud
-description: >-
-  Add a feature to an existing ***plain project the way `brood` builds one: it first asks how many
-  questions the product phase may ask - light, medium, thorough or best judgement, broader with
-  fewer - then a short feature-intent interview, then product questions - a trigger and its outcome,
-  an edge case, a rule - where every answer becomes a spec change, written as a git diff of the
-  .plain files and built the moment it is written, so the feature appears while the interview is
-  still going. What the questions leave open it decides itself, each decision a spec change of its
-  own. A change that touches what is already specified or being built is a spec diff too: what
-  is left to build is worked out again from the spec. Use when the user wants to add a
-  feature to an existing project. Not for starting a new project (use `brood`, or `spawn`
-  to start fast) or for editing generated code (the .plain specs are the source of truth).
-allowed-tools: [read, write, edit, bash, ls, grep, find, change_plain]
-metadata:
-  # Started only by the person, with its command - /bud - never by the model on its own.
-  command-only: true
-  # What each phase does, in a line - shown under the skill's progress while it runs.
-  phases:
-    intent: "what the feature is for, who it serves, and what it leaves out"
-    scope: "finds where the feature goes in the spec, and what is built already"
-    product: "the feature, question by question - each answer starts a regenerate pulse"
-  # The phase the questioning level caps, asked by the harness as the first question: light 3,
-  # medium 5, thorough 10, best judgement as many as turri judges the phase needs.
-  questioning: [product]
-  # Every answer in the product phase is a spec change: the next question waits until it is
-  # written with change_plain. Changes turri decides itself need no answer before them.
-  change-plain-per-answer: [product]
----
-
-# Bud
-
-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 adding one feature to specs that already exist - and, usually, to code already built from them, or being built. The only output is changes to `.plain` files, and every one of them is a **spec diff**: a git diff of the `.plain` files, written with `change_plain`, which applies it and queues its render spec diff job. Never write code, and never change a `.plain` file by any other means. Frame every message in terms of specs: "I'll add this to the spec."
-
-This is `brood`'s product phase, scoped to one feature, on top of what is there: the stack, the testing setup and every earlier feature are settled - read them, build on them, restart none.
-
-## How many questions
-
-The first question of the intent phase is the harness's own, not yours: how many questions the **product** phase may ask. The level sets how many questions there are and so how broad each is - never what they cover:
-
-| level | product questions | each question |
-| --- | --- | --- |
-| light | at most 3 | broad: the whole feature at once - what it does end to end, its main rules - with what fits the brief proposed, for the person to confirm or correct |
-| medium | at most 5 | one part of the feature, with its main rules |
-| thorough | at most 10 | narrow: one trigger, rule or edge case, with follow-ups on the ones that matter |
-| best judgement | as many as you judge the feature needs | as broad or as narrow as each part needs |
-
-The intent phase is not capped. Follow-ups count; the closing confirmation - asked with `confirms_phase: true` - does not. Past the cap `ask_user` refuses the question. To stop sooner, or under best judgement once the feature is settled enough to build, call `end_questions`.
-
-The level limits the questions, never the spec changes. **Every answer is a spec change**, whatever the level: written with `change_plain` and built at once, before the next question - `ask_user` refuses the next one until it is. A broad answer that covers several behaviours is several changes, and you write them all. What the questions leave open - the details of a light answer, what is left once they are over - is yours to decide, as a careful engineer would, in the light of the brief: each decision a spec change of its own, written with `change_plain` with no answer needed before it, and said in one line. The closing summary names every decision you made yourself, so the confirmation is where the person can change it.
-
-## Question style
-
-- Ask with `ask_user`, one question per call, as broad as the level says, and pass `options` so the user picks rather than types - concrete choices, plus the free-form catch-all the tool adds. Reserve `free_form: true` for a genuinely open question.
-- Ask about the product - a trigger and its outcome, an edge case, a rule, a permission, a step of a flow - never about a spec section ("which concepts?", "what reqs?"). Let the answer decide which sections change.
-- Shape each question so any plausible answer maps to one spec change. Bad: "How should it work?" Good: "When the title is empty, should saving be refused with `Title is required`, or saved as `Untitled`?"
-- Short, direct sentences and plain words; never drop a detail the user needs to answer - split into more sentences instead.
-
-## Steps
-
-### intent
-
-The harness has asked how many questions the product phase may ask before this phase starts; its note beside these instructions gives the answer. Do not ask it again.
-
-Read `references/intent.md` and ask its five core questions one at a time with `ask_user`. Ask at most one focused follow-up when an answer is too vague to summarize. If what the user has already said answers a question, confirm it in one line instead of asking.
-
-Write nothing to disk. Summarize the feature-intent brief - motivation, affected user, desired outcome, observable success criterion, boundary and explicit exclusions - and get explicit confirmation, the brief passed whole as `ask_user`'s `context`, which the dialog shows above the question. Carry the brief into every later step.
-
-### scope
-
-Keep this short: enough to ask the first product question, not a design on paper.
-
-1. Find the `.plain` file(s) the feature belongs to, and read them whole, following their `import` and `requires` chains: every definition, implementation and test req, functional spec and acceptance test the feature will sit beside. Read `config.turri.yaml` (or the old `config.yaml`, when there is no `config.turri.yaml`) and the chosen stack's `config.turri.<stack>.yaml` for whether conformance tests are on.
-2. Ask which module only if it is genuinely ambiguous; otherwise do not.
-3. Look at what is built and queued (`drift`), so you know which specs already have code and which builds are still waiting - a change to either is still just a spec diff.
-
-Say in one line where the feature goes, and move on. Write nothing to disk.
-
-### product
-
-The feature, walked question by question. Run this loop while the questioning level allows (see "How many questions"):
-
-1. **Ask** one product question with `ask_user`.
-2. The user **answers**.
-3. **Make the spec change** the answer calls for, as one git diff of the `.plain` file(s) - across every section it needs:
-   - a concept it introduces, into `***definitions***` - written the way `definitions.md` says, and defined in the same change as the functional spec that first uses it;
-   - a policy it states - error handling, a retry, a data format, a library not already in the module or its imports - into `***implementation reqs***`, the way `impl-reqs.md` says;
-   - the functional spec it adds, or the change to one already written, the way `func-specs.md` says: its wording rules, its complexity check (`analyze-if-func-spec-too-complex` - at most 200 lines of code; a spec too big is split *with the user*, as the next question) and its conflict check (`analyze-func-specs`, over the new spec and every existing one in the chain). Follow those rules and skills for what the text is; the diff is the only thing that writes it.
-   - with conformance tests on - test reqs of the module's own or imported, and a conformance testing script turri finds - an acceptance test under its functional spec when the answer states one concrete verification (`func-specs.md`, *Acceptance tests*), and a test req only when the answer changes how conformance tests run (`test-reqs.md`). With conformance off, none. Write it as a git diff: `diff --git a/<file> b/<file>`, `--- a/<file>`, `+++ b/<file>`, then the hunks with a few lines of unchanged context, paths from the project root. A new functional spec goes where it belongs in build order - after what it builds on, usually at the end.
-4. **Write it with `change_plain` at once**, before anything else. It applies the diff and starts a render spec diff job for it; with conformance on, its conformance tests follow it. An answer that covers several behaviours is a change for each: write them all. Then the changes for what you decide yourself around it, if any. Say in one line what went into the spec - "added `:Note:` and functional spec 7" - and what became of the build, as the tool says, then ask the next question. Never wait for a build, and never ask the user to approve a change.
-
-**One answer, at least one change.** A follow-up about the same behaviour - an edge case, a validation rule - is its own answer and its own change. An answer that describes two behaviours is two changes, both written before the next question. A change never carries both an answer and something you decided: what you decide is a change of its own.
-
-**What already exists.** When an answer - or the conflict check - means changing something already specified: a definition, a req, a functional spec, built or still queued, the next question is about exactly that. Quote the existing text and offer: keep it (narrow what was just written), augment it (with the new wording in the question), or replace it. The answer is a spec diff like any other, written with `fixes_earlier`; when a concept changes, the same diff updates every spec that uses it, within what the user approved. Never rewrite earlier intent without asking. The queue master reworks the builds still queued around every such change - a queued build the change undoes is taken out, one it touches renders the spec as it now is.
-
-**Fix your own mistakes in place.** When a later answer refines or contradicts a change you wrote in this feature, write the correction as its own diff with `fixes_earlier`, before the next question.
-
-Once the questions are over - the cap reached, or `end_questions` called - write what is left of the feature the same way: one decision of yours, one spec change, with no answer between. Then run `validate` on every module the feature touched, and fix what it finds with a spec diff and `fixes_earlier`.
-
-Finish by summarizing the feature's spec changes in build order, marking what you decided without asking, saying what is built and what is still queued (`drift`), and getting explicit confirmation with `confirms_phase: true`. The summary is for the person to take in at a glance - a line a change, each decision you made yourself in a few words, about fifteen lines at most, never the specs' wording. Any further change is asked for in the conversation, each one a spec diff; the next feature starts again from the intent.

package/genome/skills/bud/references/intent.md

@@ -1,27 +0,0 @@
-# The intent step - what is the feature for?
-
-Extract the intent of this feature before choosing files or authoring specifications. Ask exactly five core questions, one at a time, and do not write to disk.
-
-The harness has already asked the first question of this phase: how many questions the product phase may ask - light (3), medium (5), thorough (10) or best judgement. Do not ask it again; this phase's own questions are not capped by it.
-
-## Questions
-
-1. **Motivation** — What problem or limitation should this feature address?
-2. **Affected user** — Who should benefit from or interact with this feature?
-3. **Desired outcome** — What should that user be able to accomplish after the feature exists?
-4. **Success criterion** — What observable result would prove the feature is useful and working?
-5. **Boundary** — What should this feature deliberately leave unchanged or out of scope?
-
-Ask one focused follow-up only when an answer is too vague to summarize. Do not choose concepts, spec wording, implementation technology, or tests yet - the product questions decide those, one spec change at a time.
-
-## Feature-intent brief
-
-Summarize the answers in five short bullets:
-
-- Motivation
-- Affected user
-- Desired outcome
-- Observable success criterion
-- Boundary and explicit exclusions
-
-Ask the user to confirm or correct the brief. The intent step finishes only after explicit confirmation. Carry the brief into the scope step, so it maps the intent onto existing modules instead of restarting the feature discussion.

package/genome/skills/mature/SKILL.md

@@ -1,78 +0,0 @@
----
-name: mature
-description: >-
-  Mature a rough `***plain` spec until it is fully rendered, on its own: the goal is the spec built
-  - every functionality from the spec as it stands, its tests passing - and the loop is render,
-  watch the agents building it, and when one struggles on something the spec leaves open or
-  unclear, settle it in the spec, stop that build and render again. It reads what the builds had to
-  decide themselves - assumptions, pitfalls, a failed build's diagnosis, a spec that contradicts
-  itself - and writes what the spec should have said, as spec diffs. It decides open choices itself
-  and records every decision; it does not ask. It stops when the spec is fully rendered, or when it
-  is stuck on something the spec cannot settle. Use when the user has a rough or hand-written spec
-  and wants it made to build without steering it. Not for starting from nothing (`brood`,
-  `spawn`) or adding a feature (`bud`).
-allowed-tools: [read, write, edit, bash, ls, grep, find, change_plain, regenerate, drift, halt, watch_jobs, spec_findings]
-metadata:
-  # What each phase does, in a line - shown under the skill's progress while it runs.
-  phases:
-    intake: "reads the spec, checks it parses, and makes sure a build can start"
-    regenerate: "builds what is left, watches the builds, and settles what the spec leaves open"
-    report: "what was built, what struggled, and what was decided in the spec"
-  # It writes its fixes one after another, from what the builds show: no answer between them.
-  paced: false
----
-
-# 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.
-
-## 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 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.
-
-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 `change_plain`.
-
-## 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 `change_plain`.
-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.
-
-### regenerate
-
-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 `change_plain`. 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 `definitions.md`, `func-specs.md` and `impl-reqs.md` 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
-
-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;
-- 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.