Terminology & Prompting

Prompt Library

Common reusable prompts for starting projects, setting standards, reviewing work, troubleshooting, quality control, implementation, safety, and handoffs.

Before we design or build anything, conduct a needs analysis with me. Separate what I provide into Known Facts, Assumptions, Unknowns, and AI Inferences. Consider the users, goals, geography and languages where relevant, accessibility, devices, environment, current problem, desired outcome, organizational requirements, constraints, privacy/security, and success measures. Ask only the highest-priority questions whose answers could materially change the solution. Then recommend the next artifact or decision. Do not build yet.

Using the approved needs analysis, create a concise Project Brief covering WHAT we are making, WHO it serves, WHY it exists, WHERE it will run, RULES and constraints, what SUCCESS means, scope/non-goals, unresolved decisions, and the FIRST STEP. Do not invent missing requirements. Recommend and plan first; do not build yet.

Before producing at scale, create a proposed Design & Content Standards specification. Cover typography/type scale, colors, spacing, visual style, imagery/iconography, accessibility, voice and tone, terminology, and reusable components. Classify each rule as Locked, Controlled, Flexible, or Approval Required. Clearly separate observed patterns from your inferences. Wait for approval before large-scale production.

Before creating all instances, build one representative implementation using realistic content. Stress-test it with short, typical, and unusually long content and the important supported screen sizes/orientations. Treat it as a proposed reference implementation. Do not generate the remaining instances until I approve the pattern.

Identify repeated layout and interaction patterns and propose a small library of reusable named blocks/components with stable IDs and documented variants. New pages should use approved components unless a genuinely new pattern is needed. Recommend the component system first; do not redesign every page independently.

Evaluate this independently before discussing it as a group. Use separate UX, UI/visual design, accessibility, content, technical/QA, and first-time-user perspectives. Each reviewer should record findings, severity, confidence, reasoning, and evidence without seeing the other reviews. Then have a synthesizer compare findings, identify agreement and disagreement, and recommend priorities. Do not treat majority vote as proof. Do not implement changes yet.

Create 10 clearly labeled synthetic first-time-user perspectives with varied relevant backgrounds, technical confidence, goals, devices, and accessibility considerations. Give each the same realistic tasks and run independent cognitive walkthroughs. Record where each would likely hesitate, misunderstand terminology, choose the wrong path, get stuck, or succeed. Synthesize recurring friction afterward. Treat all findings as hypotheses from simulated users, not evidence from real usability participants.

Review the implemented change against the original request and Definition of Done. Check functionality, visual consistency, accessibility, responsive behavior, important edge cases, broken links/references, regressions, and unintended changes outside scope. Distinguish what you actually verified from what you only inferred. Report issues with severity and evidence. Do not make additional changes until I approve them.

Observe and reproduce the problem before editing. Separate the visible symptom from likely root causes. Identify the smallest affected scope, gather evidence, and compare plausible causes. Recommend the most likely cause and the safest verification step. Do not change code until the diagnosis is sufficiently supported.

Before fixing this edge case, tell me how common or important the affected use case is, what additional complexity explicit support introduces, what regressions or maintenance burden it could create, and whether excluding it from the supported range is reasonable. Compare root-cause fix, workaround, fallback, requirement change, and explicit non-support. Recommend first; do not change code.

The preferred approach is not available. Give me 2–4 workarounds or alternative approaches. For each, explain what it preserves, what it sacrifices, complexity, risk, reversibility, and whether it is temporary or suitable as a long-term solution. Recommend the simplest acceptable option. Do not change anything yet.

Implement the approved changes in the current working project and run the appropriate verification. Report the files or components changed and the evidence that the result works. Do not commit, push, publish, or deploy without my explicit approval.

Do exactly the requested work. Anything outside the stated scope should be reported as an opportunity or concern, not changed. Preserve unrelated work. If a requested change would require touching protected or unrelated areas, stop and explain why before proceeding.

Before acting, summarize the knowledge, context, permission, execution, and trust boundaries for this task. Tell me what you can read, what you can change, where the action will execute, what external systems or data it will touch, and which steps are reversible. Ask for approval before any destructive, publishing, deployment, account, or permission-changing action.

Create or update a portable project handoff that another AI or human collaborator can use without relying on this chat. Include the current goal, completed work, open work, important decisions, source-of-truth files, files changed, tests and results, known failures, protected areas, Git state if applicable, and the exact recommended next step. Do not include secrets.

I may be using the wrong terminology. Based on the visible location, purpose, and behavior I describe, tell me the most likely technical/UI term and any common alternatives. Explain the term in plain English and confirm the target before editing anything.

Review the supplied company materials and identify recurring patterns in typography, colors, spacing, imagery, components, terminology, voice, and tone. Separate directly observed patterns from your inferences. Propose a reusable design/content system, but do not treat inferred patterns as approved company standards until I confirm them.

Before changing the layout, evaluate portrait, landscape, phone, tablet, desktop, touch, pointer, and unusual screen sizes separately. Identify the minimum supported viewport and important safe-area/cutout considerations. Recommend which cases should reflow, scale, use a fallback, or reasonably remain unsupported. Explain complexity and regression risk before editing.