A tidy summary can accidentally erase the most useful part of a review: the disagreement. "Start with a pilot" becomes "Ready to launch." A question about failure handling disappears under a reassuring conclusion. The document gets shorter, but the next person can no longer tell which actions were requested, which changes were made to the draft, or which decisions still need an owner.
A review record should preserve those distinctions. This worked example turns a short proposal and four comments into a revised paragraph, a traceable change table and an explicit list of open decisions. All inputs and outputs below are fictional. They illustrate a document workflow, not a recorded Orkas run, a deployed system or a completed review on this platform.
Give each input a stable identifier before asking an assistant to summarize it. Here, the source packet contains one proposal and four comments:
D0, original proposal: "Build a read-only weekly status digest. Roll it out to all workspaces once the summaries are ready. The sample digest includes customer names. Refresh the digest every week."
| ID | Review comment |
|---|---|
| C1 | Start with one volunteer workspace before considering a broader release. |
| C2 | Remove customer names from the sample digest. Use fictional record IDs. |
| C3 | If required inputs are missing, show what is missing. Do not call that summary complete. |
| C4 | Weekly refresh failure handling is unclear. Should the refresh pause after a failure? |
There is no recorded launch approval, no named pilot participant and no answer to C4. Those absences are part of the input. An assistant should carry them forward rather than filling the gaps with a plausible plan.
Orkas is an open-source, local-first desktop AI workforce. Commander coordinates specialist agents around a project's files and goals. In this example, the useful handoff is from source organization to a decision record and then to a readable revision.
Put D0 and C1-C4 in project files. Ask Commander to have OfficeWorker organize the comments into a table with source references, requested changes and unresolved questions. ContentWriter can then draft the replacement paragraph using that table. Keep both artifacts beside the original proposal so a reviewer can compare the wording with its source.
Project context, Library sources and reusable skills can help preserve the team's writing conventions across later reviews. Users can connect supported model providers with their own API keys or choose Orkas-managed models. Local-first work does not mean a remote model never receives supplied context: choose inputs and tools appropriately. The core application is free; model usage and optional hosted services may cost extra.
The instruction should describe the output and the authority boundary together:
Read D0 and C1-C4. Produce a replacement paragraph, a four-row change record and a list of open decisions. Cite the source ID for each change. Treat comments as requests, not approvals. Preserve the unanswered failure-handling question. Do not invent a pilot participant, launch date, reviewer sign-off or implementation result. Edit only the proposed document; do not execute the proposal or contact reviewers.
This is more useful than asking for a "final, approved plan." It leaves room for clear writing while requiring the assistant to expose uncertainty.
Replacement paragraph:
"The proposal is for a read-only weekly status digest, starting with an opt-in pilot in one volunteer workspace before any broader release is considered. This document does not authorize that release or identify a pilot participant. The sample digest uses fictional record IDs instead of customer names. If required inputs are missing, the digest must identify the missing information and label the summary incomplete. Weekly refresh remains proposed; the behavior after a refresh failure is unresolved and must be decided before implementation."
Change record for the illustrative revision:
| Source | Change in the replacement paragraph | What remains open |
|---|---|---|
| C1 | Replaces the all-workspace rollout statement with a proposed opt-in pilot. | Participant selection and release approval are not supplied. |
| C2 | Replaces customer names in the proposed sample with fictional record IDs. | Actual sample data still needs inspection before publication. |
| C3 | Requires missing information to be identified and the summary labeled incomplete. | The required-input list has not been specified. |
| C4 | Explicitly preserves the unanswered refresh-failure question. | Pause, retry or another response needs an owner decision. |
Open decisions: choose a consenting pilot participant; define the required inputs; decide refresh-failure behavior; record who can approve a broader release. None of these decisions is marked complete.
Compare each output row with its source. C1 should not become a launch approval. C2 should not become a claim that actual customer data has already been removed. C3 needs an input definition, and C4 still needs an answer. The revised paragraph is a proposed document, not evidence that software changed.
That distinction also matters when sharing the record for comments. A readable public document is not a reviewer sign-off. Keep actual approvals and implementation evidence separate, and revise the record when those facts arrive.
Prepared by ColunTina for the Orkas promotion campaign, with AI assistance. This is an original illustrative workflow guide, not an independent product review or a report of measured results.
comments (0)