Update to fstack

{
  "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": "---\r\nname: principle-experience-first\r\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.\"\r\nuser-invocable: false\r\ndisable-model-invocation: true\r\n---\r\n\r\n# Experience First\r\n\r\nThe product is the experience. Every technical decision either helps or hurts it. When implementation convenience conflicts with user delight, choose delight.\r\n\r\n- Say no to 1,000 things (every feature, control, and option must earn its place)\r\n- Ship less, ship better (polished experience with three features beats rough one with ten)\r\n- Prototype before committing (design decisions are cheaper in throwaway HTML than production code)\r\n- Sweat the details (transitions, alignment, spacing, feedback, error states)\r\n- Tighten the core loop (every feature should serve the central workflow or get out of the way)\r\n\r\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.\r\n\r\nFoundations should serve the experience, not the other way around. Foundational thinking governs the *sequence* of work; this principle governs the *target*.\r\n"
}