krake_recipes

Public, community-contributable library of krake_browser recipes for everyday browser destinations: WhatsApp, Instagram, LinkedIn, FDA portal, and more.

Each recipe is a JSON file declaring a sequence of browser actions — clicks, inserts, waits, scrolls, and explicit human_intervention handoff points. The krake_browser engine reads these recipes and drives a long-lived local Chromium, pausing to ask the human whenever it needs them (2FA, approvals, anti-bot challenges, judgment calls).

What's in here

recipes/
  whatsapp/
    send_message.json        # Send a message to a named contact (human approves before send)
    pull_unread.json         # (planned) Pull unread messages
  instagram/
    login.json               # Open IG and let human handle 2FA on first run
    dm_send.json             # (planned) Send a DM (human approves)
  linkedin/
    connect_request.json     # Send a personalized connect request (human approves)
  fda/
    facility_search.json     # Search the FDA facility registration DB
schema/
  recipe.schema.json         # JSON Schema for validation

How to use a recipe

Once you have krake_browser running locally with this repo cloned to its recipe-library path:

# From an MCP-speaking LLM client:
run_recipe(
  name: "whatsapp/send_message",
  vars: {
    "CONTACT_NAME":   "Kirsten",
    "MESSAGE_DRAFT":  "Hey Kirsten, quick check-in re. inventory — got 5 min?"
  }
)

The engine opens / focuses the WhatsApp Web tab, types the contact name, opens the chat, drafts the message, then pauses with a human_intervention asking you to review and hit Continue before the message is sent.

How to contribute a recipe

1. Fork this repo.
2. Add your JSON file under the right recipes/<destination>/ folder. Create a new folder if needed.
3. Validate against schema/recipe.schema.json:

   npx ajv-cli validate -s schema/recipe.schema.json -d recipes/your_recipe.json

4. Open a PR with:
   • A one-line description of what the recipe does.
   • A note on which human_intervention points the recipe declares and why (don't skip handoffs for destinations with anti-bot detection).
   • Your test methodology — recipes against living sites drift; we'd rather have a recipe that says "last verified 2026-05-20 against WA Web v2.x.x" than one that silently rotted.

Recipe philosophy

A few conventions to keep recipes safe and reusable:

• Default to a human_intervention before any irreversible action (send a message, submit a form, fire a connect request). The LLM drafts; the human commits.
• Always declare a target_tab for always-on destinations (WhatsApp, IG, FB) so the engine reuses your logged-in tab instead of opening fresh ones.
• Be specific in prompt strings. "Click Continue" is bad. "Review the drafted message to Kirsten in the WhatsApp tab and click Continue to send" is good.
• Keep selectors brittle-resistant. Prefer aria-label, data-testid, and stable text content over CSS classes that change on every framework update.
• Don't store credentials in recipes. Sessions live in the persistent Chromium profile, not in JSON.

DSL reference

Recipe format is documented in krake_browser/DSL.md. It extends the original Krake.io DSL (2014) with the human_intervention action.

License

MIT — see LICENSE. Recipes are content; the MIT license is friendliest for forks, redistribution, and ad-hoc copying.

See also

• krake_browser — the engine that runs these recipes
• TrueSightDAO/tdg_recipes — a downstream recipe library for TrueSight DAO–specific operational flows, built on the same engine