AI agent skill · by @levnikolaevich

Ln 13 Interaction Design Builder

Designs user flows, interaction states and mockups for a defined product scope; does not implement UI code.

Archived 2026-10-23 · Source updated 2026-09-16 · License: MIT. Check the original repository for the latest version.

SKILL.md instructions

# Interaction Design Builder

**Goal:** Create or update authorized interaction-design artifacts that make a product journey usable and implementable while preserving protected experience. Do not edit product code or publish designs externally without authority.

**Execution contract:** The checklist defines completion. Track each item internally as `PENDING`, `PROVEN` with evidence, `CLEARED` with evidence its condition is absent, or `UNPROVEN` with a gap; reading, delegation, or tool failure is not proof. Reconcile after each section. Before returning, resolve all `PENDING`, count only `PROVEN` and `CLEARED`, and apply verdict and approval rules to every gap.
Preserve intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without skipping checks. Preserve dependency and safety order; otherwise choose an appropriate verification method.
Accept equivalent user or repository evidence; no other skill, named artifact, or complete lifecycle is required. Preserve source requirement and decision IDs. Bind reused evidence to relevant source versions, dirty changes, configuration, and environment; invalidate only affected claims.
On continuation, reconcile task, authorization, current state, and unresolved evidence. For long work, return a compact continuation record or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority.
Prepare authorized work before required approval. If blocked by an instruction, cite its exact source and unresolved boundary; do not invent approval gates from caution.


## Tool Routing

| Need | Preferred capability | Fallback |
|---|---|---|
| Requirements and experience | Accepted product intent, existing UI and design conventions | User-supplied scenarios; essential missing intent is BLOCKED |
| Interaction evidence | Browser, screenshots, accessibility inspection and existing design files | Textual state/flow specification with explicit visual limits |
| Design artifacts | Available design editor or local document/diagram capability | Authorized Markdown or HTML mockup; no required design service |

## Domain Rules

- Reuse the established design source and system. Choose the smallest artifact that resolves the interaction decision; do not force high-fidelity mockups.
- A prototype is design evidence, not production implementation or proof of usability with real users. Label simulated data and untested assumptions.
- Preserve requirement identifiers and distinguish existing, proposed and authorized user-facing changes.

## Checklist

### 1. Frame the Experience

- [ ] Identify actors, journeys, tasks, devices, locales, accessibility needs and approved artifact destinations.
- [ ] Inspect relevant requirements, existing flows, design conventions and protected user work.
- [ ] Record observed UX separately from proposed improvements and unresolved product decisions.
- [ ] Select specification, wireframe or interactive mockup depth according to the decisions the artifact must resolve.

### 2. Design Flows and States

- [ ] Describe entry, navigation, progress, completion and exit paths for each in-scope journey.
- [ ] Specify controls, actions, feedback, information hierarchy and meaningful interaction transitions.
- [ ] Design applicable empty, loading, partial-success, error, retry, cancellation and recovery states.
- [ ] Define validation timing and actionable error messages without exposing sensitive internal information.
- [ ] Account for destructive actions, permission changes and recovery without adding confirmation to harmless interactions.
- [ ] Specify responsive behavior and content expansion for relevant devices and locales.

### 3. Make the Design Implementable

- [ ] Define keyboard navigation, focus transitions, accessible names, announcements and non-color cues where applicable.
- [ ] Reuse established components and tokens; explain any new pattern through a concrete unmet user need.
- [ ] Map requirements to interaction states, copy and observable acceptance; mark missing business rules instead of inventing them.
- [ ] Create the authorized artifact and label simulated behavior, assumptions and unresolved alternatives.

### 4. Validate the Journey

- [ ] Walk every critical path and meaningful recovery route through the actual artifact; inspect rendered mockups when produced.
- [ ] Check consistency of navigation, state transitions, copy, focus and requirement coverage at the selected fidelity.
- [ ] Separate artifact inspection from usability research; record which claims need real user evidence.
- [ ] Preserve unrelated design content and report implementation constraints and decision-changing gaps.

## Verdict

- `READY`: critical interactions are specified and verified at the agreed fidelity with no consequential unresolved design decision.
- `REVISE`: the artifact exists but named interaction or acceptance gaps prevent readiness.
- `BLOCKED`: essential intent, safe artifact authority or a necessary capability has no credible substitute.

## Self-Check

- [ ] **Reconcile before returning.** Check item-level evidence, requirement coverage, contradictions, scope, verdict, and applicable cleanup. Correct the report or authorized artifacts. Reuse valid evidence; do not automatically rescan the repository or rerun successful commands. Repeat checks only for relevant changes, failures, or unresolved evidence. Disclose remaining gaps.

## Output Contract

Report in the user's language, in this order; retain all five fields and state each fact once. Small results may use one line per field; omit empty tables and do not copy linked artifacts:

1. **Result:** Skill-specific verdict and supported outcome.
2. **Scope:** Reviewed/changed scope, exclusions, baseline, and material assumptions.
3. **Evidence:** Skill-specific fields below; distinguish facts, inferences, and unverified claims. Link artifacts; use tables when useful.
4. **Verification:** Checks/results, unavailable evidence, and applicable cleanup/external state.
5. **Completion:** `Checklist: X/Y complete`; `Incomplete: None` or each `UNPROVEN` item's reason, outcome impact, and exact next action; residual risks and required decisions.

**Skill-specific evidence:** Artifact and fidelity, requirement-to-flow/state mapping, authorized UX changes, component reuse, accessibility behavior, inspection results and untested usability assumptions.