← OrendroCONTENT HISTORY
WHAT CHANGED
Update to Orendro
Snapshot Oct 24, 2026 · 13:29 UTC · version 1.1.3
Collection source: downloaded plugin package.
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 JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Help a user start or resume Orendro setup, choose what to track, personalize supported preferences, and complete a first useful action. Use for setup, getting-started, and Orendro-specific “what can I do?” requests. Do not interrupt an ordinary logging or read request with mandatory setup.",
"included_files": [
{
"relative_path": "references/shared-rules.md",
"size_in_bytes": 1804
}
],
"name": "get-started",
"skill_md_contents": "---\nname: get-started\ndescription: \"Help a user start or resume Orendro setup, choose what to track, personalize supported preferences, and complete a first useful action. Use for setup, getting-started, and Orendro-specific \\u201cwhat can I do?\\u201d requests. Do not interrupt an ordinary logging or read request with mandatory setup.\"\n---\n\nStart from the user's immediate goal. If they have already asked for a concrete\nOrendro action, complete that action before offering optional setup.\n\nRead [shared rules](references/shared-rules.md) before operating.\n\nFor a setup request:\n1. Confirm that the intended Orendro connection is available. If authentication\n or legal acceptance is required, use the host's supported connection flow or\n the exact link returned by the service. Never request passwords or tokens in\n the conversation and never mark legal acceptance on the user's behalf.\n2. Read onboarding_status. If incomplete, call onboarding_next. Reuse known\n profile/context information rather than asking the user to repeat it.\n3. Explain Orendro in one sentence. Establish what the user wants help with first\n if that is not already clear. Ask essential returned questions naturally, one\n decision at a time, reusing known information.\n4. Save answers through onboarding_update using its actual accepted fields,\n current state version and an idempotency key for the intended change.\n5. As soon as the chosen action has the context it requires, offer to do it now:\n log a described item, inspect groceries, prepare a workout, record time, or\n save a supported preference. Do this before optional goals, preferences or\n the tour. Execute only the action the user chooses and show the real result.\n Never create demo records or mark deferred setup as completed.\n6. While the user is continuing setup, use the next question already returned by\n onboarding_update. Do not fetch next/status again unless recovering from a\n conflict or missing result. Honor supported skip/defer choices. If the server\n still requires a field the user declines, do not fabricate a skip: ordinary\n logging can proceed with that setup section unfinished.\n7. Offer nutrition target estimates only when wanted. Ask for required estimator\n inputs only for that purpose, show the estimate as an estimate, and save the\n target only when the user accepts the reviewed recommendation.\n8. Save reusable preferences only through an available authorized preference\n contract. Verify the saved result. If persistence is unavailable, say the\n preference applies in this conversation and identify the supported next step.\n Do not use another endpoint or a direct database write as a substitute.\n9. After the first useful action, offer at most one optional next step: goals,\n personalization, or a check-in routine. If the user declines, continue\n ordinary use without repeated setup invitations.\n\nFor a returning or completed account, answer the requested goal directly or\nresume the selected unfinished part. Do not rerun all welcome questions.\n\nOutput: one concise explanation or confirmed result, then at most one useful\nquestion. Distinguish connected, ready to log, optional personalization, and\nverified scheduled routines. Never claim these are the same state.\n\nThe nutrition use case is log-only. Select nutrition_targets only when the user wants optional manual or estimated targets. Estimator inputs are requested only for requestRecommendation=true; do not invent a nutritionMode argument. A just-connected user can use the setup action or listing starter; OAuth does not itself invoke an unsolicited greeting.\n"
}SHA-256 of public snapshot: d6229099ed82e488f1b9923405f8ee32093e55d378fb7738fe34e6897f2f9a84