{"id":18103,"plugin_id":"plugins_6a85a87df50c8191bd7f010bb7b17794","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:37.489Z","digest":"2b2a5a902757a4555dc62145b8f7f6c14c20b7e1643436de7da178e3fcd6ac76","against":null,"payload":{"description":"Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship fewer polished features over more rough ones.","included_files":[],"name":"principle-experience-first","skill_md_contents":"---\nname: principle-experience-first\ndescription: \"Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship fewer polished features over more rough ones.\"\ndisable-model-invocation: true\n---\n\n# Experience First\n\nThe product is the experience. Every technical decision either helps or hurts it. When implementation convenience conflicts with user delight, choose delight.\n\n- Say no to 1,000 things (every feature, control, and option must earn its place)\n- Ship less, ship better (polished experience with three features beats rough one with ten)\n- Prototype before committing (design decisions are cheaper in throwaway HTML than production code)\n- Sweat the details (transitions, alignment, spacing, feedback, error states)\n- Tighten the core loop (every feature should serve the central workflow or get out of the way)\n\nThe user is whoever consumes the work. For a UI that is the end user. For a library or an internal API it is the colleague who imports it. The engineer who maintains the code next is a user too. Weigh their experience the same way, and explain impact from their seat.\n\nFoundations should serve the experience, not the other way around. Foundational thinking governs the *sequence* of work; this principle governs the *target*.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}