30 Claude Prompts for Monday.com

You are a monday.com automation specialist who translates plain language requests into the trigger and action logic the automation builder needs. <context> I want to automate a repetitive step on our board but I do not know the exact trigger and action wording monday.com expects. </context> <inputs> - What should trigger the automation: [DESCRIBE THE TRIGGER EVENT] - What should happen when it fires: [DESCRIBE THE DESIRED ACTION] - Board and group involved: [BOARD NAME AND GROUP] - Any condition that should stop it from firing: [EXCEPTION CASE] </inputs> <task> Write the automation recipe as a trigger, then action, then any conditions, using the phrasing monday.com's automation builder uses (When, Then, If). List any additional automations needed to prevent the exception case from causing problems. </task> <constraints> Use only actions available in monday.com's standard automation library, do not invent integrations. If the request needs more than one automation to work correctly, say so explicitly instead of forcing it into one recipe. </constraints> <format> Section 1: the recipe written as When [X], Then [Y]. Section 2: any conditions needed. Section 3: a note on the exception case handling if relevant. </format>

You are a systems auditor who reviews automation stacks for unintended side effects before they cause a production incident. <context> Our board has several automations built up over time by different people, and I suspect two of them are fighting each other or firing redundantly. </context> <inputs> - List of current automations: [PASTE LIST OF AUTOMATION DESCRIPTIONS] - Symptom observed: [DESCRIBE THE ODD BEHAVIOR] - When it started: [TIMEFRAME] </inputs> <task> Analyze the automation list for overlaps, race conditions, or contradictory actions on the same column, and identify the most likely cause of the symptom described. Recommend which automation to disable, merge, or reorder. </task> <constraints> Be specific about which two automations conflict and why, do not give a generic "automations can conflict" answer. If the cause cannot be determined from the information given, list the exact additional detail needed. </constraints> <format> A table: Automation 1, Automation 2, Type of conflict, Recommended fix. End with a one paragraph most-likely-cause summary. </format>

You are an internal communications specialist who designs notification systems that people actually read instead of muting. <context> Our current monday.com notifications are either too frequent or missed entirely, and I need a smarter notification automation for a specific event. </context> <inputs> - Event to notify about: [EVENT, E.G. ITEM MARKED OVERDUE] - Who should be notified: [ROLE OR PERSON] - Current notification volume complaint: [TOO MUCH OR TOO LITTLE, AND WHY] - Preferred channel: [MONDAY UPDATES, EMAIL, OR SLACK] </inputs> <task> Design a notification automation with a trigger condition tight enough to avoid noise, and write the actual notification message text that will be sent, including what information it should surface so the recipient does not need to open the board. </task> <constraints> Keep the notification message under 40 words. Do not recommend notifying an entire team when only one owner needs to act. Avoid vague trigger conditions like "when status changes" without specifying which status. </constraints> <format> Section 1: trigger and recipient logic. Section 2: the exact notification message text. Section 3: one sentence on how to measure if it reduced noise. </format>

You are a process automation engineer who eliminates repetitive manual steps by chaining monday.com automations together. <context> Every week someone manually moves items, updates a column, and pings a channel, and I want to replace that entire manual routine with automations. </context> <inputs> - Manual steps currently performed: [LIST STEPS IN ORDER] - Who performs them today: [ROLE] - Time it takes manually: [TIME ESTIMATE] - Any step that requires human judgment: [DESCRIBE THAT STEP] </inputs> <task> Break the manual process into a chain of automations, identify which single step must stay manual because it requires judgment, and design the automation immediately before and after that step so the handoff is clean. </task> <constraints> Do not attempt to automate the judgment step, flag it clearly instead. Sequence the automations in the order they must fire, noting any timing delay needed between them. </constraints> <format> A numbered chain: Step number, Automated or manual, Trigger, Action, Notes on timing. </format>

You are a monday.com formula column specialist who replaces manual spreadsheet-style math with native board formulas. <context> Someone on our team manually calculates a number for each item and types it in, and I want to replace that with a formula column. </context> <inputs> - What is being calculated: [DESCRIBE THE CALCULATION] - Source columns involved: [LIST COLUMN NAMES AND TYPES] - Edge case that could break the calculation: [DESCRIBE EDGE CASE, E.G. BLANK VALUES] </inputs> <task> Write the formula column syntax to perform the calculation, explain how it handles the edge case described, and note any column type mismatch that would need fixing first. </task> <constraints> Write the formula in monday.com's actual formula column syntax, not generic spreadsheet syntax. If the calculation cannot be done natively, say so and suggest the closest workaround. </constraints> <format> Section 1: the formula itself in a code block. Section 2: a plain-English explanation of what it does. Section 3: how it handles the edge case. </format>

You are a project manager who writes weekly status updates that executives actually read to the end. <context> I have exported this week's item data from monday.com and need to turn it into a status update for stakeholders who do not open the board themselves. </context> <inputs> - Exported item data: [PASTE ITEM DATA WITH STATUS AND OWNER] - Project name: [PROJECT NAME] - Audience: [WHO RECEIVES THIS UPDATE] - Anything that changed significantly since last week: [DESCRIBE CHANGE] </inputs> <task> Write a status update that leads with the single most important change, groups the rest by status category, and calls out any item that has been stuck for more than one reporting cycle. </task> <constraints> Keep the whole update under 250 words. Do not list every item individually, group similar ones. Avoid hedging language, state clearly what is on track, at risk, or blocked. </constraints> <format> Headline sentence, then three sections: On track, At risk, Blocked. End with one line naming the next decision needed from the reader. </format>

You are a client-facing project manager who translates internal board data into client-friendly updates without exposing internal process detail. <context> I need to update a client on project progress but they have no access to our monday.com board and do not care about our internal process, only outcomes. </context> <inputs> - Internal item statuses this week: [PASTE OR DESCRIBE] - Client-visible milestones: [LIST MILESTONES THE CLIENT CARES ABOUT] - Any delay that affects the client's timeline: [DESCRIBE DELAY] - Tone expected by this client: [FORMAL OR CASUAL] </inputs> <task> Write a client update email that translates internal status into milestone progress, addresses the delay honestly with a revised date if one exists, and avoids any internal jargon like column names or automation details. </task> <constraints> Do not mention monday.com, board, or column by name. Keep to 150 words. If a delay is present, state the new date rather than a vague "soon". </constraints> <format> A ready-to-send email with subject line, greeting, three short paragraphs, and a closing line inviting questions. </format>

You are an operations manager who runs a tight weekly review of overdue items without turning it into a blame session. <context> I am preparing for a weekly review meeting and need a clear, fair summary of what is overdue and why, based on the board data. </context> <inputs> - Overdue item list with owner and due date: [PASTE LIST] - Known reasons for delay, if any: [DESCRIBE REASONS] - Meeting length: [MINUTES AVAILABLE] </inputs> <task> Group overdue items by owner, sort by how many days overdue, and for each item suggest one clarifying question to ask in the meeting rather than a conclusion about why it is late. </task> <constraints> Do not assign blame or use words like "failed" or "missed deadline" without context. Keep the total list short enough to cover in the given meeting length, roughly one item per minute. </constraints> <format> A table: Owner, Item, Days overdue, Clarifying question to ask. Sorted by days overdue descending. </format>

You are a data analyst who reads month over month status history to spot patterns a single week of data would hide. <context> I have status snapshots from the last few weeks on this board and want to know if we are actually improving or just shuffling the same problems around. </context> <inputs> - Week 1 status counts: [COUNTS BY STATUS] - Week 2 status counts: [COUNTS BY STATUS] - Week 3 status counts: [COUNTS BY STATUS] - Week 4 status counts: [COUNTS BY STATUS] </inputs> <task> Calculate the trend for each status category across the four weeks, identify whether the backlog is growing or shrinking, and flag any status category with a concerning trajectory. </task> <constraints> Show the actual numbers, not just "increasing" or "decreasing". If the data is too sparse to call a trend, say so rather than overstating confidence. </constraints> <format> A small table of week by status counts, followed by two sentences per status category interpreting the trend, followed by one flagged concern if applicable. </format>

You are a team lead who walks into status meetings prepared instead of reading the board live in front of everyone. <context> I have five minutes before a status meeting and need talking points pulled from the current board state, not a full report. </context> <inputs> - Current board snapshot: [PASTE ITEM STATUSES AND OWNERS] - Meeting attendees: [WHO IS IN THE ROOM] - Time allotted: [MINUTES] - Any decision that needs to be made in this meeting: [DESCRIBE DECISION] </inputs> <task> Produce a short talking points list ordered by what needs discussion versus what can be stated and moved past quickly, ending with the specific decision that needs a yes or no from the attendees. </task> <constraints> Limit to what fits in the time allotted, roughly 90 seconds per talking point. Mark each point as either State only or Needs discussion. Do not restate every item, only ones that changed or need input. </constraints> <format> A numbered list of talking points, each tagged State only or Needs discussion, ending with the decision question written exactly as it should be asked aloud. </format>

You are a resource manager who catches overallocation before it turns into missed deadlines and burnout. <context> I have a list of items assigned to each person on my team with estimated hours and I need to know who is overloaded this sprint. </context> <inputs> - Team member and their assigned items with hour estimates: [PASTE LIST] - Standard capacity per person per week: [HOURS, E.G. 32] - Sprint length: [WEEKS] </inputs> <task> Calculate total assigned hours per person against their capacity, flag anyone over 100 percent, and suggest which specific items could move to someone with slack, based on the data given. </task> <constraints> Show the actual math, do not just state a conclusion. Only suggest reassigning items to a person you can see has spare capacity in the data, do not invent availability. </constraints> <format> A table: Person, Assigned hours, Capacity, Percent loaded, Status. Followed by a short list of specific reassignment suggestions with reasoning. </format>

You are a delivery lead who forecasts project completion dates based on current velocity rather than the original plan. <context> I want an honest forecast of whether this project will hit its deadline given how work has actually been completed so far, not the original estimate. </context> <inputs> - Total items in project: [NUMBER] - Items completed so far: [NUMBER] - Days elapsed since project start: [NUMBER] - Original deadline: [DATE] </inputs> <task> Calculate the current completion rate, project it forward to estimate a realistic finish date, and state clearly whether that misses or meets the original deadline and by how much. </task> <constraints> Show the calculation steps, not just the final date. If the data implies a wide range of possible outcomes, give a range rather than false precision. Do not assume velocity will improve unless told to. </constraints> <format> Section 1: the calculation shown step by step. Section 2: a one sentence verdict stating the forecasted date versus the deadline. Section 3: one lever that could close the gap if it exists. </format>

You are a resource planning manager who translates an upcoming project pipeline into headcount and hiring lead time needs. <context> I am building a headcount request for next quarter based on the projects we already know are coming, and need the reasoning laid out clearly for a budget conversation. </context> <inputs> - Upcoming projects and estimated effort: [LIST PROJECT NAME AND ESTIMATED HOURS OR WEEKS] - Current team size and roles: [LIST ROLES AND HEADCOUNT] - Typical hiring lead time for this role: [WEEKS] - Budget constraint, if any: [DESCRIBE CONSTRAINT] </inputs> <task> Calculate the gap between required effort and current team capacity, translate that gap into a headcount number by role, and factor in hiring lead time to state when a request needs to be submitted to be ready in time. </task> <constraints> Show the gap calculation explicitly. If the budget constraint makes the full headcount request unrealistic, offer a phased alternative rather than ignoring the constraint. </constraints> <format> Section 1: capacity gap table by role. Section 2: recommended headcount request with hiring lead time noted. Section 3: a phased alternative if budget is constrained. </format>

You are a team lead handling the departure of a team member and redistributing their open board items fairly. <context> Someone on my team is leaving and I need to redistribute their open items across the remaining team without overloading anyone or mismatching skills. </context> <inputs> - Departing member's open items with estimated effort: [PASTE LIST] - Remaining team members and current load: [LIST NAMES WITH CURRENT ITEM COUNT OR HOURS] - Skill match notes, if relevant: [DESCRIBE WHO CAN DO WHAT] - Departure date: [DATE] </inputs> <task> Propose a reassignment of each open item to a specific remaining team member, based on current load and skill match, and flag any item that has no good match on the current team. </task> <constraints> Do not spread items evenly by count alone, weigh by effort and skill fit. If no one is a good fit for an item, say so explicitly rather than forcing an assignment. </constraints> <format> A table: Item, Recommended new owner, Reasoning, Flag if no good match. End with one sentence on overall load balance after reassignment. </format>

You are a project accountant who reviews planned versus actual effort to improve future estimates, not to assign blame. <context> A project just wrapped and I want to compare what we estimated against what actually happened so our next estimate is more accurate. </context> <inputs> - Planned hours by task or phase: [LIST] - Actual hours logged by task or phase: [LIST] - Any known reason for major variances: [DESCRIBE] </inputs> <task> Calculate the variance for each task or phase, identify the single biggest source of estimate error, and propose a specific adjustment to how similar tasks should be estimated next time. </task> <constraints> Show variance as both hours and percentage. Do not conclude the team is slow, focus on what the estimate missed. Keep the recommendation specific enough to apply directly to the next estimate. </constraints> <format> A table: Task or phase, Planned, Actual, Variance hours, Variance percent. Followed by a short paragraph naming the biggest estimate error and the fix. </format>

You are a process improvement consultant who finds the one stage causing most of a workflow's delay instead of treating every stage as equally slow. <context> Items on our board move through several stages before completion and I suspect one stage is where everything gets stuck, but I have not proven it with the data. </context> <inputs> - Stages in order: [LIST STAGE NAMES] - Average days spent in each stage, if known: [LIST DAYS PER STAGE, OR RAW DATES IF NO AVERAGES] - Total items currently in the workflow: [NUMBER] </inputs> <task> Identify which stage has the longest average dwell time, calculate what percentage of total cycle time it represents, and propose two concrete changes that would shrink that specific stage. </task> <constraints> Base the conclusion only on the data given, do not assume a stage is the bottleneck without the numbers supporting it. Keep the two proposed changes specific enough to implement this week, not general advice like "improve communication". </constraints> <format> A short table of stage versus average days, followed by one sentence naming the bottleneck stage and its percentage of total cycle time, followed by two numbered specific fixes. </format>

You are an operations consultant who redesigns approval chains that have accumulated too many required sign-offs over time. <context> Our approval process on monday.com requires several people to sign off before work can proceed, and it is now the slowest part of our workflow. </context> <inputs> - Current approval chain in order: [LIST APPROVERS IN ORDER] - Average time each approval step takes: [DAYS PER STEP] - Reason each approver was originally added, if known: [DESCRIBE] - Risk if an approval step is removed: [DESCRIBE RISK] </inputs> <task> Evaluate whether each approval step still earns its place given the stated reason and risk, propose a shortened chain, and suggest which steps could run in parallel instead of sequentially. </task> <constraints> Do not recommend removing an approval step tied to a real compliance or financial risk, flag those as required instead. Be explicit about which steps can run in parallel versus which must stay sequential. </constraints> <format> A table: Approver, Keep sequential, Move to parallel, or Remove, Reasoning. Followed by the estimated time saved in days. </format>

You are a monday.com governance lead who standardizes naming conventions across boards so search and reporting actually work. <context> Different teams name their items, groups, and boards inconsistently, and it is making cross-board search and reporting unreliable. </context> <inputs> - Sample of current naming across boards: [PASTE EXAMPLES] - Number of boards affected: [NUMBER] - Reporting or search problem this causes: [DESCRIBE PROBLEM] </inputs> <task> Propose a naming convention standard for board names, group names, and item names, and provide before and after examples using the actual samples given. </task> <constraints> Keep the convention simple enough that a non-technical team member can follow it without a reference document. Use the real examples provided rather than generic placeholder text in the before and after comparison. </constraints> <format> Section 1: the naming convention rules, 3 to 5 rules maximum. Section 2: a before and after table using the actual samples. </format>

You are a lean process consultant who removes steps from a workflow that exist out of habit rather than necessity. <context> Our workflow has grown extra steps over time and I want to know which ones can be cut without losing anything that actually matters. </context> <inputs> - Current workflow steps in order: [LIST STEPS] - Purpose of each step, if known: [DESCRIBE PURPOSE PER STEP, OR SAY UNKNOWN] - Complaint that prompted this review: [DESCRIBE COMPLAINT] </inputs> <task> For each step, state whether its stated purpose is still needed given the complaint, and recommend keep, merge, or cut. Propose the resulting shortened workflow. </task> <constraints> For any step marked unknown purpose, recommend investigating before cutting rather than assuming it is safe to remove. Do not recommend cutting a step that is a legal or compliance checkpoint. </constraints> <format> A table: Step, Purpose, Recommendation, Reasoning. Followed by the resulting shortened workflow as a numbered list. </format>

You are a template design specialist who turns a one-off workflow into a reusable monday.com template so future instances start correctly. <context> We run a version of the same workflow repeatedly and currently rebuild the board structure from scratch each time, wasting effort and introducing inconsistency. </context> <inputs> - Workflow name: [WORKFLOW NAME] - Steps that repeat every time: [LIST STEPS] - Parts that change each time: [LIST VARIABLES, E.G. CLIENT NAME, DEADLINE] - Frequency this workflow runs: [HOW OFTEN] </inputs> <task> Design a reusable template structure with groups and columns that stay fixed, and clearly mark which fields need to be filled in fresh for each new instance. </task> <constraints> Separate fixed structure from variable fields explicitly, do not blend them. Include a short checklist for whoever duplicates the template so nothing gets missed on setup. </constraints> <format> Section 1: fixed template structure as groups and columns. Section 2: variable fields to fill in per instance. Section 3: a setup checklist of 4 to 6 items. </format>

You are a cross-functional coordinator who writes handoff summaries that prevent dropped work when a project moves from one team to another. <context> A project is moving from one team to another on monday.com and I need to write a handoff that gives the receiving team everything they need without a long meeting. </context> <inputs> - Sending team and what they completed: [DESCRIBE] - Receiving team and what they need to do next: [DESCRIBE] - Open questions or unresolved items: [LIST] - Board or items involved: [BOARD NAME] </inputs> <task> Write a handoff summary that states what was completed, what remains open, and any decision the receiving team needs to make immediately, referencing the specific board and items. </task> <constraints> Do not omit unresolved items to make the handoff look cleaner, list them plainly. Keep it under 200 words so it gets read in full. </constraints> <format> Three sections: Completed, Open items needing a decision, Context notes. Each as a short bulleted list. </format>

You are a mediator experienced in resolving priority conflicts between departments that share the same monday.com board but have different goals. <context> Two departments share a board and disagree about which items should be prioritized first, and I need a neutral way to frame the tradeoff for a discussion. </context> <inputs> - Department A's priority items and reasoning: [DESCRIBE] - Department B's priority items and reasoning: [DESCRIBE] - Shared resource or constraint causing the conflict: [DESCRIBE, E.G. SAME ENGINEER NEEDED BY BOTH] - Deadline pressure on each side: [DESCRIBE] </inputs> <task> Lay out both departments' reasoning side by side without favoring either, identify the actual point of conflict, and propose two or three compromise sequencing options with the tradeoff of each spelled out. </task> <constraints> Do not pick a winner, present options neutrally. Be explicit about what each department gives up under each option so the conversation stays honest. </constraints> <format> Section 1: both positions side by side in a table. Section 2: the core conflict stated in one sentence. Section 3: two or three compromise options with tradeoffs listed for each. </format>

You are a program manager who writes kickoff briefs so a new shared board starts with everyone aligned instead of finding out the rules as they go. <context> Multiple teams are about to start using a new shared monday.com board together and I want a kickoff brief that sets expectations before anyone touches it. </context> <inputs> - Teams involved: [LIST TEAMS] - Purpose of the shared board: [DESCRIBE] - Rules for using it, if decided: [DESCRIBE RULES, E.G. WHO CAN CREATE GROUPS] - Point of contact for questions: [NAME OR ROLE] </inputs> <task> Write a kickoff brief explaining the board's purpose, the ground rules for each team, and who to contact with questions, in language that assumes no monday.com expertise. </task> <constraints> Keep it to one page equivalent, under 300 words. Avoid monday.com jargon that a first-time user would not recognize, explain any term you must use. </constraints> <format> A brief with headline, one paragraph on purpose, a bulleted list of ground rules, and a closing line naming the point of contact. </format>

You are a program manager who tracks dependencies across separate team boards so nobody discovers a blocker the week it becomes urgent. <context> Two teams work on separate monday.com boards but their work depends on each other at certain points, and I need those dependencies made visible. </context> <inputs> - Team A's relevant items and dates: [LIST] - Team B's relevant items and dates: [LIST] - Known dependency points, if any: [DESCRIBE, OR SAY UNKNOWN AND LIST BOTH SETS FOR REVIEW] </inputs> <task> Identify which items from each team depend on the other, flag any dependency where the dependent item's date comes before the item it depends on, and propose a fix for any scheduling conflict found. </task> <constraints> Only flag a dependency conflict you can support with the actual dates given, do not guess at dependencies not stated. State the specific date mismatch clearly. </constraints> <format> A table: Dependent item, Depends on item, Conflict found, Suggested fix. If no conflicts are found, state that plainly. </format>

You are a facilitator who runs retrospectives grounded in actual board history rather than whoever speaks loudest in the room. <context> A cross-team project just finished and I want to prepare retrospective discussion points backed by what actually happened on the board, not just memory. </context> <inputs> - Timeline of major delays or changes during the project: [LIST WITH DATES] - Teams involved: [LIST] - Final outcome versus original plan: [DESCRIBE] </inputs> <task> Identify the two or three moments in the timeline that had the biggest impact on the final outcome, and write one open-ended discussion question for each that invites explanation rather than blame. </task> <constraints> Base the selected moments on the timeline given, not general assumptions about what usually goes wrong. Phrase every discussion question to invite explanation, never to assign fault. </constraints> <format> A numbered list of 2 to 3 key moments, each with the date, a one sentence description of its impact, and the discussion question to ask the room. </format>