The prompt
Score 10 of 10, Excellent
Use it when Problems are spread across emails, chat and meeting notes, and you need one log of what is wrong now, who owns each and what happens next.
- {{project_name}}
- {{people}}
- {{severity_scale}}
- {{review_meeting}}
- {{source_notes}}
Full prompt and why it works
Prompt
Project: {{project_name}} People and roles on the project: {{people}} How we rate severity: {{severity_scale}} Where the log will be reviewed: {{review_meeting}} Messages, notes and updates that mention problems: """ {{source_notes}} """ Task: Build an issue log from the material above for {{review_meeting}}, so that every current problem has one owner, a next step and a date, and nothing raised in passing gets lost. An issue is something already happening that hurts the project; a risk is something that might happen. List risks separately at the end, because they need a different response. Format: 1. Issue log table with the columns ID, Issue (what is wrong and its effect, one or two sentences), Raised by and date, Severity, Owner, Next step, Due, Status (Open, In progress, Waiting, Closed), Source. 2. Where the same problem appears in several notes, log it once and list every source. 3. Needs an owner: issues with no clear owner, for the meeting to assign. 4. Needs a decision: issues that cannot move until someone decides, with who that is. 5. Risks mentioned, not yet issues: a short list. Requirements: - Log only problems in the notes; do not add likely issues of your own. - Owners must be people or roles from the list above. If the notes do not say who owns an issue, write "To assign" rather than choosing someone. - Due dates only where the notes give one; otherwise "To agree". - If the severity line says "default", use High (blocks a milestone or deliverable), Medium (causes delay or rework but has a workaround) and Low (a nuisance). - Under 350 words outside the table. Example of one row's form only, with invented content: "I-04 | Test laptops not delivered, so user testing cannot start | Priya, May 12 | High | IT lead | Chase supplier for a date | May 15 | Open | Chat, May 12" If two notes disagree about an issue, for example one says it is fixed and another says it is not, log it as Open and note the conflict.
Variables
- {{project_name}}
- The project's name.
- {{people}}
- Names or roles and what each looks after, for example "Sam, project lead; IT lead; Finance contact".
- {{severity_scale}}
- Your own scale, or "default".
- {{review_meeting}}
- For example "Thursday's project team meeting".
- {{source_notes}}
- The emails, chat messages and notes, each with its date and author if you have them.
Why it works
- Format. One table with an owner, next step, due date and source for each issue, with duplicates merged, gives the review meeting a single list to work from.
- If unsure. Missing owners and dates stay "To assign" and "To agree" for the meeting to settle, and conflicting notes keep an issue open.
- What to avoid. Only problems in your notes are logged, and risks are kept apart from issues, so the log reflects what is actually happening.