30 Claude Prompts for Asana

You are a delivery lead who is good at decomposing large deliverables into concrete, assignable subtasks. <context> I have one big task sitting in Asana that is too large for anyone to actually pick up and start on. I need it split into real subtasks before I assign it. </context> <inputs> - Big task name: [TASK NAME] - What done actually looks like: [DEFINITION OF DONE] - Who might work on pieces of it: [NAMES OR ROLES] - Hard deadline: [DEADLINE] </inputs> <task> Break the big task into 5 to 10 subtasks that could each be an Asana subtask, each small enough that one person could finish it in a day or two, in the order they need to happen. </task> <constraints> Each subtask name must start with a verb. Do not create subtasks that depend on tools or approvals I have not mentioned. Flag any subtask that seems to need more than 2 days with [OVERSIZED, SPLIT FURTHER]. </constraints> <format> Return a numbered list, each line as "Subtask name, roughly N days, suggested owner". After the list, one sentence naming the single riskiest subtask for hitting the deadline. </format>

You are an implementation manager who converts client requirements documents into internal task lists. <context> A client sent over a requirements document written in their own language and format, and I need to translate it into task line items my team can actually work from in Asana. </context> <inputs> - Requirements text: [PASTE REQUIREMENTS TEXT] - Internal team that will execute: [TEAM NAME] - Contract deadline: [DEADLINE DATE] </inputs> <task> Extract every discrete requirement from the document and convert each into a task line item written the way my internal team would phrase it, grouped by the part of the product or service it affects. </task> <constraints> Do not merge two separate client requirements into one task even if they seem related, keep traceability to the original document. Mark anything in the document that is vague or contradictory with [CLARIFY WITH CLIENT]. Keep task names under 80 characters. </constraints> <format> Return a markdown table with columns: Group, Task, Source line from requirements (short quote), Status (Clear or CLARIFY WITH CLIENT). </format>

You are a cross functional program manager who is responsible for sequencing work across multiple teams. <context> I have a flat list of tasks across three teams for one initiative, and right now nobody can tell what blocks what. I need a dependency map before I set due dates in Asana. </context> <inputs> - Flat task list with team owner: [TASK LIST WITH TEAM PER LINE] - Overall initiative deadline: [DEADLINE] - Known hard blockers, if any: [KNOWN BLOCKER OR NONE] </inputs> <task> Analyze the task list and produce a dependency map showing which tasks must finish before others can start, organized so I can set Asana dependencies directly from it. </task> <constraints> Only claim a dependency exists if it is logically necessary, not just convenient ordering. Call out any task with no dependencies as [CAN START IMMEDIATELY]. If two teams both claim to own overlapping work, flag it with [OWNERSHIP CONFLICT]. </constraints> <format> Return as a list: "Task A blocks Task B" one per line, grouped by team pairs involved. End with a short bullet list of anything flagged CAN START IMMEDIATELY or OWNERSHIP CONFLICT. </format>

You are a QA lead who turns launch requirements into pre-launch checklists. <context> We are close to launching something and I need a QA checklist turned into actual Asana subtasks under the launch task, not just a document nobody checks off. </context> <inputs> - What is launching: [LAUNCH DESCRIPTION] - Platforms or environments involved: [PLATFORM LIST] - Past launch issues to specifically avoid repeating: [PAST ISSUE OR NONE] </inputs> <task> Produce a QA checklist written as individual checkable subtasks, covering functional checks, the platforms listed, and at least one check that directly targets the past issue mentioned. </task> <constraints> Each checklist item must be phrased as a single verifiable action, not a vague area like "[TEST EVERYTHING]". Group items by platform. Keep the total list to 15 to 25 items so it stays usable the night before launch. </constraints> <format> Return as a markdown checklist using "- [ ] item" syntax, grouped under a heading per platform. Mark the item addressing the past issue with (regression check) at the end of that line. </format>

You are a productivity coach who specializes in fixing vague, unactionable task lists. <context> My Asana board has a bunch of tasks that sound fine but nobody knows what to actually do when they open them. I need each one rewritten to be genuinely actionable. </context> <inputs> - Current task list: [PASTE CURRENT TASK NAMES] - Project this belongs to: [PROJECT NAME] - Team members who will read these: [TEAM MEMBER NAMES] </inputs> <task> Rewrite every task name so it starts with a specific verb and states the concrete output expected, and add one line under each explaining what "done" looks like for that task. </task> <constraints> Do not change the underlying scope of any task, only its clarity. If a task is too vague to fix without more information, mark it [NEEDS MORE DETAIL FROM AUTHOR] instead of guessing at scope. Keep each rewritten name under 70 characters. </constraints> <format> Return a table with columns: Original name, Rewritten name, Done means. Put a final row count summary at the bottom showing how many were rewritten cleanly versus flagged. </format>

You are a project manager who writes weekly status updates for stakeholders who do not live inside Asana. <context> I need to send a weekly status update and I have a rough dump of what happened in the project this week, but it is not written in a way I can send to stakeholders yet. </context> <inputs> - Raw notes on tasks completed, in progress, and blocked: [RAW TASK NOTES] - Project name: [PROJECT NAME] - Audience for this update: [AUDIENCE, e.g. steering committee] - Overall project health as I see it: [ON TRACK, AT RISK, OFF TRACK] </inputs> <task> Write a weekly status update covering what shipped this week, what is in progress, what is blocked and why, and what is coming next week, calibrated to the audience I named. </task> <constraints> Keep it to one screen, under 250 words. State the health status plainly in the first sentence, do not bury it. Do not soften a genuine blocker into vague language like "[MINOR HICCUP]", name the actual blocker. </constraints> <format> Return with these exact headers: Status, Shipped this week, In progress, Blocked, Next week. One or two lines under each. </format>

You are a program manager experienced at writing escalation messages that get a real response without sounding alarmist. <context> A task or milestone is going to slip and I need to escalate it to my manager or a stakeholder before it becomes a surprise, but I want to sound calm and solution oriented, not panicked. </context> <inputs> - What is slipping and by how much: [TASK OR MILESTONE AND DELAY] - Root cause as I understand it: [ROOT CAUSE] - Options I am considering: [OPTION LIST] - Who this is going to: [RECIPIENT ROLE] </inputs> <task> Draft an escalation message that states the slip clearly, explains the root cause in one sentence, presents the options with a recommendation, and asks for a specific decision or resource by a specific date. </task> <constraints> Do not use hedging language that obscures the actual delay. Keep it under 150 words. End with one clear question, not a vague open ended request like "[LET ME KNOW YOUR THOUGHTS]". </constraints> <format> Return as a ready to send message with a one line subject, then the body in short paragraphs. </format>

You are an account manager who translates internal Asana progress into client-facing updates. <context> My internal Asana board has dozens of small tasks and some internal back and forth that a client does not need to see, but I owe them a progress update this week. </context> <inputs> - Internal task and activity notes: [PASTE INTERNAL NOTES] - Client name: [CLIENT NAME] - Contract milestone we are working toward: [MILESTONE] - Anything the client is specifically anxious about: [CLIENT CONCERN OR NONE] </inputs> <task> Write a client-facing progress summary that reports real progress toward the milestone, addresses the specific concern if one was given, and omits internal process detail the client has no reason to see. </task> <constraints> Do not mention internal tool names, internal team disagreements, or staffing issues. Keep a professional, confident tone without overpromising a date we have not confirmed. Limit to 120 words. </constraints> <format> Return as an email-ready paragraph or two, no headers needed, ready to paste into a client email. </format>

You are a PMO analyst who compiles multi-project status rollups for a leadership team. <context> I manage or track several projects at once and leadership wants one rollup summary instead of reading each project separately, and I need to compile that from notes across all of them. </context> <inputs> - Per-project status notes: [PROJECT NAME AND STATUS NOTES, ONE PER LINE OR BLOCK] - Reporting period: [REPORTING PERIOD] - Number of projects to include: [NUMBER OF PROJECTS] </inputs> <task> Produce a single rollup that shows each project's health at a glance, the single most important update per project, and a short overall summary sentence for the whole portfolio. </task> <constraints> Use only Green, Yellow, or Red for health, no other labels. Limit each project's update to one sentence. If a project's notes do not clearly support a health rating, mark it [RATING UNCLEAR FROM NOTES] rather than guessing. </constraints> <format> Return a table with columns: Project, Health, Key update this period. Follow with one summary sentence below the table. </format>

You are a delivery manager who is direct about schedule recovery rather than making excuses. <context> Several tasks in my Asana project are overdue and I need to communicate a recovery plan rather than just apologize for being behind. </context> <inputs> - Overdue tasks with how many days late: [OVERDUE TASK LIST WITH DAYS LATE] - Original deadline for the overall project: [ORIGINAL DEADLINE] - Resources I could add or reprioritize: [AVAILABLE RESOURCE OR NONE] </inputs> <task> Write a recovery update that acknowledges the overdue items without excessive apology, groups them by how they will be recovered, and states a revised realistic date for each group. </task> <constraints> Do not promise recovery that the resources listed cannot realistically support. Group tasks into at most 3 recovery buckets, such as reprioritize, add resource, or descope. Avoid apologetic filler like "[WE ARE SORRY FOR ANY INCONVENIENCE]", state facts and next steps instead. </constraints> <format> Return with headers: What is late, Recovery approach, Revised dates. Use short bullets under each, end with one line stating the new overall project date. </format>

You are a resource manager who balances workload across a team using rough capacity numbers. <context> I need to assign next sprint's task list across my team and I want the workload actually balanced instead of just going in order down the list. </context> <inputs> - Task list with rough effort in hours: [TASK LIST WITH HOURS] - Team members with available hours: [NAME AND AVAILABLE HOURS PER PERSON] - Skills each person is strongest at: [NAME AND SKILL] </inputs> <task> Assign each task to the team member best suited by skill, while keeping each person's total assigned hours within their stated availability, and flag anything that cannot fit. </task> <constraints> Do not assign anyone more than their stated available hours. If total task hours exceed total team capacity, do not silently overload someone, list the excess as [UNASSIGNED, OVER CAPACITY] instead. Prefer skill match over even distribution when the two conflict. </constraints> <format> Return a table with columns: Person, Assigned tasks, Total hours, Remaining capacity. Add an "Unassigned" section below listing anything that did not fit and why. </format>

You are an operations manager focused on catching overallocation before it causes burnout or missed deadlines. <context> Before I commit to next sprint's plan in Asana, I want to check whether anyone is quietly overloaded across multiple projects at once, not just within this one project. </context> <inputs> - Person and their tasks across all active projects with hours: [PERSON, PROJECT, TASK, HOURS LIST] - Standard working hours per week: [STANDARD HOURS PER WEEK] - Sprint length in weeks: [SPRINT LENGTH] </inputs> <task> Calculate total committed hours per person across all listed projects for the sprint length given, compare against standard capacity, and identify anyone over 100 percent allocated. </task> <constraints> Show the actual math, do not just state a conclusion. For anyone over capacity, name which specific project's tasks are the best candidates to defer, based on lowest apparent urgency in the data given. Do not recommend deferring anything not in the input list. </constraints> <format> Return a table with columns: Person, Total hours committed, Capacity, Percent allocated. List anyone over 100 percent below the table with a one line deferral recommendation each. </format>

You are a department lead building a business case for additional headcount using real workload data. <context> My team has been consistently over capacity and I want to build a data backed case for a new hire or contractor instead of just saying "we are busy" to leadership. </context> <inputs> - Average team hours committed per sprint over recent sprints: [AVERAGE HOURS PER SPRINT] - Total team standard capacity per sprint: [TOTAL CAPACITY PER SPRINT] - Specific work that has been delayed or dropped: [DELAYED OR DROPPED WORK] - Role being requested: [ROLE TITLE] </inputs> <task> Build a short business case showing the capacity gap using the numbers given, connecting that gap directly to the specific delayed or dropped work, and stating what adding the requested role would resolve. </task> <constraints> Use only the numbers provided, do not invent industry benchmarks. Keep the case to one page equivalent, under 300 words. State the gap as a percentage, not just raw hours, so it reads clearly to a non technical approver. </constraints> <format> Return with headers: The gap, What it is costing us, The ask. Two to four sentences under each. </format>

You are a team lead who needs to quickly redistribute work when someone goes out unexpectedly. <context> A team member just went unavailable with little notice, out sick or an emergency, and I need to redistribute their open Asana tasks fast without dropping anything time sensitive. </context> <inputs> - Their open tasks with due dates: [TASK LIST WITH DUE DATES] - Remaining team members with current rough load: [NAME AND CURRENT LOAD] - How long they are expected to be out: [EXPECTED DURATION] </inputs> <task> Sort their open tasks by urgency based on due date, then reassign each to the remaining team member best able to absorb it given current load, or mark it [HOLD UNTIL THEY RETURN] if it can safely wait. </task> <constraints> Only reassign tasks with a due date inside the expected absence window, everything else should default to HOLD unless clearly urgent regardless. Do not pile everything on one person just because they have the lowest current load if the task does not match their skill history. State your reasoning for each reassignment in one short clause. </constraints> <format> Return a table: Task, Due date, New owner or HOLD, Reason. Keep the reason under 12 words each. </format>

You are a resourcing lead who plans team capacity across a quarter of overlapping projects. <context> I need to plan how my team's capacity will be split across several projects for the coming quarter before I commit to timelines with each project's stakeholders. </context> <inputs> - Projects and their rough total effort needed this quarter: [PROJECT AND EFFORT ESTIMATE] - Team size and standard capacity per person per quarter: [TEAM SIZE AND CAPACITY] - Priority order of projects if capacity runs short: [PRIORITY ORDER] </inputs> <task> Allocate the team's total quarterly capacity across the listed projects according to the priority order, showing which projects get fully staffed, which get partial capacity, and which get none this quarter. </task> <constraints> Respect the priority order strictly, do not partially fund a lower priority project before a higher one is fully covered unless capacity is left over. Show the math for total capacity versus total demand. State clearly if total demand exceeds total capacity and by how much. </constraints> <format> Return a table: Project, Priority, Effort needed, Effort allocated, Status (Fully staffed, Partial, Not staffed). End with one line stating the total capacity gap or surplus. </format>

You are a product operations lead who scores backlog items to decide what goes into Asana next. <context> I have a long backlog of potential tasks and I need to decide what actually gets added to the active Asana project next, using something more rigorous than gut feel. </context> <inputs> - Backlog items: [BACKLOG ITEM LIST] - Business goal this quarter: [BUSINESS GOAL] - Rough effort estimate per item if known: [EFFORT ESTIMATE OR UNKNOWN] </inputs> <task> Score each backlog item on impact toward the stated business goal and on effort, then rank the full list from highest to lowest priority using an impact versus effort logic. </task> <constraints> Use a simple 1 to 5 scale for impact and effort, explain the score in a few words rather than just giving a number. Items marked effort unknown should be scored effort 3 by default and flagged [EFFORT UNCONFIRMED]. Do not let a large item automatically win just because it sounds important. </constraints> <format> Return a table: Item, Impact score, Effort score, Priority rank, One line rationale. Sort the table by priority rank, highest first. </format>

You are a launch planner who builds milestone plans by working backward from a fixed date. <context> I have a fixed launch date that cannot move, and I need to work backward to figure out what milestones and their deadlines need to look like in Asana to actually hit it. </context> <inputs> - Fixed launch date: [LAUNCH DATE] - Major phases of work required: [PHASE LIST] - Known lead times, like vendor or approval delays: [KNOWN LEAD TIME] </inputs> <task> Work backward from the launch date through each phase, assigning a deadline to each milestone so the whole chain lands on time, explicitly accounting for the known lead times as fixed, non-compressible blocks. </task> <constraints> Treat the known lead times as fixed, do not compress them to make the schedule work. If working backward reveals the plan needs to have started in the past, say so plainly instead of quietly shifting the launch date. Show milestones in calendar order, earliest first. </constraints> <format> Return a table: Milestone, Deadline, Notes. End with one sentence flagging if the plan is feasible or already behind. </format>

You are a pragmatic delivery lead experienced in scope trade-off decisions under a fixed deadline. <context> My current scope will not fit inside the remaining time before the deadline, and I need a clear recommendation on what to cut or defer rather than everyone quietly working overtime. </context> <inputs> - Remaining tasks with rough effort: [TASK LIST WITH EFFORT] - Remaining time until deadline: [REMAINING TIME] - Which tasks are considered must-have by the stakeholder: [MUST HAVE LIST] </inputs> <task> Compare total remaining effort against remaining time, and if it does not fit, recommend specifically which non-must-have tasks to cut or defer to make the must-have list achievable by the deadline. </task> <constraints> Never recommend cutting anything on the must-have list, if even the must-have list does not fit the remaining time, say so explicitly instead of forcing a fit. Rank cut candidates from safest to riskiest to cut. Avoid soft language like "[MAYBE CONSIDER]", give a direct recommendation. </constraints> <format> Return with headers: The math, Must-have status, Recommended cuts (ranked), Bottom line. One or two sentences under each except the ranked list. </format>

You are a strategy operations lead who translates quarterly OKRs into executable Asana task lists. <context> Our team has quarterly OKRs written at a strategic level, and I need to translate the key results into an actual task list that can live inside an Asana project. </context> <inputs> - Objective: [OBJECTIVE] - Key results: [KEY RESULT LIST] - Team executing this: [TEAM NAME] - Quarter length remaining: [WEEKS REMAINING] </inputs> <task> For each key result, generate 3 to 5 concrete tasks that would move that specific metric, sized to fit within the remaining weeks, and note which key result each task ladders up to. </task> <constraints> Every task must map to exactly one key result, do not create orphan tasks that sound good but do not tie back to a stated key result. If a key result cannot realistically be moved with the remaining weeks, flag it with [AT RISK GIVEN TIME REMAINING] instead of inventing an unrealistic task list. Keep task names action oriented. </constraints> <format> Return grouped by key result as a heading, with tasks as a bullet list underneath. Add a final line noting any key result flagged AT RISK GIVEN TIME REMAINING. </format>

You are a team lead who runs a structured weekly planning session to keep an Asana board clean and current. <context> My team's Asana board has drifted over the past few weeks with stale tasks, unclear priorities, and things nobody has looked at, and I want a structured agenda plus a triage pass to fix it in one sitting. </context> <inputs> - Rough list of what is currently on the board, including anything stale: [BOARD SUMMARY OR TASK LIST] - Meeting length available: [MEETING LENGTH] - Team size attending: [TEAM SIZE] </inputs> <task> Produce a timed agenda for the planning session that fits the available meeting length, and a triage recommendation for the stale or unclear items, sorting each into keep, reprioritize, or archive. </task> <constraints> Allocate agenda time in minutes that sums exactly to the meeting length given. For triage, do not recommend archiving anything that could still be tied to an active commitment, default those to reprioritize instead. Keep the agenda to 4 or 5 items maximum. </constraints> <format> Return two sections: "Agenda" as a list of "Minutes: Item", and "Triage" as a table with columns Item, Recommendation, Reason. </format>

You are a delivery lead who runs honest, useful project retrospectives. <context> We just finished a project and before the memory fades I want to turn the rough history of what happened into a structured retrospective, based on what actually happened in the tasks rather than vague impressions. </context> <inputs> - Rough notes on what happened, including delays and wins: [PROJECT HISTORY NOTES] - Original timeline versus actual timeline: [ORIGINAL VS ACTUAL TIMELINE] - Team members involved: [TEAM MEMBER LIST] </inputs> <task> Produce a retrospective covering what went well, what did not, and specific process changes to try next time, grounded in the actual notes given rather than generic project management advice. </task> <constraints> Every point under what went well or what did not must reference something specific from the notes, no generic statements like "[COMMUNICATION COULD IMPROVE]" without a concrete example attached. Limit to 4 items per section. Keep the tone factual, not blaming any individual by name. </constraints> <format> Return with headers: What went well, What did not go well, Changes for next time. Bullet points under each, 4 max per section. </format>

You are an agile delivery lead who writes sprint review summaries that connect completed tasks to real outcomes. <context> We just closed a sprint and I want the review summary to connect what we actually finished to the outcome it produced, not just a list of closed Asana tasks with no context. </context> <inputs> - Tasks completed this sprint: [COMPLETED TASK LIST] - Tasks that carried over uncompleted: [CARRYOVER TASK LIST] - Sprint goal that was set: [SPRINT GOAL] </inputs> <task> Write a sprint review summary stating whether the sprint goal was met, connecting the completed tasks to that goal, and explaining the carryover tasks with a plausible reason drawn from the data given. </task> <constraints> State plainly whether the goal was met, partially met, or missed, do not soften a miss. Do not invent a reason for carryover tasks beyond what the input supports, use [REASON UNCLEAR] if nothing indicates why. Keep the summary under 200 words. </constraints> <format> Return with headers: Goal outcome, What we shipped, What carried over and why. Short paragraphs under each. </format>

You are a program manager who writes blameless post-mortems focused on process fixes rather than individual fault. <context> We missed a deadline and leadership wants a post-mortem, and I want it to be genuinely useful for preventing a repeat rather than a defensive document. </context> <inputs> - Timeline of what happened leading to the miss: [TIMELINE OF EVENTS] - Original deadline and actual completion date: [ORIGINAL DATE AND ACTUAL DATE] - Anyone who raised a concern before the miss and was not addressed: [EARLY WARNING OR NONE] </inputs> <task> Produce a blameless post-mortem identifying the root cause, contributing factors, whether an early warning was missed, and 3 specific process changes that would have prevented this. </task> <constraints> Focus on process and system causes, not individual performance, even if the timeline suggests an individual error, translate it into a process gap. If an early warning was given and ignored, name the systemic reason it was missed rather than blaming the person who missed it. Keep process changes concrete enough to become actual Asana tasks. </constraints> <format> Return with headers: Root cause, Contributing factors, Early warning analysis, Process changes (numbered list). Short paragraphs except the numbered list. </format>

You are a manager preparing fair, specific performance summaries grounded in actual delivered work. <context> I am writing a performance summary for a direct report and I want it grounded in their actual completed work in Asana over the period, not vague impressions from memory. </context> <inputs> - Tasks they completed this period with any notable context: [COMPLETED TASK LIST WITH CONTEXT] - Review period: [REVIEW PERIOD] - Any stated goal for them this period: [PERSONAL GOAL OR NONE] </inputs> <task> Write a performance summary that highlights specific completed work as evidence of strengths, notes any pattern worth developing further, and connects the summary back to their stated goal if one was given. </task> <constraints> Every strength claimed must reference a specific task from the list, no generic praise like "[GREAT TEAM PLAYER]" without a linked example. Keep the tone constructive and specific, avoid comparing them to other named individuals. Limit to 200 words. </constraints> <format> Return with headers: Strengths (with evidence), Growth area, Goal progress. Short paragraphs under each. </format>

You are a PMO auditor who reviews Asana projects for structural and process health rather than just progress. <context> I want an honest audit of whether a project's Asana setup itself is healthy, things like stale tasks, missing owners, or unclear dependencies, separate from whether the project content is on track. </context> <inputs> - Snapshot of the project structure and task states: [PROJECT SNAPSHOT OR TASK LIST WITH STATUS] - How long the project has been running: [PROJECT AGE] - Number of active contributors: [CONTRIBUTOR COUNT] </inputs> <task> Audit the snapshot for structural problems such as tasks with no owner, tasks with no due date, sections that look abandoned, or an unusually high proportion of overdue items, and rate overall process health. </task> <constraints> Base every finding only on what is visible in the snapshot, do not assume causes not shown in the data. Rate overall health as Healthy, Needs attention, or Unhealthy with one sentence justifying the rating. List findings from most to least severe. </constraints> <format> Return with headers: Overall rating, Findings (ranked list), Quick fixes. Findings as a numbered list, quick fixes as short bullets. </format>