@farmslot/skills 0.2.0 → 0.3.0

package/CHANGELOG.md

@@ -4,6 +4,9 @@ All notable changes to `@farmslot/skills` are tracked here.
 
 ## Unreleased
 
+## 0.3.0 - 2026-08-03
+
+- Teach recipe authors to start from existing parameterized recipes and compose them node by node before adding new capabilities.
 - Active-development baseline; add user-facing changes here before release or package publication.
 
 ## 0.2.0 - 2026-07-19

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@farmslot/skills",
-  "version": "0.2.0",
+  "version": "0.3.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.2.0"
+    "@farmslot/agent-runtime": "0.6.0"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",

package/scripts/run-cooking-lane.cjs

@@ -222,9 +222,7 @@ function resolveRepoLocalContext({ startDir, repoName }) {
   const repoRoot = findUp(startDir, (candidate) => {
     if (!fs.existsSync(path.join(candidate, '.git'))) return false;
     if (repoName === 'example-browser') {
-      return (
-        findFilesByBasename(candidate, ['validate-recipe.js', 'validate-flow-schema.js']).length > 0
-      );
+      return findFilesByBasename(candidate, ['validate-recipe.js']).length > 0;
     }
     if (repoName === 'example-mobile') {
       return findFilesByBasename(candidate, ['validate-recipe.sh']).length > 0;
@@ -661,17 +659,11 @@ function discoverValidationSteps({ repoName, repoRoot, recipePath, artifactsDir,
   }
 
   if (repoName === 'example-browser') {
-    const schemaValidator = findFilesByBasename(repoRoot, ['validate-flow-schema.js'])[0];
     const recipeValidator = findFilesByBasename(repoRoot, ['validate-recipe.js'])[0];
-    if (!schemaValidator || !recipeValidator) {
+    if (!recipeValidator) {
       return [];
     }
     const steps = [
-      {
-        name: 'schema_validation',
-        command: ['node', schemaValidator, recipePath],
-        cwd: repoRoot,
-      },
       {
         name: 'dry_run',
         command: ['node', recipeValidator, '--recipe', recipePath, '--dry-run'],

package/skills/recipe-cook/SKILL.md

@@ -101,7 +101,7 @@ Completion requires:
 - Do not emit canonical success output if every target is unresolved
 - Do not prefer screenshots when state proof is enough
 - Do not skip screenshots when the claim is visual or review-sensitive
-- Do not rebuild known flows as raw steps when `call` exists
+- Do not rebuild known recipes as raw steps when `call` exists
 - Do not stop after printing a recipe or JSON payload if writable artifacts and validation surfaces still exist
 - Do not leave the copied `TASK.md` as the untouched template
 - Do not write `SIGNAL.json` with `complete/success` when a required validation failed or when a required proof target remains `UNRESOLVED`
@@ -112,11 +112,11 @@ Completion requires:
 
 | Pitfall                                                            | Correct Pattern                                                                                      |
 | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
-| Treating cooking as deterministic templating                       | Treat it as LLM synthesis constrained by repo flows/evals and honest proof                           |
+| Treating cooking as deterministic templating                       | Treat it as LLM synthesis constrained by repo journeys/recipes/evals and honest proof                |
 | Using the whole PR description as one target                       | Extract small executable proof targets                                                               |
 | Defaulting every UI claim to screenshots only                      | choose `visual` or `mixed` deliberately                                                              |
 | Defaulting every non-visual claim to a screenshot anyway           | prefer state/log/trace proof                                                                         |
-| Rewriting long repeated setup chains                               | reuse `call` flows                                                                                   |
+| Rewriting long repeated setup chains                               | reuse parameterized recipes through `call`                                                           |
 | Forcing a canonical recipe when the claim is unresolved            | stop or emit only resolved targets with explicit gaps                                                |
 | Treating interactive farmslot execution like chat-only drafting    | keep driving the workspace until artifacts + validation evidence exist                               |
 | Writing recipe artifacts but forgetting the copied `TASK.md`       | rewrite the task file and update `STATUS` / evidence sections before stopping                        |
@@ -127,7 +127,7 @@ Completion requires:
 Stop and report instead of forcing a recipe when:
 
 - target text is still too ambiguous to map honestly
-- repo has no viable flow/eval/native interaction path for the claim
+- repo has no viable recipe/eval/native interaction path for the claim
 - current runner context is missing and the missing context changes what should be proven
 - the repo has no validation runner and you already recorded `validation unavailable`
 

package/skills/recipe-cook/TASK.md

@@ -22,7 +22,7 @@ Paste or summarize:
 - PR body
 - linked ticket ACs / expected behavior
 - investigation findings
-- existing recipe / flow / eval refs
+- existing action / recipe / eval refs
 
 ## Acceptance Criteria
 
@@ -88,11 +88,11 @@ It must include:
 ## Checklist
 
 - [ ] **1. Fill the task block** — set `TARGET_REPO`, `SOURCE_KIND`, `SOURCE_REF`, `ARTIFACT_DIR`, `VALIDATION_MODE`, `STATUS: working`.
-- [ ] **2. Gather the real source of truth** — PR/ticket/investigation text plus existing flows/evals in the target repo.
+- [ ] **2. Gather the real source of truth** — PR/ticket/investigation text plus existing user journeys, recipes, and evals in the target repo.
 - [ ] **3. Enumerate acceptance criteria** — write a numbered canonical list under `## Acceptance Criteria`.
 - [ ] **4. Extract proof targets** — split the work into the smallest executable claims.
 - [ ] **5. Decide proof mode** — choose `state`, `visual`, or `mixed` for every target and justify every `mixed`.
-- [ ] **6. Discover reuse** — list existing `flow` / `eval_ref` / canonical recipe surfaces before writing new graph steps.
+- [ ] **6. Discover reuse** — list existing actions, recipes, and eval refs before writing new graph steps.
 - [ ] **7. Draft the recipe** — write `artifacts/recipe.json` and, when supported, `artifacts/recipe-cook.json`.
 - [ ] **8. Run schema validation** — if the repo provides a schema validator, run it and record the command + output under `## Validation Evidence`.
 - [ ] **9. Run runner dry-run validation** — if the repo provides a runner, run at least a dry-run and record the command + output.

package/skills/recipe-cook/references/TASK.md

@@ -43,7 +43,7 @@ Then replace this section with your own summary of:
 - PR body
 - linked ticket ACs / expected behavior
 - investigation findings
-- existing recipe / flow / eval refs
+- existing action / recipe / eval refs
 
 ## Acceptance Criteria
 
@@ -111,11 +111,11 @@ It must include:
 ## Checklist
 
 - [ ] **1. Fill the task block** — set `TARGET_REPO`, `SOURCE_KIND`, `SOURCE_REF`, `ARTIFACT_DIR`, `VALIDATION_MODE`, `STATUS: working`.
-- [ ] **2. Gather the real source of truth** — PR/ticket/investigation text plus existing flows/evals in the target repo.
+- [ ] **2. Gather the real source of truth** — PR/ticket/investigation text plus existing user journeys, recipes, and evals in the target repo.
 - [ ] **3. Enumerate acceptance criteria** — write a numbered canonical list under `## Acceptance Criteria`.
 - [ ] **4. Extract proof targets** — split the work into the smallest executable claims.
 - [ ] **5. Decide proof mode** — choose `state`, `visual`, or `mixed` for every target and justify every `mixed`.
-- [ ] **6. Discover reuse** — list existing `flow` / `eval_ref` / canonical recipe surfaces before writing new graph steps.
+- [ ] **6. Discover reuse** — list existing actions, recipes, and eval refs before writing new graph steps.
 - [ ] **7. Draft the recipe** — write `artifacts/recipe.json` and, when supported, `artifacts/recipe-cook.json`. Use documented runner field names for nodes (for example `timeout_ms` / `poll_ms` on `wait_for`), not guessed aliases.
 - [ ] **8. Rewrite this copied TASK file** — replace the template placeholders with the real run data and working notes. Leaving the untouched template is a failure.
 - [ ] **9. Run schema validation** — if the repo provides a schema validator, run it and record the command + output under `## Validation Evidence`.

package/skills/recipe-cook/repos/example-browser.md

@@ -12,7 +12,7 @@ Use this overlay when the target project is a browser or web app and has no more
 Start with:
 
 ```bash
-rg --files | rg 'recipes?/.*\\.json$|flows?/.*\\.json$|validate-recipe\\.(js|mjs|cjs|ts)|validate-flow-schema\\.(js|mjs|cjs|ts)|playwright|cypress|vitest|agentic-toolkit\\.md'
+rg --files | rg 'recipes?/.*\\.json$|validate-recipe\\.(js|mjs|cjs|ts)|playwright|cypress|vitest|agentic-toolkit\\.md'
 ```
 
 Then inspect package scripts for existing validation surfaces:
@@ -37,7 +37,6 @@ Look for:
 Use repo-local commands first. Common shapes include:
 
 ```bash
-node <validate-flow-schema.js> <recipe.json>
 node <validate-recipe.js> --recipe <recipe.json> --dry-run
 npm test -- --runInBand
 ```

package/skills/recipe-cook/repos/example-mobile.md

@@ -12,7 +12,7 @@ Use this overlay when the target project is a mobile app and has no more specifi
 Start with:
 
 ```bash
-rg --files | rg 'recipes?/.*\\.json$|flows?/.*\\.json$|validate-recipe\\.(sh|js|mjs|cjs|ts)|detox|maestro|appium|testIds?|accessibility|agentic-toolkit\\.md'
+rg --files | rg 'recipes?/.*\\.json$|validate-recipe\\.(sh|js|mjs|cjs|ts)|detox|maestro|appium|testIds?|accessibility|agentic-toolkit\\.md'
 ```
 
 Then inspect package scripts for local test and validation commands:
@@ -23,7 +23,7 @@ node -e "const p=require('./package.json'); console.log(p.scripts || {})"
 
 ## Cooking Rules
 
-- Prefer stable accessibility labels, test IDs, or existing mobile flows when they exist.
+- Prefer stable accessibility labels, test IDs, or existing mobile automation when it exists.
 - Keep proof targets separate from platform mechanics.
 - Do not import web-only selectors or desktop assumptions into mobile recipes.
 - If mobile lacks a repo-owned helper, write a recipe and proof plan, then mark live validation unavailable with the concrete blocker.

package/skills/recipe-harness/SKILL.md

@@ -16,7 +16,7 @@ Use the local recipe runtime when one exists, or recommend the smallest install
 
 1. Find the project-owned recipe command first.
 2. If no command exists, check for `@farmslot/recipe-harness` or an app-specific harness package.
-3. Before authoring, inspect declared actions and reusable flows. Prefer project discovery commands. For generic flow discovery, run `farmslot-recipe flows list` and `farmslot-recipe flows describe <ref>`. If no action discovery command exists, read only the relevant project manifest entries and examples.
+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.
 6. If no runner exists, stop with a concrete install recommendation.
@@ -25,7 +25,7 @@ Use the local recipe runtime when one exists, or recommend the smallest install
 
 - Do not invent runner commands.
 - Do not require Farmslot Gateway, pool files, slots, Command Center, or Companion for first use.
-- Do not bypass project fixtures or user-flow validation by directly mutating app state.
+- Do not bypass project fixtures or user-journey validation by directly mutating app state.
 
 ## Output