interaction-map
Analyze every interactive UI element — classify effects, detect broken promises, map cross-screen dependencies
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Analyze every interactive UI element — classify effects, detect broken promises, map cross-screen dependencies
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Full QA procedure — interaction map, unit tests, Maestro flows, visual review
Add/remove features, fix bugs, redesign — keeping code clean and artifacts in sync
Generate a new mobile app — full pipeline or code-only if PRD already exists
Run full QA — interaction map, unit tests, Maestro UI tests, visual review
Read screenshots and verify UI against DESIGN.md, reference mockups, and quality checklist
Build an app from a pre-written PRD file without interactive discovery
| name | interaction-map |
| description | Analyze every interactive UI element — classify effects, detect broken promises, map cross-screen dependencies |
Build an interaction map for every interactive element in the app.
For EVERY interactive element in the codebase — onPress, onValueChange, onSubmit:
Determine what a USER expects from the element's label, type, and context — NOT from reading the handler code. Infer expected behavior from what the control promises visually.
Read the handler code and trace the effect chain: handler → state change → re-render → UI change
Compare user expectation vs actual effect. If the UI promises something the code doesn't deliver — that's a bug, not a "design gap".
Classify the effect type:
| Type | Example | How to test |
|---|---|---|
| Visual on current screen | "Save" → success message appears | Maestro: tap → assertVisible |
| Visual on another screen | Setting that affects other screens | Maestro: tap → navigate → takeScreenshot → Claude reviews |
| Navigation | "View Details" → detail screen opens | Maestro: tap → assertVisible destination |
| State without immediate visual | Store update, preference save | Unit test: fireEvent.press → expect(store.field).toBe(value) |
| Side effect without visual | Analytics event, prefetch, log | Unit test: expect(mockFn).toHaveBeenCalled() |
| Broken promise | Control's label implies an effect that doesn't happen | Report as BUG |
CRITICAL RULE: "stores preference but has no visible effect" is a BUG if the user would expect a visible effect from the control's label and context. Do NOT classify unimplemented functionality as "design gaps" — if the UI shows the control, the feature must work.
Output: a table with columns: Element | testID | Screen | Effect Type | Details | Bug?