Patterns/Featured
How to usePrompt builder

Interface patterns

12 patterns

View pattern
View pattern
View pattern
View pattern
View pattern
View pattern
View pattern
View pattern
View pattern
View pattern
View pattern
View pattern

Use the interaction, not the decoration.

Choose a pattern by the decision it helps someone make. Keep the required states, then adapt its visual language to your product.

Refine your build prompt
Starting work

Context Composer

A prompt input that collects the job, source material, constraints, and output format before the assistant starts.

OutcomeFewer clarification loops and fewer polished answers to the wrong question.

Use when

The quality of the answer depends on context the user may forget to provide.

Avoid when

A single short question is enough and extra setup would slow the user down.

Anatomy

  • Job field
  • Context attachments
  • Constraint controls
  • Output format
  • Send action

Required states

  • Empty
  • Ready
  • Uploading context
  • Blocked by missing input
  • Submitted

Build prompt

Build a Context Composer for [product and audience].

The component must help a user define:
- the job to be done
- the source material the assistant may use
- hard constraints
- the required output format

Keep one primary text field visible. Put optional controls in a compact expandable area. Show attached sources as removable items with file type and size. Disable the primary action only when a genuinely required input is missing, and explain what is missing beside the action.

Include empty, ready, uploading, validation-error, and submitted states. Support keyboard submission without making Enter submit multiline text accidentally. Use explicit labels, a visible focus state, and an aria-live status for uploads and submission.
Starting work

Useful Starters

An empty state that offers a small set of outcome-based starting points instead of generic example prompts.

OutcomeA blank workspace becomes a deliberate first step.

Use when

Users know the broad job but may not know how to begin or what the assistant can do.

Avoid when

The workflow has one obvious first action or the user already supplied a request.

Anatomy

  • Outcome heading
  • Three to five starters
  • Context hint
  • Custom path

Required states

  • First visit
  • Returning user
  • Starter selected
  • No relevant starter

Build prompt

Build a Useful Starters empty state for [workflow].

Offer three to five starting actions based on outcomes, not features. Each option should be a complete verb phrase such as "Compare two supplier proposals" rather than a vague topic such as "Analysis".

Selecting an option should prefill the main composer with a structured draft while keeping it editable. Include a clear path for a custom request. If prior work exists, replace generic starters with recent or relevant actions.

Design first-visit, returning-user, selected, and no-relevant-suggestion states. Keep the choices keyboard accessible and make the selected result obvious without relying only on color.
Reviewing work

Evidence Stack

A review surface that keeps each claim beside its source, confidence, and unresolved caveats.

OutcomeReviewers can check the answer claim by claim instead of hunting through a bibliography.

Use when

Users must verify research, policy, financial, medical, or other source-dependent work.

Avoid when

The content is creative, subjective, or does not make factual claims.

Anatomy

  • Claim
  • Source excerpt
  • Source link
  • Confidence label
  • Caveat
  • Review action

Required states

  • Supported
  • Partly supported
  • Conflicting sources
  • No source
  • Reviewed

Build prompt

Build an Evidence Stack for [research workflow].

Render the answer as a sequence of reviewable claims. Keep every claim physically connected to its supporting sources, publication dates, and a plain-language confidence label. Show unresolved caveats before the user approves the claim.

Do not hide weak evidence behind a single overall score. Let reviewers mark a claim as checked, request a better source, or exclude it from the final output. Preserve the original source link and enough quoted context to verify the interpretation.

Include supported, partly supported, conflicting, unsourced, loading, and reviewed states. Make the relationship between claims and sources understandable to screen-reader users.
Reviewing work

Decision Approval

A focused approval block with the proposed result, consequences, and distinct approve, revise, and reject paths.

OutcomeApproval becomes informed and auditable instead of a vague yes or no.

Use when

A human must own a consequential decision before work proceeds.

Avoid when

The action is easily reversible and does not need a formal checkpoint.

Anatomy

  • Proposal summary
  • Impact
  • Evidence link
  • Approve
  • Request changes
  • Reject reason

Required states

  • Awaiting review
  • Approved
  • Changes requested
  • Rejected
  • Expired

Build prompt

Build a Decision Approval component for [workflow].

Present one decision at a time. State what is being approved, what will happen next, which inputs informed it, and whether the action can be reversed. Keep Approve, Request changes, and Reject visually distinct without making the destructive choice dominant.

Require a short reason for rejection. Let a reviewer request changes with specific feedback. After any decision, replace the controls with a receipt containing the reviewer, time, decision, and next action.

Include awaiting-review, approved, changes-requested, rejected, expired, and permission-error states. Trap no focus, support keyboard use, and announce the saved decision.
Reviewing work

Draft Comparison

A comparison view that explains meaningful differences between two outputs and lets users choose by section.

OutcomeThe user chooses based on differences that matter, not on scanning two walls of text.

Use when

Users need to compare revisions, model outputs, or competing approaches.

Avoid when

The alternatives differ so little that a concise change summary would be clearer.

Anatomy

  • Shared brief
  • Difference summary
  • Aligned sections
  • Choose section
  • Final selection

Required states

  • Loading both drafts
  • Comparable
  • Missing section
  • Mixed selection
  • Finalized

Build prompt

Build a Draft Comparison for [content or decision workflow].

Align equivalent sections from two drafts and summarize the meaningful differences before showing full text. Let the user choose one complete draft or pick preferred sections from each. Clearly identify any section that exists on only one side.

Do not use a generic red and green diff for subjective writing. Describe tradeoffs in plain language, such as "shorter and more direct" or "includes two additional sources". Keep the original brief visible in a compact reference area.

Include loading, comparable, missing-section, mixed-selection, finalized, and comparison-error states. Preserve reading order on mobile by presenting one aligned section at a time.
Agent operations

Agent Plan

A plan preview that separates autonomous steps from checkpoints, risks, and expected deliverables.

OutcomeUsers understand what the agent will do and where it must stop for approval.

Use when

An agent will take several actions or touch external systems before returning a result.

Avoid when

The job is a single low-risk read or transformation.

Anatomy

  • Goal
  • Ordered actions
  • Tool scope
  • Checkpoints
  • Risks
  • Deliverables

Required states

  • Draft plan
  • Needs approval
  • Running
  • Plan changed
  • Completed
  • Stopped

Build prompt

Build an Agent Plan component for [agent workflow].

Start with the goal and expected deliverables. Show ordered actions with the tool or system each action will touch. Visually separate actions the agent may perform automatically from actions that require human approval.

Surface material risks beside the relevant action, not in a detached warning box. If the plan changes while running, show what changed and why before continuing. Provide Start, Edit plan, and Stop controls with one clear primary action.

Include draft, needs-approval, running, changed-plan, completed, stopped, and failed states. Use an ordered semantic list and expose progress changes through an aria-live region.
Agent operations

Tool Receipt

A compact record of what an agent sent to a tool, what changed, and where to inspect the result.

OutcomeTool activity is understandable without dumping raw logs into the conversation.

Use when

An agent reads or changes an external service and the user needs traceability.

Avoid when

The tool call is an internal implementation detail with no user-facing consequence.

Anatomy

  • Tool name
  • Purpose
  • Input scope
  • Result summary
  • Changed items
  • Raw details

Required states

  • Queued
  • Running
  • Succeeded
  • Partial
  • Failed
  • Undone

Build prompt

Build a Tool Receipt for [agent and tool].

Summarize why the tool was called, what data or records were in scope, what changed, and where the result can be inspected. Keep raw request and response data available in a collapsed technical detail area.

For write actions, list created, updated, and removed items separately. For read actions, report the query scope and result count. Provide an undo action only when reversal is genuinely supported.

Include queued, running, succeeded, partial, failed, and undone states. Never expose secrets or personal data in the collapsed details. Use status text and icons or shape, not color alone.
Agent operations

Durable Progress

A long-running progress view organized around completed deliverables, current work, and recoverable interruptions.

OutcomeProgress remains trustworthy across refreshes, retries, and handoffs.

Use when

The task may continue for minutes or hours and users can leave and return.

Avoid when

The operation normally completes within a few seconds.

Anatomy

  • Overall status
  • Completed deliverables
  • Current action
  • Pending work
  • Resume point
  • Cancel

Required states

  • Starting
  • Running
  • Waiting
  • Interrupted
  • Resuming
  • Completed
  • Cancelled

Build prompt

Build a Durable Progress view for [long-running workflow].

Organize progress around real deliverables rather than an invented percentage. Show what is complete, what is happening now, what is waiting, and whether the user may safely leave. Persist enough state that a returning user sees the same task and its latest update.

If work is interrupted, explain whether it can resume from the last completed action or must restart. Keep Cancel available but separate from the main progress narrative. Show time only when it is measured, not guessed.

Include starting, running, waiting-for-input, interrupted, resuming, completed, cancelled, and stale-state variants. Announce meaningful stage changes without announcing every minor log line.
Agent operations

Human Checkpoint

A pre-action checkpoint for irreversible, expensive, public, or permission-changing operations.

OutcomeThe user sees the exact target and consequence before committing.

Use when

The next action sends, publishes, deletes, purchases, deploys, or changes access.

Avoid when

The action is a normal reversible edit already covered by the user request.

Anatomy

  • Action statement
  • Exact target
  • Consequence
  • Cost or reach
  • Confirm
  • Go back

Required states

  • Ready to confirm
  • Target changed
  • Confirming
  • Completed
  • Failed

Build prompt

Build a Human Checkpoint for [high-consequence action].

Use a direct sentence that names the action and exact target. Show the immediate consequence, whether it is reversible, and any real cost, audience reach, or permission change. Do not use a generic "Are you sure?" dialog.

The confirm label must name the action, such as "Publish article" or "Delete 12 records". Keep the safe return action visible. If the target changes after the checkpoint opens, invalidate confirmation and require review again.

Include ready, changed-target, confirming, completed, permission-error, and failed states. Move initial focus to the heading, return focus on close, and do not confirm from a single Enter keypress on a destructive action.
Decision support

Model Fit Matrix

A task-first model comparison that turns cost, speed, reliability, and capability into a clear recommendation.

OutcomeThe recommendation is tied to the job instead of a universal best-model claim.

Use when

A user must choose a model or tool for a specific recurring job.

Avoid when

The page is a general benchmark leaderboard with no defined workload.

Anatomy

  • Job definition
  • Decision criteria
  • Candidate rows
  • Tradeoffs
  • Recommendation
  • Source date

Required states

  • Needs job
  • Comparing
  • Recommended
  • Insufficient evidence
  • Data outdated

Build prompt

Build a Model Fit Matrix for [defined job].

Ask for the job, budget boundary, latency tolerance, required context, and quality threshold before ranking candidates. Show only criteria that affect this job. Provide a recommendation with explicit tradeoffs and a lower-cost or faster fallback.

Keep benchmark sources and dates visible. Mark missing or incomparable data rather than converting it into a zero. Avoid one overall score unless the weighting formula is visible and editable.

Include needs-job, comparing, recommendation-ready, insufficient-evidence, outdated-data, and source-error states. Tables must have proper headers and remain readable as stacked candidate summaries on small screens.
Decision support

Research Brief

A compact research output that separates the answer, supporting findings, unknowns, and next actions.

OutcomeReaders get the decision-relevant answer without losing the evidence or uncertainty.

Use when

Research must lead to a decision or a clear next step.

Avoid when

The user asked for a raw source collection or an exhaustive literature review.

Anatomy

  • Question
  • Short answer
  • Key findings
  • Evidence
  • Unknowns
  • Recommended next action

Required states

  • Scoping
  • Researching
  • Draft
  • Needs evidence
  • Reviewed

Build prompt

Build a Research Brief component for [audience and decision].

Lead with the research question and a short answer. Follow with the few findings that materially affect the decision, each connected to evidence. Keep unknowns and conflicting evidence in their own visible section.

End with a recommended next action and who should own it. Do not turn the brief into a generic article or hide uncertainty in footnotes. Allow reviewers to request evidence for a specific finding.

Include scoping, researching, draft, needs-evidence, reviewed, and blocked states. Use semantic headings, descriptive source links, and a print layout that preserves source references.
Decision support

Recovery Panel

An error state that explains what completed, what failed, and the safest route forward.

OutcomeUsers recover without repeating completed work or guessing what the system changed.

Use when

A multi-step task can fail after producing partial work or changing external state.

Avoid when

A field-level validation message can resolve the issue in place.

Anatomy

  • Plain-language failure
  • Completed work
  • Unfinished work
  • Safe retry
  • Fallback
  • Technical details

Required states

  • Retry available
  • Fallback available
  • Needs permission
  • Needs input
  • Cannot continue

Build prompt

Build a Recovery Panel for [workflow].

Explain the failure in plain language. Separate completed work from unfinished work and state whether retrying will duplicate any action. Offer the safest next step as the primary action and a realistic fallback when one exists.

Keep technical diagnostics in an expandable area with a copy button. If permission or user input is required, say exactly what is needed. Never erase partial results when the user retries.

Include safe-retry, fallback, needs-permission, needs-input, cannot-continue, and recovered states. Move focus to the error heading, use an assertive live announcement only for blocking failures, and preserve entered data.