# Make It Flow > Select, compare, compose, specify, implement, and verify interaction patterns for screen-based interfaces. Use when choosing or revising navigation, screen structure, workflows, list/detail behavior, action and state models, forms, data exploration, feedback and recovery, responsive adaptations, or whether an implementation preserves interaction state, especially when alternatives have meaningful… - **Type:** Skill - **Install:** `agentstack add skill-mrblushu-blushu-design-skills-make-it-flow` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [MrBlushu](https://agentstack.voostack.com/s/mrblushu) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [MrBlushu](https://github.com/MrBlushu) - **Source:** https://github.com/MrBlushu/blushu-design-skills/tree/main/plugins/blushu-design-skills/skills/make-it-flow ## Install ```sh agentstack add skill-mrblushu-blushu-design-skills-make-it-flow ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Make It Flow Turn a concrete interface problem into a coherent, testable interaction model. Implement only when the user explicitly requests a build or change; keep review and advice read-only. ## Workflow 1. **Set scope and mode.** - Classify the request as design, revision, implementation, or review. - Limit mixed requests to the interaction-pattern portion and name any necessary handoff. - Route away unresolved product discovery, pure visual direction, generic usability review, text editing, certification, and unrelated debugging. - If the primary request is a generic audit or asks for everything wrong without naming an interaction-pattern decision, stop after stating that boundary and the appropriate handoff. Do not manufacture a pattern decision from the artifact or produce audit findings. 2. **Inspect before proposing.** - Read supplied artifacts and search the workspace for the existing implementation before asking for more context. - Require a concrete artifact for implementation or review: repository files, a screenshot, prototype, flow, recording, or sufficiently detailed markup/specification. - Locate established components, routes, state ownership, data loading, empty/error states, and relevant tests. - Distinguish observed facts, supported inferences, assumptions, and unknowns. 3. **Capture the decision context.** - Record the task, actors, frequency, content scale, platform, input methods, state lifetime, latency, risk, and constraints only when they can change the choice. - Treat missing evidence as an assumption. Ask only when alternatives would produce materially different, costly, or irreversible work; otherwise choose a reversible default and flag it. 4. **Model the interaction before controls.** - List the relevant objects, actions, states, relationships, transitions, entry, exit, failure, and recovery. - Identify the dominant screen purpose and navigation topology when applicable. - Remove unnecessary steps or unclear state boundaries before selecting a pattern. 5. **Load references selectively.** - Use the routing rules below and read only the files needed for the current decision. - Do not load every reference or recite the reference set as a catalog. 6. **Compare viable candidates.** - Generate no more than three candidates, including a direct unnamed solution when it may be simpler. - Compare user and task fit, content, state, navigation, feedback, recovery, input parity, platform, latency, and technical cost. - Reject mismatched candidates explicitly and choose one; do not return a neutral menu. 7. **Specify each retained pattern.** - State: problem and context; observable fit signals; contraindications and failure modes; effects on content, state, navigation, and feedback; relevant variants; technical dependencies; observable verification criteria. - Write `not applicable` only with a reason. A pattern name without this record is incomplete. 8. **Compose the interaction.** - Define screens or regions, entry and exit, actions, state ownership, transitions, and responsive/input variants. - Resolve conflicts between patterns, including Back, Close, Cancel, Done, focus, shortcuts, gestures, and shared regions. - Coordinate loading, empty, success, error, retry, cancel, undo, persistence, and synchronization. - Preserve selection, location, uncommitted work, and relevant history across switches unless a deliberate reset is safer. 9. **Act according to mode.** - For design, deliver the decision and interaction blueprint. - For revision, identify the current mismatch and the smallest coherent replacement. - For implementation, reuse local conventions, edit the minimum coherent surface, and add or update proportionate tests. - For review, report evidence-backed mismatches and pass criteria without modifying files unless asked to fix them. 10. **Verify and report.** - Exercise the critical task and alternate paths that affect safety, continuity, recovery, input, responsiveness, or latency. - Prefer observable interface behavior over static code inference when a runnable surface exists. - Report in proportion to the task; do not narrate this workflow. ## Collaboration handoff - Accept an optional handoff with goal, evidence, constraints, decisions, open risks, artifact paths, and one next task; verify the artifacts instead of treating the handoff as proof. - Preserve facts, supported inferences, assumptions, unknowns, and prior decisions as distinct states. Reopen a prior decision only for new evidence or a blocking contradiction, and say why. - Own functional regions, relationships, state, behavior, semantic order, and responsive interaction changes; leave tracks, spans, gutters, and query geometry to structural layout work. - When structural layout is the next unresolved responsibility, produce a handoff of at most 400 words containing regions, invariants, DOM and focus order, states to preserve, responsive behaviors, constraints, risks, and artifact paths. - Record retained patterns and rejected alternatives in `Decisions`; keep unverified behavior and missing cases in `Open Risks`. - Set `Next Task` to one precise out-of-scope responsibility. Suggest an installed skill only when useful; otherwise name the capability. Do not require an upstream handoff or make later specialists mandatory. ## Decision order Prioritize: 1. task completion, data integrity, and prevention of irreversible harm; 2. fit to known users, evidence, frequency, skill, and context; 3. state continuity, orientation, feedback, and recovery; 4. accessible input parity and platform conventions; 5. content scale, latency, and technical feasibility; 6. consistency with the product and design system; 7. learnability versus repeated-use efficiency; 8. visual novelty. When candidates are equivalent, choose the simpler, conventional, and reversible option. Change a structural mismatch instead of compensating with explanatory copy. ## Reference routing - Read [pattern-selection.md](references/pattern-selection.md) when requirements are sparse, multiple solutions are plausible, or a no-pattern option may win. - Read [structure-and-navigation.md](references/structure-and-navigation.md) for screen purposes, workflow order, entry points, modes, hierarchy, parallel workspaces, orientation, or movement between places. - Read [content-and-layout.md](references/content-and-layout.md) for functional hierarchy, disclosure, list/detail behavior, collections, pagination, or transformation across viewport sizes. - Read [actions-and-state.md](references/actions-and-state.md) for command placement, asynchronous or destructive work, preview, progress, cancellation, undo, persistence, or cross-view continuity. - Read [data-and-input.md](references/data-and-input.md) for data exploration, filtering, structured or forgiving entry, autocomplete, defaults, validation, and recoverable form errors. - After the request passes the scope check, read [verification.md](references/verification.md) for every in-scope review and after implementation; use it for scenario coverage, transition checks, navigation continuity, input parity, responsive behavior, latency, and evidence-backed findings. If a task crosses domains, load only the intersecting references and keep ownership explicit. Let content/layout choose the spatial relationship; let actions/state define what survives transitions. ## Output Scale the response to the decision. For a small choice, provide context, decision, retained-pattern specification, and verification; keep each required field to a phrase when that is sufficient. For a workflow, revision, or implementation, use: ```markdown ## Context Facts, assumptions, task, platform, and constraints that affect the decision. ## Pattern decision Up to three candidates, rejected alternatives, and the final choice. ## Pattern specification The complete seven-field record for each retained pattern. ## Interaction blueprint Objects, actions, regions, navigation, states, transitions, recovery, and variants. ## Implementation Files/components changed or exact guidance. Include only when relevant. ## Verification Scenarios exercised, observable pass criteria, tests, and residual risks. ``` Use tables only for comparisons or state mappings that become clearer in tabular form. Cite real artifact paths and line numbers when reviewing or implementing. ## Quality rules - Link every choice to the concrete task and available evidence; never invent research, personas, or user behavior. - Resolve conflicting effects between selected patterns instead of listing them independently. - Specify state, feedback, recovery, and technical consequences wherever they can affect the task. - Verify current platform behavior, framework APIs, accessibility rules, and numeric requirements from authoritative current sources when they materially affect the decision. - Never claim accessibility certification from this workflow. - Preserve local product and code conventions unless they cause the interaction mismatch being fixed. - Run proportionate tests and state untested conditions or residual risks. - Keep implementation claims, review findings, and output length proportional to observed evidence and user impact. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [MrBlushu](https://github.com/MrBlushu) - **Source:** [MrBlushu/blushu-design-skills](https://github.com/MrBlushu/blushu-design-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-mrblushu-blushu-design-skills-make-it-flow - Seller: https://agentstack.voostack.com/s/mrblushu - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.