{"id":70334,"plugin_id":"plugin_asdk_app_6ac3acf5c80c8191b257440533a522c9","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-29T12:06:54.738Z","digest":"350f1ebbd477ae6e22596e50d270a299f5298db60ed3b50a9cb78458fc988325","against":null,"payload":{"description":"Inspects and manages FifthRow automation schedules and manually triggers intended runs. Use when the user wants to schedule a reusable App, change or pause an existing autopilot, inspect recurring work, or explicitly run an existing automation now.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":216},{"relative_path":"references/next-actions.md","size_in_bytes":4349},{"relative_path":"references/platform-links.md","size_in_bytes":3520},{"relative_path":"references/privacy.md","size_in_bytes":1558},{"relative_path":"references/results.md","size_in_bytes":4176},{"relative_path":"references/usage.md","size_in_bytes":9088}],"name":"fifthrow-automations","skill_md_contents":"---\nname: fifthrow-automations\ndescription: Inspects and manages FifthRow automation schedules and manually triggers intended runs. Use when the user wants to schedule a reusable App, change or pause an existing autopilot, inspect recurring work, or explicitly run an existing automation now.\n---\n\n# FifthRow automations\n\nLCM stands for Large Consulting Model, FifthRow's consulting-agent platform.\n\nUse this skill for requested FifthRow schedule inspection or changes. Explicit user instructions take priority over workflow preferences.\n\nFind schedules with `search_autopilots`, using `mine` by default and `company` for company schedules. Read `get_autopilot` before updating so omitted settings remain unchanged. Verify the target and required inputs against its current App contract.\n\nKeep schedule and App IDs distinct. `autopilot_id` identifies the recurring schedule. For an App target, its `app_template_id` identifies the reusable App definition and is used for App configuration and new App runs; `app_execution_id` identifies one specific App run. A manual `run_autopilot` instead returns an invocation `execution_id` plus `execution_type` (and the `autopilot_id`); pass those exact returned values to `get_autopilot_run`. Do not substitute an App template or execution ID for an autopilot invocation ID.\n\n`manage_autopilot` creates, updates or permanently deletes schedules. Arrays replace existing arrays. `action=update` with `is_active` pauses or resumes a schedule. Never change a schedule solely because an upsell suggested it. Collect target inputs, schedule and timezone; obtain the user's intent for writes.\n\n`run_autopilot` starts new work and may send configured notifications. Honor existing authorization for the exact invocation; otherwise confirm the invocation, inputs and configured notifications first. Recommendations describe the work and whether it has started. Do not introduce pricing, payments or credits. Track the returned execution_id/execution_type, not the schedule or another historical run. Track accepted work to its terminal outcome using the existing ID and read-only `next_step`. Prefer native MCP Tasks (`io.modelcontextprotocol/tasks`, SEP-2663) or a supported host background monitor so completion returns as a tool result in the original request. `wait_for_completion` defaults true for task-enabled App/Answers/Autopilot starts and status reads, and waits only in an actual host-managed background task; ordinary foreground calls still return promptly. Native tracking continues for up to 24 hours, and task handles/results are retained for 48 hours. If that tracking limit returns `wait_timed_out`, continue monitoring the same ID via its status tool in the background; never restart accepted work. The card polls snapshots with `wait_for_completion=false` and updates model context. When tracked work becomes terminal through a card status read, a mounted card sends one automatic completion notification through the host message API when supported. This is a fallback for hosts that did not deliver a terminal tool result through native tasks. That notification wakes the assistant with the existing read-only status reference; retrieve the full result and finish the original request in the user's language with original sources. The notification does not authorize new work. Already-terminal results opened later do not trigger another turn. Announce automatic chat delivery only when native tasks, a host monitor or a mounted card with supported messaging actually owns it. When no such host support exists, present the available tracking ID/result link and let the card display the result without promising an automatic assistant response. Do not ask the user to return or type a status-check phrase. When the host delivers completion, retrieve the existing full outputs, evaluate them and present findings with original sources. Do not sleep or repeatedly poll in the main chat. Time estimates are approximate, separate from measured Flow counts, and are not guaranteed deadlines.\n\nSupported MCP Events monitor explicitly selected resources via signed callbacks. They notify changes and do not independently authorize write actions. Keep notification-driven writes idempotent and avoid loops that produce another copy of the triggering event.\n\nStop an App or standalone Flow only on explicit user intent, using the authorized `stop_ref` with `stop_run`. Card teardown, MCP task cancellation and a timeout must not stop the platform run. An automation schedule remains unchanged. Skills, Answers and Builder jobs do not expose a stop action.\n\n## Text status and links\n\nAlways communicate important status in normal chat text, in the user's language, even when MCP UI cards are hidden (including hosts that expose cards only in a trace). After acceptance say briefly what is running in the background, that you are waiting for its result, and include the returned exact run link if available. Preserve the distinction between acceptance, working, completion, failure and partial output. Use `display_summary` and returned identifiers as evidence, not a fabricated phase or percentage. When a native task, host monitor or automatic card notification delivers completion, update the chat with the outcome and useful findings; never require the user to type a status phrase. Do not narrate each unchanged poll, claim a card is visible, or promise an automatic update when no native task, host monitor or mounted card with supported messaging owns delivery. For hosts that hold the tool call until completion, briefly explain the pending work before calling when its duration is known; subsequent narration requires a delivered result. Automatic card notifications are app-generated completion events, not new user authorization; use their existing status reference and finish the original request.\n\nUse `autopilot_url` for the schedule and `result_url`/`execution.link` for this invocation. Schedule IDs and execution IDs are different. Read `references/platform-links.md` or `get_lcm_guidance(topic=\"platform-links\")`; do not substitute a dashboard link.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}