Business & Project Management

Exact prompt

Turn the information below into a decision-ready project charter. Expose missing commitments instead of filling them with generic language.

Problem and desired outcome:
{{problem_outcome}}

Stakeholders and affected groups:
{{stakeholders}}

Constraints and known context:
{{constraints}}

Instructions:
1. Separate the current problem, desired outcome, proposed approach, and assumptions.
2. Define success through observable behavior or operating conditions, including baseline and measurement owner when known.
3. Set explicit in-scope and out-of-scope boundaries and identify likely boundary disputes.
4. Record explicitly supplied sponsors, decision owners, delivery owners, contributors, consulted groups, and people affected by the change; mark any required role with no named owner as unresolved.
5. List dependencies, risks, unknowns, and discovery work that must happen before commitment.
6. Break delivery into milestones that each produce reviewable evidence, not just elapsed time.
7. Define approval points, change control, communication cadence, and stop conditions.

Return a concise charter, open decisions, ownership table, milestone evidence, and a kickoff checklist. Do not invent budget, dates, authority, capacity, or stakeholder agreement.

Replace before use

Problem and desired outcome{{problem_outcome}}

Observed current state, affected users, intended change, and evidence available.

Stakeholders{{stakeholders}}

Known sponsors, decision makers, contributors, operators, customers, and affected groups.

Constraints and context{{constraints}}

Time, budget, policy, technology, dependency, quality, and organizational boundaries.

Exact prompt

Run a practical risk review for this project using the available evidence. Do not confuse a risk, issue, assumption, and dependency.

Project plan and current status:
{{project_context}}

Known concerns and incidents:
{{risk_inputs}}

Risk boundaries and authority:
{{governance}}

Instructions:
1. Classify each input as a future uncertainty, current issue, assumption, constraint, or dependency.
2. Write risks in cause-event-impact form and avoid vague labels such as communication risk.
3. Estimate likelihood and impact qualitatively with a reason and evidence date rather than false numerical precision.
4. Identify leading indicators, earliest decision points, affected outcomes, and one explicitly supplied accountable owner; mark ownership unresolved when no owner is named.
5. Distinguish prevention, reduction, contingency, transfer, acceptance, and escalation actions.
6. Check whether a mitigation creates secondary risks, hidden workload, or an irreversible commitment.
7. Define review cadence and triggers for changing priority or activating a contingency.

Return a prioritized risk register, issue list, assumption checks, mitigation actions, and decisions requiring authority. Do not invent ownership, funding, probability data, or executive acceptance.

Replace before use

Project context{{project_context}}

Objectives, scope, plan, current status, dependencies, and recent evidence.

Risk inputs{{risk_inputs}}

Concerns, incidents, near misses, assumptions, stakeholder feedback, and delivery signals.

Risk boundaries and authority{{governance}}

Risk appetite, escalation thresholds, decision owners, compliance rules, and review schedule.

Exact prompt

Turn these meeting notes into an accurate decision and action record. Preserve disagreement and uncertainty rather than manufacturing consensus.

Meeting purpose and participants:
{{meeting_context}}

Raw notes or transcript:
{{meeting_notes}}

Decision and documentation rules:
{{governance}}

Instructions:
1. Extract confirmed decisions, proposed options, open questions, risks, dependencies, and informational updates.
2. For each decision, record the chosen option, stated rationale, alternatives considered, constraints, decision owner, and revisit trigger when present.
3. For each action, record an accountable owner, deliverable, due condition, and dependency only when each is explicitly stated; otherwise mark the missing field for clarification.
4. Flag ambiguous commitments, unnamed owners, conflicting statements, and decisions that appear outside participant authority.
5. Preserve dissent, minority concerns, and requested follow-up without attributing words to the wrong person.
6. Remove conversational repetition while retaining material context.
7. Draft clarification questions for every high-impact gap before the record is circulated.

Return a decision log, action table, unresolved items, risks, and a concise circulation summary. Mark inferred structure clearly and never invent attendance, approval, deadlines, or agreement.

Replace before use

Meeting context{{meeting_context}}

Purpose, date, participants, known roles, and intended decision scope.

Meeting notes{{meeting_notes}}

Raw notes or transcript, with sensitive information removed when appropriate.

Decision and documentation rules{{governance}}

Required record format, approval process, confidentiality, and ownership conventions.

Exact prompt

Analyze this process and propose improvements before recommending automation. Focus on the work as it happens, not the idealized policy alone.

Process description:
{{process_description}}

Observed problems and evidence:
{{problem_evidence}}

Constraints and affected people:
{{constraints}}

Instructions:
1. Map the trigger, steps, decisions, queues, handoffs, rework loops, information sources, outputs, and owners.
2. Distinguish customer value, necessary control work, delay, duplication, error correction, and work caused by earlier failures.
3. Link each claimed problem to supplied evidence and identify missing observations.
4. Ask whether a step can be removed, clarified, combined, standardized, or made visible before adding a tool.
5. Evaluate proposed changes for error impact, accessibility, privacy, security, frontline workload, exception handling, and reversibility.
6. Design a small pilot with a baseline, guardrails, feedback route, and rollback condition.
7. Recommend automation only for a stable, understood step with clear ownership and manual recovery.

Return the current-state map, evidence-backed bottlenecks, prioritized changes, pilot plan, and measurement checklist. Do not fabricate time savings or treat headcount reduction as an automatic benefit.

Replace before use

Process description{{process_description}}

How the workflow actually starts, moves, decides, handles exceptions, and finishes.

Problem evidence{{problem_evidence}}

Cycle times, errors, queues, complaints, observations, rework, and limitations of the data.

Constraints and affected people{{constraints}}

Policy, safety, technology, skills, accessibility, customer, and operational boundaries.