@turri-dev/cli 0.1.11-next.fec1e14 → 0.1.12-next.8125d07

package/genome/skills/spawn/SKILL.md

@@ -11,7 +11,7 @@ description: >-
   when the user wants to start a new project fast, or says to just build it. For a full interview
   that settles the stack, the testing and every feature with the user, use `brood`. Not for adding a
   feature to an existing project (use `bud`).
-allowed-tools: [read, write, edit, bash, ls, grep, find, write_spec_diff]
+allowed-tools: [read, write, edit, bash, ls, grep, find, change_plain]
 metadata:
   # Started only by the person, with its command - /spawn - never by the model on its own.
   command-only: true
@@ -64,9 +64,9 @@ Set the module up and start the first build - on your own, no questions.
 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. 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.** 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 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.
 4. Run `validate` on every module you wrote, and fix what it finds.
-5. **The first spec.** Write the module's first functional spec with `write_spec_diff`: the smallest thing that runs and shows something - the server answers one request (`GET /` with the app's name), the command-line tool prints its usage, the page shows the app's name, the library exposes one call with a fixed result. It holds no product logic, so its build only sets the project up and lands fast - and its pulse is not reviewed. Follow `add-functional-spec` for its wording, and keep it to that one observable result.
+5. **The first spec.** Write the module's first functional spec with `change_plain`: the smallest thing that runs and shows something - the server answers one request (`GET /` with the app's name), the command-line tool prints its usage, the page shows the app's name, the library exposes one call with a fixed result. It holds no product logic, so its build only sets the project up and lands fast - and its pulse is not reviewed. Follow `add-functional-spec` for its wording, and keep it to that one observable result.
 
-`write_spec_diff` takes 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 build. Go straight on to the next step - never wait for a build.
+`change_plain` takes 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 build. Go straight on to the next step - never wait for a build.
 
 ### regenerate
 
@@ -76,7 +76,7 @@ Write the first slices of what the user described, each a spec diff, while the f
 
 1. **The main slice.** The one thing the user said the software is for, on its happy path - the half-built main function a developer writes first and runs. Its concepts go into `***definitions***` in the same change, following `add-concept`; its functional spec follows `add-functional-spec`, placed where it fits.
 2. **One more slice at most** - the next thing the user described, also on its happy path. Stop there: two slices beyond the first spec. What the user says once they have tried the first ones decides the rest, and slices written far ahead are slices to rework.
-3. **Write each with `write_spec_diff`**, one after another - never wait for a build. Never change a `.plain` file in this step by any other means. Correct a change you find wrong once written with a diff and `fixes_earlier`, never by editing the file.
+3. **Write each with `change_plain`**, one after another - never wait for a build. Never change a `.plain` file in this step by any other means. Correct a change you find wrong once written with a diff and `fixes_earlier`, never by editing the file.
 
 Write no validation, no edge cases and no hardening in this step: they come later, as changes to these specs, once the user has tried the slices.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.1.11-next.fec1e14",
+  "version": "0.1.12-next.8125d07",
   "license": "MIT",
   "type": "module",
   "repository": {

package/genome/skills/init-plain-project/SKILL.md

@@ -1,117 +0,0 @@
----
-name: init-plain-project
-description: >-
-  Lightweight initializer for a new ***plain project. Asks about the base
-  technology and project kind, asks whether conformance testing is enabled,
-  then scaffolds a template import module (with base implementation reqs and
-  test reqs), a stub top-level module, the unit testing script, and
-  (optionally) the conformance testing script under `test_scripts/`. Does NOT run `validate`. Use when the user wants a
-  quick project skeleton to start writing functional specs against, without
-  the full `brood` interview.
-allowed-tools: [read, write, edit, bash, ls, grep, find]
----
-
-# Init Plain Project
-
-## Scope
-
-This skill is intentionally **minimal**. It produces a runnable project skeleton — not a complete spec. **No `***definitions***` sections are written by this skill — not in the template module, not in the top module.** No functional specs, no concepts, no acceptance tests, no validation. The user will fill those in afterwards with `bud`, `add-concept`, `add-functional-spec`, etc.
-
-What this skill writes:
-
-- `template/base.plain` — an import module with the project's base `***implementation reqs***` and `***test reqs***`.
-- `<project>.plain` — a top-level module that imports `base`. Frontmatter only — no body sections. The user adds `***functional specs***` later.
-- `test_scripts/run_unittests_<lang>.sh` — always.
-- `test_scripts/run_conformance_tests_<lang>.sh` — only if conformance testing is enabled.
-
-turri requires these scripts: a build with no unit testing script (or, with conformance on, no conformance testing script) stops before it starts. The harness runs them with Bash on the person's machine, so they are `.sh` scripts.
-
-What this skill does **not** do:
-
-- Run `validate`.
-- Author concepts, functional specs, or acceptance tests.
-- Probe the host environment (`check-plain-env` is a separate step the user can run later).
-
-## Workflow
-
-### 1. Ask the project basics
-
-Ask each with `ask_user`, one question per call, in this order:
-
-- **Project name** — used as the top module filename and as `:AppName:` later. Free-form (`free_form: true`).
-- **Base technology** — programming language and primary framework (e.g. Python + FastAPI, Node.js + Express, Go + net/http, Java + Spring Boot). Offer the most common stacks as options.
-- **Project kind** — CLI tool, web app, REST API / backend service, library, desktop app, mobile app, other. Offer the common kinds as options.
-
-Follow up with one free-form question for anything the options didn't cover (e.g. specific Python version, monorepo layout).
-
-### 2. Ask about testing
-
-Ask each with `ask_user`, one question per call:
-
-- **Unit testing framework** — propose the canonical one for the chosen language (pytest, Jest, Go `testing`, JUnit, ...) and let the user override.
-- **Conformance testing** — enabled or not. If the user is unsure, briefly explain it adds a `run_conformance_tests` script and per-spec acceptance tests later.
-
-### 3. Author `template/base.plain`
-
-Create the import module with `create-import-module`. It must contain:
-
-- `***implementation reqs***` — the base stack as requirements **and everything about `:UnitTests:`**:
-  - Programming language and version.
-  - Primary framework (if any).
-  - Dependency / package manager.
-  - Project kind as a constraint (e.g. ":Implementation: should be a REST API service.").
-  - `:UnitTests:` framework (pytest / Jest / JUnit / Go's `testing` / …) and the command used to run them — phrased in terms of `:UnitTests:` so the partition is explicit.
-  - Anything else the user added in the free-form catch-all.
-- `***test reqs***` — the base **conformance**-testing rules (only added if conformance testing is enabled):
-  - ":ConformanceTests: must be implemented and executed - do not skip tests."
-  - The `:ConformanceTests:` framework and the command used to run them.
-  - **Do NOT** put unit-test framework / command here — that lives in `***implementation reqs***` above.
-
-Do **not** add a `***definitions***` section to `template/base.plain`. This skill does not author any concepts. Use only the predefined concepts (`:Implementation:`, `:ConformanceTests:`) in the reqs — no project-specific concepts like `:AppName:` or `:App:`. Do not declare `required_concepts` either.
-
-Do **not** add `***functional specs***` to `template/base.plain` — it is an import module.
-
-### 4. Author the top module `<project>.plain`
-
-Create it at the repo root with frontmatter:
-
-```yaml
----
-import:
-  - base
-description: <one-line project description>
----
-```
-
-Body: **none**. The file ends after the closing `---` of the frontmatter. Do **not** add `***definitions***`, do **not** add `***functional specs***`, do **not** add any other section. The user will add `***functional specs***` later via `add-functional-spec` / `add-functional-specs`, and any concepts via `add-concept`.
-
-The file must still be created on disk — an empty body is fine, but the file itself is required.
-
-### 5. Generate the testing scripts
-
-Call the corresponding implementation skills in order. Each skill writes a Bash script, which is what the harness runs.
-
-- `implement-unit-testing-script` — always. It runs the stack's static checks - formatter, linter, type checker - with the unit tests, and they count as the tests do.
-- `implement-conformance-testing-script` — only if conformance testing was enabled. The script is self-contained: it stages the build, installs dependencies, and runs the module's whole conformance suite.
-
-### 6. Check turri finds the scripts
-
-turri finds the testing scripts in the project root, not through the specs: first in `config.turri.yaml` (`unittests-script:`, `conformance-tests-script:`, paths relative to the root), then the one `run_unittests*.sh` / `run_conformance_tests*.sh` in the root, then the one of each kind in `test_scripts/`. It puts them into the prompts of the agents that write and run the tests itself, so do not link them from `template/base.plain` (a link to one is ignored). Confirm every generated script is in `test_scripts/` and is the only one of its kind there - or, if the project wants it, that a `config.turri.yaml` at the root names the one to use and the path resolves. A project with parts on different stacks (e.g. a Python backend and a React frontend sharing an imported `base`) keeps one `config.turri.yaml` for what they share and gives each stack its own `config.turri.<stack>.yaml` beside it - `config.turri.backend.yaml`, `config.turri.frontend.yaml` - naming that stack's `unittests-script:` and `conformance-tests-script:`. Name each stack after the module it builds - `config.turri.backend.yaml` for `backend.plain` - and that module is built with it by itself, with nothing to choose; a stack named otherwise is passed as `stack` to `regenerate` in the chat, or `--stack <stack>` on the command line. 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 copies; never write `config.yaml`.
-
-Do **not** run `validate` here — keeping this skill light is the whole point. The user can run it when they want validation.
-
-### 7. Recap
-
-Tell the user what was created and what's next:
-
-- Files written: `template/base.plain`, `<project>.plain`, the test scripts.
-- Suggested next steps: add concepts with `add-concept`, add functional specs with `add-functional-spec` or `add-functional-specs`, or jump straight into `bud`.
-- Mention that `validate` has not been run on `<project>.plain` yet.
-
-## Validation checklist
-
-Before the recap, walk `references/checklist.md` and confirm every box is met. It is a self-audit of this workflow — never a substitute for it. A box only counts as met when the file is on disk as described; complete any unmet step before recapping.
-
-## Question style
-
-Use simple grammatical structures: short direct sentences, one idea per sentence, plain words over jargon. Keep every constraint and edge case the user needs to answer accurately.

package/genome/skills/init-plain-project/references/checklist.md

@@ -1,30 +0,0 @@
-# Init Plain Project Workflow Checklist
-
-Use this to verify the scaffold was produced correctly — never as a substitute for the workflow. Run it once before the recap. This skill is intentionally minimal: it writes a runnable skeleton, not a complete spec. If a box is unmet, go back and complete the step.
-
-## Setup
-
-
-## Ask the basics
-
-- [ ] Asked the project basics with `ask_user`, one question per call (project name, base technology, project kind), plus a free-form catch-all.
-- [ ] Asked testing with `ask_user`, one question per call (unit-test framework, conformance on/off).
-
-## Author the modules
-
-- [ ] Created `template/base.plain` via `create-import-module` with `***implementation reqs***` (language/version, framework, package manager, project kind, and everything about `:UnitTests:` — framework + run command).
-- [ ] Added `***test reqs***` to `template/base.plain` with the `:ConformanceTests:` rules **only** when conformance testing is enabled — and kept unit-test facts out of it.
-- [ ] No `***definitions***`, no `***functional specs***`, and no project-specific concepts in `template/base.plain`; only predefined concepts (`:Implementation:`, `:ConformanceTests:`) used; no `required_concepts` declared.
-- [ ] Created `<project>.plain` at the repo root with frontmatter only (`import: [base]`, `description`) and **no body sections** — the file exists on disk.
-
-## Generate scripts
-
-- [ ] Generated `implement-unit-testing-script` (always).
-- [ ] The unit testing script runs the stack's static checks with the tests, exiting `80` when only the checks fail.
-- [ ] Generated `implement-conformance-testing-script` only if conformance was enabled.
-- [ ] Every generated script is in `test_scripts/`, the only one of its kind there - or named in a `config.turri.yaml` at the root (`unittests-script:`, `conformance-tests-script:`) - or, for a part on a stack of its own, in that stack's `config.turri.<stack>.yaml` - whose paths resolve. No script is linked from the specs.
-- [ ] Did **not** run `validate` or `check-plain-env` (out of scope for this skill).
-
-## Recap
-
-- [ ] Told the user what was written, suggested next steps (`add-concept`, `add-functional-spec(s)`, `bud`), and noted that `validate` has not been run.