A project question rarely arrives with all the history attached. It may refer to a previous email, a shared document, a chat message or a change that was discussed but never approved.
As the co-founder and CTO of CV Infotech, I use ChatGPT to help gather that context and turn it into something I can review. The useful output is not simply a shorter version of the conversation. It is an answer that shows what is agreed, what changed and what still needs a decision.
Begin with the question and the authoritative source
I start by defining what I need to know. “Summarise this project” is broad. “Check whether the current scope document includes the client's latest approved changes” gives the review a clearer purpose.
Next, I identify which source controls the answer. A shared scope document may define the approved requirement. A later email may amend it. A developer update may report implementation, but that is different from approval or QA evidence.
When those sources disagree, I want the conflict stated explicitly. The assistant should not decide that the most recently edited summary is automatically correct.
Read the latest thread before preparing a reply
Email review needs the current conversation, not just an individual message. Someone may already have answered the question. A later reply may withdraw a request or narrow it.
I ask for the actual sender, the relevant recipients and any intervening reply to be checked before a response is prepared. This avoids duplicate answers and reduces the risk of sending information to people who were not part of the authorised discussion.
Unread status is not a reliable definition of unfinished work. A message can be read and still need an answer. An unread acknowledgement may need none.
Separate five different kinds of information
I find it useful to distinguish a requirement, a proposal, an implementation report, a QA result and client acceptance.
A requirement says what should be delivered. A proposal asks for a change. An implementation report says someone believes the work is done. A QA result records what was actually tested and what happened. Client acceptance is a separate decision by the client.
Combining these into a single “complete” status hides important work. My review asks for these distinctions to remain visible, especially when the next step affects scope or a client-facing document.
Evidence before action
- Define the question
Name the decision and the source that controls it.
- Read authorised sources
Check the current thread and document versions.
- Compare the evidence
Keep requirements, proposals, reports, tests and acceptance distinct.
- Review the finding
Resolve conflicts or ask for a decision.
- Take the permitted next step
Check the outcome and preserve the evidence.
- Approved requirement
- What was authorised for delivery.
- Proposed change
- A suggestion awaiting a decision.
- Reported implementation
- A claim about work performed.
- Tested result
- Observed behaviour within the test scope.
- Client acceptance
- A separate decision by the client; testing does not establish acceptance.
Make the document useful to the person implementing it
A document can look detailed while still leaving practical questions unanswered. What happens when an operation fails halfway through? Who owns a decision? Is a number an estimate or an agreed limit? What evidence will show that the requirement is met?
I use the assistant to find those gaps and propose clearer wording. Then I review the findings and require the proposed changes to be checked against the original discussion. The assistant should not fill an evidence gap with a new promise just to make the document look complete.
For an implementation handoff, I want the agreed behaviour, the exceptions, the open questions and the acceptance checks in separate places. That helps the team see what to build now and what must wait for a decision.
A prompt structure I use
Review the latest relevant thread and the current shared document. Identify the approved requirements, later corrections, unresolved conflicts and unanswered questions. Link the evidence for each material finding. Do not create new scope, pricing or deadlines. If a conclusion cannot be supported, say what decision is needed. Keep the summary short and preserve the detailed findings in the working document.
This is a starting structure, not a guarantee. The connected sources still need to be available, and I still need to check the output.
Review again before sharing
For an important document, I ask for a second pass against the original evidence. That pass should look for missing conditions and contradictions, not merely improve the writing.
I also check the version being shared. A link to an updated document and an older attached PDF can create confusion. The recipients need to know which version is current and whether an earlier attachment has been superseded.
Before sending, I require the intended account and recipients to be verified, followed by a checked sent record. A draft, a send attempt and a confirmed sent message are different states.
What I would recommend to another founder
Start with one active project and one specific question. Give the assistant access only to the sources needed for that review. Ask for a concise answer with evidence and an explicit list of uncertainties.
The value comes from making the discussion easier to evaluate. You should finish with a clearer decision, not just another document to read.
Read the full founder experience and practical guide to ChatGPT dots.