The client sent comments in a document, added points during a call, and clarified one item later. Before revising, you need one list that reflects the current request.
OGAD (Off Grid AI Desktop) can help you turn saved feedback into a revision checklist with a local model. Collect the sources, identify the asset version, and ask for proposed actions with evidence. Review conflicts and approvals before treating the list as instructions for the next draft.
Download OGAD | Desktop releases
What would you like to do with Off Grid AI?
Have a feature or use case you would like us to support? Tell us what you want to do and which device you use.
Write to support@offgridmobileai.co, join our Slack community, or talk to us on Reddit.
For a small creative team, the useful result is a clear work list for one review round. It should show what to change, where, and which questions need an answer before the work can proceed.
What information belongs beside each comment?
Keep the asset, version, source, and date with the feedback. A comment without context can send you back to a problem that the latest version already solved.
Suppose a client reviews a product launch page. One document asks for a shorter introduction, a call adds a request for a clearer feature example, and a later note confirms that the current headline should stay.
A useful checklist separates those instructions:
| Field | What it establishes |
|---|---|
| Asset and version | Which piece the comment concerns |
| Location | The section or element to review |
| Requested change | The client's wording or checked interpretation |
| Source | Where the request came from |
| Status | Accepted, unclear, conflicting, or already resolved |
The model should not turn every comment into an accepted change. A question or suggestion may still need a decision.
How should you collect the feedback?
Save the relevant material in readable files. Copy the needed messages into dated notes, use checked call notes, and include the current brief when it defines the review's scope.
This workflow does not automatically gather comments from every service. You choose the sources and provide enough context to interpret them. Keep unrelated client details out of the working set.
Install OGAD and download a local text model. The free core file workflow is available on supported Mac and Windows computers. Release 0.0.54-beta.108 also has Linux beta packages.
Complete setup while connected. Use TXT, Markdown, DOCX, or text PDFs. For scanned comments or annotations embedded only in images, prepare a checked text version and keep the original for review.
How do you create the first revision table?
Attach a manageable set of feedback sources to a new chat. Ask for extracted requests before asking the model to combine or prioritise them.
- Select a downloaded local model in Models > Text.
- Open a new chat and use + > Attach files.
- Add the feedback notes and relevant brief.
- Wait for processing and inspect the extracted text.
- Ask for a source-backed request list.
The file-processing path supplies text to the model. It does not confirm that an annotation refers to the latest design or that a requested change has been approved.
Try:
Extract revision requests from these feedback sources. For each, identify the asset, version, location, requested change, date if present, and supporting wording. Keep questions, suggestions, and explicit approvals separate. Do not invent an owner, deadline, or implementation detail.
Check the table before turning it into tasks.
How do you combine duplicates without losing meaning?
Ask the model to group comments that clearly request the same change, while keeping each source reference. Review the groups because similar wording can refer to different parts of the work.
For the launch-page example, “shorten the opening” and “get to the point sooner” may concern the same introduction. “Shorten the page” could be a broader request and should not be merged automatically.
Use:
Group clear duplicate requests. Preserve the source references for every group. Flag comments that sound similar but may have different scope. Do not remove conditions or treat a broad request as resolved by a narrower one.
Then decide which grouped requests become checklist items. Keep ambiguous comments in a clarification section rather than burying them inside an action.
What if the feedback conflicts?
Show the conflict and ask for a decision. Do not let the model choose based only on file date or who wrote the longest comment.
For example, one note may ask for more product detail while another asks for a shorter page. Those could be compatible if the detail moves into a different section, but that is a proposed solution until reviewed.
Ask:
Identify possible conflicts in this checked request list. For each, quote the relevant comments and draft one neutral clarification question. Separate a true conflict from requests that may apply to different sections or versions.
Confirm the intended direction through your normal client process before completing dependent work.
How do you make the final checklist actionable?
Use one change per item and include the location, intended result, and review check. Keep the original source close enough that the person revising can inspect it.
A useful item might be: “Shorten the introduction while preserving the approved headline; check that the feature example remains clear.” That is more specific than “Improve the top section” when the sources support it.
Ask the local model:
Turn these accepted requests into a revision checklist. Give each item a clear action, location, intended result, and source. Put unresolved questions in a separate section. Do not add new creative directions or claim that an item is complete.
Review the draft for hidden assumptions. A checklist can still contain a plausible action that nobody asked for.
How should you check the revised work?
Use the approved checklist to review the new version item by item. Mark completion yourself against the actual deliverable. A generated list does not know that a designer changed a file elsewhere.
Keep a short note when a request is addressed differently from the original wording. Explain the agreed reason and source so the next reviewer understands the decision.
| Problem | Next action |
|---|---|
| A comment refers to an old version | Check whether it still applies |
| A question becomes a task | Move it to clarification until answered |
| Two requests were merged incorrectly | Split them and preserve their sources |
| The checklist adds a new requirement | Remove it or seek approval |
| The draft marks work complete | Verify the actual revised asset |
For a large set of comments, work by asset or review round. The model's context is limited, so smaller checked lists are easier to use than one unverified summary of the entire engagement.
Prepare the next revision round
Download OGAD and collect the feedback for one asset version. Extract the requests, resolve the conflicts, and finish with a checklist the team can review against the source.
Keep the model local for drafting after setup. Sharing the checklist or requesting clarification uses your normal communication tools. The useful result is a clearer revision round with fewer assumptions hidden in the work list.
Top comments (0)