150 Claude Prompts That Build Project Plans

<context> We are migrating from [source system] to [target system] across [number of teams] teams. I need a single master plan that covers strategy through go-live so leadership and engineers share one source of truth. </context> <inputs> - Business reason for the migration: [fill] - Source and target capabilities and gaps: [list] - Hard deadline and budget: [fill] - Teams and stakeholders involved: [list] </inputs> <task> Produce an end-to-end migration plan covering: strategy and approach, workstreams, phase breakdown, milestones, owners, dependencies, key risks, and a go-live definition of done. </task> <constraints> - Every milestone needs an owner and an exit criterion - Flag any assumption that, if wrong, breaks the plan </constraints> <format> Markdown artifact: an executive summary, a phase table, a milestone table, and an open-questions list. </format>

<context> We need to move data from [source system] to [target system]. The schemas differ and some fields must be transformed or merged. </context> <inputs> - Source entities and approximate volumes: [list] - Target schema or model: [describe] - Known transformation rules: [list] - Data owners who can answer questions: [names] </inputs> <task> Build a data migration plan: extraction approach, field-by-field mapping with transformations, handling of nulls and duplicates, sequencing of dependent entities, and a load-and-verify loop. </task> <constraints> - Call out every field with no clean target as an open decision - Preserve referential integrity across dependent entities </constraints> <format> Markdown artifact: a source-to-target mapping table, a transformation-rules list, and a load-order list. </format>

<context> A big-bang cutover from [source system] to [target system] is too risky. We want to move in phases so each wave de-risks the next. </context> <inputs> - Modules, regions, or user groups that could be split into waves: [list] - Dependencies between them: [describe] - Constraints on timing per group: [fill] </inputs> <task> Design a phased cutover plan: define each wave, why it is sequenced where it is, entry and exit criteria, the soak period before the next wave, and the rollback boundary for each phase. </task> <constraints> - No wave may depend on a later wave - Each wave must be independently rollback-able </constraints> <format> Markdown artifact: a wave-sequence table plus a dependency note explaining the ordering. </format>

<context> We must migrate [workload or service] from [source system] to [target system] with no perceptible downtime for users in [cutover window]. </context> <inputs> - Service and traffic profile: [describe] - Current availability target (SLA): [fill] - Replication or sync options available: [list] - Load balancer or routing layer in front: [describe] </inputs> <task> Design a zero-downtime migration: how to stand up the target in parallel, sync state, shift traffic incrementally, verify health at each step, and drain the source safely. </task> <constraints> - No step may require taking the service fully offline - Define the health signals that gate each traffic shift </constraints> <format> Markdown artifact: a traffic-shift sequence table plus a health-gate checklist. </format>

<context> We are migrating from [source system] to [target system] and need a contingency plan for when steps fail mid-cutover. </context> <inputs> - Major cutover steps already planned: [list] - Point of no return, if known: [fill] - Backups, snapshots, and their freshness: [describe] - Who can authorize a rollback: [names] </inputs> <task> Build a rollback and contingency playbook: for each failure scenario, the detection signal, the immediate containment action, the rollback procedure, the data-recovery step, and how to resume later. </task> <constraints> - Distinguish reversible failures from those past the point of no return - Every rollback must state how data written during the attempt is reconciled </constraints> <format> Markdown artifact: a failure-scenario table plus an escalation and authorization note. </format>

<context> We are moving [workloads or applications] from [source environment] to [target cloud]. I need a structured migration plan that picks the right approach per workload. </context> <inputs> - Inventory of applications and their dependencies: [list] - Target cloud and any landing-zone constraints: [describe] - Compliance or data-residency requirements: [fill] - Cost and timeline targets: [fill] </inputs> <task> Produce a cloud migration plan: classify each workload by migration approach (rehost, replatform, refactor, retire, retain), justify each, sequence the moves, and call out networking, identity, and data-transfer considerations. </task> <constraints> - Justify the approach chosen for each workload - Flag workloads that should not move yet and why </constraints> <format> Markdown artifact: a workload-disposition table plus a sequencing note. </format>

<context> We are switching from [source tool] to [target tool] for [team or function]. Records, automations, and integrations all need to move without disrupting daily work. </context> <inputs> - Object types and record counts to migrate: [list] - Automations, workflows, and reports in use: [list] - Integrations connected to the old tool: [list] - Daily-active users and their key workflows: [describe] </inputs> <task> Build a tooling migration plan: data and history migration, automation and report rebuild, integration recreation, user retraining, and a switchover plan that protects in-flight work. </task> <constraints> - Preserve historical records and timestamps - Sequence so no team is blocked from doing their daily job </constraints> <format> Markdown artifact: a migration-scope table, an automation-rebuild list, and a switchover checklist. </format>

<context> We are migrating from [source database] to [target database] during [cutover window]. I need a runbook engineers can execute step by step. </context> <inputs> - Schemas, sizes, and engines: [fill] - Migration tooling available: [list] - Connection strings and apps that depend on the DB: [list] - Maintenance window and read/write expectations: [fill] </inputs> <task> Write a database migration runbook: pre-checks, schema conversion, initial bulk load, change-data-capture sync, application cutover, post-cutover validation, and the rollback path at each stage. </task> <constraints> - Each step needs a command or action, an expected result, and a verification - Specify where replication lag must reach zero before proceeding </constraints> <format> Markdown artifact: an ordered runbook table plus a pre-flight checklist. </format>

<context> The migration from [source system] to [target system] touches many components that depend on each other. I need to know what must move before what. </context> <inputs> - Components, services, and data stores in scope: [list] - Known dependencies between them: [describe] - Components that cannot move at the same time: [list] </inputs> <task> Build a dependency and sequencing map: identify upstream and downstream relationships, detect any circular dependencies, and produce a valid migration order that respects all constraints. </task> <constraints> - Surface circular dependencies explicitly and propose how to break them - The final order must satisfy every stated constraint </constraints> <format> Markdown artifact: a dependency table (component, depends-on, must-precede) plus an ordered migration sequence. </format>

<context> We are planning a migration from [source system] to [target system] and need a living risk register to manage proactively. </context> <inputs> - What we are migrating and the timeline: [fill] - Known concerns and past incidents: [list] - Constraints (people, budget, downtime tolerance): [fill] </inputs> <task> Build a migration risk register: identify risks across data, technical, schedule, people, and vendor dimensions, score each by likelihood and impact, assign an owner, and define a mitigation plus a trigger that means the risk is materializing. </task> <constraints> - Score every risk and sort by severity - Each risk needs both a mitigation and an early-warning trigger </constraints> <format> Markdown artifact: a risk-register table (risk, category, likelihood, impact, score, owner, mitigation, trigger). </format>

<context> Before we start the migration from [source system] to [target system], I need to confirm we are actually ready and not about to discover gaps mid-cutover. </context> <inputs> - Planned cutover date: [fill] - Environments, access, and tooling status: [describe] - Backups, runbooks, and rollback plans status: [describe] - Stakeholder and approval status: [describe] </inputs> <task> Produce a pre-migration readiness checklist grouped by category (data, environment, access, tooling, people, approvals, rollback), with a clear ready/not-ready test for each item and a single go/no-go question. </task> <constraints> - Each item must be objectively verifiable, not a judgment call - Highlight any item that is a hard blocker for go-live </constraints> <format> Markdown artifact: a grouped checklist with a status column and a final go/no-go summary. </format>

<context> After migrating data from [source system] to [target system], we need to prove the data is correct before trusting it in production. </context> <inputs> - Entities and critical fields: [list] - Known business rules the data must obey: [list] - Volumes and any sampling constraints: [fill] </inputs> <task> Build a data validation and test plan: row-count and checksum comparisons, field-level spot checks, business-rule assertions, referential-integrity checks, and a defined pass threshold for each test category. </task> <constraints> - Every test must state how it is run and what counts as a pass - Include both automated checks and targeted manual spot checks </constraints> <format> Markdown artifact: a test-case table (test, method, scope, pass criteria, owner) plus a sign-off section. </format>

<context> The migration from [source system] to [target system] will affect [user groups]. I need a communication plan so no one is surprised and support is not overwhelmed. </context> <inputs> - Audiences impacted and how each is affected: [list] - Key dates (freeze, cutover, go-live): [fill] - Channels available (email, in-app, Slack, status page): [list] - Support and escalation contacts: [names] </inputs> <task> Build a migration communication plan: for each audience, the messages to send, the timing relative to cutover, the channel, the owner, and the call to action. Include a what-to-do-if-something-breaks note. </task> <constraints> - Tailor message detail to each audience, not one generic blast - Cover before, during, and after the cutover </constraints> <format> Markdown artifact: a comms-schedule table plus draft text for the three most important messages. </format>

<context> To migrate safely from [source system] to [target system], we need to freeze changes and define a blackout window. I need the freeze scoped so it protects the migration without halting the whole business. </context> <inputs> - What activities could mutate state during migration: [list] - Business-critical processes that cannot fully stop: [list] - Proposed freeze start and cutover window: [fill] </inputs> <task> Design a freeze and blackout-window plan: define what is frozen, what stays allowed and how it is handled, the exact freeze and thaw times, who enforces it, and the exception process for urgent changes. </task> <constraints> - Distinguish a full freeze from a partial freeze where needed - Define an exception path so true emergencies are not blocked </constraints> <format> Markdown artifact: a freeze-scope table plus a timeline with freeze, blackout, and thaw markers. </format>

<context> We want to run [source system] and [target system] in parallel with dual writes so we can validate the target under real load before fully cutting over. </context> <inputs> - Write paths and operations in scope: [list] - How long we can sustain a parallel run: [fill] - Tolerance for write divergence between systems: [fill] - Reconciliation tooling available: [describe] </inputs> <task> Design a parallel-run dual-write plan: how writes go to both systems, how reads are served during the run, how to detect and reconcile divergence, the success criteria to declare the target trustworthy, and how to retire the source. </task> <constraints> - Define exactly how divergence is detected and resolved - State the measurable criteria that end the parallel run </constraints> <format> Markdown artifact: a dual-write flow description, a divergence-handling table, and exit criteria. </format>

<context> We are cutting over from [source system] to [target system] during [cutover window]. I need a precise runbook the team can execute under pressure. </context> <inputs> - Systems involved and integrations: [list] - Cutover window and timezone: [fill] - Team on call and roles: [names] </inputs> <task> Produce a minute-by-minute cutover runbook: each step with start time, action, owner, expected result, verification check, and the rollback action if it fails. </task> <constraints> - Every step must have a verification and a rollback - Mark the point of no return explicitly </constraints> <format> Markdown artifact: an ordered step table plus a go/no-go checklist at the top. </format>

<context> The cutover from [source system] to [target system] is done. Before we declare success and release the team, I need a structured plan to verify everything actually works. </context> <inputs> - Critical user journeys to confirm: [list] - Integrations and downstream consumers: [list] - Performance and error-rate baselines from before: [fill] - Monitoring and alerting in place: [describe] </inputs> <task> Build a post-migration verification plan: functional smoke tests, integration checks, performance comparison against baseline, error-rate monitoring window, and the criteria to officially declare the migration complete. </task> <constraints> - Compare against pre-migration baselines, not absolutes - Define the monitoring window length before sign-off </constraints> <format> Markdown artifact: a verification checklist table plus a completion sign-off section. </format>

<context> Now that [target system] is live, we need to safely retire [source system] without losing data, breaking forgotten integrations, or violating retention rules. </context> <inputs> - Data and history that must be retained or archived: [list] - Integrations or jobs that may still point at the legacy system: [list] - Licensing, hosting, and access to be wound down: [describe] - Compliance retention requirements: [fill] </inputs> <task> Build a legacy decommission plan: confirm nothing still depends on the source, archive required data, revoke access, shut down in a reversible-then-permanent sequence, and capture cost savings realized. </task> <constraints> - Include a quiet period where the system is off but recoverable before permanent deletion - Verify zero live dependencies before any shutdown </constraints> <format> Markdown artifact: a decommission step table plus a data-retention and dependency-clearance checklist. </format>

<context> The migration from [source system] to [target system] spans multiple teams and decisions keep stalling over who owns what. I need a clear RACI. </context> <inputs> - Major activities and decisions in the migration: [list] - Roles and people involved: [names and titles] - Known areas of unclear ownership: [list] </inputs> <task> Build a migration RACI matrix: for each activity, assign who is Responsible, Accountable, Consulted, and Informed, ensuring exactly one accountable owner per activity and no orphaned decisions. </task> <constraints> - Exactly one Accountable per activity, never zero or two - Flag any activity where ownership is currently ambiguous </constraints> <format> Markdown artifact: a RACI table (activity down the rows, roles across the columns) plus a note on ownership gaps to resolve. </format>

<context> During the cutover from [source system] to [target system], we must not debate whether to roll back in the heat of the moment. I need objective decision criteria set in advance. </context> <inputs> - Health and success signals being monitored: [list] - Acceptable thresholds for errors, latency, and data issues: [fill] - Time budget for the cutover window: [fill] - Who holds the rollback decision: [names] </inputs> <task> Define rollback decision criteria: the specific signals and thresholds that mandate a rollback, the ones that warrant pause-and-assess, the time-box past which we abort, and exactly who calls it. </task> <constraints> - Criteria must be objective numbers or binary conditions, not opinions - Separate must-rollback from pause-and-watch conditions </constraints> <format> Markdown artifact: a decision-criteria table (signal, threshold, action, decider) plus a one-line abort rule. </format>

<context> We run a multi-tenant platform on [source system] and are moving tenants to [target system] one batch at a time to limit blast radius. </context> <inputs> - Tenant list with size, plan tier, and risk profile: [describe] - Per-tenant constraints (timezones, contracts, SLAs): [fill] - Capacity for how many tenants per batch: [fill] </inputs> <task> Design a staged tenant-by-tenant migration: order tenants from lowest to highest risk, define batch sizes, per-tenant cutover steps, the soak window between batches, and the criteria to proceed to the next batch. </task> <constraints> - Start with low-risk tenants and escalate only after clean batches - Each tenant must be migratable and rollback-able independently </constraints> <format> Markdown artifact: a tenant-batch schedule table plus per-batch go/no-go criteria. </format>

<context> Before migrating everyone from [source system] to [target system], we want to run a pilot with a small group to find problems cheaply. </context> <inputs> - Candidate pilot group and why they fit: [describe] - What we most want to learn or de-risk: [list] - Duration we can run the pilot: [fill] - How feedback will be collected: [describe] </inputs> <task> Build a pilot migration plan: pilot-group selection criteria, scope and guardrails, the success metrics and feedback loop, the issues-triage process, and the go/no-go decision for full rollout. </task> <constraints> - Pilot must be representative enough that results generalize - Define a clear graduation bar to move from pilot to full rollout </constraints> <format> Markdown artifact: a pilot-plan summary, a success-metrics table, and a feedback-and-decision section. </format>

<context> We need to define what 'a successful migration' from [source system] to [target system] actually means, in numbers, before we start. </context> <inputs> - Business goals behind the migration: [list] - Current baselines (cost, performance, error rates, satisfaction): [fill] - Timeline and budget targets: [fill] </inputs> <task> Define migration success metrics: pick leading and lagging indicators across delivery, technical health, data integrity, cost, and user impact; set a target and measurement method for each; and assemble them into a scorecard. </task> <constraints> - Each metric needs a baseline, a target, and how it is measured - Include at least one user-impact metric, not just technical ones </constraints> <format> Markdown artifact: a success-scorecard table (metric, baseline, target, source, owner). </format>

<context> After migrating from [source system] to [target system], I need to reconcile both sides to prove nothing was lost, duplicated, or silently altered. </context> <inputs> - Entities and the keys that uniquely identify records: [list] - Fields where exact match matters versus tolerated transformation: [describe] - Acceptable discrepancy tolerance, if any: [fill] </inputs> <task> Build a data-integrity reconciliation plan: counts comparison, key-by-key matching, field-level diffing on critical fields, classification of discrepancies (missing, extra, mismatched), and a remediation path for each class. </task> <constraints> - Account for legitimate transformations so they are not flagged as errors - Every discrepancy class needs a defined remediation step </constraints> <format> Markdown artifact: a reconciliation-check table plus a discrepancy-classification and remediation list. </format>

<context> Our migration from [source vendor] to [target vendor] has commercial and contractual moving parts, not just technical ones. I need a plan to manage the vendor transition cleanly. </context> <inputs> - Existing contract terms, notice periods, and end dates: [fill] - New vendor onboarding requirements and timelines: [describe] - Data export and ownership clauses with the old vendor: [fill] - Procurement and legal stakeholders: [names] </inputs> <task> Build a vendor and contract transition plan: align contract end dates with technical cutover, secure data extraction rights, sequence onboarding of the new vendor, plan overlap to avoid a coverage gap, and define exit obligations on both sides. </task> <constraints> - Avoid any window where we are paying both or covered by neither - Confirm data-export rights and format before terminating the old contract </constraints> <format> Markdown artifact: a transition-timeline table plus a contractual-obligations and risks checklist. </format>

<context> I own product for [team/product] and need a credible roadmap for [quarter] that I can defend to leadership and rally engineering around. </context> <inputs> - Product vision and strategy: [paste] - Top problems / opportunities this quarter: [list] - Known constraints (team size, tech debt, hard deadlines): [list] - Candidate initiatives: [list] </inputs> <task> Build a quarterly product roadmap. For each initiative, state the problem it solves, the target outcome, a rough effort tier (S/M/L), and a confidence level. Sequence items across the quarter and justify the order. </task> <constraints> - Tie every item to a problem or outcome, not a feature for its own sake - Be explicit about what is NOT being done this quarter and why </constraints> <format> Markdown artifact: a roadmap table (initiative, problem, outcome, effort, confidence, month) plus a short "not now" list. </format>

<context> I run [team] and want our [quarter] roadmap to flow directly from our OKRs so every project earns its place. </context> <inputs> - Our OKRs for the quarter: [paste objectives and key results] - Backlog of candidate work: [list] - Capacity (people, weeks available): [numbers] </inputs> <task> Map each candidate piece of work to the Key Result it moves. Drop or flag anything that maps to nothing. Then build a quarter plan that allocates capacity to the highest-leverage KRs first. </task> <constraints> - Every committed item must trace to a specific KR - Leave 15 to 20 percent capacity unplanned for the unexpected </constraints> <format> Markdown artifact: a KR-to-work mapping table, an orphaned-work list, and a capacity allocation summary. </format>

<context> I want to organize [team]'s [quarter] roadmap around a few strategic themes rather than a flat list of features, so the story is clear to everyone. </context> <inputs> - Strategic priorities this quarter: [paste] - Candidate initiatives and ideas: [list] - Audience for the roadmap: [exec / customers / internal] </inputs> <task> Cluster the initiatives into 3 to 5 coherent themes. Name each theme, write a one-line rationale, and list the initiatives under it with intended outcomes. Highlight any initiative that does not fit a theme and decide whether to cut or reframe it. </task> <constraints> - Themes must be outcome-oriented and mutually distinct - No theme should hold more than half the total work </constraints> <format> Markdown artifact: theme sections, each with a rationale line and an initiative table (name, outcome, effort). </format>

<context> My stakeholders keep asking for exact dates we cannot honestly commit to. I want a Now / Next / Later roadmap for [team] that signals direction without false precision. </context> <inputs> - Current in-flight work: [list] - High-confidence upcoming work: [list] - Directional bets and ideas: [list] - Strategic context: [one paragraph] </inputs> <task> Sort all items into Now, Next, and Later. For each, note the outcome we expect and our confidence. Explain the criteria that move an item from Later to Next to Now. </task> <constraints> - Confidence and detail should decrease from Now to Later - No hard dates; use relative horizons only </constraints> <format> Markdown artifact: three columns (Now, Next, Later) as tables, plus a short note on promotion criteria. </format>

<context> I keep overcommitting [team] each quarter. For [quarter] I want a roadmap that respects real capacity including meetings, support, and time off. </context> <inputs> - Team members and their roles: [list] - Planned time off and known commitments: [list] - Recurring overhead (support, meetings, on-call) as a percent: [number] - Candidate work with rough estimates: [list] </inputs> <task> Calculate true available capacity per person and in total. Fit the candidate work into that capacity, showing what makes the cut and what is deferred. Surface any week that looks overloaded. </task> <constraints> - Do not exceed realistic capacity; explicitly reserve overhead - Flag single-person dependencies as risks </constraints> <format> Markdown artifact: a capacity table per person, a committed-vs-deferred list, and a load-by-week summary. </format>

<context> I am coordinating [quarter] planning across [list of teams] and need one shared roadmap that exposes hand-offs and shared bets. </context> <inputs> - Each team's goals and planned work: [paste per team] - Shared initiatives requiring more than one team: [list] - Known inter-team dependencies: [list] </inputs> <task> Build a unified roadmap showing each team's lane plus shared initiatives. Map dependencies between teams and flag any sequencing conflict where one team needs another's output before it is ready. </task> <constraints> - Make every cross-team hand-off explicit with a needed-by timing - Highlight conflicts rather than silently resolving them </constraints> <format> Markdown artifact: a swimlane-style table (rows = teams, columns = months), a dependency list, and a conflicts section. </format>

<context> I have a messy backlog for [team] and need to shape it into a coherent [quarter] roadmap instead of a flat to-do list. </context> <inputs> - Raw backlog items: [paste] - This quarter's goals: [list] - Rough capacity: [number of person-weeks] </inputs> <task> Deduplicate and cluster the backlog, score each cluster for value and effort, then select and sequence the highest-value clusters that fit capacity into a quarter roadmap. Note what is parked. </task> <constraints> - Merge duplicates and near-duplicates before scoring - Be explicit about the cut line and what falls below it </constraints> <format> Markdown artifact: a cleaned cluster table (value, effort, decision) plus the resulting month-by-month roadmap. </format>

<context> I lead [team] and need OKRs for [quarter] that ladder up to our company goals, not vanity metrics. </context> <inputs> - Company goals this quarter: [paste] - My team's mandate: [one paragraph] - Constraints (headcount, dependencies): [list] </inputs> <task> Draft 3 Objectives, each with 3 measurable Key Results. For each KR give a baseline, a target, and how it is measured. Flag any KR that is an output rather than an outcome and suggest a better one. </task> <constraints> - Key Results must be measurable and outcome-focused - No more than 3 objectives; ruthless focus </constraints> <format> Markdown artifact: objective sections with KR tables (baseline, target, measure). </format>

<context> We have company-level OKRs for [quarter] and I need to cascade them into aligned team OKRs across [list of teams] without losing the thread. </context> <inputs> - Company OKRs: [paste objectives and key results] - Teams and their mandates: [list] - Any team-specific constraints: [list] </inputs> <task> For each team, draft Objectives and Key Results that contribute to the company KRs. Show the line from each team KR up to the company KR it supports. Flag any company KR with no team owning it and any duplication across teams. </task> <constraints> - Every team KR must trace upward to a company KR - Avoid having two teams own the identical KR unless intentional </constraints> <format> Markdown artifact: an OKR tree showing company-to-team linkage, plus a coverage table flagging gaps and overlaps. </format>

<context> I am facilitating [team]'s [quarter] planning session ([duration], [in person / remote]) and want a tight agenda plus a way to capture decisions. </context> <inputs> - Attendees and roles: [list] - Inputs available (last-quarter results, OKRs, backlog): [list] - Decisions we must leave with: [list] </inputs> <task> Design a timeboxed agenda that moves from context to prioritization to commitment. For each block give a goal, an activity, an owner, and a timebox. Include pre-reads and a decision-capture template. </task> <constraints> - Total time must fit the stated duration - Every block must produce a concrete artifact or decision </constraints> <format> Markdown artifact: an agenda table (block, goal, activity, owner, minutes), a pre-read list, and a decisions log template. </format>

<context> I need a crisp one-pager for [initiative] to get it onto [team]'s [quarter] roadmap and win stakeholder buy-in. </context> <inputs> - The problem and who has it: [paste] - Proposed approach: [paste] - Expected outcome and how we will measure it: [notes] - Rough cost or effort: [estimate] </inputs> <task> Write a one-page initiative brief covering the problem, the opportunity size, the proposed solution, the target outcome and metric, scope boundaries, key risks, and the ask. Keep it skimmable. </task> <constraints> - Fit on a single page; lead with the problem, not the solution - State explicitly what is out of scope </constraints> <format> Markdown artifact: a one-pager with clear headers and a bolded one-line "the ask" at the end. </format>

<context> I have more candidate work than [team] can do in [quarter] and want an objective RICE pass to decide what makes the roadmap. </context> <inputs> - Candidate items with any data I have (reach, impact, effort): [paste] - How I define impact on a 0.25 to 3 scale: [definition] - Capacity available: [person-weeks] </inputs> <task> Score each item with RICE (Reach, Impact, Confidence, Effort) and compute the RICE score. Rank items, draw the cut line at capacity, and call out any item where low confidence should override a high raw score. </task> <constraints> - Show your assumptions for every estimate you fill in - Penalize low-confidence items rather than ignoring confidence </constraints> <format> Markdown artifact: a RICE table (reach, impact, confidence, effort, score) sorted descending, with the capacity cut line marked. </format>

<context> [Team]'s [quarter] roadmap has chains of work that depend on each other and I keep getting blindsided. I want dependencies modeled up front. </context> <inputs> - Initiatives with rough estimates: [list] - Known dependencies (A needs B first): [list] - External dependencies on other teams or vendors: [list] </inputs> <task> Build a dependency graph for the roadmap, identify the critical path, and sequence work so prerequisites land before dependents. Flag any external dependency that could stall the chain and suggest a fallback ordering. </task> <constraints> - Never schedule a dependent item before its prerequisite - Call out the longest dependency chain as the critical path </constraints> <format> Markdown artifact: a dependency list, a critical-path callout, and a sequenced timeline table. </format>

<context> Before I commit [team]'s [quarter] roadmap I want a clear-eyed look at the risks and the assumptions it secretly rests on. </context> <inputs> - The draft roadmap: [paste] - Things I am assuming will hold true: [list] - Recent surprises that hurt us: [list] </inputs> <task> Surface the key assumptions baked into the roadmap and the risks to delivery. Rate each risk by likelihood and impact, propose a mitigation or early-warning signal, and name an owner. Highlight assumptions that, if wrong, would break the plan. </task> <constraints> - Separate assumptions from risks; do not conflate them - Every high-impact risk needs a mitigation and an owner </constraints> <format> Markdown artifact: an assumptions list and a risk register table (risk, likelihood, impact, mitigation, owner, signal). </format>

<context> I have a [quarter] roadmap for [team] and need a compelling narrative for a stakeholder deck, not just a list of features. </context> <inputs> - The roadmap (themes and initiatives): [paste] - The strategic context and why now: [notes] - Audience and what they care about: [describe] </inputs> <task> Write a slide-by-slide narrative that opens with the strategic why, frames the quarter's bets, walks through the roadmap by theme, and closes with the expected outcomes and asks. Provide speaker notes for each slide. </task> <constraints> - Lead with outcomes and strategy, not feature lists - Keep each slide to one core idea </constraints> <format> Markdown artifact: a slide outline (slide title, on-slide bullets, speaker notes) ordered for a 10 to 12 slide deck. </format>

<context> We set annual goals for [year] and I need to break them into a quarter-by-quarter plan for [team] so progress is paced and measurable. </context> <inputs> - Annual goals or themes: [paste] - Any fixed dates or seasonal constraints: [list] - Rough quarterly capacity: [notes] </inputs> <task> Decompose each annual goal into quarterly milestones across Q1 to Q4. Define what "done" looks like by the end of each quarter and a checkpoint metric. Sequence so early quarters set up later ones. </task> <constraints> - Each quarter must have a concrete, measurable milestone per goal - Front-load enabling work that later quarters depend on </constraints> <format> Markdown artifact: a table with goals as rows and Q1 to Q4 as columns, each cell holding a milestone and a checkpoint metric. </format>

<context> [Team] cannot do everything in [quarter] and I need a structured trade-off analysis to choose between competing roadmap options. </context> <inputs> - The competing options or bundles of work: [describe each] - What we are optimizing for this quarter: [criteria] - Constraints and capacity: [list] </inputs> <task> Compare the options against our criteria. Show what each option gains and gives up, the second-order effects, and which stakeholders win or lose under each. Recommend one option with explicit reasoning and the conditions under which you would switch. </task> <constraints> - Make the costs of each option as explicit as the benefits - State the decision criteria before scoring against them </constraints> <format> Markdown artifact: a weighted comparison table, a gains-and-gives-up summary per option, and a recommendation with switch conditions. </format>

<context> My current roadmap is a list of features. I want to reframe [team]'s [quarter] roadmap around outcomes so teams have room to find the best solution. </context> <inputs> - The feature-based roadmap I have today: [paste] - The business or user outcomes we actually want: [list] - Metrics that signal each outcome: [list] </inputs> <task> Rewrite the roadmap as a set of target outcomes, each with a success metric and a few candidate solution bets rather than fixed features. Identify any current feature that does not map to a real outcome and challenge it. </task> <constraints> - State desired outcomes and metrics, not prescribed features - Each outcome needs at least one measurable success signal </constraints> <format> Markdown artifact: outcome sections (outcome, metric, candidate bets) plus a list of features that lacked an outcome. </format>

<context> Stakeholders treat everything on [team]'s [quarter] roadmap as a promise. I want to clearly separate firm commitments from stretch aspirations. </context> <inputs> - The full roadmap of intended work: [paste] - Our true confidence per item (high/medium/low): [notes] - Capacity and known risks: [list] </inputs> <task> Classify every item as a Commitment (we will deliver this) or an Aspiration (we will attempt if things go well). Justify each call using confidence, dependencies, and capacity. Ensure commitments fit comfortably inside capacity with aspirations as upside. </task> <constraints> - Commitments must fit within conservative capacity, not best-case - Each classification needs a one-line rationale </constraints> <format> Markdown artifact: two tables (Commitments, Aspirations) with rationale, plus a capacity check showing commitments stay within budget. </format>

<context> We are halfway through [quarter] and I want to run a mid-quarter review for [team] to course-correct the roadmap before it is too late. </context> <inputs> - The roadmap and OKRs we committed to: [paste] - Progress and status per item: [notes] - Things that changed since planning: [list] </inputs> <task> Assess where we are versus the plan, flag items at risk of missing, and recommend cuts, swaps, or re-sequencing for the back half. Produce a short review agenda and a decisions template for the meeting. </task> <constraints> - Recommend concrete actions, not just status colors - Protect the highest-leverage KR if something must be cut </constraints> <format> Markdown artifact: a status table (item, planned, actual, on-track?), a recommended-changes list, and a review agenda. </format>

<context> I need a resourcing plan that staffs [team]'s [quarter] roadmap, matching people and skills to initiatives and exposing gaps. </context> <inputs> - Roadmap initiatives with rough effort: [list] - People, their skills, and availability: [list] - Skills each initiative requires: [notes] </inputs> <task> Allocate people to initiatives across the quarter, matching required skills to available skills. Surface over-allocation, skill gaps, and any initiative without enough qualified staff. Recommend hires, training, or scope cuts to close gaps. </task> <constraints> - No person allocated above 100 percent in any period - Explicitly flag single points of failure on critical initiatives </constraints> <format> Markdown artifact: an allocation grid (people x initiatives x month), an over-allocation flag list, and a gap-closure recommendation. </format>

<context> I need two views of [team]'s [quarter] roadmap from one source: a strategic version for execs and a detailed version for engineering. </context> <inputs> - The underlying roadmap (initiatives, outcomes, effort): [paste] - What execs care about: [outcomes, dates, dependencies] - What engineers care about: [scope, tickets, sequencing, tech risks] </inputs> <task> Generate two consistent roadmap views from the same data. The exec view emphasizes outcomes, themes, and high-level timing. The engineering view emphasizes detailed scope, sequencing, dependencies, and technical risks. Keep them reconciled so they never contradict. </task> <constraints> - Both views must derive from the identical underlying data - Exec view hides implementation detail; engineering view hides nothing </constraints> <format> Markdown artifact: two clearly separated sections, each with its own appropriately-pitched roadmap table. </format>

<context> Our backlog for [team] has grown stale and inconsistent. I want a structured grooming plan to get it ready for [quarter] planning. </context> <inputs> - A sample or summary of the current backlog: [paste] - Common problems (no estimates, duplicates, vague titles): [notes] - Our definition of ready: [paste or describe] </inputs> <task> Design a grooming pass: rules for closing stale items, merging duplicates, splitting epics, and enforcing the definition of ready. Sort items into keep, refine, merge, or archive, and lay out a sequence and timebox for the grooming session. </task> <constraints> - Apply an objective staleness and readiness rule, not gut feel - Every kept item must meet the definition of ready or get a refine action </constraints> <format> Markdown artifact: a grooming ruleset, a triage table (item, decision, action), and a session plan with timeboxes. </format>

<context> I want a single line of sight for [team] in [quarter] connecting our goals to the initiatives we run to the metrics that prove progress. </context> <inputs> - Quarterly goals: [paste] - Planned initiatives: [list] - Metrics and instrumentation we have: [list] </inputs> <task> Build a goal-to-initiative-to-metric map. For each goal, list the initiatives meant to move it and the metric that proves movement. Flag goals with no initiative, initiatives with no metric, and metrics we cannot currently measure. </task> <constraints> - Every initiative must link to at least one goal and one metric - Surface measurement gaps rather than assuming data exists </constraints> <format> Markdown artifact: a three-column traceability table (goal, initiatives, metric) plus a gaps section for unlinked or unmeasurable items. </format>

<context> [Quarter] is ending and I want to run a retrospective for [team] and feed the lessons directly into next quarter's roadmap. </context> <inputs> - What we committed to vs what we delivered: [paste] - The OKR results: [numbers] - What felt good and what hurt: [notes] </inputs> <task> Run a structured retro: what worked, what did not, and why, separating process issues from estimation issues from external causes. Extract concrete lessons, then translate each lesson into a specific change to how we plan or what we commit to next quarter. </task> <constraints> - Tie every lesson to evidence from this quarter, not opinion - Each lesson must produce one actionable change for next quarter </constraints> <format> Markdown artifact: a retro table (observation, root cause, lesson), then a "changes for next quarter" action list with owners. </format>

<context> I'm planning [event name], a [event type] on [date] in [location/virtual] for [audience size] attendees. </context> <inputs> - Goal and success metric: [fill] - Budget and owner: [budget], [owner] - Team and roles available: [list] - Hard deadlines and constraints: [fill] </inputs> <task> Build a complete event project plan. Break it into workstreams (venue, content, promotion, logistics, sponsorship, day-of). For each workstream, list milestones with owners, due dates counted backward from event day, and dependencies. Flag the critical path. </task> <constraints> - Every milestone needs an owner and a date - Surface dependencies explicitly so nothing blocks silently - Keep the plan scannable, not a wall of prose </constraints> <format> Markdown artifact: one milestone table per workstream, plus a short critical-path summary. </format>

<context> I'm running a webinar [topic] on [date] and need a runbook covering promotion through follow-up. </context> <inputs> - Goal and target registrations: [fill] - Speakers and roles: [list] - Channels and budget: [fill] </inputs> <task> Produce a runbook with three phases: Pre (promo timeline, assets, registration), Live (run-of-show minute by minute with owners), Post (follow-up sequence, lead routing, metrics). Include owners and due dates. </task> <constraints> - Promo timeline must count backward from the event date - Every live-segment needs an owner and a fallback </constraints> <format> Markdown artifact: three phase sections, each with a task table. </format>

<context> We're launching [product name] with a [in-person/virtual/hybrid] launch event on [date] aimed at [audience]. </context> <inputs> - Launch narrative and key messages: [fill] - Demo or reveal moment: [describe] - Press, partners, and VIP list: [fill] - Budget and team: [budget], [team] </inputs> <task> Create a launch event plan that ties the event to the broader product launch. Cover pre-launch teaser sequence, event-day program, the reveal moment, and post-event amplification. Map each phase to owners, dates, and the messages they carry. </task> <constraints> - The reveal moment must be the structural centerpiece of the day - Coordinate event timing with embargo and press needs - No segment without an owner </constraints> <format> Markdown artifact: phased plan tables (teaser, event-day program, amplification) plus a messaging map. </format>

<context> We're exhibiting at [conference name] on [dates] with a [booth size] booth, targeting [audience/goal]. </context> <inputs> - Booth goals and lead target: [fill] - Staff available and shifts: [list] - Collateral, demos, and giveaways: [fill] - Budget and logistics constraints: [fill] </inputs> <task> Build a booth plan covering pre-show prep, on-site execution, and post-show. Include a staffing roster by shift, a lead-capture-and-qualify process, a demo schedule, and a shipping/setup/teardown checklist with owners and times. </task> <constraints> - No staffing gap during open hours - Lead capture process must specify the qualifying questions and tool - Include teardown and shipping-back steps, often forgotten </constraints> <format> Markdown artifact: staffing roster table, demo schedule, and prep/teardown checklists. </format>

<context> We're launching campaign [campaign name] from [start date] to [end date] to drive [goal] for [audience]. </context> <inputs> - Core offer and key message: [fill] - Channels in scope: [email, social, paid, web, etc.] - Budget split and team: [fill] - KPIs and targets: [fill] </inputs> <task> Build a multi-channel campaign plan. For each channel, define the role it plays, the assets needed, the cadence, the owner, and how it hands off to the next channel. Add a unified timeline showing how channels fire in sequence, plus a single KPI dashboard spec. </task> <constraints> - Each channel must have a distinct role, not just repeat the same message - Show cross-channel handoffs explicitly - Tie every channel back to the shared KPIs </constraints> <format> Markdown artifact: per-channel plan tables, a sequenced timeline, and a KPI tracking table. </format>

<context> I need a content calendar for campaign [campaign name] running [start date] to [end date] across [channels]. </context> <inputs> - Themes or content pillars: [list] - Posting cadence per channel: [fill] - Key dates and milestones to hit: [fill] - Owners and approval steps: [fill] </inputs> <task> Build a dated content calendar. For each slot, specify date, channel, format, working title, theme/pillar, owner, status, and draft-due date. Sequence content so it builds toward the campaign's key moments rather than reading as random posts. </task> <constraints> - Respect each channel's cadence; do not over- or under-post - Every slot needs a draft-due date earlier than its publish date - Anchor content around the key dates provided </constraints> <format> Markdown artifact: a single chronological calendar table sortable by date and channel. </format>

<context> We need to produce [number/type of assets] for campaign [campaign name] by [deadline] with team [roles]. </context> <inputs> - Asset list and formats: [fill] - Production stages we use: [brief, draft, design, review, publish] - Owners per stage and capacity: [fill] - Hard deadlines: [fill] </inputs> <task> Build a content production plan. Map every asset through each production stage with an owner and due date per stage, back-planned from publish. Flag bottlenecks where one owner is overloaded in the same window, and propose rebalancing. </task> <constraints> - Each stage must have its own due date, not just a final deadline - Surface capacity conflicts where an owner has too much due at once - Keep review/approval time realistic, not zero </constraints> <format> Markdown artifact: production-tracker table (asset x stage x owner x date) plus a bottleneck note. </format>

<context> Campaign [campaign name] goes live on [launch date/time] across [channels]. I need a launch-day checklist. </context> <inputs> - What goes live and where: [fill] - Tracking, links, and UTMs to verify: [fill] - Approvals still pending: [fill] - Owners and on-call for launch day: [fill] </inputs> <task> Produce a launch checklist split into T-minus (day before), go-live hour, and first-day monitoring. For each item, list the check, the owner, the expected result, and what to do if it fails. Include a go/no-go gate before anything publishes. </task> <constraints> - Every item must be verifiable, not vague - Include a rollback or pause step for each live channel - The go/no-go gate must list its pass criteria </constraints> <format> Markdown artifact: three checklist tables (T-minus, go-live, monitoring) plus a go/no-go gate. </format>

<context> I'm running [event name] on [date] from [start time] to [end time] at [venue/platform]. </context> <inputs> - Program segments and durations: [list] - Speakers, hosts, and crew: [list] - Transitions, AV cues, and breaks: [fill] - Known risk points: [fill] </inputs> <task> Build a minute-by-minute run-of-show. For each time block, list start time, segment, who is on stage/mic, AV or tech cue, owner backstage, and a fallback if it runs long or a speaker drops. Include buffer time and a recovery plan for overruns. </task> <constraints> - Times must be absolute (clock times), not just durations - Every block needs a backstage owner and a fallback - Build in buffer so one overrun does not collapse the schedule </constraints> <format> Markdown artifact: a run-of-show table keyed by clock time, plus a contingency note. </format>

<context> For [event name] on [date] I'm coordinating [number] speakers and their deliverables. </context> <inputs> - Speakers, sessions, and contacts: [list] - Required assets per speaker: [bio, headshot, slides, A/V needs] - Deadlines per asset: [fill] - Approval/owner on our side: [fill] </inputs> <task> Build a speaker and asset tracker. For each speaker, track every required asset with a status (not started / in progress / received / approved), a due date, and our chasing owner. Add a follow-up cadence that escalates as deadlines approach, and a summary of what is at risk. </task> <constraints> - Status values must be consistent across the tracker - Each missing asset needs a chase date before its hard deadline - Surface an at-risk list, not just raw rows </constraints> <format> Markdown artifact: speaker-asset tracker table plus an at-risk summary and chase schedule. </format>

<context> For campaign [campaign name] I need clear ownership across the team [roles/people]. </context> <inputs> - Major activities and deliverables: [list] - People and their roles: [list] - Decision points and approvers: [fill] - Known ambiguity or past friction: [fill] </inputs> <task> Build a RACI matrix for the campaign. For each activity, assign exactly one Accountable owner, the Responsible doers, and who is Consulted and Informed. Flag any activity with no clear Accountable owner or with too many cooks, and recommend a fix. </task> <constraints> - Exactly one Accountable per activity, never zero or two - Keep Consulted/Informed lists lean so the matrix stays usable - Call out gaps and overlaps explicitly </constraints> <format> Markdown artifact: a RACI table (activities as rows, people as columns) plus a gaps-and-overlaps note. </format>

<context> I need a Gantt-style timeline for campaign [campaign name] running [start date] to [end date]. </context> <inputs> - Phases and tasks: [list] - Durations or known dates: [fill] - Dependencies between tasks: [fill] - Owners: [list] </inputs> <task> Build a Gantt-style timeline as a table. Use rows for tasks and columns for weeks (or days), marking the active span of each task. Capture start, end, owner, and dependency for each. Highlight the critical path and any tasks that overlap on the same owner. </task> <constraints> - Respect dependencies: a task cannot start before its predecessor ends - Mark the critical path distinctly - Keep the time columns even and labeled with dates </constraints> <format> Markdown artifact: a Gantt table with weeks across the top and task spans marked, plus a critical-path callout. </format>

<context> I'm budgeting campaign [campaign name] with a total of [budget] over [timeframe]. </context> <inputs> - Cost categories: [media, creative, tools, talent, events, etc.] - Known quotes or estimates: [fill] - Expected returns or targets: [fill] - Approval thresholds: [fill] </inputs> <task> Build a campaign budget plan. Allocate the total across categories with line items, planned vs. committed amounts, and an owner per line. Hold a contingency reserve, compute remaining headroom, and show a simple cost-per-result and projected ROI based on the targets. </task> <constraints> - Allocations must sum to the total, including the reserve - Separate planned from committed so we can track burn - State assumptions behind any ROI projection </constraints> <format> Markdown artifact: budget table by category and line, a reserve line, and a cost-per-result summary. </format>

<context> For campaign [campaign name] launching [date] I want to get ahead of what could go wrong. </context> <inputs> - Campaign scope and dependencies: [fill] - External factors in play: [fill] - Past failures or near-misses: [fill] - Owners available to respond: [list] </inputs> <task> Build a risk register. Identify risks across delivery, technical, messaging, budget, and external categories. For each, rate likelihood and impact, define an early-warning signal, a mitigation, a contingency, and an owner. Rank by severity and call out the top risks to brief leadership on. </task> <constraints> - Each risk needs both a mitigation (prevent) and a contingency (respond) - Tie a measurable early-warning signal to each high risk - Assign one owner per risk </constraints> <format> Markdown artifact: risk register table sorted by severity, plus a top-risks briefing summary. </format>

<context> [Event name] just wrapped on [date] with [number/type] attendees, and I need a follow-up plan. </context> <inputs> - Attendee segments and counts: [fill] - Goals for follow-up: [fill] - Assets to share (recording, slides, offer): [fill] - Sales/CRM owners: [fill] </inputs> <task> Build a post-event follow-up plan. Define segmented follow-up tracks (attended, registered-no-show, hot leads), the message and asset for each touch, the timing, the owner, and the handoff to sales. Add a thank-you and feedback-survey step, and a window to close the loop before interest cools. </task> <constraints> - Different segments must get different messages, not one blast - First touch should land within a tight post-event window - Specify the sales handoff trigger for hot leads </constraints> <format> Markdown artifact: per-segment follow-up sequence tables plus a handoff and timing summary. </format>

<context> For campaign/event [name] I need leads captured cleanly and routed to the right owner fast. </context> <inputs> - Capture points: [forms, booth, webinar, landing pages] - Fields and qualifying data collected: [fill] - Routing rules by segment/territory: [fill] - CRM and tools in use: [fill] </inputs> <task> Design a lead capture and routing plan. Map each capture point to the fields collected, the qualification logic, and the routing destination (owner, queue, or nurture). Define SLAs for first response, de-duplication handling, and a fallback for unrouted leads. Diagram the flow as steps. </task> <constraints> - Every lead must have a defined destination, including a catch-all - State a first-response SLA per route - Handle duplicates and missing-data cases explicitly </constraints> <format> Markdown artifact: capture-to-route mapping table, routing rules list, and a step-by-step flow. </format>

<context> I need a measurement plan for campaign [campaign name] before it launches on [date]. </context> <inputs> - Primary goal and target: [fill] - Channels and conversion steps: [fill] - Tools and data sources: [fill] - Reporting cadence and audience: [fill] </inputs> <task> Build a metrics and tracking plan. Define a metric tree from the primary goal down to leading indicators per channel. For each metric, specify definition, source, owner, target, and tracking setup (UTMs, events, dashboards). Add a reporting cadence and a guide for what action each metric should trigger. </task> <constraints> - Distinguish leading indicators from lagging outcomes - Every metric needs a single agreed definition and source - Tie each metric to a decision it informs, not vanity tracking </constraints> <format> Markdown artifact: metric-tree table, UTM/event tracking spec, and a reporting cadence. </format>

<context> We're running campaign [campaign name] with [number] influencers/partners launching [date] for [goal]. </context> <inputs> - Partners, tiers, and audiences: [list] - Deliverables and posting windows: [fill] - Briefs, messaging, and do/don't list: [fill] - Budget, payment terms, and tracking: [fill] </inputs> <task> Build an influencer/partner campaign plan. For each partner, define deliverables, brief, posting dates, tracking links/codes, approval steps, and payment milestones. Stagger posts for sustained reach, define a content-approval workflow, and specify how performance is attributed per partner. </task> <constraints> - Each partner needs a unique tracking link or code for attribution - Posts should be staggered, not all on one day - Include an approval step before anything goes live </constraints> <format> Markdown artifact: per-partner plan table, a staggered posting calendar, and an attribution method note. </format>

<context> For campaign [campaign name] I want email and social working together over [timeframe] toward [goal]. </context> <inputs> - Email list segments and platform: [fill] - Social channels and cadence: [fill] - Core message arc and offer: [fill] - Key dates to converge on: [fill] </inputs> <task> Design a coordinated email-and-social sequence. Lay out each send and post on a shared timeline, showing how social warms up an email, an email drives to a post, and both converge on the key moment. For each touch, give the channel, message angle, CTA, owner, and the cross-channel link to the next touch. </task> <constraints> - Email and social must reinforce, not duplicate, each other - Show the cross-channel handoffs explicitly on one timeline - Build toward the key date rather than spreading evenly </constraints> <format> Markdown artifact: a unified channel timeline table plus a message-arc summary. </format>

<context> We're announcing [news/product] on [target date] and need a PR and announcement plan. </context> <inputs> - The news and key messages: [fill] - Target outlets, journalists, and spokespeople: [fill] - Assets needed (release, quotes, media kit): [fill] - Embargo and owned-channel timing: [fill] </inputs> <task> Build a PR launch plan. Sequence pre-briefings under embargo, the announcement moment, and post-announcement amplification across owned channels. Include an outreach tracker (outlet, contact, angle, status), a spokesperson prep list, and a Q&A/holding-statement set for tough questions. </task> <constraints> - Respect the embargo: nothing public before the lift time - Tailor the angle per outlet rather than one generic pitch - Prepare holding statements for foreseeable hard questions </constraints> <format> Markdown artifact: phased timeline, an outreach tracker table, and a spokesperson Q&A prep. </format>

<context> We've signed a sponsorship of [property/event] for [investment] and need to activate it from [start] to [end]. </context> <inputs> - Sponsorship assets and rights we hold: [fill] - Goals (awareness, leads, brand): [fill] - On-site and digital activation ideas: [fill] - Budget beyond the fee, and team: [fill] </inputs> <task> Build a sponsorship activation plan that turns the rights into outcomes. Map each contractual asset (logo, speaking slot, booth, list, social) to a specific activation, owner, deadline, and the goal it serves. Add a measurement plan to prove ROI on the sponsorship fee and a leave-behind/follow-up step. </task> <constraints> - Every contractual right must map to at least one activation, not sit unused - Tie activations to measurable goals for ROI - Include lead capture so the sponsorship produces pipeline, not just logos </constraints> <format> Markdown artifact: rights-to-activation table, activation timeline, and an ROI measurement plan. </format>

<context> We're running [number] field events across [regions] between [start] and [end] for [goal]. </context> <inputs> - Regions, dates, and local owners: [list] - Shared format and what varies locally: [fill] - Central support and budget per event: [fill] - Lead and pipeline targets per region: [fill] </inputs> <task> Build a field/regional event plan that balances a central playbook with local flexibility. Define the standard event template, what local teams customize, a per-region schedule with owners and dates, shared assets, and a rollup that aggregates results across regions for central reporting. </task> <constraints> - Standardize what should be consistent; localize what must adapt - Each region needs a named owner and its own targets - Provide a single rollup view for central visibility </constraints> <format> Markdown artifact: central template, per-region schedule table, and a cross-region rollup. </format>

<context> We're hosting a community event [name] on [date] for [community/audience] to drive [goal]. </context> <inputs> - Community profile and what they value: [fill] - Format and program ideas: [fill] - Engagement and participation goals: [fill] - Hosts, moderators, and volunteers: [list] </inputs> <task> Build a community event plan focused on genuine engagement, not broadcast. Design the program for participation, a pre-event invite and warm-up sequence, day-of facilitation with moderators, and a post-event plan to keep the community active. Include a code of conduct and an engagement metric beyond attendance. </task> <constraints> - Optimize for participation and belonging, not just headcount - Assign facilitation and moderation owners for the live portion - Measure engagement, not only how many showed up </constraints> <format> Markdown artifact: program plan, pre/during/post engagement sequence, and an engagement-metric definition. </format>

<context> Campaign [campaign name] ran from [start] to [end] and I want to run a structured retrospective. </context> <inputs> - Goals and actual results: [fill] - Budget planned vs. spent: [fill] - What the team felt went well/poorly: [fill] - Decisions and bets we made: [fill] </inputs> <task> Plan and structure a campaign retrospective. Compare targets to actuals across the funnel, separate what worked from what did not, and trace each outcome to a root cause rather than a symptom. Produce concrete, owned action items for the next campaign and a short reusable list of learnings to carry forward. </task> <constraints> - Anchor on data: targets vs. actuals before opinions - Push to root causes, not surface symptoms - Every learning becomes an owned, actionable item </constraints> <format> Markdown artifact: results-vs-target table, what-worked/what-didn't sections, and an owned action list. </format>

<context> We run [campaign type] every [cadence, e.g. quarter] and I want a reusable template instead of rebuilding it each time. </context> <inputs> - Steps and assets that repeat every cycle: [fill] - What changes per cycle (theme, dates, offer): [fill] - Roles that own each part: [fill] - Lessons from past runs to bake in: [fill] </inputs> <task> Build a reusable recurring-campaign template. Separate the fixed scaffold (standard tasks, owners, sequence) from the per-cycle variables to fill in. Include a back-planned timeline keyed to a single launch-date input, a kickoff checklist, and a slot to capture each cycle's learnings so the template improves over time. </task> <constraints> - Cleanly separate the fixed template from the per-run inputs - The timeline should regenerate from one launch-date variable - Include a learnings-capture step so the template compounds </constraints> <format> Markdown artifact: fixed-template tables, a per-cycle inputs block, and a back-planned timeline. </format>

<context> I need to hire a [role] for [team] at a [company stage] company. I want a hiring plan I can run end to end, not just a job description. </context> <inputs> - Why this role exists now: [business reason] - Must-have outcomes in year one: [list] - Budget band and level: [comp range and seniority] - Constraints: [timeline, location, remote policy] </inputs> <task> Build a complete hiring plan: a sharp role scorecard (mission, outcomes, competencies), a sourcing strategy, an interview loop, and a decision rubric. Flag the two hardest things about hiring well for this role. </task> <constraints> - Outcomes must be measurable, not vague adjectives - Keep the loop to five stages or fewer </constraints> <format> Markdown artifact: scorecard table, then sourcing, loop, and rubric sections. </format>

<context> [Team] needs to grow from [current size] to [target size] over [timeframe] to support [goal or roadmap]. </context> <inputs> - Current roles and levels: [list] - Workload or roadmap driving growth: [summary] - Budget envelope: [annual headcount budget] - Hiring constraints: [ramp time, manager span limits] </inputs> <task> Produce a phased headcount plan: which roles to hire in what order, target start months, the reasoning for sequence, and the resulting org shape at each phase. Identify the single role that unlocks the most downstream hiring. </task> <constraints> - Respect a maximum span of control of [number] reports per manager - Sequence by dependency, not just by urgency </constraints> <format> Markdown artifact: a phased hiring table (role, level, start month, rationale) plus a short org-shape note per phase. </format>

<context> A new [role] joins [team] on [start date]. I want a 30-60-90 plan that gets them to real impact fast. </context> <inputs> - Role and responsibilities: [paste JD or summary] - Team context and key people: [list] - What success at 90 days looks like: [one paragraph] </inputs> <task> Produce a 30-60-90 plan with, for each window: learning goals, deliverables, people to meet, and a success checkpoint. Tie the 90-day outcomes to the success definition. </task> <constraints> - Each phase builds on the last; no busywork - Make the 90-day outcomes measurable </constraints> <format> Markdown artifact: three phase sections, each a short table. </format>

<context> I am designing the interview process for [role] at [team]. Today it is [current state: ad hoc, inconsistent, too long, etc]. </context> <inputs> - Competencies that predict success: [list] - Current stages and who runs them: [list] - Pain points: [drop-off, slow decisions, false positives] - Target time-to-decision: [days] </inputs> <task> Design a structured interview loop. For each stage, specify its purpose, the one or two competencies it tests, the format, the interviewer, and the signal it should produce. Map competencies to stages so nothing is tested twice and nothing is missed. </task> <constraints> - Every competency must be covered by at least one stage - No stage may test more than two competencies </constraints> <format> Markdown artifact: a loop table plus a competency-to-stage coverage matrix. </format>

<context> Interviewers for [role] rate candidates inconsistently. I want a structured scorecard that drives evidence-based hire decisions. </context> <inputs> - Key competencies to assess: [list] - Seniority and level expectations: [summary] - The signals that separate strong from weak for this role: [notes] </inputs> <task> Build a structured scorecard. For each competency, define a clear 1-to-4 rating scale with behavioral anchors describing what a 1, 2, 3, and 4 actually look like. Add an evidence field and a final recommendation scale (strong no to strong yes) with guidance on what threshold should advance. </task> <constraints> - Anchors must be observable behaviors, not adjectives - Force evidence before any rating </constraints> <format> Markdown artifact: one scorecard table per competency plus a summary recommendation block. </format>

<context> [New hire] starts as [role] on [start date] at [team]. I want a complete onboarding checklist so nothing is dropped before or during week one. </context> <inputs> - Tools and systems they need access to: [list] - Required compliance or paperwork: [list] - Key intro meetings: [people and topics] - First-week deliverable, if any: [item] </inputs> <task> Produce an onboarding checklist grouped by owner and timing: before day one, day one, and week one. Include access provisioning, paperwork, introductions, training, and first tasks. Mark each item with its owner and whether it blocks the new hire from starting work. </task> <constraints> - Separate IT and access items from people and culture items - Flag any item that, if missed, leaves the hire blocked </constraints> <format> Markdown artifact: checklists grouped by timing, each row showing task, owner, and blocking flag. </format>

<context> A new [role] on [team] needs a clear ramp to full productivity. The role has a measurable output once ramped, around [target metric]. </context> <inputs> - What full productivity looks like: [metric and level] - Skills or context the role must build: [list] - Typical ramp time for this role: [weeks or months] - Support available: mentor, docs, shadowing: [notes] </inputs> <task> Build a ramp plan that moves the hire from zero to full productivity in stages. For each stage, define the expected output level as a percentage of full, the capabilities being built, and the milestone that proves the stage is complete. Show the productivity curve over time. </task> <constraints> - Productivity targets must escalate realistically, not jump to full early - Every milestone must be verifiable </constraints> <format> Markdown artifact: a ramp table (stage, weeks, target output percent, milestone) plus a short curve description. </format>

<context> [Team or function] has outgrown its current structure. I need to redesign the org for [goal] without losing momentum. </context> <inputs> - Current structure and reporting lines: [describe or paste] - What is breaking: [handoffs, ownership gaps, span issues] - Target operating model: [how we want to work] - Constraints: [no layoffs, fixed budget, etc] </inputs> <task> Propose an org design. Define the teams or pods, each one's mission and ownership, the reporting lines, and the interfaces between them. Explain what each change fixes and the main risk it introduces. Offer one alternative structure with its tradeoff. </task> <constraints> - Every team needs a single clear owner and mission - Name the risk in each boundary you draw </constraints> <format> Markdown artifact: a teams table (team, mission, owner, headcount) plus a reporting outline and a risks section. </format>

<context> I am opening [number] roles for [team] and need a recruiting pipeline plan to hit the targets by [deadline]. </context> <inputs> - Roles and counts: [list] - Historical conversion rates by stage, if known: [data or unknown] - Sourcing channels available: [referrals, inbound, agencies, outbound] - Recruiter and interviewer capacity: [notes] </inputs> <task> Build a pipeline plan working backward from hires needed. Estimate the candidates required at each stage given conversion rates, recommend a channel mix to fill the top of funnel, and set weekly throughput targets. Flag where the pipeline is most likely to bottleneck. </task> <constraints> - If conversion data is missing, state the benchmark you assume - Make weekly targets concrete numbers </constraints> <format> Markdown artifact: a funnel math table (stage, conversion, volume needed) plus channel mix and weekly targets. </format>

<context> A new req for [role] on [team] is opening. Before sourcing starts, I want a structured intake conversation with the hiring manager so we align on what good looks like. </context> <inputs> - What I already know about the role: [summary] - Open questions: [list] - Past hires for this role that worked or did not: [notes] </inputs> <task> Produce a hiring-manager intake guide. Generate the questions that pin down the role's mission, must-have outcomes, deal-breakers, target profiles, comp expectations, and timeline. Then provide a one-page intake summary template the manager and I sign off on before sourcing begins. </task> <constraints> - Questions must force specifics, not yes or no answers - The summary must be approvable in one read </constraints> <format> Markdown artifact: a grouped question list plus a sign-off summary template. </format>

<context> [Team] wants to pair every new hire with an onboarding buddy. I need a plan to launch the program so it actually helps rather than fizzling out. </context> <inputs> - Team size and new-hire cadence: [numbers] - What buddies should and should not own: [notes] - Time buddies can realistically give: [hours per week] </inputs> <task> Design a buddy program. Define the buddy's role and boundaries, how buddies are matched to new hires, a week-by-week buddy cadence for the first month, and how the program is measured and kept alive. Include a short brief that any buddy can read in five minutes before starting. </task> <constraints> - Buddy time must fit the realistic hours given - Keep the buddy role distinct from the manager's role </constraints> <format> Markdown artifact: program overview, matching rules, a week-by-week cadence table, and the five-minute buddy brief. </format>

<context> [Name] is becoming a manager of [team] on [start date], whether a first-time manager or new to the company. I want an onboarding plan tailored to leading, not just doing. </context> <inputs> - Their background: [individual contributor, external manager, etc] - The team they inherit: [size, dynamics, any known issues] - What success looks like at 90 days as a manager: [paragraph] </inputs> <task> Build a manager onboarding plan across the first 90 days covering: understanding the team through one-on-ones, learning the work and systems, building trust, and taking ownership of team outcomes. Separate the people-leadership track from the domain-learning track. End with the first leadership decisions they should make and when. </task> <constraints> - Do not have them make major changes before they understand the team - Make trust-building concrete, not a platitude </constraints> <format> Markdown artifact: two parallel 30-60-90 tracks plus a first-decisions checklist. </format>

<context> A new [role] joins [team] fully remote on [start date], across [timezone gap if any]. I want an onboarding plan built for distance, where nothing happens by hallway osmosis. </context> <inputs> - Tools the team runs on: [list] - How the team communicates async vs live: [norms] - Key people across timezones: [list] - First-month deliverable: [item] </inputs> <task> Build a remote onboarding plan. Cover equipment and access shipped ahead, a structured week-one schedule with deliberate live and async touchpoints, how the hire builds relationships without an office, and explicit documentation they should read in what order. Make connection intentional, not accidental. </task> <constraints> - Respect the timezone gap; do not stack live calls in someone's night - Replace every hallway interaction with a deliberate equivalent </constraints> <format> Markdown artifact: pre-start checklist, a week-one schedule table, and a connection plan. </format>

<context> I need a [role] productive by [target start date]. I want to work backward to figure out when sourcing must begin and whether the date is realistic. </context> <inputs> - Desired start date: [date] - Typical durations for this role: sourcing, interviewing, offer, notice period: [estimates or unknown] - Internal approvals needed before posting: [list] - Any hard external constraints: [holidays, freezes] </inputs> <task> Back-plan the hiring timeline from the start date. Lay out each phase with its duration, the date it must begin, and its dependencies. State clearly whether the start date is achievable, and if not, the earliest realistic one. Highlight the two phases most likely to slip. </task> <constraints> - Account for candidate notice periods and approval lead times - If the date is not feasible, say so plainly with the math </constraints> <format> Markdown artifact: a reverse timeline table (phase, duration, must-start-by date) plus a feasibility verdict. </format>

<context> A candidate for [role] is about to receive an offer. I want a runbook covering everything from offer to a strong first day, so we do not lose them in the gap. </context> <inputs> - Offer details and any negotiation room: [summary] - Expected notice period and gap before start: [weeks] - Pre-start risks: [counteroffers, cold feet, competing offers] - Who owns each handoff: [recruiter, manager, HR, IT] </inputs> <task> Build an offer-to-start runbook. Cover making and closing the offer, the pre-start nurture during the notice gap to prevent renege, paperwork and equipment provisioning, and a confirmed day-one plan. Assign an owner and a target date to every step. Add a renege-risk watchlist. </task> <constraints> - Treat the notice gap as an active retention window, not dead time - Every step needs an owner </constraints> <format> Markdown artifact: a runbook table (step, owner, timing) plus a renege-risk watchlist. </format>

<context> [Name], a [role] on [team], is leaving on [last day]. I need a backfill plan that covers the gap and replaces them well. </context> <inputs> - Their responsibilities and what only they own: [list] - Critical in-flight work: [projects and deadlines] - Notice or transition time available: [days] - Budget and approval status for the backfill: [status] </inputs> <task> Build a backfill plan in two tracks: an interim coverage plan that redistributes critical work and captures their knowledge before they leave, and a replacement hiring plan with an updated role profile reflecting what the team actually needs now. Identify the single most at-risk responsibility and how to protect it. </task> <constraints> - Knowledge capture must happen before the last day, not after - Do not simply clone the old role; reassess what is needed </constraints> <format> Markdown artifact: a coverage table (responsibility, interim owner, knowledge-transfer step) plus a replacement hiring outline. </format>

<context> [Team] is newly formed or needs realignment. I want a team charter that makes our mission, scope, and ways of working explicit. </context> <inputs> - Why this team exists: [purpose] - What we own and explicitly do not own: [scope notes] - Key stakeholders and partner teams: [list] - Current friction or ambiguity: [notes] </inputs> <task> Draft a team charter covering: mission, scope and non-scope, success metrics, roles and responsibilities, decision rights, ways of working, and how we interface with other teams. Make the non-scope section as clear as the scope to prevent boundary creep. Provide a short version the team can pin and a full version. </task> <constraints> - Decision rights must name who decides, not just who is involved - Keep the pinned version under one screen </constraints> <format> Markdown artifact: full charter sections plus a one-screen pinned summary. </format>

<context> [Team] has a growing workload and I need to decide what to solve with hiring versus other levers before committing headcount. </context> <inputs> - Current capacity and demand: [hours, throughput, or backlog] - Roadmap or demand forecast: [summary] - Non-hiring levers available: [automation, reprioritization, contractors, process] - Budget reality: [constraints] </inputs> <task> Analyze the capacity gap. Quantify current supply versus forecast demand, then lay out how much of the gap to close with hiring versus other levers, with the tradeoff of each. Recommend a specific mix and the headcount it implies, plus the trigger that would change the recommendation. </task> <constraints> - Do not default to hiring for every gap; weigh alternatives honestly - Make the capacity math explicit and checkable </constraints> <format> Markdown artifact: a supply-vs-demand table, a levers comparison, and a recommended mix with implied headcount. </format>

<context> We are hiring [role] for [team] and want to widen the candidate pool so we evaluate a genuinely broad slate, while keeping the bar and process fair for everyone. </context> <inputs> - Where we currently source and who that reaches: [channels] - Gaps we have noticed in our pipeline: [observations] - Constraints: [location, budget, timeline] </inputs> <task> Build a sourcing plan that broadens the top of funnel. Recommend additional channels and communities to reach candidates current channels miss, audit the job description and process for language or requirements that unnecessarily narrow the pool, and define a consistent, criteria-based evaluation that applies equally to every candidate. Suggest pipeline metrics to track slate breadth over time. </task> <constraints> - Widen sourcing and reduce bias in process; keep selection criteria identical for all candidates - Recommend only lawful, merit-based practices </constraints> <format> Markdown artifact: channel recommendations, a JD and process audit, and a consistent evaluation rubric. </format>

<context> We are standing up a brand-new [team] of [number] people starting around [start window]. I need an onboarding plan for the whole team, not just individuals. </context> <inputs> - Roles being hired into the team: [list] - The team's mission and first big goal: [summary] - What exists already vs what we build from scratch: [notes] - Leadership in place: [who] </inputs> <task> Build a team-level onboarding plan. Cover establishing shared context and norms, individual ramp by role, building the team's first ways of working, and getting to a first shared deliverable. Sequence what the whole team does together versus what individuals do alone. End with the milestone that signals the team is operational. </task> <constraints> - Balance individual ramp against team formation; do not neglect either - Define the operational milestone concretely </constraints> <format> Markdown artifact: a phased plan separating team-wide and individual tracks, ending with the operational milestone. </format>

<context> We are bringing on a [contractor or agency] for [scope of work] starting [start date] for [duration]. I want an onboarding plan that gets them productive fast without over-granting access. </context> <inputs> - Scope and deliverables: [summary] - Systems they need versus do not need: [list] - Internal point of contact and approval flow: [who] - Confidentiality and security requirements: [notes] </inputs> <task> Build a contractor onboarding plan. Cover scoped access provisioning on a least-privilege basis, the context and assets they need to start, working norms and check-in cadence, deliverable milestones, and a clean offboarding and access-revocation plan for the engagement end. Distinguish what a contractor needs from full-employee onboarding. </task> <constraints> - Grant least-privilege access and plan revocation up front - Keep it lighter than employee onboarding but complete for the scope </constraints> <format> Markdown artifact: access table (system, level, justification), a context pack list, a milestone schedule, and an offboarding checklist. </format>

<context> I want to define how we will measure whether a new [role] on [team] is succeeding in their first 90 days, set before they start so expectations are clear and fair. </context> <inputs> - The role's core outcomes: [list] - What is realistically achievable in 90 days vs later: [notes] - Signals that predict long-term success in this role: [observations] </inputs> <task> Define a first-90-days success framework. Separate leading indicators of ramp from lagging outcome metrics, set a clear target and a check-in point for each, and distinguish must-hit signals from nice-to-haves. Add the early-warning signs that the hire is off track and the supportive action to take for each. </task> <constraints> - Do not measure outcomes the role cannot influence in 90 days - Pair every warning sign with a supportive intervention, not a judgment </constraints> <format> Markdown artifact: a metrics table (metric, type, target, check-in) plus an early-warning and response section. </format>

<context> [Team or org] needs to restructure to better fit [goal or new strategy]. This is sensitive and affects people, so I want a careful, neutral plan. </context> <inputs> - Current structure: [describe] - Why change is needed: [business rationale] - Constraints: [whether roles are eliminated, budget, timeline] - Stakeholders and their concerns: [list] </inputs> <task> Produce a restructure plan covering the new structure and its rationale, a mapping of how current roles map to the new model, a phased transition sequence, a clear and respectful communication plan, and the main people-risks with mitigations. Keep the tone neutral and factual throughout, focused on roles and structure rather than individuals. </task> <constraints> - Neutral, respectful tone; never speculate about specific individuals' performance - Surface people-impact risks honestly with mitigations; recommend involving HR and legal where roles change </constraints> <format> Markdown artifact: new structure, role-mapping table, phased transition, communication plan, and a risks-and-mitigations section. </format>

<context> [Team] has single points of failure where only one person knows how to do critical things. I want a cross-training plan so coverage does not collapse when someone is out. </context> <inputs> - Critical responsibilities and who currently owns each: [list] - Where we have bus-factor-of-one risk: [observations] - Time available for training per week: [hours] - Upcoming leave or attrition risk: [notes] </inputs> <task> Build a cross-training and coverage plan. Map each critical responsibility to its primary and required backup owners, prioritize which knowledge gaps to close first by risk, define how each skill transfers (shadowing, docs, paired work), and produce a coverage matrix showing who can cover whom. Identify any responsibility still left with no backup. </task> <constraints> - Prioritize by risk and frequency, not by what is easiest to teach - Every critical responsibility needs a named backup or an explicit gap flag </constraints> <format> Markdown artifact: a coverage matrix (responsibility, primary, backup, transfer method) plus a prioritized training schedule. </format>

<context> [Role] is critical to [team], and if [current holder] left we would be exposed. I want a succession plan, planned calmly in advance rather than in a crisis. </context> <inputs> - The role's critical responsibilities and relationships: [list] - Potential internal successors and their current readiness: [names and gaps] - Timeline horizon: [emergency cover vs planned 1-2 year succession] - Knowledge that lives only in this person's head: [notes] </inputs> <task> Build a succession plan with two layers: an emergency interim-cover plan if the role were suddenly vacant tomorrow, and a development plan to grow one or more successors to readiness over time. For each candidate, define their readiness gap and the experiences that would close it. Include a knowledge-documentation plan so critical context is not trapped in one person. </task> <constraints> - Cover both sudden-vacancy and planned-transition scenarios - Frame successor gaps as development paths, kept confidential and constructive </constraints> <format> Markdown artifact: emergency-cover plan, a successor readiness table (candidate, gap, development action), and a knowledge-documentation plan. </format>

<context> I'm running [project] and need a living risk register I can review weekly with stakeholders. </context> <inputs> - Project summary and timeline: [paste] - Known concerns so far: [list] - Team and dependencies: [fill] </inputs> <task> Produce a risk register: for each risk give Description, Likelihood, Impact, Score (L x I), Owner, Mitigation, and Trigger/early-warning sign. Sort by score. Add 5 risks I likely have not considered for this type of project. </task> <constraints> - Be specific to this project, not generic risks - Each risk needs an owner and an early-warning trigger </constraints> <format> Markdown artifact: a sorted risk table plus a short "top 3 to watch" callout. </format>

<context> I need to understand how the moving parts of [project] depend on each other before I commit to a schedule. </context> <inputs> - Workstreams and major tasks: [list] - Teams or vendors involved: [list] - Hard external dependencies (approvals, deliveries, integrations): [list] </inputs> <task> Build a dependency map. For each task note what it depends on, what depends on it, the dependency type (finish-to-start, etc.), and whether it is internal or external. Flag single points of failure and any circular or hidden dependencies. </task> <constraints> - Call out the 3 dependencies most likely to stall the whole project - Distinguish hard dependencies from soft preferences </constraints> <format> Markdown artifact: a dependency table, a text-based chain diagram, and a "bottlenecks" section. </format>

<context> My PMO wants a proper RAID log for [project] covering Risks, Assumptions, Issues, and Dependencies in one place. </context> <inputs> - Project overview and phase: [paste] - Things that are already going wrong (issues): [list] - Things we are taking for granted (assumptions): [list] - Known risks and dependencies: [list] </inputs> <task> Build a four-quadrant RAID log. For each entry include ID, Description, Owner, Status, Priority, and Next action. Keep Risks (future, uncertain) separate from Issues (already happening). Suggest entries I have missed in each quadrant. </task> <constraints> - Never file a current problem as a risk - Every entry needs an owner and a next action </constraints> <format> Markdown artifact: four labelled tables (R, A, I, D) plus a one-line summary of overall project posture. </format>

<context> I send a weekly status update on [project] to [stakeholders] and want it consistent, skimmable, and honest. </context> <inputs> - This week's progress: [list] - Planned for next week: [list] - Current blockers and risks: [list] - Overall RAG status (Red/Amber/Green) and why: [fill] </inputs> <task> Write a weekly status report: headline summary, RAG status with a one-line justification, key accomplishments, planned work, blockers needing help, risks to watch, and metrics or milestone progress. Translate jargon into plain outcomes. </task> <constraints> - Lead with the RAG status and what changed since last week - Be candid about slippage; do not bury bad news </constraints> <format> Markdown artifact, under one page, scannable headers, bold the items that need a decision. </format>

<context> I have to brief [executive audience] on [project] in a single page; they want signal, not detail. </context> <inputs> - Project goal and business value: [paste] - Current status and confidence level: [fill] - Top 3 risks or blockers: [list] - Budget and timeline position: [fill] - Decisions or support I need from leadership: [list] </inputs> <task> Produce an executive one-pager: outcome being delivered, overall health, are-we-on-track call, top risks with mitigations, budget/timeline position, and explicit asks. Write for someone with two minutes and no context on the day-to-day. </task> <constraints> - No team-level minutiae; tie everything to business impact - Make the asks unmissable </constraints> <format> Markdown artifact: a tight one-pager with a status banner at the top and an "asks of leadership" box at the bottom. </format>

<context> I want to know the critical path of [project] so I protect the tasks that actually drive the end date. </context> <inputs> - Tasks with durations and dependencies: [paste] - Target end date: [date] - Tasks I think are already tight: [list] </inputs> <task> Identify the critical path. For each task estimate float/slack, mark zero-float tasks as critical, and show the longest dependency chain to the end date. Flag near-critical paths that could become critical with minor slippage, and suggest where to add buffer or parallelize. </task> <constraints> - Be explicit about which assumptions drive the path - Separate true critical-path tasks from merely busy ones </constraints> <format> Markdown artifact: critical-path chain, a float table for all tasks, and a "where to protect time" section. </format>

<context> One risk on [project] is serious enough to need its own response plan: [risk description]. </context> <inputs> - The risk and why it matters: [paste] - Likelihood and impact estimate: [fill] - What we have done about it so far: [list] - Constraints (budget, time, people): [fill] </inputs> <task> Build a single-risk response plan covering: avoid/reduce/transfer/accept options with tradeoffs, a recommended preventive action set, a contingency plan if it occurs, early-warning triggers, owner and decision point, and the residual risk after mitigation. </task> <constraints> - Distinguish preventive actions from contingency (after-the-fact) actions - State the residual risk honestly; mitigation rarely takes it to zero </constraints> <format> Markdown artifact: options table, recommended plan, trigger-and-response section, residual-risk note. </format>

<context> [project] rests on assumptions that, if wrong, would blow up the plan. I want them logged and tested, not buried. </context> <inputs> - Plan summary and key decisions made: [paste] - Assumptions I am aware of: [list] - What I do not yet know for certain: [list] </inputs> <task> Build an assumptions log. For each assumption capture: statement, why it matters, confidence level, impact if false, how to validate it, owner, and a by-when date. Add unstated assumptions you can infer from my plan that I have not written down. </task> <constraints> - Surface implicit assumptions, not just the obvious ones - Every high-impact assumption needs a validation step and a date </constraints> <format> Markdown artifact: assumptions table sorted by impact-if-false, plus a "test these first" shortlist. </format>

<context> Blockers on [project] sit too long because nobody knows when or to whom to escalate. I want a clear escalation ladder. </context> <inputs> - Current open blockers: [list] - Decision-makers and their areas: [list] - How long things typically wait before moving: [fill] </inputs> <task> Design an escalation plan: define escalation tiers (team lead, manager, sponsor, steering), the trigger and time threshold for each tier, who owns the escalation, and what information to bring. Then map each current blocker to the right tier with a recommended next action and deadline. </task> <constraints> - Tie each tier to an objective trigger (time waited or impact), not a feeling - Make escalation a normal tool, not a last resort </constraints> <format> Markdown artifact: escalation-ladder table, current-blocker routing table, and a short escalation email template. </format>

<context> I want a recurring health dashboard for [project] so status is glanceable instead of buried in updates. </context> <inputs> - What leadership and the team each care about: [fill] - Available metrics and data sources: [list] - Reporting cadence: [fill] </inputs> <task> Design a project health dashboard: choose the handful of indicators that actually predict trouble (schedule, budget, scope, risk, quality, team), define RAG thresholds for each, specify the data source and refresh cadence, and explain how each indicator should drive action. Then render a sample populated with placeholder values. </task> <constraints> - Fewer, leading indicators beat many lagging ones - Every indicator must have a defined threshold and an action it triggers </constraints> <format> Markdown artifact: indicator definition table plus a rendered sample dashboard with a RAG header. </format>

<context> [project] has many stakeholders with different needs and I keep over- or under-communicating to the wrong people. </context> <inputs> - Stakeholders and their roles: [list] - Their influence and interest levels: [fill] - Channels available (email, standup, steering, dashboard): [list] </inputs> <task> Build a stakeholder communication plan. Map each stakeholder on influence vs interest, then specify what each needs to know, the format, frequency, channel, and owner. Recommend a manage-closely / keep-satisfied / keep-informed / monitor approach per quadrant. </task> <constraints> - Right-size communication to influence and interest; do not blast everyone equally - Name an owner for each recurring touchpoint </constraints> <format> Markdown artifact: influence/interest grid (text form), a communication matrix table, and a cadence summary. </format>

<context> [project] changes how [affected group] works, and adoption is the real risk, not the build. </context> <inputs> - What is changing and for whom: [paste] - Likely sources of resistance: [list] - Sponsors and change champions available: [list] - Go-live timing: [fill] </inputs> <task> Create a change-management plan: stakeholder impact assessment, readiness check, communication and training plan, resistance-management approach, reinforcement after go-live, and success metrics for adoption. Include a phased timeline from awareness to sustained use. </task> <constraints> - Treat adoption as the goal, not delivery of the system - Address the emotional and political resistance, not only logistics </constraints> <format> Markdown artifact: impact assessment table, phased change timeline, and an adoption-metrics section. </format>

<context> [project] keeps absorbing small scope changes and I need a disciplined log so creep is visible and decided, not silent. </context> <inputs> - Original agreed scope: [paste] - Change requests raised so far: [list] - Baseline budget and timeline: [fill] </inputs> <task> Build a scope-change log. For each request capture: ID, requested by, description, reason, impact on schedule/budget/quality, recommendation (approve/defer/reject), decision, and decision date. Total the cumulative schedule and budget impact of all approved changes so creep is quantified. </task> <constraints> - Quantify cumulative impact, not just per-change impact - Force an explicit decision on every request; no silent acceptances </constraints> <format> Markdown artifact: change-log table plus a running "cumulative scope drift" summary against baseline. </format>

<context> [key person or team] is over-allocated across [project] and competing work, and something has to give. </context> <inputs> - The contended resource and their commitments: [list] - Competing priorities and deadlines: [list] - What is flexible vs fixed: [fill] </inputs> <task> Analyze the resource conflict and propose resolution options: re-sequencing, reallocating, adding capacity, descoping, or renegotiating deadlines. For each option give the tradeoff, who is affected, and the downstream schedule impact. Recommend one and draft the case I would make to decision-makers. </task> <constraints> - Be honest about what each option costs; there is no free fix - Quantify schedule impact wherever possible </constraints> <format> Markdown artifact: options table with tradeoffs, a recommendation, and a short decision brief for stakeholders. </format>

<context> I want a clean milestone tracker for [project] so everyone sees what is due, what is done, and what is at risk. </context> <inputs> - Major milestones and target dates: [list] - Current progress against each: [fill] - Dependencies that gate each milestone: [list] </inputs> <task> Build a milestone tracker. For each milestone show: name, owner, target date, forecast date, status (not started / on track / at risk / slipped / done), gating dependencies, and a one-line note. Highlight any milestone whose forecast date now misses its target and the knock-on effects. </task> <constraints> - Show forecast date alongside target so slippage is visible - Flag downstream milestones threatened by an upstream slip </constraints> <format> Markdown artifact: milestone table sorted by date, with a "slipping" callout at the top. </format>

<context> [project] runs in [sprints or phases] and I want burndown and burnup tracking that actually informs decisions. </context> <inputs> - Total scope (story points, tasks, or deliverables): [fill] - Cadence and timeframe: [fill] - Progress data I can collect each period: [list] </inputs> <task> Design a burndown/burnup tracking approach. Explain what each chart shows, when burnup is better (it reveals scope changes that burndown hides), what data to log each period, how to read the trend lines for early warning, and how to forecast a completion date from velocity. Render a sample table with placeholder numbers and an ASCII trend. </task> <constraints> - Explain why burnup exposes scope creep that burndown masks - Make the forecast method explicit and repeatable </constraints> <format> Markdown artifact: tracking-plan section, sample data table, ASCII trend, and a forecast note. </format>

<context> [project] is approaching [launch or gate] and I need a structured go/no-go rather than a gut call. </context> <inputs> - What we are deciding to launch or proceed with: [paste] - Readiness areas (technical, ops, support, legal, comms): [list] - Known open issues: [list] - Decision date and decision-makers: [fill] </inputs> <task> Build a go/no-go decision framework. Define the readiness criteria per area, set pass/conditional/fail thresholds, list must-haves versus nice-to-haves, specify who votes and how a no-go is overridden, and include a rollback/contingency trigger. Then score current readiness against the criteria using my inputs. </task> <constraints> - Separate true blockers (no-go) from issues we can launch with and fix later - Require an explicit owner and sign-off per readiness area </constraints> <format> Markdown artifact: readiness scorecard, go/no-go criteria, and a recommendation with conditions. </format>

<context> I'm about to kick off [project] and want one brief that aligns the team before any work starts. </context> <inputs> - Project goal and why now: [paste] - Scope (in and out): [fill] - Team, roles, and stakeholders: [list] - Timeline and key milestones: [fill] - Known risks and constraints: [list] </inputs> <task> Write a kickoff brief covering: objective and success criteria, scope boundaries, team and responsibilities, timeline and milestones, working norms (meetings, tools, decisions), top risks, and the immediate next steps with owners. Surface any ambiguity that should be resolved in the kickoff meeting. </task> <constraints> - Make in-scope and out-of-scope explicit to prevent early drift - End with concrete next actions and owners, not vibes </constraints> <format> Markdown artifact: a structured kickoff brief plus a short "open questions for kickoff" list. </format>

<context> [project] needs a formal charter to get authorized and to anchor scope, sponsor, and success criteria. </context> <inputs> - Business case and problem being solved: [paste] - Sponsor and key stakeholders: [list] - High-level scope, objectives, and deliverables: [fill] - Budget, timeline, and major constraints: [fill] - Known risks and assumptions: [list] </inputs> <task> Draft a project charter: purpose and business justification, measurable objectives and success criteria, scope and explicit exclusions, key deliverables and milestones, roles and authority (especially the PM's mandate), high-level budget and timeline, assumptions, constraints, and top risks. Note anything underspecified that the sponsor must confirm. </task> <constraints> - Objectives must be measurable, not aspirational - Make the PM's authority and the sponsor's commitment explicit </constraints> <format> Markdown artifact: a complete charter with clear section headers and a sponsor sign-off block. </format>

<context> I want a standard weekly status template I can reuse across [project] and future projects so reporting is consistent. </context> <inputs> - Audience for the weekly update: [fill] - What that audience must always see: [list] - Tone and length preference: [fill] </inputs> <task> Design a reusable weekly status template with placeholder fields and inline guidance on what belongs in each section: RAG status, summary, progress, next steps, blockers/asks, risks, and metrics. Add brief instructions for keeping it honest and skimmable, plus a filled-in example so the format is obvious. </task> <constraints> - Make it copy-paste ready with clear placeholders - Include guidance notes, not just empty headers </constraints> <format> Markdown artifact: the blank template, inline guidance per section, and one worked example. </format>

<context> Before I commit to the [project] plan, I want to imagine it has already failed and work backward to find why. </context> <inputs> - The current plan and key assumptions: [paste] - Timeline, budget, and team: [fill] - What I am most confident about: [list] </inputs> <task> Run a pre-mortem. Assume the project failed badly twelve months out, then generate the most plausible failure stories: what went wrong, the earliest point we could have caught it, and the warning signs we ignored. Red-team my confident assumptions especially hard. End with the changes I should make to the plan now. </task> <constraints> - Attack the parts I am most confident about; that is where blind spots hide - Every failure story needs an early-detection point and a preventive change </constraints> <format> Markdown artifact: ranked failure scenarios, warning signs, and a "change the plan now" action list. </format>

<context> [project] has uncertainty that needs deliberate buffer and contingency, not optimism baked into the dates. </context> <inputs> - Schedule and the riskiest tasks: [list] - Budget and any reserve: [fill] - Areas of highest uncertainty: [list] </inputs> <task> Build a contingency plan: recommend where to place schedule buffer (and why aggregated buffer beats padding every task), size a sensible time and budget reserve based on risk, define contingency triggers that release the reserve, and specify fallback plans for the top failure points. Distinguish management reserve from contingency reserve. </task> <constraints> - Aggregate buffer rather than padding each task; explain the reasoning - Tie reserve release to explicit triggers, not pressure </constraints> <format> Markdown artifact: buffer-placement plan, reserve-sizing table, and trigger-to-fallback mapping. </format>

<context> [project] both depends on and feeds other initiatives, and I need a portfolio-level view of those cross-project links. </context> <inputs> - Other projects or programs we touch: [list] - What we need from them and by when: [list] - What they need from us and by when: [list] - Shared resources or systems: [list] </inputs> <task> Build a cross-project dependency view. Map inbound and outbound dependencies, their due dates, owning project, and current status, then flag clashes: where two projects need the same resource at once, where a slip elsewhere endangers us, and where our slip endangers others. Recommend coordination actions and who to align with. </task> <constraints> - Separate inbound from outbound dependencies clearly - Highlight shared-resource collisions across projects, not just task links </constraints> <format> Markdown artifact: inbound and outbound dependency tables, a clash list, and recommended cross-team actions. </format>

<context> [project] has committed deadlines or SLAs and I need to know which are genuinely at risk before I get caught short. </context> <inputs> - Committed deadlines and SLAs: [list] - Current progress and forecast for each: [fill] - Dependencies and external parties that affect them: [list] - Penalty or consequence for missing each: [fill] </inputs> <task> Analyze deadline and SLA risk. For each commitment estimate the likelihood of meeting it, the buffer remaining, the main threats, the consequence of a miss, and a recommended action (protect, renegotiate, or escalate now). Prioritize by consequence times likelihood so the most dangerous commitments rise to the top. </task> <constraints> - Weight by consequence, not just probability of slipping - Recommend renegotiating early where a miss looks likely; late notice is worse </constraints> <format> Markdown artifact: SLA risk table sorted by exposure, plus a "renegotiate or escalate this week" shortlist. </format>

<context> [project] is wrapping up and I want a proper closeout and retrospective so it ends cleanly and the lessons survive. </context> <inputs> - Objectives and what was actually delivered: [paste] - What went well and what did not: [list] - Open items, handovers, and loose ends: [list] - Final budget and timeline versus plan: [fill] </inputs> <task> Build a closeout and retrospective plan: verify deliverables against the charter, capture variance on scope/time/budget, document lessons learned (start/stop/continue), confirm handovers and ownership of remaining items, release resources, and recognize the team. Turn lessons into reusable recommendations a future project would actually apply. </task> <constraints> - Lessons must be specific and reusable, not "communicate better" - Confirm every open item has an owner after the project closes </constraints> <format> Markdown artifact: closeout checklist, variance summary, lessons-learned table, and an open-items handover list. </format>