← OrendroCONTENT HISTORY

Update to Orendro

Snapshot Oct 24, 2026 · 13:29 UTC · version 1.1.3

Collection source: downloaded plugin package.

WHAT CHANGED

First saved snapshot

No earlier snapshot is available to establish a change.

Save Orendro and check future changes in Following.

Up to 10 plugins free · no card required.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Help the user configure, inspect, change, pause, or stop Orendro-related check-ins and purchase-evidence routines in their chosen assistant. Use for explicit requests for recurring or conditional help. A request to discuss or draft a routine does not activate it.",
  "included_files": [
    {
      "relative_path": "references/executor-procedure.md",
      "size_in_bytes": 2887
    },
    {
      "relative_path": "references/runtime-recipes.md",
      "size_in_bytes": 6308
    },
    {
      "relative_path": "references/shared-rules.md",
      "size_in_bytes": 1804
    }
  ],
  "name": "proactive-routines",
  "skill_md_contents": "---\nname: proactive-routines\ndescription: \"Help the user configure, inspect, change, pause, or stop Orendro-related check-ins and purchase-evidence routines in their chosen assistant. Use for explicit requests for recurring or conditional help. A request to discuss or draft a routine does not activate it.\"\n---\n\nRead [shared rules](references/shared-rules.md) before operating.\n\nThis is the Dev pilot workflow. Validate the host capability and actual execution before production promotion. User requests to discuss or draft a routine never authorize activation.\n\n1. Identify whether the user wants an explanation, a draft, activation, a change,\n   or a stop. Complete only that scope. Reuse details already provided.\n2. Ask one decision at a time for the routine's purpose, exact condition, days,\n   local time/timezone, permitted sources and delivery destination. Clarify\n   ambiguous AM/PM or a condition such as 'if I haven't logged' before scheduling.\n3. Discover the host capabilities actually available: scheduler, relevant source\n   connector, notification conditions, task inspection/update and durable context.\n   Do not assume these from a product name or another user's account.\n4. Before creating a dependent task, verify harmless authorized reads from Orendro\n   and each required external source. Do not create a knowingly nonfunctional\n   routine. Explain the exact missing dependency and prepare a useful fallback.\n5. Show a compact preview of when it runs, what it reads, when it notifies and what\n   it may write. Default unattended food/receipt checks to reading and proposing\n   records. Do not add automatic food logging to an evidence-search permission.\n6. If activation is authorized and supported, inspect relevant existing tasks and\n   create/update the intended one through the host. Avoid duplicates. Use a\n   self-contained saved prompt with its connection, timezone, condition and\n   failure behavior. Do not mix time and event triggers when unsupported.\n7. Verify the returned task ID, enabled state and schedule. Describe it as scheduled\n   with first verification pending until an actual run succeeds. Saving a routine\n   preference in Orendro is a separate operation and requires its own supported\n   persistence contract.\n8. If activation is unavailable, supply a ready-to-use configuration prompt and\n   say clearly that no task has been created. Do not subscribe the user to a paid\n   service, start a provider-owned worker or promise unsupported background access.\n9. For receipt workflows, limit source/window, deduplicate evidence, distinguish\n   purchases from consumption, and ask before saving candidate records unless a\n   specific existing standing authorization covers that exact action. Do not alter\n   the mailbox, send replies, or persist full email bodies as a default.\n10. Support pause/stop/change through the actual executor. Do not imply that editing\n    an Orendro note stops a task in ChatGPT or another bot. Report any remaining\n    manual step accurately and show when executor state was last verified.\n\nRuntime rules: no missing-record conclusion after a failed read; no guilt-based\nwording; obey chosen quiet hours and notification limits; use the host's actual\nquiet-result mechanism. If quiet conditional delivery cannot be guaranteed,\nexplain the limitation before activation. Keep the user's current explicit\ninstruction ahead of older preferences.\n\n\nUse [runtime recipes](references/runtime-recipes.md) for self-contained task prompts. Resolve every placeholder before creating a task.\n"
}

SHA-256 of public snapshot: 2f36fd424c075662bc2cfa42b1786277cfd3da9a56c199410b949dd5aed92c42