Guide
Build a weekly review from work history
Group dated evidence by project, separate progress from activity, and turn the reviewed facts into a short update. Keep gaps visible.
A weekly review should explain what changed, what finished and what needs attention. A list of apps opened or meetings attended does not establish any of those things. Start with work records, then check what they actually support.
Define the week and audience
Specify the start date, end date and timezone. “Last week” could mean a calendar week or the last seven days. Choose the projects to include and who will read the result: your own planning notes, an internal team update or a client recap.
Keep private or unrelated projects out of a shared update. A record that is useful to you is not automatically appropriate to send to someone else.
Gather evidence in four sections
Review my work from [start date] through [end date] in [timezone]. Group it by project. For each project, list completed work, changed decisions, open actions and uncertainties. Include the source and date for important claims. Mark gaps in the record.
| Section | What belongs here |
|---|---|
| Completed | A finished result supported by the record, such as a reviewed delivery or confirmed release. |
| Changed | A decision or requirement that replaced an earlier plan, with the supporting source. |
| Open | An unresolved question or commitment, with its owner and date if specified. |
| Uncertain | Missing records, ambiguous ownership or conflicting evidence to check. |
Reading a specification, discussing a fix and shipping it are different events. Ask for completion evidence when the distinction matters. No later mention does not prove a task remains undone.
Correct the first draft against the record
Fictional practice example: the records and draft below are invented to show the review process. They are not a customer result or output from a tested Cachejay session.
- Monday, October 12: a design note proposes a new checkout error message.
- Wednesday, October 14: a coding session records a completed implementation and passing local tests.
- Friday, October 16: a project note says release is waiting for approval from the owner.
A draft saying “Shipped the checkout improvement” goes beyond that evidence. The corrected version is: “Implemented and locally tested the checkout error message. Release is waiting for owner approval.”
Put implementation under Completed and release approval under Open. Do not invent a release date or treat the local test as proof of a production deployment. Keep the dated references beside the corrected statement.
Write for the reader after checking the facts
Using the reviewed facts above, draft an update for [audience]. Include what changed, what is blocked and the next planned step. Leave out unrelated projects and private material. Do not turn uncertain items into completed work.
An engineering teammate may need the failing test or dependency. A client may need the consequence and the decision you need from them. The evidence stays the same while the explanation changes.
For your own planning, ask:
Which open actions need a decision from me? Separate my commitments from other people's work. Keep owners and due dates only where the evidence states them. List anything I need to confirm.
Finish with a small next-action list. Add an offline conversation or unrecorded task explicitly if it changes the review, and identify it as your correction.
Where Cachejay fits
Cachejay organizes captured work into project context and summaries that connected AI apps can retrieve. Start with the relevant project or week, then check underlying evidence for important claims. See daily and weekly summaries and the freelancer workflow.
Capture gaps, exclusions and retention limits mean the record may be incomplete. Captured text and notes sync to your account by default; hosted summaries and connected assistants can process that text. Review capture and cloud controls before choosing which work to include.
Try one week you remember well. The goal is a short, corrected update that you can stand behind—not a complete-looking account of work the system never saw.