design-interaction

Stars11

Forks2

UpdatedJuly 7, 2026 at 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

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

nullhack

nullhack/temple8

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Web and Digital Interface DesignersComputer and Mathematical Occupations·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.

More from this repository

same 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.