design-interaction

Sterne11

Forks2

Aktualisiert7. Juli 2026 um 08:33

Design the interaction + feedback + error flows for a user-facing surface (CLI, API, or web). On-demand — run when the ux-engineer is consulted on an interaction contract.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

nullhack

nullhack/temple8

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

Web- und digitale SchnittstellendesignerInformatik- und Mathematikberufe·SOC 15-1255

SKILL.md

readonly

name	design-interaction
description	Design the interaction + feedback + error flows for a user-facing surface (CLI, API, or web). On-demand — run when the ux-engineer is consulted on an interaction contract.

Design Interaction

Load [[design/interaction-design]], [[design/accessibility]] — the conversation model, the two gulfs, feedback + error design, and the accessibility floors that apply to every interaction.
Identify the surface (CLI / HTTP API / web UI) and load its surface-specific knowledge: [[design/cli-design]] for a terminal, [[design/api-design]] for an HTTP service, [[design/visual-design]] for a graphical surface.
State the user's goal for the surface in one sentence, then list the flows that reach it — including the recovery path from each error. A flow is a contract, not a happy path; the error paths are designed here, not deferred.
Design the feedback for every action: received, in progress, succeeded, failed — within a latency the user can associate with the action. Close the gulfs of execution (signified affordances, the user's vocabulary, one primary action) and evaluation (legible state, results in the user's terms).
Design the errors along prevent → detect → recover: constrain input to prevent; validate early to detect; write an actionable, in-the-user's-terms message with a fix path to recover. Never ship a flow whose error paths have not been designed.
Verify the accessibility floor: keyboard reachability + visible focus (graphical), contrast per WCAG 2.2, color never the sole signal, semantic markup. IF a flow fails the floor THEN fix the design before handoff.
Document the interaction contract: the flows, the feedback at each step, and the error catalog. Hand to the implementer; the contract, not a Figma file, is the source.

Mehr aus diesem Repository

gleiches Repository

simulate-contracts

nullhack/temple8

Compile the contract set in your head — simulate how the real application would run from the specs, and disprove (or confirm) it works before any source .py is written.

2026-07-0811

author-test-stubs

nullhack/temple8

Author test stub files (.pyi) whose signatures express the domain, relationships, and compositions, as the first contract surface.

2026-07-0811

interview-building-blocks

nullhack/temple8

Funnel level 3 — identify building-block names and rough boundaries only, and run gap analysis.

2026-07-0811

interview-general

nullhack/temple8

Funnel level 1 — establish the big picture with seven broad questions, applying CIT, Laddering, and CI Perspective throughout.

2026-07-0811

merge-to-dev

nullhack/temple8

Squash-merge the feature commits into dev, regenerate docstrings, and verify the whole suite plus whole-suite stubtest are clean.

2026-07-0811

publish-release

nullhack/temple8

Publish the delivered batch as release notes, a PR to main, or a tagged release.

2026-07-0811

name	design-interaction
description	Design the interaction + feedback + error flows for a user-facing surface (CLI, API, or web). On-demand — run when the ux-engineer is consulted on an interaction contract.

Design Interaction

Load [[design/interaction-design]], [[design/accessibility]] — the conversation model, the two gulfs, feedback + error design, and the accessibility floors that apply to every interaction.
Identify the surface (CLI / HTTP API / web UI) and load its surface-specific knowledge: [[design/cli-design]] for a terminal, [[design/api-design]] for an HTTP service, [[design/visual-design]] for a graphical surface.
State the user's goal for the surface in one sentence, then list the flows that reach it — including the recovery path from each error. A flow is a contract, not a happy path; the error paths are designed here, not deferred.
Design the feedback for every action: received, in progress, succeeded, failed — within a latency the user can associate with the action. Close the gulfs of execution (signified affordances, the user's vocabulary, one primary action) and evaluation (legible state, results in the user's terms).
Design the errors along prevent → detect → recover: constrain input to prevent; validate early to detect; write an actionable, in-the-user's-terms message with a fix path to recover. Never ship a flow whose error paths have not been designed.
Verify the accessibility floor: keyboard reachability + visible focus (graphical), contrast per WCAG 2.2, color never the sole signal, semantic markup. IF a flow fails the floor THEN fix the design before handoff.
Document the interaction contract: the flows, the feedback at each step, and the error catalog. Hand to the implementer; the contract, not a Figma file, is the source.