30 Claude Prompts for Trello

You are a content operations manager who writes standardized Trello card templates for recurring request types. <context> Our team receives the same type of content request over and over and every card comes in with different information missing, so I want a fixed card template to paste in. </context> <inputs> - Request type: [CONTENT TYPE SUCH AS BLOG POST OR SOCIAL GRAPHIC] - Fields we always end up chasing after the fact: [FIELD 1, FIELD 2, FIELD 3] - Who typically fills out the card: [REQUESTER ROLE] </inputs> <task> Write a card description template with a title format, a checklist of required fields, and a checklist of production steps the assignee will complete. </task> <constraints> The required fields checklist must include every field listed above as chased after the fact. Write the title format as a literal pattern the requester can copy, for example "[TYPE] Client name, due date". Keep the whole template short enough to fit without scrolling on a standard card view. </constraints> <format> Return the title format on its own line, then the required fields checklist, then the production steps checklist, each as markdown style checkbox lists. </format>

You are a QA lead who standardizes bug report card templates on a development team's Trello board. <context> Our developers keep asking for more information after a bug is reported because the current cards are too vague to act on. </context> <inputs> - Product or app name: [PRODUCT NAME] - Platforms we support: [WEB, IOS, ANDROID, DESKTOP] - Information developers say they are missing most often: [MISSING INFO EXAMPLES] </inputs> <task> Write a bug report card template with sections for reproduction steps, expected versus actual behavior, environment details, and severity, structured so the missing information above is captured by default. </task> <constraints> Severity must be a fixed set of labels, not a free text field, list the exact label names to create in Trello. Reproduction steps must be a numbered list format, not a paragraph. Keep environment details to fields that are genuinely useful across all listed platforms. </constraints> <format> Return the card template as it should appear in the card description, followed by a short list of the label names to set up for severity. </format>

You are a customer onboarding manager who designs Trello checklist cards for bringing new clients on board. <context> Every new client we sign needs the same set of setup steps completed and I want one master checklist card we duplicate for each new client. </context> <inputs> - Service we onboard clients into: [SERVICE NAME] - Internal teams involved in onboarding: [TEAM 1, TEAM 2, TEAM 3] - Typical time from signed contract to fully onboarded: [TIMEFRAME] </inputs> <task> Produce a full onboarding checklist grouped by which team owns each item, in the order the steps should actually happen, sized to fit the stated timeframe. </task> <constraints> Group checklist items under a heading per team so ownership is unambiguous at a glance. Order items by dependency, not alphabetically, a step should never appear before the step it depends on. Do not pad the list with steps that are not real onboarding work just to look thorough. </constraints> <format> Return the checklist grouped under bold team name headings, each item as a checkbox line, ordered top to bottom by when it happens. </format>

You are a talent acquisition coordinator who builds Trello card templates for candidate tracking. <context> We track candidates as cards moving across hiring stages and I want a consistent card format so anyone on the panel can open a candidate's card and immediately know where things stand. </context> <inputs> - Role being hired for: [JOB TITLE] - Hiring stages in order: [STAGE 1, STAGE 2, STAGE 3, ...] - Interviewers involved: [NAME OR ROLE PER STAGE] </inputs> <task> Write a candidate card template covering summary fields, an interview feedback section per stage, and a decision checklist for the final stage. </task> <constraints> The feedback section must have one clearly labeled subsection per stage listed above, not a single shared notes field. Keep candidate personal information limited to what is operationally necessary, do not template fields that invite storing sensitive data unrelated to hiring decisions. The final decision checklist must force a yes or no recommendation, not an open ended comment. </constraints> <format> Return the card template with clear section headers matching the stages, ending with the final decision checklist. </format>

You are an executive assistant who standardizes meeting notes as Trello cards for a leadership team. <context> Our leadership team's meeting notes currently live in whatever format the note taker feels like that day, and decisions get lost between meetings. </context> <inputs> - Meeting name: [MEETING NAME] - Meeting cadence: [WEEKLY, BIWEEKLY, MONTHLY] - Recurring agenda topics: [TOPIC 1, TOPIC 2, TOPIC 3] </inputs> <task> Write a meeting notes card template with sections for attendees, each recurring agenda topic, decisions made, and action items with owners, structured to be duplicated for every occurrence of this meeting. </task> <constraints> Action items must include an owner field and a due date field on every single item, no exceptions. Keep the decisions section separate from the discussion notes so decisions do not get buried in prose. Structure the template so the previous meeting's open action items can be pasted at the top before the meeting starts. </constraints> <format> Return the full card template with headers in this order: attendees, carried over action items, agenda topics, decisions, new action items. </format>

You are a release manager who writes pre launch checklists for Trello cards tracking product releases. <context> We ship product releases and want a single card checklist that catches the things we have forgotten before in past launches. </context> <inputs> - Product type: [PRODUCT TYPE SUCH AS MOBILE APP OR WEBSITE] - Teams that must sign off before launch: [TEAM 1, TEAM 2, TEAM 3] - Past launch problems we want to prevent: [PROBLEM 1, PROBLEM 2] </inputs> <task> Build a pre launch checklist organized by sign off team, including a specific item addressing each past problem listed, ending with a final go or no go item. </task> <constraints> Each past problem must map to a named checklist item, not a vague catch all line. Group items under the responsible team so it is clear who checks what. The final item must require an explicit named person to check it, not just a checkbox with no owner. </constraints> <format> Return the checklist grouped by team as bold headers with checkbox items underneath, ending with the go or no go line. </format>

You are an editorial lead who builds editing checklists for Trello cards before content is published. <context> We publish content through Trello cards and keep letting small errors through because there is no consistent final check before publishing. </context> <inputs> - Content type: [BLOG POST, VIDEO SCRIPT, NEWSLETTER, ETC] - Publishing platform: [PLATFORM NAME] - Errors that have slipped through before: [ERROR EXAMPLES] </inputs> <task> Write a pre publish checklist that specifically catches each error type listed, ordered from structural checks to surface level checks. </task> <constraints> Order checks so structural issues, such as broken links or missing images, are caught before spelling and tone checks, catching a structural issue late wastes the earlier review time. Each error type listed must appear as its own checklist item, worded specifically enough that two different reviewers would check it the same way. Keep the checklist to items that can be verified in under two minutes each. </constraints> <format> Return a single ordered checklist, structural items first, then surface level items, each as a checkbox line. </format>

You are an HR operations specialist who builds offboarding checklists as Trello cards for departing employees. <context> We run employee offboarding as a Trello card and I want a checklist that covers every system and asset we need to close out, not just the obvious ones. </context> <inputs> - Company size and type: [COMPANY SIZE, INDUSTRY] - Systems and tools employees typically have access to: [TOOL 1, TOOL 2, TOOL 3] - Physical assets typically issued: [LAPTOP, BADGE, PHONE, ETC] </inputs> <task> Build an offboarding checklist split into access revocation, asset return, and knowledge transfer, covering every tool and asset listed. </task> <constraints> Every tool listed must have its own access revocation item naming that tool, do not group them into one vague "revoke all access" line. Include a deadline relative to the last working day for each section, for example same day versus within one week. Knowledge transfer items must name what gets handed off, not just say "document knowledge". </constraints> <format> Return three headed sections, access revocation, asset return, knowledge transfer, each with checkbox items and a relative deadline in parentheses. </format>

You are a procurement analyst who builds Trello checklist cards for evaluating new vendors. <context> We are evaluating a new vendor and want a consistent checklist card so every vendor gets assessed on the same criteria before we sign anything. </context> <inputs> - Type of vendor: [VENDOR CATEGORY SUCH AS SOFTWARE OR LOGISTICS] - Budget range for this category: [BUDGET RANGE] - Past vendor problems we want to screen for: [PAST ISSUE 1, PAST ISSUE 2] </inputs> <task> Build a vendor evaluation checklist covering pricing, references, security or compliance basics, and contract terms, with an item that directly screens for each past issue listed. </task> <constraints> Each past issue must map to a specific screening question, worded as something you can actually ask the vendor or check in a document. Keep the checklist realistic for the stated budget range, do not require an enterprise security audit for a small low cost vendor. Include a final item requiring a named approver before signing. </constraints> <format> Return the checklist in four headed sections, pricing, references, compliance, contract terms, ending with the named approver line. </format>

You are a productivity coach who designs a daily shutdown checklist as a recurring Trello card. <context> I end most days with loose ends I forgot to close out, and I want a short daily shutdown checklist card I run through before logging off. </context> <inputs> - My role: [JOB TITLE] - Things I regularly forget to do before ending the day: [FORGOTTEN TASK 1, FORGOTTEN TASK 2] - Time I want this to take: [MINUTES] </inputs> <task> Build a daily shutdown checklist that fits inside the stated time budget and specifically includes each forgotten task listed. </task> <constraints> Keep total items low enough that the whole checklist genuinely fits inside the stated minutes, do not pad it. Each forgotten task must appear as its own specific item rather than folded into a vague catch all. Order the checklist so quick wins come first and the item most likely to get skipped comes last, since anything skipped will be the last item under time pressure. </constraints> <format> Return a single checklist as checkbox items in the order to complete them, with a one line note at the end estimating total time. </format>

You are a Trello automation specialist who writes Butler rules for support ticket boards. <context> Our support tickets move through a Trello board and I want Butler rules that handle the repetitive moves and notifications our team currently does by hand. </context> <inputs> - List names on the board in order: [LIST 1, LIST 2, LIST 3, ...] - Priority labels we use: [URGENT, HIGH, NORMAL, LOW] - Repetitive manual actions we want automated: [ACTION 1, ACTION 2, ACTION 3] </inputs> <task> Write a set of Butler rules, each as a trigger and action pair, that automates the manual actions listed using the actual list and label names given. </task> <constraints> Each rule must be written as valid Butler syntax or Butler's plain English rule builder phrasing, not pseudocode. Reference the exact list and label names given, not generic placeholders, in the rule text itself. Flag any requested automation that Butler cannot do natively so it does not get silently dropped. </constraints> <format> Return each rule as a numbered item with the trigger on one line and the resulting action on the next, followed by a short note on anything Butler cannot handle. </format>

You are an agile coach who designs work in progress limit policies for Trello boards. <context> Our team's in progress list keeps growing and nothing finishes on time, and I think we need work in progress limits but do not know how to set them without a paid Power-Up. </context> <inputs> - Team size: [NUMBER OF PEOPLE] - In progress list current card count on a typical day: [APPROXIMATE COUNT] - Board's in progress style lists: [LIST NAME 1, LIST NAME 2] </inputs> <task> Propose a specific work in progress limit per list based on team size, and a manual enforcement policy the team can follow without a paid limiting Power-Up. </task> <constraints> Base the numeric limit on the team size given, explain the reasoning, do not just assert a round number. The enforcement policy must specify who checks the limit and what happens when a list is over, since Trello's free plan will not block the move automatically. Address the gap between the current count and the proposed limit directly, since that gap is the actual problem. </constraints> <format> Return the proposed limit per list with reasoning, followed by the enforcement policy as a short numbered process. </format>

You are a delivery operations manager who designs escalation policies for cards that stall on a Trello board. <context> Cards on our board sit untouched for too long and nobody notices until a deadline is already missed, and I want a clear escalation rule for stalled cards. </context> <inputs> - List where cards most often stall: [LIST NAME] - How long a card should sit before it counts as stalled: [TIME PERIOD] - Who should be notified at each escalation stage: [PERSON OR ROLE PER STAGE] </inputs> <task> Design a two or three stage escalation policy for cards stalled in the named list, specifying the exact trigger time for each stage and who gets notified, plus how this could be implemented with Butler due date and inactivity rules. </task> <constraints> Each escalation stage must have a specific time trigger derived from the stalled time period given, not a vague "after a while". Name the exact Butler trigger type to use for each stage, such as a due date rule or a card age rule. The final stage must escalate to a different person than the first stage, escalating to the same person twice is not a real escalation. </constraints> <format> Return each stage as a numbered item with its time trigger, who is notified, and the Butler rule type to implement it. </format>

You are a Trello workflow designer who sets up automatic labeling rules based on card content. <context> Cards get added to our board without consistent labels and we end up manually relabeling everything, so I want automatic labeling rules based on keywords in the card title. </context> <inputs> - Labels currently in use: [LABEL 1, LABEL 2, LABEL 3] - Common keywords that should map to each label: [KEYWORD LIST PER LABEL] - List where new cards typically get added: [LIST NAME] </inputs> <task> Write Butler rules that automatically apply the correct label when a card is created in the named list and its title contains one of the given keywords, one rule per label. </task> <constraints> Handle the case where a card title could match keywords for more than one label and specify which label wins. Write the keyword matching as Butler's actual "card name contains" style syntax. Note that this only fires on card creation unless a separate rule is added for edits, and mention that limitation explicitly. </constraints> <format> Return one rule per label as trigger and action pairs, followed by a short note on the multiple keyword match handling and the creation only limitation. </format>

You are a Trello workflow auditor who designs recurring board hygiene routines combining manual review and Butler automation. <context> Our board slowly fills with stale cards, duplicate labels, and forgotten checklists, and I want a repeatable weekly hygiene routine plus any Butler rules that can automate part of it. </context> <inputs> - Board's main lists: [LIST 1, LIST 2, LIST 3] - Person responsible for hygiene: [ROLE OR NAME] - Time budget for the weekly review: [MINUTES] </inputs> <task> Design a weekly hygiene checklist for the named person to run manually, plus a small set of Butler rules that automate the parts of hygiene that do not require human judgment, such as archiving very old done cards. </task> <constraints> Separate clearly which items are manual judgment calls versus which are safe to fully automate, automating a judgment call risks silently archiving live work. Keep the manual portion inside the stated time budget. Any automation rule that archives or moves cards must include a specific safe condition, such as a minimum time in the done list, so it cannot fire on active work. </constraints> <format> Return two sections, manual weekly checklist and automated Butler rules, with the automation section including the safe condition for each rule. </format>

You are a program manager who converts a Trello board's current state into a written status update for stakeholders. <context> I need to send a status update to stakeholders based on the current state of our Trello board and do not want to write it from scratch every week. </context> <inputs> - Cards currently in each list with a one word status each: [LIST NAME AND CARD TITLES] - Deadline that matters most this period: [DEADLINE AND WHAT IT IS FOR] - Audience for this update: [WHO IS READING IT] </inputs> <task> Write a status update summarizing what moved, what is at risk relative to the stated deadline, and what needs a decision from the audience, based only on the card information given. </task> <constraints> Do not invent progress or risks not implied by the card list given, if the information does not support a claim, leave it out. Lead with the deadline risk assessment, not a generic summary paragraph. Match the tone to the audience, an executive audience gets brevity, a working team gets more operational detail. </constraints> <format> Return three short sections, deadline risk, what moved this period, decisions needed, each two to four sentences. </format>

You are an agile facilitator who builds retrospective agendas informed by what actually happened on the team's Trello board. <context> We run a retrospective at the end of each cycle and I want the agenda grounded in what actually happened on the board, not a generic retro template. </context> <inputs> - Cards that got stuck or bounced backward this cycle: [CARD TITLES AND WHERE THEY STUCK] - Cards that moved smoothly and fast: [CARD TITLES] - Cycle length: [DURATION] </inputs> <task> Build a retrospective agenda that opens discussion on the specific stuck cards and the specific smooth cards given, structured as went well, went wrong, and one committed change for next cycle. </task> <constraints> Reference the actual card titles given in the discussion prompts, do not generalize them into abstract categories. Limit the agenda to fit inside a session proportional to the cycle length, a one week cycle gets a shorter retro than a monthly one. End with exactly one committed change, not a wishlist, since more than one action rarely survives to the next cycle. </constraints> <format> Return the agenda as three headed sections, went well, went wrong, one committed change, each referencing specific cards by name. </format>

You are a project coordinator who summarizes long Trello card comment threads for handoff between team members. <context> A card I am handing off has a long comment history and the person taking it over should not have to read the entire thread to get up to speed. </context> <inputs> - Card title: [CARD TITLE] - Full comment thread text pasted below: [PASTE ALL COMMENTS IN ORDER] - Person taking over: [NAME OR ROLE] </inputs> <task> Summarize the comment thread into current state, decisions already made, open questions, and what the new owner should do first. </task> <constraints> Separate decisions already made from open questions clearly, treating an open question as decided would cause the new owner to skip work that still needs doing. Only summarize what is actually in the pasted thread, do not fill gaps with assumptions. Keep the summary short enough to read in under a minute, this is a handoff aid not a full archive. </constraints> <format> Return four short sections, current state, decisions made, open questions, first action for the new owner. </format>

You are an operations analyst who reports on team throughput using Trello card completion data. <context> I want a monthly report on how much work our team actually finished based on when cards were completed, to compare against the previous month. </context> <inputs> - Cards completed this month with completion dates: [CARD TITLE AND DATE LIST] - Cards completed last month with completion dates: [CARD TITLE AND DATE LIST] - Metric the team cares about most: [SPEED, VOLUME, OR CONSISTENCY] </inputs> <task> Compare this month's completions against last month's, calling out the change in the metric specified as most important, and note any pattern in what type of work is finishing versus stalling. </task> <constraints> Calculate the comparison from the actual dates and counts given, do not estimate. Lead the report with the metric specified as most important, not with a generic overview. If the data given is too sparse to support a real conclusion, say so plainly instead of manufacturing a trend. </constraints> <format> Return a short report with a headline number for the chosen metric, a one paragraph comparison to last month, and a short note on any pattern observed. </format>

You are an incident response coordinator who writes postmortem summaries as Trello card content after an incident is resolved. <context> We track an operational incident as a Trello card and once it is resolved I need to turn the card's timeline into a clean postmortem summary. </context> <inputs> - Incident name: [INCIDENT NAME] - Timeline of events as logged on the card: [TIMESTAMPED EVENTS] - Impact on customers or the business: [IMPACT DESCRIPTION] </inputs> <task> Write a postmortem summary covering what happened, root cause based on the timeline given, impact, and follow up actions to prevent recurrence. </task> <constraints> Derive the root cause from the timeline actually given, if the timeline does not clearly show a root cause, say the root cause is still under investigation rather than guessing. State impact in concrete terms drawn from what was given, not vague severity language. Follow up actions must be specific enough to become their own Trello cards, not general advice like "improve monitoring". </constraints> <format> Return four sections, what happened, root cause, impact, follow up actions, with follow up actions as a numbered list specific enough to copy into new cards. </format>

You are a team lead who writes onboarding guides that get a new hire comfortable using the team's Trello board fast. <context> A new person is joining my team and needs to understand how we use Trello before their first week of real work. </context> <inputs> - Board's list structure: [LIST 1, LIST 2, LIST 3] - Labels and what each one means: [LABEL AND MEANING LIST] - Anything the team does differently from a default Trello board: [TEAM SPECIFIC QUIRK] </inputs> <task> Write a short onboarding guide explaining the board's list structure, what each label means, and the team specific quirk, ending with the first three actions the new hire should take on the board. </task> <constraints> Explain the team specific quirk clearly since that is exactly the thing a generic Trello tutorial would not cover. Keep the guide short enough to read in under five minutes, a new hire will not read a long document in their first week. End with concrete first actions, not general encouragement to "explore the board". </constraints> <format> Return the guide with three short sections, list structure, labels, team quirk, followed by a numbered list of first actions. </format>

You are a change management consultant who helps teams move from ad hoc coordination to a shared Trello board. <context> My team currently coordinates through scattered messages and I want to propose moving to a shared Trello board, but I expect pushback from people who think it is unnecessary overhead. </context> <inputs> - Current coordination method: [EMAIL, CHAT, VERBAL, SPREADSHEET] - Specific problem this has caused recently: [RECENT INCIDENT] - Person or people most likely to resist: [ROLE OR PERSONALITY TYPE] </inputs> <task> Draft a short message proposing the move to Trello that addresses the likely resistance directly and anchors the case in the specific recent incident given. </task> <constraints> Do not oversell Trello as a magic fix, tie the case specifically to the incident described. Address the likely resistance by name, for example if the resistance is "another tool to check", answer that concern directly rather than ignoring it. Keep the message short enough to read in one sitting, a long pitch will not get read by someone already skeptical. </constraints> <format> Return the message as a short piece of prose, no more than five short paragraphs, ready to send as is. </format>

You are an operations lead who writes a permanent reference card explaining the rules of how a Trello board should be used. <context> Our board keeps drifting from how it is supposed to be used because there is no written reference, and I want a pinned card that spells out the rules. </context> <inputs> - Rules we currently enforce informally: [RULE 1, RULE 2, RULE 3] - Common mistakes new members make on this board: [MISTAKE 1, MISTAKE 2] - Who to ask when unsure: [PERSON OR ROLE] </inputs> <task> Write the content for a pinned reference card that states the rules clearly, calls out the common mistakes and what to do instead, and names who to ask when unsure. </task> <constraints> State each rule as a direct instruction, not a suggestion, ambiguity is what caused the drift in the first place. Address each common mistake by name with the correct alternative right next to it, not in a separate section. Keep the card skimmable, use short lines rather than paragraphs. </constraints> <format> Return the reference card content with a rules section as short direct statements, a mistakes section pairing each mistake with its fix, and a closing line naming who to ask. </format>

You are a workflow adoption specialist who designs check-in plans to make sure a new Trello process actually sticks after rollout. <context> We just rolled out a new Trello board for the team and I know from past tool rollouts that adoption fades within a month if nobody checks in. </context> <inputs> - Team size: [NUMBER OF PEOPLE] - Main behavior change we need people to actually do: [SPECIFIC BEHAVIOR SUCH AS MOVING CARDS DAILY] - Why past rollouts faded: [PAST FAILURE REASON] </inputs> <task> Design a 30 day check-in plan with specific checkpoints at set intervals, each checking whether the main behavior change is actually happening, structured to directly counter the reason past rollouts faded. </task> <constraints> Each checkpoint must specify what evidence to look for on the board itself, such as card movement patterns, not just "ask people how it's going". Directly counter the stated past failure reason at the specific checkpoint most likely to hit it. Keep the plan realistic for the stated team size, a plan requiring one on one meetings does not scale the same way for five people versus fifty. </constraints> <format> Return the plan as dated checkpoints, for example day 7, day 14, day 30, each with what to check and what action to take if adoption is slipping. </format>

You are a tools consultant who helps teams decide when Trello is the right choice versus a different tool for a specific type of work. <context> Someone on my team is asking why we use Trello for this instead of a different tool they used at a previous job, and I want a clear honest answer rather than just defending the status quo. </context> <inputs> - Type of work in question: [WORK TYPE] - Tool being suggested as an alternative: [ALTERNATIVE TOOL NAME] - What matters most to our team: [SPEED OF SETUP, COST, FLEXIBILITY, REPORTING, ETC] </inputs> <task> Compare Trello against the named alternative specifically for the work type given, weighted by what matters most to the team, and give a direct recommendation. </task> <constraints> Be honest about real weaknesses of Trello for this work type if they exist, a one sided defense will not convince a skeptical reader. Weight the comparison explicitly by the stated priority, do not give a balanced feature list that ignores what actually matters to this team. End with a direct recommendation, not a noncommittal "it depends". </constraints> <format> Return a short comparison covering the two or three factors that matter most given the stated priority, ending with one paragraph giving a direct recommendation. </format>