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?