{"id":26378,"plugin_id":"plugin_asdk_app_6aab6c4bd7d88191a4108d8f4c5e4b4e","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-04T06:02:49.844Z","digest":"b34aee9e6ef5519ddcbe1d014264116a9504ad8104738973bd47bf5b2831991a","against":null,"payload":{"description":"Explain Light Remote policy boundaries, effective permissions, activity, PTY behavior, and update/helper state without bypassing local controls.","included_files":[],"name":"policy-and-observability","skill_md_contents":"---\nname: policy-and-observability\ndescription: Explain Light Remote policy boundaries, effective permissions, activity, PTY behavior, and update/helper state without bypassing local controls.\n---\n\nUse this skill when the user asks why an operation was allowed or denied, wants recent activity, or wants to understand Wall/Fleet/update behavior.\n\n1. Use `light_remote_inspect_device` for routing, effective capabilities, policy, Fleet relationship, and sanitized update/helper status.\n2. Use `light_remote_recent_activity` for recent session, job, PTY/process, routing, policy, and update events.\n3. Distinguish product capability from effective permission on the selected device.\n4. Device-local policy is a final deny boundary. Explain a denial rather than trying another command, another device, sudo, or a policy bypass.\n5. Do not request or expose passwords, API keys, MFA/OTP codes, private keys, signing secrets, raw transport credentials, or unnecessary internal identifiers.\n6. Treat updater/helper and signing architecture as observable product state, not authority to disable signature checks or obtain signing keys.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}