Prompt Recipes

Act as a senior [role, e.g., design systems designer / UX director / front-end engineer]. Review the following [deliverable, e.g., component spec / Confluence doc / Figma annotation]. Provide feedback on: 1. Clarity and completeness 2. Gaps or edge cases I may have missed 3. Whether this meets the standard expected at a senior IC level Be direct. Do not flatter me. Here is the content: [paste content]

I am writing documentation for a design system component. Here are two examples of the format and tone I use: Example 1: [paste existing doc] Example 2: [paste existing doc] Now write documentation for [component name] following the same structure and tone. Include: overview, variants, usage guidance, do/don't, edge cases, and accessibility notes.

Step 1 — Send this first: Here are my rough notes on [topic]. Summarize the key points and identify any gaps or missing information I should address before writing the full page. [paste notes] Step 2 — After reviewing the summary, send: Now structure this into a Confluence page. Use the following sections: [Overview / Context / Guidance / Examples / Related Resources]. Keep the tone clear and professional. Audience is [designers / engineers / cross-functional]. Step 3 — Polish: Review the draft above. Tighten any sections that are vague. Flag anything that reads like an assumption rather than a decision.

Act as a senior design systems auditor. I will give you a list of [components / patterns / screen descriptions]. For each item, identify: 1. Inconsistencies with standard design system patterns 2. Missing variants or states 3. Accessibility concerns 4. Recommendations for consolidation or standardization Format your output as a table with columns: Item | Issue | Severity (High / Med / Low) | Recommendation Here is the list: [paste content]

I completed the following work: [describe what you did in plain terms]. Reframe this as a senior-level impact statement using this format: [Action verb] + [what you built or led] + [who it affected or how many] + [measurable or qualitative outcome] Write 3 versions: one for a self-review, one for a LinkedIn bullet, and one for a verbal summary I could say in a 1:1 with my manager.

I need to communicate [situation, e.g., a blocker / a scope concern / feedback on a decision] to [person, e.g., my manager / a PM / an engineer]. My goal is: [state desired outcome, e.g., get a decision unblocked / flag a risk without derailing the project] The relationship context is: [e.g., my direct manager / a peer I collaborate with regularly] Give me: 1. Key points to lead with 2. How to frame the concern constructively 3. A short version for a Teams message 4. A longer version for a written async update

Act as a senior strategy consultant. I am making a decision about [design system initiative, e.g., which pattern to document first / whether to build a new component vs. adapt an existing one]. Apply two of the following frameworks to help me think through the decision: - MECE breakdown - Impact vs. Effort matrix - Jobs to be Done - Now / Next / Later For each framework, walk me through how it applies to my situation and what it reveals. Then give me a clear recommendation with your reasoning. My situation: [describe in 3-5 sentences]

I have a goal: [e.g., earn a promotion to Senior System Product Designer within the next 6-9 months]. Using the Backwards Planning Method: 1. Identify the minimum requirements to qualify for this goal 2. Break the goal into quarterly milestones working backwards from the target date 3. Convert milestones into monthly actions 4. Suggest weekly habits that contribute to progress 5. Identify the biggest obstacles and how to address them 6. Suggest metrics I can use to track progress My advantages: [e.g., active ownership of pattern documentation, Reskin Initiative lead role, strong cross-functional relationships] My obstacles: [e.g., design systems specialization is recent, estimation reliability flagged in past review]

Summarize the following [meeting notes / async thread / transcript] into three sections: 1. Key Decisions — what was agreed upon 2. Action Items — table with columns: Task | Owner | Deadline 3. Open Questions — anything that still needs resolution Use plain, professional language. Cut filler. If a field is unknown, write "Not specified." Here is the content: [paste content]

Rewrite the following message for [channel: Teams / Jira / Figma / email]. Channel guidance: - Teams: casual, warm, brief — 1-3 sentences - Jira: formal, structured, rationale-driven — bullet points preferred - Figma: friendly, collaborative, action-oriented - Email: professional, concise, clear ask at the end Original message: [paste your draft] Target channel: [channel] Audience: [e.g., my manager / a cross-functional engineer / the full design team]

My main goal this sprint / this week is: [state your primary objective]. Here is my full task list: [paste list] Organize these using the Eisenhower Matrix: - Urgent + Important: do now - Important + Not Urgent: schedule - Urgent + Not Important: delegate or timebox - Neither: cut or defer For anything in the "do now" category, suggest a rough time estimate. Flag anything that depends on another person or team as a potential blocker.

I am building [feature name, e.g., a Figma plugin that syncs components from a codebase into a Figma library]. Before writing any code, help me break this down into: 1. User stories (what the user should be able to do when this is complete) 2. Epics (major functional areas) 3. MVP features vs. nice-to-have features 4. The smallest first chunk I could build and test independently Do not write any code yet. Ask me clarifying questions if anything is unclear.

Before writing any code, explain your approach step by step. Include: 1. What files or components you plan to create or modify 2. What assumptions you are making about the existing codebase 3. Any potential issues or edge cases you foresee 4. An estimate of how many steps this will take DO NOT CHANGE OR CREATE ANYTHING YET. Wait for my approval before proceeding.

Act as a senior solutions architect. I am building [describe project in 1-2 sentences]. Recommend 3 different tech stack options. For each: - List what it includes (frontend, backend if needed, data layer, deployment) - Explain why it fits my situation in plain language - State the main trade-offs - Give a rough complexity estimate (low / medium / high) End with a comparison table and a clear recommendation. My constraints: [e.g., must work as a Figma plugin / no backend / team has limited JS experience] DO NOT WRITE ANY CODE YET.

Summarize this meeting transcript. Then provide two outputs: 1. A one paragraph summary written in plain prose — cover the purpose of the meeting, the main discussion points, and any outcomes or next steps. 2. A simplified highlights version as bullet points — keep each bullet to one clear, concise thought. Focus on decisions made, actions agreed upon, and anything someone who missed the meeting would need to know. Transcript attached.

Using the Figma MCP, read the components on this page: [node ID or page name]. Compare what you find against these rules: - Naming convention: [describe your convention] - Token usage: components should use semantic tokens, not raw hex or hardcoded values - Variant completeness: [list expected variants/states if relevant] Output your findings as a table with columns: Component | Issue | Severity (High / Med / Low) | Recommendation

Using the Figma MCP, read the component set at: [node ID or component name]. List all existing variants and properties you find. Then compare against this expected list of states: [e.g., default, hover, pressed, disabled, focused, error] Flag any missing variants, and note any variants that exist but seem incomplete or inconsistent with the others.

Using the Figma MCP, get the variable definitions for: [node ID or component name]. Explain in plain English which semantic tokens map to which visual properties (color, spacing, typography, etc.) on this component. Write this for an audience of designers who are new to the token system. Avoid jargon where possible, and use the actual token names so they can find them in Figma.

Using the Figma MCP, view this frame: [node ID or frame name]. Critique it against usability, visual hierarchy, consistency with the design system, and accessibility. Structure your response as: 1. Strengths — what's working well 2. Concerns — what might raise questions in review 3. Suggestions — specific, actionable changes Be direct. This is a first pass before a live critique, so don't soften issues that would come up in the room.

Using the Figma MCP, view this component: [node ID or component name]. Based on its structure, naming, and any annotations, infer its purpose and likely behavior. Draft the following sections for a documentation page: - When to use - When not to use - A short description of how it behaves (states, interactions, variants) Write this as a first draft — flag anything you inferred versus anything that's explicit in the file, so I know what to verify.

I'm coming back to [this chat or task ] after some time away. Before I do any new work, help me reorient. Search our past conversations in this project and produce a status brief covering: 1. WHERE I LEFT OFF - What stage of the work I was at (drafting, reviewing, finalizing, blocked) - The last meaningful decision I made or output I produced 2. KEY DECISIONS LOCKED IN - Component choices (chip, badge, toolbar treatment) - Terminology I committed to - Anything I inherited from Adanma's Reset All Filters pattern for cohesion - Sizing, spacing, or overflow rules I settled on 3. OPEN QUESTIONS STILL UNRESOLVED - List each one - Who I flagged as the owner for resolution - Whether I had a leaning or it's genuinely undecided 4. WHAT'S LEFT TO DO - Specific next action, not a general phase - Any dependencies (waiting on PM, design, engineering) 5. CONTEXT I MIGHT HAVE FORGOTTEN - Anything from the ticket acceptance criteria I haven't addressed yet - Any sync conversations or feedback that shaped decisions Format this as a brief, not a transcript. I want to read it in under two minutes and know exactly where to pick up. If you can't find clear answers in past conversations for any of these sections, say so explicitly rather than guessing. I'd rather know there's a gap than get a confident-sounding summary built on assumptions.

I am doing more development work and need help learning and understanding our team process. Explain each section of this page as if you have to teach me what these development terms mean. I know html, css and basic JS, with a little React. I have used the command line but it's been a while since I was a power user. [Link]

I want to construct a new Claude project and need help creating the custom instructions, project description, and a list recommende knowledge base artifacts. I'm going to feed you a bunch of information about what I need for this project to do, and when I'm ready, I'll let you know to construct it.

Lets look into industry best practices for each item and revise your recommendations accordingly. Please provide confidence scores and cite yourself per recomendation.

Summarize this chat for migration: capture the goal of the conversation, the key decisions or conclusions, any code or artifacts produced, and any open questions. Output as a single Markdown block I can paste into a new chat.Then list any files generated in the conversation so I can download them.