{"id":81060,"plugin_id":"plugin_asdk_app_6aac2e7529fc819188f331a42e6d0a91","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-04T18:10:41.231Z","digest":"cc04fc138ab68f1b3be13c25931583408e65fb5a8790ffe80c8203ee603203df","against":null,"payload":{"description":"Compare published BeliefState investment cases and explain how recorded investor views changed over a requested period. Use for opposing theses, investment alternatives, research updates or dated diligence; do not create automatic monitoring or execute trades.","included_files":[],"name":"compare-views-and-follow-changes","skill_md_contents":"---\nname: compare-views-and-follow-changes\ndescription: Compare published BeliefState investment cases and explain how recorded investor views changed over a requested period. Use for opposing theses, investment alternatives, research updates or dated diligence; do not create automatic monitoring or execute trades.\n---\n\n# Compare views and follow changes\n\nAnswer the comparison or change question the user actually asked; do not run both branches unnecessarily. Reuse adequate cases and history already in the conversation.\n\n## Compare available views\n\n- Identify the requested company, theme, alternatives or two cases. Use `search_beliefs` or a subject brief to discover relevant cases if their IDs are not already available. Open selected cases with `get_belief` when full reasoning is needed.\n- Call `compare_beliefs` with distinct returned `belief_id` and `compare_to_belief_id`. If the available schema supports `comparison_focus`, use only the public proposition being compared, never a desired outcome or private portfolio information.\n- Explain each investor's thesis, supporting passages, reasons, catalysts, risks, horizon and date. Preserve the returned supports, contradicts, depends_on, unknown or unrelated result and dependency direction. Shared subject matter does not prove agreement, contradiction or independent corroboration.\n- Attribute the relationship assessment to the engine. Retain shared-source qualifications, assessment time and the case snapshot cutoff; a stored assessment is not new inference. Do not infer whose research performs better without adequate scoped outcome evidence.\n\n## Explain recorded changes\n\n- Use a concrete requested period or cutoff; clarify an ambiguous period when it changes the question. Use `get_belief_changes` for the ordered journal and a specific returned subject or case selector. Do not replace journal history with search's `changed_since` filter.\n- For changes to an investor's stated view, use `domain=author_view`; use `revision_only=true` when only authored revisions are requested. Keep author publication, system observation, condition checks, distribution events and calculated outcomes distinct.\n- Explain what changed and what evidence supports the change. Empty or incomplete history does not prove there was no earlier view. Preserve reconstructed, stale, catching-up and resynchronization states.\n- For what was known by a historical date, retain `as_of` and recorded availability/observation dates; publication alone does not prove earlier library availability. Use a historical subject brief or case when the user wants a snapshot rather than a journal.\n- Continue a requested history window with its returned cursor and unchanged selectors. A continuation cursor is not a next-poll checkpoint. Save a completed polling checkpoint in the customer's AI only after draining that requested window; never invent one. Do not start recurring monitoring, notifications or new research collection from a one-time question.\n\nAdapt detail to the user: a plain-language comparison for an individual investor, a cited change log for an analyst, or exact IDs and continuation fields for a research agent. Keep goals, holdings, quantities, risk preferences and conversation history in the customer's AI. Tool `context` contains only the public research goal, with truthful required model metadata and no private account/portfolio details or credentials. Make the first call serial, then reuse the server's exact `conversation_id` unchanged, including across follow-ups. Use available schemas, preserve citations and unknowns, and relay access/provider errors and recovery guidance without repeated paid retries. These workflows return research, not trading authority.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}