Product interface engineering
Skill RobinGru/AgentSkillForge/skills/product-interface-engineering
Portable, reusable instruction packages for AI coding assistants.
npx -y skills add RobinGru/AgentSkillForge --skill product-interface-engineeringAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use for building, changing, debugging, or reviewing user-facing UI/UX and frontend behavior: pages, screens, forms, dialogs or modals, navigation, dashboards, components, interaction flows, validation and recovery, loading, empty, error, success, disabled, or permission states, accessibility, keyboard, focus, touch behavior, and responsive or mobile layouts. Also use when implementing a supplied design where visible behavior or interaction states change. Do not use for backend-only work, isolated visual-token changes, or behavior-preserving component refactors.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.2 KB, as published. Nobody here has run it
Product interface engineering
Use the repository's established language and conventions for any artifacts you create or update.
Build or review interfaces by making user task, interaction behavior, states, and verification explicit. Reuse product conventions before introducing a new visual pattern.
Use this skill when
- A screen, component, flow, accessibility behavior, or responsive interaction changes.
- Users must make a decision, enter data, recover from failure, or complete an action.
Do not use this skill when
- Work is backend-only or has no user-facing effect.
- A structural component refactor preserves interaction and visual behavior.
- An exact token or alignment correction has no behavior impact; use local scope only.
Scope
Choose local for isolated adjustment, flow for bounded journey, or
systemic for reusable or cross-screen change. Increase verification depth only
when scope or risk requires it.
Workflow
1. User job
Identify actor, concrete goal, decision or action supported, and costly errors. Mark missing product knowledge as unknown; do not fabricate research.
2. Existing system
Inspect nearby components, tokens, content conventions, routes, state patterns, supported platforms, tests, and stories. Retain established patterns when they serve job.
3. Interaction contract
Specify primary action, inputs, outcomes, errors, cancellation, resumption, and permission-limited behavior. State result users can safely expect.
4. State model
List relevant states: initial, pending, empty, partial, populated, invalid, recoverable or terminal failure, success, disabled, permission-limited, destructive confirmation, and offline when applicable. Define recovery for each state that can fail.
5. Implementation
Use semantic elements and existing primitives. Keep component APIs minimal. Support keyboard, touch, and assistive technology; account for responsive text, layout, and localization. Do not invent production content or measurements.
6. Verification
Use verification matrix to report checks. Load accessibility baseline and visual decision guidance when needed.
Output contract
Report Scope, User job, System facts, Interaction contract, State model, Implementation, Checks, and Remaining risks. Each check uses
Passed, Failed, Not run, or Not applicable. State unverified assumptions and
accessibility conflicts with closest usable alternative.