Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship fewer polished features over more rough ones.
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
# Experience First
The product is the experience. Every technical decision either helps or hurts it. When implementation convenience conflicts with user delight, choose delight.
- Say no to 1,000 things (every feature, control, and option must earn its place)
- Ship less, ship better (polished experience with three features beats rough one with ten)
- Prototype before committing (design decisions are cheaper in throwaway HTML than production code)
- Sweat the details (transitions, alignment, spacing, feedback, error states)
- Tighten the core loop (every feature should serve the central workflow or get out of the way)
The 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.
Foundations should serve the experience, not the other way around. Foundational thinking governs the *sequence* of work; this principle governs the *target*.
The line at the top of this page pins the label git:20260827.04830a9, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
GET https://markdownregistry.com/api/v1/artifacts/art_dwh3byiphwqjfvfg
GET https://markdownregistry.com/api/v1/resolve?ref=painhardcore/pstack/principle-experience-first
GET https://markdownregistry.com/api/v1/blob/f8f61e0b0c215988b3199ae4b1f9e16c9443e5580906594feb23d48b12d3dafe
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
painhardcore/pstack · .opencode/skills/architect/SKILL.md · Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use…
painhardcore/pstack · .opencode/skills/arena/SKILL.md · Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for…
painhardcore/pstack · .opencode/skills/blast-radius/SKILL.md · Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe…
painhardcore/pstack · .opencode/skills/create-verification-skill/SKILL.md · Generate a project-local verification skill that drives your app the way a user does — any language, framework, or…
painhardcore/pstack · .opencode/skills/figure-it-out/SKILL.md · Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a…
painhardcore/pstack · .opencode/skills/how/SKILL.md · Explain how a subsystem works, trace a runtime flow, or determine where code and ownership belong before making a…
painhardcore/pstack · .opencode/skills/interrogate/SKILL.md · Use for "interrogate", "adversarial review", "multi-model review", "challenge this", "stress test this code", "find…
painhardcore/pstack · .opencode/skills/principle-boundary-discipline/SKILL.md · Apply when wiring validation, error handling, or framework adapters. Concentrate guards at system boundaries (CLI…
cursor/plugins · harness/pstack/claude-code/skills/principle-experience-first/SKILL.md · Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship…
cursor/plugins · pstack/skills/principle-experience-first/SKILL.md · Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship…
michael-denyer/pstack-claude · plugins/pstack/skills/principle-experience-first/SKILL.md · Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship…
backnotprop/pstack · skills/principle-experience-first/SKILL.md · Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship…
j-star-films-studios/vibecode-protocol-suite · assets/.agent/skills/engineering-principles/experience-first/SKILL.md · Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship…
creedants/pstack-t3 · skills/principle-experience-first/SKILL.md · Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship…
arjitj2/open-pstack · plugins/pstack/skills/principle-experience-first/SKILL.md · Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship…
edbertchan/catstack · corpus/skills/principle-experience-first/SKILL.md · Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship…