SME review breaks when fact-checking, workflow validation, preference editing, risk review, and approval all land in one overloaded pass.
Good SME review corrects facts, resolves workflow issues with the right owner, bounds preference edits, escalates risk, and turns approval into a named decision instead of a pile of comments.
Separate comment types before asking people to approve the work.
Collect one messy review
Pull one review thread, the draft that was reviewed, and the final published asset. Keep the goal narrow. One real example will teach more than a theoretical process map.
Sort every comment
Label each comment as fact issue, workflow issue, preference, risk issue, approval issue, or unclear. Do this before responding to any of them.
Name the decision owner
For each category, name who can make the call. The SME may own facts, but a workflow owner, legal reviewer, manager, or program owner may own other decisions.
Write the review brief
Create a one-page brief with purpose, audience, source material, review categories, what to review, what not to review, due date, and approval rule.
Test on one small asset
Use the brief on a small draft. Ask reviewers to tag their comments. Watch where they resist, misunderstand, or need examples.
Build a visible tracker
Move review state into a table, spreadsheet, Microsoft List, Planner board, or Sheet with comment type, owner, decision needed, status, due date, and scope impact.
Define closeout rules
Agree what resolved, reopened, deferred, and out-of-scope mean. This stops old comments from coming back as if they were new decisions.
Write response language
Prepare calm language for common patterns: preference edits, late workflow changes, missing authority, unclear risk, and comments that need more source material.
Measure review health
Track review cycle time, unresolved comments, reopened decisions, late scope changes, comments without an owner, and comments that were really preferences.
Publish the review rhythm
Share the brief, tracker, category rules, owner map, and closeout rules so the next project uses the same review system.
The system gets clearer when these become explicit.
- A review comment is not a decision.
- Preference feedback needs a budget. If every preference is treated like a defect, the timeline will always lose.
- SMEs should review the truth of the work, not become unpaid copy editors.
- Late workflow corrections are usually missed discovery signals.
- Looks good is not approval unless the decision right is named.
- The best SME review process starts before the first draft is complete.
- Separate truth reviewers from taste reviewers.
- If a comment cannot be tagged, it cannot be actioned yet.
- One overloaded SME is often a system smell, not a person problem.
Give every comment a lane before it becomes work.
The asset is inaccurate or missing required detail. Correct it against the approved source.
The asset shows the work differently than it happens. Confirm with the process owner before revising.
The comment is about wording, style, order, or example choice. Accept it only if it improves clarity without changing scope.
The comment points to compliance, privacy, contractual, customer, learner, or operational risk. Pause publishing until the right owner reviews it.
The comment is really a decision-right question. Route it to the person who can approve the call.
The team cannot tell what kind of feedback this is yet. Ask a clarifying question before revising.
Pick the lightest system that makes the work repeatable.
Use a working meeting, whiteboard, or simple table. Sort comments by review type, assign an owner after the type is clear, and add a decision-needed column so comments do not pretend to be decisions.
Use Word or Google Docs comments for draft feedback, then track review state in Excel, Microsoft Lists, Planner, Sheets, or a shared Google Sheet. Suggested columns: comment, comment type, reviewer, owner, decision needed, status, due date, scope impact, and final resolution.
Use AI to cluster comments, flag contradictions, draft clarifying questions, identify scope changes, and convert review notes into a decision log. Keep human review mandatory, especially for facts, workflow, risk, customer impact, and approval.
- Use document comments for the draft and a tracker for decisions. The draft should not be the only place review status lives.
- Use Teams or Google Chat for escalation, not as the source of truth.
- Add a status column that uses the same words every cycle: new, needs clarification, accepted, deferred, out of scope, resolved, reopened.
- Add a scope-impact column. This is where the team sees whether review is changing the work or cleaning it up.
- Cluster raw comments by feedback type before the designer starts revising.
- Flag comments that contradict each other or require different decision owners.
- Draft reviewer follow-up questions that are specific enough to answer.
- Turn a long review thread into a decision log for human confirmation.
- Stress-test the review brief for missing source material, risk checks, and approval gates.
Use these words before feedback turns into a mixed pile.
- Before we start revising, I want to make sure we know what kind of feedback each comment represents.
- Facts, workflow issues, preferences, risks, and approval calls need different owners.
- If a comment changes scope or requires a decision, we will tag it before we rewrite anything.
- Preference edits can still matter, but they cannot compete with factual or workflow corrections.
- At the end of review, we should know what changed, what did not, what still needs a decision, and who owns that decision.
Treat comments as signals until someone owns the decision.
The comment is accurate, in scope, and owned. Make the change and record the final resolution.
The team cannot tell whether the comment is fact, workflow, preference, risk, or approval. Ask before revising.
The comment affects risk, policy, customer impact, compliance, privacy, or decision rights. Route it to the named owner.
The comment may be useful, but it is outside the launch scope or belongs in a later content update.
The comment conflicts with approved source material, adds unsupported scope, or changes voice without improving clarity.
Look for review health, not just whether the asset shipped.
- Percent of comments tagged before revision.
- Average time from review start to final decision.
- Number of comments reopened after they were marked resolved.
- Number of comments that changed scope after production started.
- Number of preference comments accepted, deferred, or rejected.
- Number of comments without a clear decision owner.
Use the sources as thinking tools, not a script.
Helps frame SME review as a multi-person system problem involving interests, relationships, rules, and behaviors.
Supports making roles, schedules, review expectations, and risk visible before SME feedback turns into rework.
Use AI to sort, inspect, and prepare review work.
Categorize SME comments
The team has raw reviewer comments and needs to sort them before revising the asset.
ChatGPT GPT-5 family
Use an outcome-first prompt with the job, approved source material, constraints, and the exact artifact you want back.
I am working on Categorize SME comments for an L&D system problem.
Goal: Help me turn the notes below into a practical next move.
Context: The team has raw reviewer comments and needs to sort them before revising the asset.
Use these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
Rules:
- Use only the source notes I provide.
- Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
- Separate known facts, assumptions, missing information, and next actions.
- Flag anything that needs requester, reviewer, leader, legal, compliance, LMS owner, or manager confirmation.
- Keep the output practical enough to review in a working meeting.
Source notes:
[paste approved notes here]
Return:
1. Comment category
2. Known facts
3. Assumptions
4. Missing information
5. Decision owner
6. Recommended next actionClaude 4 family
Use XML-style sections so context, source material, task, constraints, and output format stay separate.
<context>
I am working on Categorize SME comments for an L&D system problem.
The team has raw reviewer comments and needs to sort them before revising the asset.
</context>
<source_notes>
[paste approved notes here]
</source_notes>
<task>
Turn the source notes into a practical next move using these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
</task>
<constraints>
Use only the source notes provided.
Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
Separate known facts, assumptions, missing information, risks, and next actions.
Flag anything that changes scope, ownership, evidence, risk, or decision rights.
</constraints>
<output_format>
1. Comment category
2. Known facts
3. Assumptions
4. Missing information
5. Decision owner
6. Recommended next action
</output_format>Gemini 3 family
Use a clear task, labeled input, and one example pattern. For Obsidian context, use approved excerpts, Drive exports, Google Docs, or NotebookLM source sets.
Task: Help me make progress on Categorize SME comments from the notes provided.
Context: The team has raw reviewer comments and needs to sort them before revising the asset.
Working fields:
- comment
- comment type
- known fact
- assumption
- missing information
- risk
- decision owner
- next action
Example pattern:
Field: Missing information
Good answer: Name the specific information to confirm, who can confirm it, and why it affects the next decision.
Rules:
- Use only the source notes provided.
- If information is missing, write "Needs confirmation".
- Keep the output concise and reviewable.
- End with the next best action.
Source notes:
[paste approved notes here]
Output format:
1. Comment category
2. Known facts
3. Assumptions
4. Missing information
5. Decision owner
6. Recommended next actionMicrosoft 365 Copilot
Use goal, context, source, expectations, and output. For Obsidian context, use approved excerpts, Word summaries, OneDrive files, SharePoint pages, Teams context, or Outlook threads.
Goal: Help me make progress on Categorize SME comments.
Context: The team has raw reviewer comments and needs to sort them before revising the asset.
Source: Use the selected document, meeting notes, spreadsheet, email thread, SharePoint file, or pasted notes as the only source.
Expectations:
- Work with these fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
- Mark uncertain items as "Needs confirmation".
- Do not add facts that are not in the source.
- Separate known facts, assumptions, missing information, risks, and next actions.
- Summarize the top review questions for the team.
Output:
1. Comment category
2. Known facts
3. Assumptions
4. Missing information
5. Decision owner
6. Recommended next actionSeparate facts, workflow issues, and preferences
The review thread mixes factual corrections, process changes, and wording preferences.
ChatGPT GPT-5 family
Use an outcome-first prompt with the job, approved source material, constraints, and the exact artifact you want back.
I am working on Separate facts, workflow issues, and preferences for an L&D system problem.
Goal: Help me turn the notes below into a practical next move.
Context: The review thread mixes factual corrections, process changes, and wording preferences.
Use these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
Rules:
- Use only the source notes I provide.
- Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
- Separate known facts, assumptions, missing information, and next actions.
- Flag anything that needs requester, reviewer, leader, legal, compliance, LMS owner, or manager confirmation.
- Keep the output practical enough to review in a working meeting.
Source notes:
[paste approved notes here]
Return:
1. Fact issues
2. Workflow issues
3. Preferences
4. Risks
5. Needs clarification
6. Suggested responseClaude 4 family
Use XML-style sections so context, source material, task, constraints, and output format stay separate.
<context>
I am working on Separate facts, workflow issues, and preferences for an L&D system problem.
The review thread mixes factual corrections, process changes, and wording preferences.
</context>
<source_notes>
[paste approved notes here]
</source_notes>
<task>
Turn the source notes into a practical next move using these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
</task>
<constraints>
Use only the source notes provided.
Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
Separate known facts, assumptions, missing information, risks, and next actions.
Flag anything that changes scope, ownership, evidence, risk, or decision rights.
</constraints>
<output_format>
1. Fact issues
2. Workflow issues
3. Preferences
4. Risks
5. Needs clarification
6. Suggested response
</output_format>Gemini 3 family
Use a clear task, labeled input, and one example pattern. For Obsidian context, use approved excerpts, Drive exports, Google Docs, or NotebookLM source sets.
Task: Help me make progress on Separate facts, workflow issues, and preferences from the notes provided.
Context: The review thread mixes factual corrections, process changes, and wording preferences.
Working fields:
- comment
- comment type
- known fact
- assumption
- missing information
- risk
- decision owner
- next action
Example pattern:
Field: Missing information
Good answer: Name the specific information to confirm, who can confirm it, and why it affects the next decision.
Rules:
- Use only the source notes provided.
- If information is missing, write "Needs confirmation".
- Keep the output concise and reviewable.
- End with the next best action.
Source notes:
[paste approved notes here]
Output format:
1. Fact issues
2. Workflow issues
3. Preferences
4. Risks
5. Needs clarification
6. Suggested responseMicrosoft 365 Copilot
Use goal, context, source, expectations, and output. For Obsidian context, use approved excerpts, Word summaries, OneDrive files, SharePoint pages, Teams context, or Outlook threads.
Goal: Help me make progress on Separate facts, workflow issues, and preferences.
Context: The review thread mixes factual corrections, process changes, and wording preferences.
Source: Use the selected document, meeting notes, spreadsheet, email thread, SharePoint file, or pasted notes as the only source.
Expectations:
- Work with these fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
- Mark uncertain items as "Needs confirmation".
- Do not add facts that are not in the source.
- Separate known facts, assumptions, missing information, risks, and next actions.
- Summarize the top review questions for the team.
Output:
1. Fact issues
2. Workflow issues
3. Preferences
4. Risks
5. Needs clarification
6. Suggested responseDetect contradictory feedback
Different reviewers may be asking for changes that conflict with each other or with the approved source.
ChatGPT GPT-5 family
Use an outcome-first prompt with the job, approved source material, constraints, and the exact artifact you want back.
I am working on Detect contradictory feedback for an L&D system problem.
Goal: Help me turn the notes below into a practical next move.
Context: Different reviewers may be asking for changes that conflict with each other or with the approved source.
Use these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
Rules:
- Use only the source notes I provide.
- Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
- Separate known facts, assumptions, missing information, and next actions.
- Flag anything that needs requester, reviewer, leader, legal, compliance, LMS owner, or manager confirmation.
- Keep the output practical enough to review in a working meeting.
Source notes:
[paste approved notes here]
Return:
1. Potential contradiction
2. Source detail to verify
3. People to confirm with
4. Risk if unresolved
5. Next decisionClaude 4 family
Use XML-style sections so context, source material, task, constraints, and output format stay separate.
<context>
I am working on Detect contradictory feedback for an L&D system problem.
Different reviewers may be asking for changes that conflict with each other or with the approved source.
</context>
<source_notes>
[paste approved notes here]
</source_notes>
<task>
Turn the source notes into a practical next move using these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
</task>
<constraints>
Use only the source notes provided.
Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
Separate known facts, assumptions, missing information, risks, and next actions.
Flag anything that changes scope, ownership, evidence, risk, or decision rights.
</constraints>
<output_format>
1. Potential contradiction
2. Source detail to verify
3. People to confirm with
4. Risk if unresolved
5. Next decision
</output_format>Gemini 3 family
Use a clear task, labeled input, and one example pattern. For Obsidian context, use approved excerpts, Drive exports, Google Docs, or NotebookLM source sets.
Task: Help me make progress on Detect contradictory feedback from the notes provided.
Context: Different reviewers may be asking for changes that conflict with each other or with the approved source.
Working fields:
- comment
- comment type
- known fact
- assumption
- missing information
- risk
- decision owner
- next action
Example pattern:
Field: Missing information
Good answer: Name the specific information to confirm, who can confirm it, and why it affects the next decision.
Rules:
- Use only the source notes provided.
- If information is missing, write "Needs confirmation".
- Keep the output concise and reviewable.
- End with the next best action.
Source notes:
[paste approved notes here]
Output format:
1. Potential contradiction
2. Source detail to verify
3. People to confirm with
4. Risk if unresolved
5. Next decisionMicrosoft 365 Copilot
Use goal, context, source, expectations, and output. For Obsidian context, use approved excerpts, Word summaries, OneDrive files, SharePoint pages, Teams context, or Outlook threads.
Goal: Help me make progress on Detect contradictory feedback.
Context: Different reviewers may be asking for changes that conflict with each other or with the approved source.
Source: Use the selected document, meeting notes, spreadsheet, email thread, SharePoint file, or pasted notes as the only source.
Expectations:
- Work with these fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
- Mark uncertain items as "Needs confirmation".
- Do not add facts that are not in the source.
- Separate known facts, assumptions, missing information, risks, and next actions.
- Summarize the top review questions for the team.
Output:
1. Potential contradiction
2. Source detail to verify
3. People to confirm with
4. Risk if unresolved
5. Next decisionDraft reviewer clarification questions
The team needs follow-up questions that clarify review comments without sounding defensive.
ChatGPT GPT-5 family
Use an outcome-first prompt with the job, approved source material, constraints, and the exact artifact you want back.
I am working on Draft reviewer clarification questions for an L&D system problem.
Goal: Help me turn the notes below into a practical next move.
Context: The team needs follow-up questions that clarify review comments without sounding defensive.
Use these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
Rules:
- Use only the source notes I provide.
- Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
- Separate known facts, assumptions, missing information, and next actions.
- Flag anything that needs requester, reviewer, leader, legal, compliance, LMS owner, or manager confirmation.
- Keep the output practical enough to review in a working meeting.
Source notes:
[paste approved notes here]
Return:
1. Original comment
2. What is unclear
3. Clarifying question
4. Why it matters
5. Decision neededClaude 4 family
Use XML-style sections so context, source material, task, constraints, and output format stay separate.
<context>
I am working on Draft reviewer clarification questions for an L&D system problem.
The team needs follow-up questions that clarify review comments without sounding defensive.
</context>
<source_notes>
[paste approved notes here]
</source_notes>
<task>
Turn the source notes into a practical next move using these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
</task>
<constraints>
Use only the source notes provided.
Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
Separate known facts, assumptions, missing information, risks, and next actions.
Flag anything that changes scope, ownership, evidence, risk, or decision rights.
</constraints>
<output_format>
1. Original comment
2. What is unclear
3. Clarifying question
4. Why it matters
5. Decision needed
</output_format>Gemini 3 family
Use a clear task, labeled input, and one example pattern. For Obsidian context, use approved excerpts, Drive exports, Google Docs, or NotebookLM source sets.
Task: Help me make progress on Draft reviewer clarification questions from the notes provided.
Context: The team needs follow-up questions that clarify review comments without sounding defensive.
Working fields:
- comment
- comment type
- known fact
- assumption
- missing information
- risk
- decision owner
- next action
Example pattern:
Field: Missing information
Good answer: Name the specific information to confirm, who can confirm it, and why it affects the next decision.
Rules:
- Use only the source notes provided.
- If information is missing, write "Needs confirmation".
- Keep the output concise and reviewable.
- End with the next best action.
Source notes:
[paste approved notes here]
Output format:
1. Original comment
2. What is unclear
3. Clarifying question
4. Why it matters
5. Decision neededMicrosoft 365 Copilot
Use goal, context, source, expectations, and output. For Obsidian context, use approved excerpts, Word summaries, OneDrive files, SharePoint pages, Teams context, or Outlook threads.
Goal: Help me make progress on Draft reviewer clarification questions.
Context: The team needs follow-up questions that clarify review comments without sounding defensive.
Source: Use the selected document, meeting notes, spreadsheet, email thread, SharePoint file, or pasted notes as the only source.
Expectations:
- Work with these fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
- Mark uncertain items as "Needs confirmation".
- Do not add facts that are not in the source.
- Separate known facts, assumptions, missing information, risks, and next actions.
- Summarize the top review questions for the team.
Output:
1. Original comment
2. What is unclear
3. Clarifying question
4. Why it matters
5. Decision neededConvert comments into a review decision log
The team needs a visible record of what changed, what did not, what still needs a decision, and who owns it.
ChatGPT GPT-5 family
Use an outcome-first prompt with the job, approved source material, constraints, and the exact artifact you want back.
I am working on Convert comments into a review decision log for an L&D system problem.
Goal: Help me turn the notes below into a practical next move.
Context: The team needs a visible record of what changed, what did not, what still needs a decision, and who owns it.
Use these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
Rules:
- Use only the source notes I provide.
- Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
- Separate known facts, assumptions, missing information, and next actions.
- Flag anything that needs requester, reviewer, leader, legal, compliance, LMS owner, or manager confirmation.
- Keep the output practical enough to review in a working meeting.
Source notes:
[paste approved notes here]
Return:
1. Decision item
2. Owner
3. Status
4. Scope impact
5. Due date
6. Final resolutionClaude 4 family
Use XML-style sections so context, source material, task, constraints, and output format stay separate.
<context>
I am working on Convert comments into a review decision log for an L&D system problem.
The team needs a visible record of what changed, what did not, what still needs a decision, and who owns it.
</context>
<source_notes>
[paste approved notes here]
</source_notes>
<task>
Turn the source notes into a practical next move using these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
</task>
<constraints>
Use only the source notes provided.
Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
Separate known facts, assumptions, missing information, risks, and next actions.
Flag anything that changes scope, ownership, evidence, risk, or decision rights.
</constraints>
<output_format>
1. Decision item
2. Owner
3. Status
4. Scope impact
5. Due date
6. Final resolution
</output_format>Gemini 3 family
Use a clear task, labeled input, and one example pattern. For Obsidian context, use approved excerpts, Drive exports, Google Docs, or NotebookLM source sets.
Task: Help me make progress on Convert comments into a review decision log from the notes provided.
Context: The team needs a visible record of what changed, what did not, what still needs a decision, and who owns it.
Working fields:
- comment
- comment type
- known fact
- assumption
- missing information
- risk
- decision owner
- next action
Example pattern:
Field: Missing information
Good answer: Name the specific information to confirm, who can confirm it, and why it affects the next decision.
Rules:
- Use only the source notes provided.
- If information is missing, write "Needs confirmation".
- Keep the output concise and reviewable.
- End with the next best action.
Source notes:
[paste approved notes here]
Output format:
1. Decision item
2. Owner
3. Status
4. Scope impact
5. Due date
6. Final resolutionMicrosoft 365 Copilot
Use goal, context, source, expectations, and output. For Obsidian context, use approved excerpts, Word summaries, OneDrive files, SharePoint pages, Teams context, or Outlook threads.
Goal: Help me make progress on Convert comments into a review decision log.
Context: The team needs a visible record of what changed, what did not, what still needs a decision, and who owns it.
Source: Use the selected document, meeting notes, spreadsheet, email thread, SharePoint file, or pasted notes as the only source.
Expectations:
- Work with these fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
- Mark uncertain items as "Needs confirmation".
- Do not add facts that are not in the source.
- Separate known facts, assumptions, missing information, risks, and next actions.
- Summarize the top review questions for the team.
Output:
1. Decision item
2. Owner
3. Status
4. Scope impact
5. Due date
6. Final resolutionStress-test the review workflow
The team wants to know whether the review brief and tracker will prevent late-stage rework.
ChatGPT GPT-5 family
Use an outcome-first prompt with the job, approved source material, constraints, and the exact artifact you want back.
I am working on Stress-test the review workflow for an L&D system problem.
Goal: Help me turn the notes below into a practical next move.
Context: The team wants to know whether the review brief and tracker will prevent late-stage rework.
Use these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
Rules:
- Use only the source notes I provide.
- Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
- Separate known facts, assumptions, missing information, and next actions.
- Flag anything that needs requester, reviewer, leader, legal, compliance, LMS owner, or manager confirmation.
- Keep the output practical enough to review in a working meeting.
Source notes:
[paste approved notes here]
Return:
1. What works
2. Missing review gate
3. Risk to check
4. Owner to confirm
5. One simplificationClaude 4 family
Use XML-style sections so context, source material, task, constraints, and output format stay separate.
<context>
I am working on Stress-test the review workflow for an L&D system problem.
The team wants to know whether the review brief and tracker will prevent late-stage rework.
</context>
<source_notes>
[paste approved notes here]
</source_notes>
<task>
Turn the source notes into a practical next move using these working fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
</task>
<constraints>
Use only the source notes provided.
Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
Separate known facts, assumptions, missing information, risks, and next actions.
Flag anything that changes scope, ownership, evidence, risk, or decision rights.
</constraints>
<output_format>
1. What works
2. Missing review gate
3. Risk to check
4. Owner to confirm
5. One simplification
</output_format>Gemini 3 family
Use a clear task, labeled input, and one example pattern. For Obsidian context, use approved excerpts, Drive exports, Google Docs, or NotebookLM source sets.
Task: Help me make progress on Stress-test the review workflow from the notes provided.
Context: The team wants to know whether the review brief and tracker will prevent late-stage rework.
Working fields:
- comment
- comment type
- known fact
- assumption
- missing information
- risk
- decision owner
- next action
Example pattern:
Field: Missing information
Good answer: Name the specific information to confirm, who can confirm it, and why it affects the next decision.
Rules:
- Use only the source notes provided.
- If information is missing, write "Needs confirmation".
- Keep the output concise and reviewable.
- End with the next best action.
Source notes:
[paste approved notes here]
Output format:
1. What works
2. Missing review gate
3. Risk to check
4. Owner to confirm
5. One simplificationMicrosoft 365 Copilot
Use goal, context, source, expectations, and output. For Obsidian context, use approved excerpts, Word summaries, OneDrive files, SharePoint pages, Teams context, or Outlook threads.
Goal: Help me make progress on Stress-test the review workflow.
Context: The team wants to know whether the review brief and tracker will prevent late-stage rework.
Source: Use the selected document, meeting notes, spreadsheet, email thread, SharePoint file, or pasted notes as the only source.
Expectations:
- Work with these fields: comment, comment type, known fact, assumption, missing information, risk, decision owner, next action.
- Mark uncertain items as "Needs confirmation".
- Do not add facts that are not in the source.
- Separate known facts, assumptions, missing information, risks, and next actions.
- Summarize the top review questions for the team.
Output:
1. What works
2. Missing review gate
3. Risk to check
4. Owner to confirm
5. One simplificationTake one messy review thread and tag every comment before responding to any of them.