@turri-dev/cli 0.0.0-stage → 0.1.1

package/genome/skills/analyze-if-func-spec-too-complex/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: analyze-if-func-spec-too-complex
+description: >-
+  Analyze a functional spec to determine if it is too complex for the renderer.
+  A spec is too complex if it would produce more than 200 lines of code changes.
+  Use after drafting a new functional spec (during `add-functional-spec`, or
+  per spec during `add-functional-specs`) to verify it fits within the
+  complexity limit before inserting it.
+allowed-tools: [read, ls, grep, find]
+---
+
+# Analyze If Functional Spec Is Too Complex
+
+## Why This Matters
+
+The renderer enforces a hard complexity limit: each functional spec must imply a **maximum of 200 changed lines of code**. If a spec exceeds this, the renderer rejects it with "Functional spec too complex!" and the spec must be broken down. Catching this before insertion saves a failed render cycle.
+
+## Input
+
+A drafted functional spec (not yet inserted into the file), plus the full context of the `.plain` file it will be added to — definitions, implementation reqs, and existing functional specs.
+
+## Workflow
+
+1. **Read the full `.plain` file** (and any `requires`/`import` modules) to understand the current codebase context — what already exists and what the new spec builds on.
+2. **Read the drafted functional spec** carefully.
+3. **Run the complexity analysis** using the checklist below.
+4. **Output the verdict and nothing else** — either `ACCEPTABLE` or `TOO COMPLEX`. No reasoning, no LOC estimate, no breakdown.
+
+## Complexity Analysis Checklist
+
+Work through each indicator. A single "yes" does not automatically mean the spec is too complex, but multiple "yes" answers are a strong signal.
+
+### 0. First-Spec Bootstrap Cost
+
+Is this the first functional spec in a new root module with no implementation baseline supplied by
+`requires`? If so, include the implicit cost of creating the project structure, package metadata,
+framework configuration, entry point, initial source files, and unit-test infrastructure.
+
+The first spec must be substantially simpler than a later spec. It should expose one minimal,
+deterministic capability that can be invoked and tested. Setup without an observable result is not
+acceptable, but combining bootstrap work with persistence, integrations, multiple interfaces,
+branching workflows, or cross-cutting behavior is a strong `TOO COMPLEX` signal.
+
+### 1. Number of Distinct Behaviors
+
+Does the spec describe more than one independently testable behavior?
+
+Too complex:
+```plain
+***functional specs***
+
+- A :User: can create, edit, delete, and archive :Task: items, with validation on all fields and confirmation dialogs for destructive actions.
+```
+
+Acceptable (one behavior each):
+```plain
+***functional specs***
+
+- A :User: can create :Task:. Only valid :Task: items can be added.
+
+- A :User: can edit :Task:.
+
+- A :User: can delete :Task:.
+
+- A :User: can archive :Task:.
+
+```
+
+### 2. Number of Concepts Introduced or Modified
+
+Does the spec require introducing new data structures, UI components, API endpoints, or other constructs that don't already exist? Count them.
+
+- 0–1 new constructs → likely fine
+- 2–3 new constructs → borderline, examine closely
+- 4+ new constructs → almost certainly too complex
+
+### 3. Branching Logic and Conditions
+
+Does the spec describe multiple conditional paths, modes, or special cases?
+
+
+Too complex:
+```plain
+***functional specs***
+
+- :Order: processing depends on :OrderType:. Standard orders are validated and stored. Express orders skip validation and are queued for immediate dispatch. Bulk orders are split into sub-orders of 100 items each, validated individually, and processed in parallel with progress tracking.
+```
+
+Acceptable (separate the modes):
+```plain
+***functional specs***
+
+- A standard :Order: is validated and stored.
+
+- An express :Order: is queued for immediate dispatch without validation.
+
+- A bulk :Order: is split into sub-orders of 100 items each.
+  - Each sub-order is processed individually.
+```
+
+### 4. Cross-Cutting Concerns
+
+Does the spec bundle core functionality with cross-cutting concerns like error handling, logging, retry logic, pagination, or caching?
+
+Too complex:
+```plain
+***functional specs***
+
+- :Resource: items are fetched from the external API with pagination support, retry on transient errors with exponential backoff, caching for 5 minutes, and logging of all API calls.
+```
+
+Acceptable (separate concerns):
+```plain
+***functional specs***
+- :Resource: items are fetched from the external API.
+
+- :Resource: items are fetched from the external API in pages.
+
+- Fetching :Resource: items is retried on transient errors using exponential backoff.
+```
+
+### 5. UI Complexity
+
+Does the spec describe a complete screen or page with multiple interactive elements, layouts, and state transitions?
+
+Too complex:
+```plain
+***functional specs***
+
+- The dashboard shows :User: profile, recent :Task: items in a sortable table, a notification bell with unread count, and a sidebar with navigation links that highlights the active page.
+```
+
+Acceptable (build incrementally):
+```plain
+***functional specs***
+
+- A dashboard page is shown for :User:.
+
+- Recent :Task: items are shown in a sortable table on the dashboard.
+
+- A notification indicator with the unread count is shown on the dashboard.
+```
+
+### 6. Data Transformation Complexity
+
+Does the spec involve complex data mapping, aggregation, or transformation across multiple entities?
+
+- Simple field mapping or filtering → likely fine
+- Multi-step transformations, joins across entities, or aggregations → likely too complex
+
+### 7. Implied Technical Component
+
+Does the spec imply building a substantial technical component — an engine, parser, scheduler, layout algorithm, state machine, or sync mechanism — **in addition to** the behavior it describes? A component is not a free primitive: code must be generated for it too, so it counts toward the 200-LOC budget and must be evaluated as part of the estimate. A spec that needs a component **and** wires up behavior on top of it is really two bodies of code in one spec — a strong "too complex" signal. Count the component's implementation, not just the glue that calls it.
+
+Too complex (builds the component and uses it in one spec):
+```plain
+***functional specs***
+
+- A :Report: is exported to PDF, laying out multi-page tables with repeating headers and page numbers, and charts rendered from :Report: data.
+```
+
+Acceptable (component in its own spec, then referenced):
+```plain
+***functional specs***
+
+- :PdfRenderer: lays out multi-page tables from structured content.
+  - Table headers repeat at the top of each page.
+  - Each page shows its page number.
+
+- A :Report: is exported to PDF using :PdfRenderer:, embedding charts rendered from :Report: data.
+```
+
+When this indicator fires, the fix is `break-down-func-spec` Strategy 6 — extract the component into its own earlier spec and reference it.
+
+### 8. Rough LOC Estimation
+
+Mentally estimate the implementation. Consider:
+- New files that need to be created
+- New functions/methods
+- Code for any implied technical component (engine, parser, algorithm), not just the glue that uses it
+- Data model changes (schema, migrations, types)
+- UI components (if applicable)
+- Test setup and assertions (unit tests are auto-generated alongside)
+- For the first spec in a new root module, all project and test scaffold implied by implementation requirements
+- Error handling paths
+- Import statements and boilerplate
+
+If the estimate exceeds ~150 LOC, the spec is at high risk of being too complex (leave headroom for the renderer to add necessary boilerplate).
+
+## Output Format
+
+The skill emits exactly one of these two strings, with no surrounding text, explanation, estimate, or breakdown:
+
+```
+ACCEPTABLE
+```
+
+or
+
+```
+TOO COMPLEX
+```
+
+The internal analysis (checklist, LOC estimation, reasoning) informs the verdict but must not appear in the output. The caller decides what to do with the result.
+
+## Integration with add-functional-spec / add-functional-specs
+
+This skill is called during step 3 of the `add-functional-spec` workflow (or per spec during `add-functional-specs`), after drafting a spec but **before** inserting it into the file. The caller acts on the one-word verdict:
+
+- **ACCEPTABLE** — proceed to insert the spec.
+- **TOO COMPLEX** — invoke `break-down-func-spec` to produce smaller specs, then insert each one individually (running conflict checks on each).

package/genome/skills/break-down-func-spec/SKILL.md

@@ -0,0 +1,205 @@
+---
+name: break-down-func-spec
+description: >-
+  Break down a functional spec that is too complex into smaller specs that
+  each imply ≤ 200 lines of code. Use when analyze-if-func-spec-too-complex
+  flags a spec as TOO COMPLEX, or when a spec is suspected of being too large.
+allowed-tools: [read, write, edit, bash, ls, grep, find]
+---
+
+# Break Down Functional Spec
+
+## When to Use
+
+- `analyze-if-func-spec-too-complex` flagged a spec as TOO COMPLEX.
+- A spec is suspected of exceeding the 200 LOC limit and needs to be split preemptively.
+- A spec bundles multiple behaviors, constructs, or concerns that should be separated.
+
+## Input
+
+The functional spec to break down, plus the full `.plain` file it belongs to.
+
+## Workflow
+
+1. **Read the full `.plain` file** — definitions, implementation reqs, and all functional specs (including `requires` modules) to understand context.
+2. **Identify the spec to break down** — the one flagged as too complex or pointed to by the user.
+3. **Analyze why it is too complex** — use the indicators from `analyze-if-func-spec-too-complex`:
+   - Multiple distinct behaviors bundled together?
+   - Too many new constructs introduced at once?
+   - Complex branching logic or conditional paths?
+   - Cross-cutting concerns mixed with core functionality?
+   - A full UI screen described in one spec?
+   - Complex data transformations across multiple entities?
+   - Implies one substantial technical component (engine, parser, scheduler, algorithm, state machine, sync mechanism) that must be built in code?
+4. **Identify the split boundaries** — find the natural seams where the spec can be divided. Each resulting spec must be:
+   - Independently meaningful (makes sense on its own with previous specs as context)
+   - Self-contained (does not require a later spec to be useful)
+   - Within the 200 LOC limit
+5. **Draft the replacement specs** — write the smaller specs in chronological order. The first replacement spec typically sets up the foundation, and subsequent ones layer behavior on top.
+6. **Verify functional completeness** — this is critical. The replacement specs taken together must cover **100% of the functionality** described in the original spec. Walk through every behavior, condition, and detail in the original and confirm it appears in exactly one of the replacement specs. Nothing may be lost, weakened, or left implicit. If any functionality from the original is missing, add it to the appropriate replacement spec or create an additional one.
+7. **Verify each replacement spec** — run `analyze-if-func-spec-too-complex` on each to confirm it fits within the limit.
+8. **Check for conflicts** — run `analyze-func-specs` **once** with the full set of replacement specs plus every existing spec in the file and its `requires` chain. The batched analyzer reports every conflicting pair (replacement × existing and replacement × replacement) in one call — do not loop over pairs. Resolve each reported pair with `resolve-spec-conflict`, then re-run `analyze-func-specs` over the touched set until the verdict is `COMPATIBLE`.
+9. **Replace in the file** — remove the original spec and insert the replacement specs in its position, preserving chronological order.
+10. **Read the file again** to confirm correct placement and syntax.
+
+## Splitting Strategies
+
+### Strategy 1: Separate Distinct Behaviors
+
+If the spec bundles multiple independently testable actions, split each into its own spec.
+
+**Before:**
+```plain
+***functional specs***
+
+- A :User: can create, edit, and delete :Recipe: items, with validation on all fields.
+```
+
+**After:**
+```plain
+***functional specs***
+
+- A :User: can create a :Recipe:. Only valid :Recipe: items can be created.
+
+- A :User: can edit an existing :Recipe:. Validation rules apply to the edited fields.
+
+- A :User: can delete a :Recipe:.
+```
+
+### Strategy 2: Separate Setup from Behavior
+
+If the spec introduces a new construct and immediately defines complex behavior on it, split into setup + behavior.
+
+**Before:**
+```plain
+***functional specs***
+
+- The :MealPlan: screen displays a weekly grid of :Slot: items, allows drag-and-drop reordering, and shows nutritional totals per day.
+```
+
+**After:**
+```plain
+***functional specs***
+
+- The :MealPlan: screen displays a weekly grid of :Slot: items.
+
+- A :User: can reorder :Slot: items within a day on the :MealPlan: screen using drag-and-drop.
+
+- The :MealPlan: screen displays nutritional totals for each day.
+```
+
+### Strategy 3: Separate Core Logic from Cross-Cutting Concerns
+
+If the spec mixes primary functionality with error handling, retries, caching, pagination, or logging, pull cross-cutting concerns into their own specs.
+
+**Before:**
+```plain
+***functional specs***
+
+- :Ingredient: data is fetched from the external API with pagination, retry on transient errors, and caching for 10 minutes.
+```
+
+**After:**
+```plain
+***functional specs***
+
+- :Ingredient: data is fetched from the external API.
+
+- :Ingredient: data is fetched from the external API in pages.
+
+- Fetching :Ingredient: data is retried on transient errors.
+```
+
+### Strategy 4: Separate Conditional Paths
+
+If the spec describes different modes or branches, give each its own spec.
+
+**Before:**
+```plain
+***functional specs***
+
+- :MealPlan: generation depends on :DietType:. Standard plans use round-robin assignment. Restrictive plans filter out excluded ingredients first, then apply round-robin. Custom plans allow manual slot-by-slot selection.
+```
+
+**After:**
+```plain
+***functional specs***
+
+- A standard :MealPlan: is generated using round-robin :Recipe: assignment.
+
+- A restrictive :MealPlan: is generated.
+  - Excluded :Ingredient: items are filtered out first.
+  - Round-robin :Recipe: assignment is then applied.
+
+- A :User: can manually assign :Recipe: items to :Slot: items for a custom :MealPlan:.
+```
+
+### Strategy 5: Build UI Incrementally
+
+If the spec describes a full screen, split into layout + individual interactive elements.
+
+**Before:**
+```plain
+***functional specs***
+
+- The :Dashboard: screen shows a summary card with stats, a scrollable list of recent :MealPlan: items, a floating action button to create a new plan, and a bottom navigation bar.
+```
+
+**After:**
+```plain
+***functional specs***
+
+- The :Dashboard: screen shows a summary card with :MealFrameStats:.
+
+- The :Dashboard: screen shows a scrollable list of recent :MealPlan: items.
+
+- The :Dashboard: screen includes a button to create a new :MealPlan:.
+```
+
+### Strategy 6: Extract a Reusable Technical Component
+
+Sometimes a spec is too complex not because it bundles many behaviors, but because it implies building one substantial technical component inline — an engine, parser, scheduler, layout algorithm, state machine, or sync mechanism. Splitting the behavior sideways does not help when the weight sits in that single component. Instead, pull the component out: define a concept for it, build it in its own dedicated spec placed **earlier** in the chain, then rewrite the original to use the component **by reference**. Because specs render incrementally top-to-bottom, the original now implies far less code — it wires up a component that already exists rather than implementing it from scratch.
+
+Define the component concept in `***definitions***` (via `add-concept`) before the first spec that references it.
+
+**Before:**
+```plain
+***functional specs***
+
+- A :Report: is exported to PDF, laying out multi-page tables with repeating headers, page numbers, and charts rendered from :Report: data.
+```
+
+**After:**
+```plain
+***functional specs***
+
+- :PdfRenderer: lays out multi-page tables from structured content.
+  - Table headers repeat at the top of each page.
+  - Each page shows its page number.
+
+- A :Report: is exported to PDF using :PdfRenderer:, embedding charts rendered from :Report: data.
+```
+
+The extracted component spec and the rewritten original must together still cover 100% of the original functionality (step 6): the original must **reference** the component, never re-describe it. Keep the component's technology and architecture choices in `***implementation reqs***`, not in the functional spec. If the component is a self-contained subsystem or will be reused across modules, promote it to its own module with `create-requires-module` / `refactor-module` instead of a sibling spec.
+
+## Preserving Chronological Order
+
+The replacement specs take the position of the original spec. Earlier specs remain unchanged. The first replacement spec should make sense given only the specs above it. Each subsequent replacement spec can reference behavior from the ones before it.
+
+If the original spec had acceptance tests, redistribute them to the most appropriate replacement spec — or drop tests that no longer apply to a single smaller spec and rewrite them.
+
+## Validation Checklist
+
+- [ ] Original spec has been removed from the file
+- [ ] Replacement specs together cover 100% of the original spec's functionality — nothing lost
+- [ ] Each replacement spec implies ≤ 200 LOC (verified via `analyze-if-func-spec-too-complex`)
+- [ ] No conflicts between replacement specs and existing specs (verified via one batched `analyze-func-specs` call)
+- [ ] No conflicts between the replacement specs themselves (covered by the same batched call)
+- [ ] Replacement specs are in correct chronological order
+- [ ] Each replacement spec is independently meaningful
+- [ ] All `:Concepts:` referenced in replacement specs are defined
+- [ ] Any extracted technical component is defined as a concept, built by its own earlier spec, and only **referenced** (not re-described) by the original
+- [ ] Replacement specs are language-agnostic
+- [ ] Replacement specs trimmed per `concise-specs.md` — a split is not a licence to re-add prose
+- [ ] All external interfaces remain explicit
+- [ ] Acceptance tests (if any) have been redistributed or rewritten

package/genome/skills/brood/SKILL.md

@@ -0,0 +1,229 @@
+---
+name: brood
+description: >-
+  `***plain` spec authoring in four phases - intent, stack, testing, product - where every answer
+  in the product interview becomes one spec change, written as a git diff of the .plain files and
+  built the moment it is written, so code appears while the interview is still going. It first asks
+  how many questions the stack and product phases may ask - light, medium, thorough or best
+  judgement, broader with fewer - and decides what they leave open itself, each decision a spec
+  change of its own. The testing
+  phase comes first, so each change is conformance tested as it is built: it decides on
+  conformance tests and writes the test reqs and the conformance testing script. Use when the user starts a new project or wants to build
+  something new from scratch and settle it with you step by step; when they want it built fast from
+  what they want alone, use its quick twin, `spawn`. Not for adding a
+  feature to an existing project (use `bud`) or for editing generated code (the .plain
+  specs are the source of truth).
+allowed-tools: [read, write, edit, bash, ls, grep, find, write_spec_diff]
+metadata:
+  # 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 write_spec_diff. Changes turri decides itself need no answer before them.
+  spec-diff-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 `write_spec_diff`, 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 `write_spec_diff`. 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 `write_spec_diff` 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 `write_spec_diff` 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 `write_spec_diff` 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. A stack is chosen, never worked out: tell the user to
+choose it with `/stack <stack>` (`--stack <stack>` on the command line) before building this module.
+
+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 `write_spec_diff` 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 `write_spec_diff`**, 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 `write_spec_diff`.
+
+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.