make-it-flow

name

make-it-flow

description

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 tradeoffs or behavior is unresolved. Do not use for product discovery, generic usability audits without a pattern decision, purely aesthetic polish, text-only editing, accessibility certification, unrelated debugging, or mechanical implementation of an already complete interaction specification.

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 when requirements are sparse, multiple solutions are plausible, or a no-pattern option may win.
• Read 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 for functional hierarchy, disclosure, list/detail behavior, collections, pagination, or transformation across viewport sizes.
• Read 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 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 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:

## 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.