Put the first draft of your status report within a macOS shortcut

Give the report a cutoff and a source of truth

Before opening the overlay, define the reporting period and cutoff time. Copy only the notes you are allowed to share, removing personal or confidential detail that the draft does not require. Include a reference identifier beside each item so you can find the original task or decision again. The model should reorganize this material, not infer project health from your tone.

Keep completed work, current blockers, future risks and decisions requested in separate source lines. “Testing is complete” and “testing should finish tomorrow” must not collapse into the same status. If an owner, date or acceptance result is missing, make that absence explicit in the input.

Produce two views from the same facts

The status report answers what changed, what matters and what decision is needed. The risk log records what might happen, the trigger to watch and the response owner. A problem already occurring belongs in the blocker section; its possible downstream effect can also be a risk, but the two statements should be distinguishable.

Consider fictional inputs: task T-18 is complete and accepted; task T-19 is waiting for an external test environment; the team targets a demonstration on 12 October, but the date is not committed. The following records show how to preserve that difference. These are exercise inputs, not a real project or measured result.

Keep a reusable reporting prompt

Save the prompt with your reporting template outside the model conversation so it remains easy to inspect and change. Choose available agents in Colay if you want separate checks for missing decisions and ambiguous dates. There is no need to request many rewrites when a single source-bound draft already serves the report.

Create two drafts from these project notes only: [notes with reference IDs]. Reporting period and cutoff: [period]. First, a concise status update: completed, changed, blocked, next and decisions needed. Second, a risk log: cause, possible event, impact, trigger, response, owner and review date. Preserve the difference between actuals, targets and commitments. Map every factual line to an input ID. Mark missing owners or dates as unknown. Do not invent progress percentages, probabilities, approvals or completion. List contradictions separately for my review.

Use the shortcut for drafting, then return to the original tool

The shortcut is configurable in Settings. Opening the overlay does not extract the current screen, synchronize tickets or send the report. This matters because the final tool remains the place where owners, versions and distribution are managed. Keep Colay’s draft step explicit so nobody mistakes an attractive summary for a system-of-record update.

1. Open Colay’s macOS overlay with the default ⌘⇧K, or your configured shortcut.
2. Supply the prepared notes and prompt; check that the intended reporting period is present.
3. Compare the output with the original notes, especially dates, owners and whether work was accepted.
4. Copy the reviewed draft into your normal report or risk register and complete its approval process.

Check the report by its decisions, not its polish

For each red or amber item, ask whether the reader can identify the next action and the person needed to take it. For each risk, ask what observable trigger would change the response. Avoid precise percentages unless they come from a defined, supplied measurement; a model-generated number can make uncertainty look resolved.

Keep a short correction log: dates strengthened into commitments, missing owners hidden by passive language, or blockers softened into generic progress. Use it to refine the next prompt. The useful improvement is a report that requires fewer factual repairs while retaining the evidence trail, not an unsupported claim that reporting now takes only one keystroke.

Questions, answered