@farmslot/skills 0.4.0 → 0.6.0

package/CHANGELOG.md

@@ -6,6 +6,16 @@ All notable changes to `@farmslot/skills` are tracked here.
 
 - Active-development baseline; add user-facing changes here before release or package publication.
 
+## 0.6.0 - 2026-10-04
+
+- `import` of `@farmslot/skills/scripts/worker-terminal-contract.cjs` exposes its names: it re-exports `@farmslot/agent-runtime/scripts/worker-terminal-contract.cjs` with a literal `require`, which ESM can follow, instead of a computed path with a repo-relative fallback.
+- Skills refer to the recipe runner package as `@farmslot/recipe-runner` (renamed from `@farmslot/recipe-harness`).
+- Publish with agent-runtime 0.17.0.
+
+## 0.5.0 - 2026-09-20
+
+- README documents the checklist-shaped skill rule: a skill invoked as a child checklist unit (ADR-060) needs `##` sections and `- [ ]` rows the shared parser can enumerate, informational sections named so the skip list drops them, and numbered labels matching their positions. A prose-only skill cannot be a child unit.
+
 ## 0.4.0 - 2026-09-17
 
 - Recipe Cook lane: the runner envelope reports `terminal_status` (`done|blocked|failed`) and `terminal_reason`; the lane no longer reads or rewrites a `STATUS:` line in the run-local TASK.md, and `meta.json` records `terminal_reason`. Templates and skill text drop the field. An envelope without a valid `terminal_status`, or a blocked/failed one without `terminal_reason`, fails the run; the model output stays in `runner-output.txt`. The `tmux-model-driver` launcher and watcher stop mentioning or parsing the field.

package/README.md

@@ -44,6 +44,35 @@ Supported layouts:
 | `project-adopt`  | Recommend the smallest useful Farmslot integration level for the project.                       |
 | `packet`         | Communicate plans, blockers, decisions, and evidence reviews as compact operator packets.       |
 
+## Checklist-shaped skills
+
+A checklist step can hand its work to a skill as a **child unit**: the step registers the
+skill, `mark` materializes its body as `subtasks/<id>.md` beside the task checklist, and the
+worker marks the skill's own rows so progress is visible per row instead of one box open for
+the whole review. Farmslot only materializes and observes files; nothing is spawned.
+
+A skill can be a child unit when its body is enumerable by the same parser the task checklist
+uses:
+
+- `##` (or deeper) headings and `- [ ]` rows, with at least one row. A prose-only skill cannot be
+  a child unit.
+- Name informational sections so the shared skip list drops them: `Rules`, `Description`,
+  `Task`, `Acceptance Criteria`, `Affected Area`, `Screenshots`, `Comments`, `Root Cause`,
+  `Recipe ACs`, `Pre-merge`. Boxes there are never steps.
+- If a row label carries its own number (`**3. …**`), it must match the row's position. The
+  numbering guard refuses a body where they diverge, because `mark` targets positions.
+
+A template step registers the installed skill and finishes it:
+
+```bash
+{{TASK_DIR}}/mark sub start perps-review --step 21 --from .agents/skills/mms-perps-review-pr/skill.md
+{{TASK_DIR}}/mark sub perps-review 1        # …one per row
+{{TASK_DIR}}/mark sub perps-review complete --report artifacts/review.md
+```
+
+The step's own box is ticked by that `complete`, so the template says what to register, and the
+skill owns what to check.
+
 ## Adoption Ladder
 
 1. Skills only: author and review recipes without a runner.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@farmslot/skills",
-  "version": "0.4.0",
+  "version": "0.6.0",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -33,7 +33,7 @@
     "prepublishOnly": "node ../../scripts/quality/check-farmslot-package-readiness.mjs --publish --packages @farmslot/skills"
   },
   "dependencies": {
-    "@farmslot/agent-runtime": "0.10.0"
+    "@farmslot/agent-runtime": "0.17.0"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",

package/scripts/worker-terminal-contract.cjs

@@ -1,17 +1,4 @@
 'use strict';
 
-const path = require('node:path');
-const { createRequire } = require('node:module');
-
-const requireFromHere = createRequire(__filename);
-
-function resolveRuntimeScript() {
-  try {
-    return requireFromHere.resolve('@farmslot/agent-runtime/scripts/worker-terminal-contract.cjs');
-  } catch (error) {
-    if (error.code !== 'MODULE_NOT_FOUND') throw error;
-    return path.resolve(__dirname, '../../agent-runtime/scripts/worker-terminal-contract.cjs');
-  }
-}
-
-module.exports = require(resolveRuntimeScript());
+// A literal require: Node can then see this re-export's names when an ESM consumer imports it.
+module.exports = require('@farmslot/agent-runtime/scripts/worker-terminal-contract.cjs');

package/skills/recipe-doctor/SKILL.md

@@ -22,7 +22,7 @@ Check how far a project can go with recipes today.
 
 1. Inspect package scripts and repo docs for recipe commands.
 2. Look for recipe files, runner manifests, action manifests, schemas, or artifact conventions.
-3. Check whether `@farmslot/recipe-harness`, an app-specific runner, or a custom script is installed.
+3. Check whether `@farmslot/recipe-runner`, an app-specific runner, or a custom script is installed.
 4. Identify proof surfaces: state/log artifacts, screenshots, traces, browser control, mobile bridge, or command output.
 5. Report the smallest useful next step.
 

package/skills/recipe-harness/SKILL.md

@@ -4,7 +4,7 @@ description: Help run or install a local recipe runtime without assuming the ful
 compatibility: Claude, Codex, Cursor, and Markdown skill runners with shell access
 metadata:
   package: '@farmslot/skills'
-  related_package: '@farmslot/recipe-harness'
+  related_package: '@farmslot/recipe-runner'
 allowed-tools: Read Bash(rg:*) Bash(node:*) Bash(npm:*) Bash(yarn:*) Bash(pnpm:*) Bash(farmslot-recipe:*)
 ---
 
@@ -15,7 +15,7 @@ Use the local recipe runtime when one exists, or recommend the smallest install
 ## Workflow
 
 1. Find the project-owned recipe command first.
-2. If no command exists, check for `@farmslot/recipe-harness` or an app-specific harness package.
+2. If no command exists, check for `@farmslot/recipe-runner` or an app-specific harness package.
 3. Before authoring, inspect the closest recipes with `farmslot-recipe run --list` and `farmslot-recipe run <id> --describe`, then inspect declared actions only if no recipe fits. Prefer project discovery commands; otherwise read only the relevant manifest entries and examples.
 4. Run dry-run or schema validation before live execution when available.
 5. Record artifact paths and validation output.