DeepBotDownload

The app's skill: what the Bot reads

skill/SKILL.md decides whether the app is ever used. The Bot reads the front matter's description to decide when to use the skill, and the body for how.

DeepBot adds a short preamble before your text, telling the Bot: which app the skill belongs to, where the app's files are on the computer ({{APP_DIR}} in your text is replaced by that folder), how to run its scripts (python on Windows, python3 elsewhere), and that the workspace folders in permissions.files are where the app reads and writes. You do not repeat that.

#Template

---
name: recipe-box
description: "Use when the person wants a recipe, asks what to cook, wants a recipe scaled or converted, or wants a shopping list from recipes: writes recipes into the Recipe box app and shows them."
---

# Recipe box

The Recipe box app shows recipes the Bot writes as JSON files in the workspace:

    recipes/<slug>.json        one recipe

`<slug>`: the title in lowercase with dashes ("Banana pancakes" -> banana-pancakes).

## The recipe file

    {
      "title": "Banana pancakes",
      "servings": 4,
      "minutes": 20,
      "ingredients": [{ "item": "flour", "amount": 200, "unit": "g" }],
      "steps": ["Mash the bananas.", "..."],
      "tags": ["breakfast", "vegetarian"]
    }

Amounts are numbers (the card scales them); units: g, kg, ml, l, tsp, tbsp, cup, pcs.

## Showing a recipe

1. Write the file.
2. Call `showRecipeBoxRecipe` with `slug` (and `servings` if the person asked for a number).
3. Do not repeat the recipe in your answer; one sentence at most.

## Changing a recipe

Read the file, change it, write it back, show it again.

## When the person comes from the app

A message from the app's buttons may come with instructions (for example "rewrite the file in
place"). Follow them.

#Rules for a good skill

  • The description is a trigger list. Start with "Use when ..." and name the situations and the words people use. A vague description means the skill is never picked; an over-broad one means it is picked for the wrong things.
  • Define the data exactly. File paths, the JSON shape with an example, which fields are required, units, limits. The card and the Bot must agree byte for byte. Make your UI tolerant anyway (normalise what you read: missing fields, wrong types).
  • Say which card to call, with which arguments, and what to say after. "Do not repeat what the card shows" saves the person reading everything twice.
  • Keep content in files, not in card arguments. Arguments are an id or a path; the card reads the file. Big arguments are slow to stream and lost when the conversation is summarised.
  • Steps the Bot must not skip go in numbered lists. Things it must never do go in their own short section.
  • Write for any model. Plain instructions, examples over theory, no reliance on one model's quirks. Local models read it too.
  • Keep it under ~400 lines. Put long reference material (a full schema, a style guide) in the skill folder next to SKILL.md and tell the Bot to read it when needed: Read {{APP_DIR}}/skill/blocks.md before writing a lesson.
← Bridge APIDesign →