@farmslot/skills 0.1.0

package/skills/project-adopt/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: project-adopt
+description: Recommend the smallest useful Farmslot recipe adoption level for a project
+compatibility: Claude, Codex, Cursor, and Markdown skill runners with repo read access
+metadata:
+  package: '@farmslot/skills'
+allowed-tools: Read Bash(rg:*) Bash(node:*) Bash(git:*)
+---
+
+# Project Adopt
+
+Recommend a pragmatic adoption path for recipe-first validation.
+
+## Adoption Levels
+
+0. Skills only: author and review recipes with no runner.
+1. Recipe runner: add a local command that executes one recipe and emits artifacts.
+2. Project recipe layer: add recipes, runner manifest, project actions, and artifact conventions.
+3. Farmslot project integration: add `project.json` hooks for slot-based execution.
+4. Full OS: adopt Gateway, Command Center, multi-slot dispatch, Companion, and retrospectives.
+
+## Workflow
+
+1. Identify the project type and current test commands.
+2. Identify the proof surfaces the project can already produce.
+3. Pick the lowest level that would produce reviewer-trustworthy evidence.
+4. List only the next one or two concrete changes.
+
+## Hard Rules
+
+- Do not prescribe the full Farmslot OS when a local recipe runner is enough.
+- Do not add domain-specific assumptions.
+- Do not require a project to change its test stack before proving the first useful recipe.

package/skills/recipe-cook/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: recipe-cook
+description: Build a validation recipe from PR intent, ticket ACs, or investigation findings
+compatibility: Designed for agent runners with Markdown skill loading, Bash access, git diff visibility, and repo-local recipe validation runners when available
+metadata:
+  package: recipe-cook
+  loop_model: inner-run-cook plus validator-run-refine
+  outputs: artifacts/recipe.json artifacts/recipe-cook.json artifacts/recipe-cook-learning.json
+allowed-tools: Bash(rg:*) Bash(node:*) Bash(git:*) Read Write
+---
+
+# Recipe Cook
+
+Turn PR intent, ticket acceptance criteria, or investigation findings into a validation recipe.
+
+This is an LLM skill.
+Do not treat it as deterministic templating.
+
+Use [references/TASK.md](references/TASK.md) as the immutable harness template.
+[TASK.md](TASK.md) remains the compatibility harness path for runners that expect a package-root task file.
+For each run, materialize a fresh `TASK.md` beside the run artifacts and work through that copy top-to-bottom.
+File-first is the default pattern. The launcher prompt should be small; the real instructions live in the run-local `TASK.md`.
+Do not stop after writing a recipe file.
+See [the validator loop reference](references/VALIDATOR-LOOP.md) when you need the versioning and experiment artifacts beyond a single cooking run.
+
+When this skill is injected into a target repo, prefer a repo-local install path like `.agents/skills/recipe-cook/`.
+Keep that path local-only via `.git/info/exclude` or the repo's existing local exclude pattern, not by editing the shared `.gitignore`.
+When running inside a target repo, prefer repo-local validator/runtime discovery first; Farmslot slot lookup is only the experiment-harness fallback.
+
+## Execution Modes
+
+Treat `recipe-cook` as one core skill with multiple execution surfaces:
+
+- **Interactive / farmslot mode**: preferred when a live slot, tmux pane, or human-observable debugging loop exists. In this mode, keep going until the recipe is written, the run-local `TASK.md` is fully rewritten from the template, and every available validation command has been executed or explicitly marked unavailable with a real reason.
+- **Batch mode**: useful for unattended benchmark reruns and validator-comparison loops. Batch mode is optional. It does not lower the completion bar.
+
+If an interactive slot exists, do not stop after pasting or emitting JSON in chat. The point is to drive the run-local workspace to completion.
+
+## When To Use
+
+- Current PR has no recipe and needs reviewable validation proof
+- Existing recipe is weak, stale, or does not cover the real acceptance criteria
+- You have investigation findings and want to turn them into a reproducible recipe
+- You need before/after visual proof or explicit state proof for a change
+
+## Workflow
+
+1. Copy `references/TASK.md` into the run-local workspace as `TASK.md` and fill the `## Task` block there.
+2. Gather the real source of truth.
+3. Enumerate acceptance criteria before recipe drafting.
+4. Extract proof targets.
+5. Decide `state` / `visual` / `mixed` per target.
+6. Discover reuse before invention.
+7. Draft the recipe.
+8. Rewrite the run-local `TASK.md` from the template into a real task artifact.
+9. Run schema validation when available.
+10. Run runner dry-run validation when available.
+11. Run the strongest honest live validation path when available.
+12. Audit resolved vs unresolved targets.
+13. Only then mark completion.
+
+The harness order is mandatory.
+Do not silently batch or skip steps.
+Mark each completed checklist step `[x]` immediately. Do not batch checkbox updates.
+
+## Output Contract
+
+Preferred outputs when the workflow/task has an artifacts directory:
+
+- `artifacts/recipe.json`
+- `artifacts/recipe-cook.json`
+
+`recipe.json` should own:
+
+- executable workflow
+- claim-to-proof linkage
+- proof steps
+
+`recipe-cook.json` should own:
+
+- resolved targets
+- unresolved targets
+- proof mode by target
+- degrade reason when relevant
+
+If the current runner/tooling does not use sidecar metadata yet, still write the recipe and include unresolved/proof-mode notes in the report or task artifact.
+
+Completion requires:
+
+- recipe artifact written
+- run-local `TASK.md` materially rewritten from the template
+- learning artifact written
+- unresolved-target audit written
+- validation evidence recorded
+- all required proof targets either `PROVEN` or explicitly non-applicable by contract
+- `STATUS: done` in the run-local copied `TASK.md`
+
+## Hard Rules
+
+- Do not fake proof for vague claims
+- 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 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`
+- For `wait_for` nodes, use canonical runner field names such as `timeout_ms` and `poll_ms`. Do not invent `timeout` unless the target runner explicitly documents that alias.
+- Do not edit `recipe-cook/SKILL.md`, `recipe-cook/references/TASK.md`, or `recipe-cook/repos/*.md` during the cooking run
+
+## Common Pitfalls
+
+| Pitfall                                                            | Correct Pattern                                                                                      |
+| ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
+| Treating cooking as deterministic templating                       | Treat it as LLM synthesis constrained by repo flows/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                                                                                   |
+| 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                        |
+| Inventing non-canonical runner fields like `timeout` on `wait_for` | use documented runner field names such as `timeout_ms` so live validation honors the intended timing |
+
+## Stop Conditions
+
+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
+- 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`
+
+Do **not** stop merely because the model has drafted a plausible recipe in chat. Drafting is not completion.
+
+## Required Response Sections
+
+1. `Proof Targets`
+2. `Resolved vs Unresolved`
+3. `Proof Mode Decisions`
+4. `Recipe Plan`
+5. `Validation Commands`
+
+## Harness Rule
+
+If the current repo has an `recipe-cook` harness, execute through it.
+If the harness is copied into a task/work directory, keep the same sections and checklist order.

package/skills/recipe-cook/TASK.md

@@ -0,0 +1,114 @@
+# Recipe Cook Task
+
+> Compatibility harness path for runners that expect `recipe-cook/TASK.md`.
+> The immutable template lives at `references/TASK.md`.
+> For each run, copy `references/TASK.md` into the run-local workspace as `TASK.md` before editing it.
+
+## Task
+
+```text
+TARGET_REPO:
+SOURCE_KIND:
+SOURCE_REF:
+ARTIFACT_DIR:
+VALIDATION_MODE:
+STATUS: pending
+```
+
+## Source Material
+
+Paste or summarize:
+
+- PR body
+- linked ticket ACs / expected behavior
+- investigation findings
+- existing recipe / flow / eval refs
+
+## Acceptance Criteria
+
+If structured ACs exist, enumerate them verbatim.
+If they do not, derive a numbered canonical list from the source material before proceeding.
+
+## Proof Targets
+
+One executable claim per line.
+Every target must map to an AC number or be explicitly marked as investigation-only.
+
+## Proof Mode Decisions
+
+For each proof target, choose exactly one:
+
+- `state`
+- `visual`
+- `mixed`
+
+If `mixed`, explain why both matter.
+
+## Resolved vs Unresolved
+
+List:
+
+- resolved targets
+- unresolved targets
+- why any unresolved target could not be covered honestly
+
+## Recipe Coverage Audit
+
+Map:
+
+- AC / finding
+- recipe node(s)
+- proof mode
+- screenshot required? yes/no
+- status: `PROVEN` | `UNRESOLVED` | `UNTESTABLE`
+
+## Validation Evidence
+
+Record:
+
+- schema validation command
+- runner dry-run command
+- live-run command if used
+- output or explicit `validation unavailable`
+
+## Learning Artifact
+
+Write:
+
+- `artifacts/recipe-cook-learning.json`
+
+It must include:
+
+- scenario type
+- recipe paths
+- evidence verdict
+- proposed next delta
+- touched files from the cooking run
+
+## 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.
+- [ ] **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.
+- [ ] **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.
+- [ ] **10. Handle unavailable validation honestly** — if the repo has no validator or runner, write `validation unavailable` with the reason. Do not fake success.
+- [ ] **11. Write the learning artifact** — write `artifacts/recipe-cook-learning.json` with evidence verdict and proposed next delta.
+- [ ] **12. Audit unresolved targets** — update `## Resolved vs Unresolved` and `## Recipe Coverage Audit` after validation evidence exists.
+- [ ] **13. Final completion gate** — set `STATUS: done` only after recipe writing, validation evidence, learning artifact, and unresolved-target audit are all present.
+
+## Failure Conditions
+
+Fail the cooking attempt if:
+
+- the recipe is written before AC extraction
+- proof modes are missing
+- unresolved targets are hidden
+- `artifacts/recipe-cook-learning.json` is missing
+- the agent stops after writing JSON with no validation evidence
+- the agent claims canonical success when every target is unresolved
+- the cooking run edits `recipe-cook/SKILL.md`, `recipe-cook/TASK.md`, or `recipe-cook/repos/*.md`

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

@@ -0,0 +1,176 @@
+# Recipe Cook Task Template
+
+> Direct-developer skill harness template.
+> Work top-to-bottom.
+> Do not stop after writing a recipe.
+> In interactive/farmslot mode, do not stop after printing JSON in chat. Finish the workspace artifact set and run validations when available.
+
+Copy this file into the run-local workspace as `TASK.md` before editing it.
+Do not edit the template in-place during a cooking run.
+
+Every time you complete a checklist step:
+
+1. immediately change `- [ ]` to `- [x]`
+2. update `STATUS` if needed
+3. only then move to the next step
+
+Do not batch checkbox updates.
+Do not leave completed steps unchecked.
+
+## Task
+
+```text
+SCENARIO_ID: {{SCENARIO_ID}}
+WRAPPER: {{WRAPPER}}
+TARGET_REPO: {{TARGET_REPO}}
+REPO_ROOT: {{REPO_ROOT}}
+SOURCE_KIND: {{SOURCE_KIND}}
+SOURCE_REF: {{SOURCE_REF}}
+SOURCE_ARTIFACT_DIR: {{SOURCE_ARTIFACT_DIR}}
+TASK_DIR: {{TASK_DIR}}
+ARTIFACT_DIR: {{ARTIFACT_DIR}}
+SOURCE_BUNDLE_FILE: {{SOURCE_BUNDLE_FILE}}
+VALIDATION_MODE: {{VALIDATION_MODE}}
+STATUS: pending
+```
+
+## Source Material
+
+Read `{{SOURCE_BUNDLE_FILE}}` first.
+
+Then replace this section with your own summary of:
+
+- PR body
+- linked ticket ACs / expected behavior
+- investigation findings
+- existing recipe / flow / eval refs
+
+## Acceptance Criteria
+
+If structured ACs exist, enumerate them verbatim.
+If they do not, derive a numbered canonical list from the source material before proceeding.
+
+## Proof Targets
+
+One executable claim per line.
+Every target must map to an AC number or be explicitly marked as investigation-only.
+
+## Proof Mode Decisions
+
+For each proof target, choose exactly one:
+
+- `state`
+- `visual`
+- `mixed`
+
+If `mixed`, explain why both matter.
+
+## Resolved vs Unresolved
+
+List:
+
+- resolved targets
+- unresolved targets
+- why any unresolved target could not be covered honestly
+
+## Recipe Coverage Audit
+
+Map:
+
+- AC / finding
+- recipe node(s)
+- proof mode
+- screenshot required? yes/no
+- status: `PROVEN` | `UNRESOLVED` | `UNTESTABLE`
+
+## Validation Evidence
+
+Record:
+
+- schema validation command
+- runner dry-run command
+- live-run command if used
+- output or explicit `validation unavailable`
+
+If the repo can run a validator or test command and you did not run it, explain exactly why.
+
+## Learning Artifact
+
+Write:
+
+- `artifacts/recipe-cook-learning.json`
+
+It must include:
+
+- scenario type
+- recipe paths
+- evidence verdict
+- proposed next delta
+- touched files from the cooking run
+
+## 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.
+- [ ] **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.
+- [ ] **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`.
+- [ ] **10. Run runner dry-run validation** — if the repo provides a runner, run at least a dry-run and record the command + output.
+- [ ] **11. Run the strongest honest live validation path** — if a live slot/runtime exists, use it. If not, record the concrete blocker.
+- [ ] **12. Handle unavailable validation honestly** — if the repo has no validator or runner, write `validation unavailable` with the reason. Do not fake success.
+- [ ] **13. Write the learning artifact** — write `artifacts/recipe-cook-learning.json` with evidence verdict and proposed next delta.
+- [ ] **14. Audit unresolved targets** — update `## Resolved vs Unresolved` and `## Recipe Coverage Audit` after validation evidence exists.
+- [ ] **15. Final completion gate** — set `STATUS: done` only after recipe writing, rewritten TASK.md, validation evidence, learning artifact, and unresolved-target audit are all present.
+- [ ] **16. Write terminal signal** — write exactly one terminal `SIGNAL.json` based on the outcome matrix below.
+
+## Outcome Matrix
+
+Write `SIGNAL.json` only after step 15 is evaluated.
+
+- **Success**:
+  - every required validation passed or was explicitly non-applicable by contract
+  - no required proof target remains `UNRESOLVED`
+  - `STATUS: done`
+  - signal:
+    ```json
+    { "status": "complete", "outcome": "success" }
+    ```
+
+- **Blocked**:
+  - a concrete environment/runtime/tooling blocker prevented required validation
+  - or a proof target remains `UNRESOLVED` because a required live/runtime dependency was unavailable
+  - `STATUS: blocked`
+  - signal:
+    ```json
+    { "status": "blocked", "outcome": "partial", "reason": "<concrete blocker>" }
+    ```
+
+- **Failed**:
+  - a required validation actually ran and failed
+  - or the recipe/proof contradicts the PR claim
+  - `STATUS: failed`
+  - signal:
+    ```json
+    { "status": "failed", "outcome": "failure", "reason": "<concrete failure>" }
+    ```
+    In particular: if live validation proves a regression or contradiction, this is `failed`, not `complete`.
+
+## Failure Conditions
+
+Fail the cooking attempt if:
+
+- the recipe is written before AC extraction
+- proof modes are missing
+- unresolved targets are hidden
+- the copied `TASK.md` remains mostly the untouched template
+- `artifacts/recipe-cook-learning.json` is missing
+- the agent stops after writing JSON with no validation evidence
+- the agent claims canonical success when every target is unresolved
+- `SIGNAL.json` reports `complete/success` while any required proof target is still `UNRESOLVED`
+- `SIGNAL.json` reports `complete/success` after a required validation actually failed
+- `SIGNAL.json` says complete before the checklist is actually complete
+- the cooking run edits `recipe-cook/SKILL.md`, `recipe-cook/references/TASK.md`, or `recipe-cook/repos/*.md`

package/skills/recipe-cook/references/VALIDATOR-LOOP.md

@@ -0,0 +1,54 @@
+# Validator Loop
+
+Use the validator loop when you are comparing `recipe-cook` versions across real runs.
+
+Core split:
+
+- cooking run writes task-local artifacts
+- validator run reads them, edits `recipe-cook/`, saves a patch, and updates ledgers
+
+Core artifacts:
+
+- task-local:
+  - `artifacts/recipe-cook-learning.json`
+  - `artifacts/recipe.json`
+  - `artifacts/recipe-cook.json` when supported
+- validator state:
+  - `.omx/artifacts/recipe-cook-runs/<run-id>.json`
+  - `.omx/artifacts/recipe-cook-patches/<timestamp>-<slug>.patch`
+  - `.omx/state/recipe-cook/runs.jsonl`
+  - `.omx/state/recipe-cook/versions.json`
+
+Score inputs:
+
+- `quality`
+- `pass_rate`
+- `cost_efficiency`
+
+Selection rules:
+
+- floors:
+  - `quality >= 0.80`
+  - `pass_rate >= 0.80`
+- tie-breaks:
+  1. higher `quality`
+  2. higher `pass_rate`
+  3. higher `cost_efficiency`
+- if cost is unknown:
+  - `balanced_score = null`
+  - compare by `quality`, then `pass_rate`
+  - do not promote that version to `keep` until cost coverage exists
+
+Convergence rules:
+
+- stop after 3 consecutive applied patches with no improvement greater than `0.02`
+- or when all three lanes reach:
+  - `quality >= 0.90`
+  - `pass_rate >= 0.90`
+  - cost remains within 10% of the current best
+
+Canonical lanes:
+
+- review
+- fix
+- investigation

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

@@ -0,0 +1,50 @@
+---
+repo: example-browser
+parent: recipe-cook
+---
+
+# Generic Browser App Recipe Cook
+
+Use this overlay when the target project is a browser or web app and has no more specific recipe skill.
+
+## Discovery
+
+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'
+```
+
+Then inspect package scripts for existing validation surfaces:
+
+```bash
+node -e "const p=require('./package.json'); console.log(p.scripts || {})"
+```
+
+## Reuse Before Invention
+
+Look for:
+
+- existing recipe files
+- browser automation tests
+- page objects or stable selectors
+- runner/action manifests
+- screenshot or trace artifact conventions
+- schema validators
+
+## Validation
+
+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
+```
+
+Live browser validation is optional for first use. When available, record the command, browser control endpoint, artifact directory, and exit status.
+
+If discovery finds no repo-local validator or runner:
+
+- write `validation unavailable: no repo-local validator/runner discovered`
+- do not claim that validation passed

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

@@ -0,0 +1,61 @@
+---
+repo: example-mobile
+parent: recipe-cook
+---
+
+# Generic Mobile App Recipe Cook
+
+Use this overlay when the target project is a mobile app and has no more specific recipe skill.
+
+## Discovery
+
+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'
+```
+
+Then inspect package scripts for local test and validation commands:
+
+```bash
+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.
+- 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.
+
+## Validation
+
+Use repo-local commands first. Common shapes include:
+
+```bash
+bash <validate-recipe.sh> <artifacts-dir> --dry-run
+node <validate-recipe.js> --recipe <recipe.json> --dry-run
+npm test
+```
+
+Live device or simulator validation is optional for first use. When available, record the device/simulator target, command, artifact directory, and exit status.
+
+If discovery finds no repo-local validator or runner:
+
+- write `validation unavailable: no repo-local validator/runner discovered`
+- do not claim that validation passed
+
+## Mobile-Specific Caution
+
+Keep stable across platforms:
+
+- proof target meaning
+- proof mode (`state`, `visual`, `mixed`)
+- honest unresolved-target reporting
+
+Allow to differ by platform:
+
+- selectors
+- navigation steps
+- runtime validation commands
+- artifact capture mechanics

package/skills/recipe-doctor/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: recipe-doctor
+description: Diagnose local readiness for recipe authoring and execution
+compatibility: Claude, Codex, Cursor, and Markdown skill runners with shell access
+metadata:
+  package: '@farmslot/skills'
+  outputs: readiness report
+allowed-tools: Read Bash(rg:*) Bash(node:*) Bash(npm:*) Bash(yarn:*) Bash(pnpm:*) Bash(git:*)
+---
+
+# Recipe Doctor
+
+Check how far a project can go with recipes today.
+
+## Use When
+
+- A project wants to try recipe-first validation
+- An agent needs to know whether a local recipe runner exists
+- A recipe failed because commands, fixtures, browser control, or artifact paths are unclear
+
+## Workflow
+
+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.
+4. Identify proof surfaces: state/log artifacts, screenshots, traces, browser control, mobile bridge, or command output.
+5. Report the smallest useful next step.
+
+## Output
+
+Return:
+
+- detected project type
+- available recipe commands
+- available proof surfaces
+- missing blockers
+- suggested adoption level from 0 to 4
+
+Do not require Farmslot Gateway, Command Center, pool files, or slots for the first readiness pass.