@turri-dev/cli 0.1.11 → 0.1.12

package/docs/authoring-plain.md

@@ -145,7 +145,7 @@ Every skill in `genome/skills/` can be run from a conversation; most are also us
 
 | to… | skills |
 | --- | --- |
-| start a project | `brood`, `spawn`, `init-plain-project` |
+| start a project | `brood`, `spawn` |
 | make rough \*\*\*plain build | `mature` |
 | add to \*\*\*plain | `bud`, `add-functional-spec`, `add-functional-specs`, `add-concept`, `add-implementation-requirement`, `add-test-requirement`, `add-acceptance-test`, `add-resource`, `add-template` |
 | check what is written | `analyze-if-func-spec-too-complex`, `analyze-2-func-specs`, `analyze-func-specs`, `resolve-section-ownership` |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.1.11",
+  "version": "0.1.12",
   "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.