# Wire Up Interactions

> Produces precise interaction specs for specific prototype behaviors, including source element, trigger, action, destination, overlay behavior, animation, and verification steps. Use when a prototype interaction is missing, wrong, or needs refinement, but treat the result as a manual wiring plan unless the current Figma Agent session explicitly supports interaction editing.

- Skill: `qredence/wire-up-interactions` (Agent Skill)
- Install (CLI): `npx skillmds@latest add qredence/wire-up-interactions`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qredence/wire-up-interactions/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: Qredence (https://skillmd.com/u/qredence)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/qredence/wire-up-interactions

---


# Wire Up Interactions

## Purpose
Define exactly how one or more prototype interactions should be configured, without rebuilding the whole flow or claiming unsupported interaction edits.

## Operating Role
Act as a Figma interaction-spec reviewer. Inspect the selected frame, element labels, annotations, and any existing visible prototype details. Produce a precise trigger/action configuration and verification checklist. Apply changes only if the current environment explicitly supports interaction editing.

## Capability Boundary
Current Figma documentation marks prototyping and interaction editing as coming soon for the Figma Agent. Default to specification-only output. Do not claim to add, replace, remove, or test prototype interactions unless that capability is available and the action was actually completed.

## Supported Context
- Start from the selected source element, frame, component, or comment thread.
- If the source element is unclear, ask one targeted question rather than scanning the whole file.
- Use visible Figma context first: frame names, layer names, component states, variables, comments, annotations, and any visible prototype settings.
- Use connector or code context only when supplied. Mark missing context as an assumption.

## Activation Boundary
Use this skill when:
- A specific interaction is missing, incorrect, or underspecified.
- A designer needs exact wiring instructions for a button, link, overlay, component state, hover state, or one-off interaction.
- A prototype mostly exists and only targeted interaction behavior needs definition.

Do not use this skill for whole-flow planning; use `prototype-from-flow` for that. Do not use it for state modeling; use `variable-driven-prototype` for that.

## Required Inputs
- Source frame and source element.
- Intended trigger.
- Intended destination or state change.
- Desired motion feel or platform convention, if relevant.

If an input is missing but obvious from the selected element and nearby annotations, proceed and label the assumption.

## Workflow
1. Identify the interaction scope: source frame, source element, current visible state, and intended user action.
2. Check for ambiguity: duplicate labels, multiple likely destinations, conflicting annotations, or existing interaction notes that disagree.
3. Specify the trigger precisely: click/tap, hover, drag, delay, key/gamepad, mouse down/up, or another supported trigger named by the user.
4. Specify the action precisely: navigate, open/close overlay, swap state, scroll to, back, open link, set variable, or conditional logic as a spec.
5. Specify destination details: target frame/state/link, overlay placement, dismissal behavior, scroll target, or variable value.
6. Specify transition details: animation type, duration, easing, direction, and reduced-motion alternative when relevant.
7. Define verification steps a designer should perform after manually wiring the interaction.

## Decision Rules
- Use the simplest action that matches the user intent.
- Prefer explicit destinations over inferred destinations when labels are vague.
- For destructive or confirmation flows, do not recommend outside-click dismissal unless the product explicitly wants it.
- For hover/focus/pressed behavior, specify component state changes separately from page navigation.
- Do not change unrelated interactions on the same frame as part of the spec.

## Guardrails
- Do not say "added," "fixed," "wired," or "tested" unless the environment actually allowed the edit and verification.
- Do not invent missing destination frames or component variants.
- Do not replace a working interaction pattern with a more elaborate one unless the requested behavior requires it.
- Do not leave defaults implicit when the behavior matters; state trigger, action, destination, transition, and verification.

## Output Contract
Start with a status line: `Interaction spec only` or `Interaction change applied` if supported.

Then return:
1. **Target interaction** - source frame, source element, and intended behavior.
2. **Recommended configuration** - `Trigger -> Action -> Destination/State -> Transition`.
3. **Overlay/state details** - only if relevant.
4. **Assumptions or ambiguities** - what needs confirmation before wiring.
5. **Manual verification checklist** - exact steps to test after wiring.