principle-experience-first
Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship fewer polished features over more rough ones.
- License 许可
- MIT
- 最近更新
- 2026-11-12
- Stars
- ★ 1
- Forks
- 1
01 前言 Front Matter
- name
- principle-experience-first
- 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.
- user-invocable
- false
03 SKILL.md 正文
Experience First
When implementation convenience conflicts with user delight, choose delight.
- Every feature, control, and option must be justified
- 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)
- Get the details right (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 perspective.
Foundations should serve the experience. Foundational thinking governs the sequence of work. This principle governs the target.
04 同仓库更多 Skills
code-review
Review the changes since a fixed point (commit, branch, tag, or merge-base) along five axes: Standards (does the code follow this repo's documented coding standards?), Spec (does the code match what the originating issue/spec asked for?), Evidence (does each claim in the pull request have evidence that shows it?), Bugs (does the changed code have logic errors, unhandled states, races, or regressions?), and Security (does the change open injection, auth, secret, input, or CI workflow holes?). Runs the reviews in parallel sub-agents, tags every finding Important, Nit, or Pre-existing, and reports them side by side with what blocks merge. Given an earlier reviewed head and its findings, it reviews only the newer commits, rechecks the earlier findings, and never repeats one. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
writing-for-pstack
Write or tighten an operator prompt for a patina-mode run. Use when the operator asks to write, revise, or review a prompt that will be passed to patina-mode.
writing-for-agents
Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.
wizard
Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.
wayfinder
Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
wait-what
Stop. That last message did not land: re-pitch it.