E-commerce Improvements · SaaS & Integrations · Release Reliability. Discuss Your Improvement →
AI and Dev Tools

How I use ChatGPT to review project emails and documents

How Akash Singh uses ChatGPT to review project threads and shared documents, distinguish proposals from decisions and prepare source-linked answers.

4 min read
Context → evidence → decision
  • Research
  • Documents
  • Email
  • Code review
  • Outreach
Illustration of the workflows discussed in this article. Original editorial artwork; not a product screenshot.
Back to Blog

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

  1. Define the question

    Name the decision and the source that controls it.

  2. Read authorised sources

    Check the current thread and document versions.

  3. Compare the evidence

    Keep requirements, proposals, reports, tests and acceptance distinct.

  4. Review the finding

    Resolve conflicts or ask for a decision.

  5. Take the permitted next step

    Check the outcome and preserve the evidence.

Missing or conflicting evidence? Hold the action, clarify the question, then return to the sources.
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.
My review workflow: evidence first, then the next authorised step. An editorial explanation, not a diagram of product architecture.

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.

Akash Singh — CTO and Co-Founder, CV Infotech

Akash Singh

View full profile

CTO and Co-Founder, CV Infotech · Gurugram, India

Akash has been building Websites, Web Apps, SaaS and Mobile Apps for clients in the USA, Europe, Australia, and Canada since 2012. He leads a 100% in-house team and personally manages every client relationship and technical decision. Francisco Escobar has worked with him since 2012. Steven has trusted the team with his AI platforms since 2019. 512 verified 5.0 reviews on Freelancer.com.